Триколор 

Настройка и установка контроллера домена. Поднимаем домен Active Directory (AD). Настройка контроллеров домена для работы в разных подсетях

В Windows Server 2016 появились новые довольно интересные новые функции, такие как временное членство в группах AD, Privileged Access Management и т.д. Постараюсь описать их более подробно в следующих статьях. В этой статье я покажу, как установить домен Active Directory в Windows Server 2016. Для установки AD, сервер по минимальным требованиям должен соответствовать следующим условиям:

Процессор :

  • 64-битный процессор с частотой не менее 1,4 Ггц
  • поддержка NX, DEP, CMPXCHG16b, LAHF/SAHF, PrefetchW, Second Level Address Translation (EPT или NPT)

Память

  • не менее 512 Мб (для Server Core и Nano редакций), 2 Гб для версии Windows Server с GUI
  • поддержка ECC (Error Correcting Code) или аналогов

Дисковый контроллер и требования к месту:

Дисковый контроллер для установки Windows Server 2016 должен быть совместим со спецификацией PCI Express. Windows Server 2016 не позволяет использовать диски ATA/PATA/IDE/EIDE для загрузки, хранения файла подкачки или дисков с данными

Минимальный размер раздела на систему: 32 Гб

Сетевой адаптер :

  • сетевой адаптер Ethernet с пропускной способностью не менее 1 Гб/с
  • Совместимость с архитектурой PCI Express
  • поддержка PXE (-boot Execution Environment)
  • Желательна (но не обязательно) поддержка сетевой отладки (KDNet)

В этом примере я использую виртуальную машину, запущенную на сервере VMWare ESXi, на которую и уставлена Windows Server 2016.

1) Войдите на сервер под локальным администраторов. На сервер кроме роли также будет установлена служба DNS . Изменим настройки сетевого интерфейса, указав в качестве первичного DNS сервера собственный IP адрес севера или адрес 127.0.0.1.

2) Затем откройте Server Manager, нажав на соответствующий значок или выполнив в консоли PowerShell команду .

3) В окне Server Manager нажмите

4) В окне мастера добавления ролей и компонентов нажмите Next .

5) В следующем окне нажмите Next

6) Т.к. установка выполняется на локальный сервер, в следующем окне оставьте переключатель в исходном положении и нажмите Next

7) В следующем окне в списке ролей выберите Active Directory Domain Services . В открывшемся окне появится список ассоциированных компонентов, которые должны быть установлены вместе с ролью ADDS. Нажмите кнопку Add features , а затем Next .

8) В списке компонентов уже должны быть отмечены требуемые для установки компоненты. Нажмите Next .

9) В следующем окне приведено небольшое описание роли AD DS . Нажмите Next.

10) Ознакомьтесь со списком выбранных для установки ролей и компонентов. Для начала установки нажмите кнопку Install .

11) На экране будет отображаться текущий статус процесса установки

12) После окончания установки, нажмите на ссылку

13) Запустите мастер настройки Active Directory. В моем случае я устанавливаю новый лес AD. В том случае, если вы добавляете дополнительный контроллер домена в существующий домен, выберите соответствующую опцию. Я же выбираю опцию Add a new forest и указывают FQDN имя домена (test.net).

14) В следующем окне нужно указать функциональный уровень домена и леса AD. Я выбрал последнюю версию схемы AD – Windows Server 2016 . Кроме того, этот сервер будет выступать сервером DNS и являться Global Catalog. Также нужно указать пароль администратора для входа в DSRM режим.

15) Т.к. мой сервер будет первым DNS сервером в лесу, нет необходимости настраивать делегацию DNS. Поэтому просто нажмите Next .

16) NETBIOS имя домена оставим без изменений (TEST)

17) На следующем экране нужно указать путь к каталогам NTDS, SYSVOL и LOG . Мы оставим все пути по-умолчанию, предполагая, что все папки будут храниться в каталоге системного диска C:\Windows.

18) На следующем экране можно ознакомиться со списком выбранных настроек. Если все OK, нажмите Next, если нет – вернитесь назад и внесите изменения.

20) Запустится процесс установки контроллера домена

21) После окончания установки, сервер автоматически перезагрузится. Войдите на сервер под учетной записью администратора домена.

22) После входа, запустите привилегированную сессию powershell и выполните команду . Откроется окно центра администрирования Active Directory (Administrative Center). Можно начинать управлять ресурсами домена

23) С помощью следующих команду можно узнать текущий функциональный уровень домена и леса команд Get-ADDomain | fl Name,DomainMode и Get-ADForest | fl Name,ForestMode

Прежде всего, не удержусь от лингвистической ехидности – настроить домен, или поднять домен? Всё ж таки настройка и поднятие – создание с нуля – домена далеко не одно и то же. Настройка – доведение до ума уже существующего домена с целью заставить его соответствовать нуждам пользователей. А вот поднятие домена – занятие особенное. Можно сказать – целое приключение в духе исследователей неизведанных миров…

Что такое «домен»?

Чтобы понять, как поднять домен, следует – что вполне очевидно – представлять себе, что такое домен, с чем его едят (и едят ли) и нужен ли он вообще. Сие банальное рассуждение видится актуальным по той простой причине, что зачастую приходится сталкиваться с ситуациями, когда человек хочет сделать что-то, о чём не имеет представления, но о чём знает, что это – штука крутая и модная. Я лично однажды слышал утверждение в духе: «У нас же серьёзная компания! Нам просто необходим домен!». А между тем в этой компании, в серьёзности коей я ни мгновения не сомневаюсь, имелось всего десять компьютеров и задачи на них возложены максимально примитивные – печатная машинка и Интернет. Для такой сети домен – однозначно пятое колесо. Но что же такое домен?
Путём прочтения умных книг1 выясняется, что домен – это не самостоятельное понятие. Домен – есть одно из основных средств формирования пространства имён каталога Active Directory. Наряду с доменами таковыми средствами формирования являются административная иерархия и физическая структура сети. Причём все три средства могут использоваться как в самостоятельном виде, так и в комплексе. В уже упомянутой умной книжке читаем, что операционные системы Windows традиционно использовали понятие «домена» для логического объединения компьютеров, совместно использующих единую политику безопасности. И далее по тексту – домен традиционно выступает в качестве основного способа создания областей административной ответственности.
Чтобы двигаться дальше нелишним, я полагаю, будет привести и некое определение той самой Active Directory, в рамках коей живёт понятие «домена». Каталог (он же – Active Directory на чужеземном языке) есть глобальное унифицированное хранилище информации об элементах сетевой инфраструктуры. Элементами же сетевой инфраструктуры являются пользователи, ресурсы (общие папки, принтеры и т.п.), сетевые службы (почтовые сервисы, веб-сервисы, сервисы базы данных и т.п.), компьютеры и прочее. Собственно, назначение каталога – дать пользователю возможность использовать все эти элементы сетевой инфраструктуры без необходимости знать точное расположение каждого элемента и выстраивать политику взаимодействия с этим элементом индивидуально.

А теперь переведём это всё на русский язык.
Итак имеем сеть. Локальную, разумеется, хотя Интернет в этом случае мало чем отличается от локалки. В ней есть куча пользователей, какие-то сетевые папки (в разной степени закрытые для доступа), принтеры, факсы, сканеры, компьютеры (разные по предназначению). В этой сети крутится пара баз данных разного предназначения. Пользователи этой сети гуляют по Всемирной Паутине (опять же, с разной степенью ограничений). Ну и ещё куча всякого разного, что способствует плодотворной работе пользователей сети и их же не менее плодотворному отдыху. Вполне очевидно, что всё это сетевое разнообразие должно быть приведено к общему знаменателю. Хотя бы для удобства управления этим сетевым хозяйством. В конце концов, представьте себе необходимость держать на контроле взаимные связи всего перечисленного со всем перечисленным же. Представили? Вот и у меня не получилось.
Но такие взаимные связи и такой общий знаменатель обеспечивается как раз с помощью Active Directory (будем для краткости далее её обозначать буквами АД). Вся структура всех взаимных связей между элементами нашей сети и вообще вся сетевая инфраструктура и иерархия хранится и учитывается именно в АД. Перед тем, как пользователь (или сервис сети) обратится к какому-либо ресурсу сети он осведомится в АД, как именно ему с этим ресурсом положено взаимодействовать.

А нужен ли нам домен?

Итак, перед нами встаёт первый вопрос – а стоит ли огород городить? Скажем, в Государственной Публичной Научно-Технической Библиотеке (ГПНТБ) имеется весьма обширный каталог содержащихся в ней изданий с рубрикатором, системой поиска и чётко заданными правами доступа к изданиям – сюда всем, а сюда только от четвёртого курса и выше. Если принять фонд ГПНТБ за сетевые ресурсы, то её каталог вполне наглядно иллюстрирует АД. И необходимость этого каталога для ГПНТБ очевидна. Но вот нужен ли такой же каталог для книжной полки, на которой стоит всего пара десятков книг? Найти нужную публикацию в ГПНТБ и воспользоваться ей в обход каталога ГПНТБ вы не сможете – даже если вам удастся пробраться непосредственно в хранилище, скорее всего, вашу мумию найдут через пару тысячелетий в трёх тысячах полок от заветной публикации. Но если мы имеем дело с книжной полкой, то проще подойти к ней и найти нужную книгу, окинув всю полку взглядом и не мороча себе голову с каталогом. Отсюда и вытекает первый вопрос – нужна ли нашей сети АД?
Критериев несколько. Во-первых, полномочия доступа пользователей к сетевым ресурсам. Во-вторых, количество этих самых ресурсов и пользователей. В-третьих, наличие в сети таких сервисов, как базы данных, почтовые сервисы, службы документооборота и тому подобное.
Ели в вашей сети имеется с десяток пользователей, пара сетевых папок, в которые каждый сваливает всё, что наработал, не скрывая своих документов от коллег. Если у вас имеется всего один сетевой принтер, на котором все и печатают, и кроме общего доступа в Интернет ничего больше нет. Если каждый ваш пользователь вот уже вторую сотню лет работает на одной и той же машине, которую привык считать своей и расставаться с которой не собирается ещё триста лет – смело забрасывайте идею поднятия АД в самый пыльный угол. Просто потому, что такой сети АД не нужна – под АД требуется выделенный (и достаточно мощный) сервер, ставить который ради учёта двух сетевых папок и одного принтера просто экономически нецелесообразно.
Если же в вашей сети живёт триста пользователей, да ещё разбитых по разделам, для каждого из которых имеется свой набор сетевых папок. Если вы используете сетевую версию 1С и весь документооборот ведёте через неё. Если вы содержите веб-сайт на серверах вашей компании и каждый отдел имеет свою почту – вам без АД не обойтись никак. Вы, как админ, быстро сойдёте с ума, если попытаетесь администрировать такую сеть без использования АД. И никогда не добьётесь успеха в этом безумном начинании.

Сколько и каких доменов нам надо?

Предположим, мы убедились, что АД нам нужна. Стало быть, необходимо её развернуть и настроить. Вот тут-то и приходит очередь домена.Дело в том, что АД не только содержит в себе информацию обо всех элементах сетевой инфраструктуры, но и описывает иерархию этой структуры. Вот с этой иерархией нам и надо определиться. В конце концов, чтобы совладать с сетью из трёхсот компьютеров и миллиона сетевых служб, её надо разбить на некие логически завершённые части и совладать с этими частями. Divida et impera!2 Таким образом, нам надо решить, как мы будем делить нашу сеть и будем ли мы её делить вообще.
Предположим, в нашей фирме имеется пять отделов, работающих в тесном контакте и содержащих не более четырёх сотрудников на отдел. Руководство, разумеется, считаем особняком. Сетевые папки, 1С, Exchange для документооборота и в качестве почтового сервиса, пара общих баз данных на SQL. АД нужна, но как её упорядочить? Вполне очевидно, что в данном случае делить сотрудников (и сетевые ресурсы) на группы внутри АД нелогично – их немного и они слишком тесно между собой контактируют.
Второй вариант – та же самая компания, но два из пяти отделов расположены в отдельном офисе на другом конце города. Связь – через Интернет (а как ещё?). Всё остальное – то же самое. Тут уже сложнее – нужно как-то сделать так, чтобы и сама АД была поделена на две части (по одной в каждом офисе), но объединена воедино.
Третий вариант – тридцать отделов в крупной фирме, каждый из которых в значительной мере независим от остальных. Вполне очевидно, что в данном случае каждому отделу компании должна соответствовать своя АД, полностью описывающая его сетевую инфраструктуру. Вместе с тем, все эти АД должны объединяться воедино в рамках предприятия.
Данные три примера несколько академичны, но хорошо описывают классические способы построения АД и создания доменов. Выше мы уже писали, что домен есть лишь средство формирования пространства имён АД – средство упорядочения АД. Как правило, домены создаются исходя из административной модели предприятия, которое обслуживается нашей сетью, или же по территориальному признаку – исходя из территориального упорядочения сети. И что же мы видим?
В первом варианте фирма представляет собой единое целое как с точки зрения административной, так и территориально. Кроме того, она не столь уж и велика. Для системного администратора это значит, что в ходе развёртывания АД будет создан один единственный домен, обслуживающий всю сеть фирмы в целом. Никакого деления в данном случае не будет – оно не нужно.
Во втором варианте фирма представляет в административном видении единое целое, но разнесена в пространстве географически. Имеет смысл разделить ЛВС этой фирмы по территориальному признаку – по количеству офисов. В этом случае в рамах развёртывания АД поднимается не один единственный домен, а лес доменов. Во-первых, свой домен у головного офиса. Во-вторых, свой домен у филиала. Ну и, наконец, корень леса – головной домен, которому будут принадлежать домены каждого из офисов. Соответственно, логично будет расположить корень леса и домен головного офиса в самом головном офисе, а домен филиала – в филиале (масло масляное, честное слово!). Соответственно, домен головного офиса будет согласовываться с корнем леса (его ещё принято называть Глобальным Каталогом – ГК сокращённо) по линиям ЛВС головного офиса, а домен филиала – через Интернет. Если же Интернет по разным причинам пропадёт, то домен филиала продолжит нормально функционировать и дождётся возобновления связи для согласования с ГК (такое согласование зачастую называют репликацией). Если бы у нас в данном случае был не лес, а отдельный домен (а такая схема тоже возможна), то обрыв Интернета парализовал бы начисто работу филиала, что не есть хорошо.
И, наконец, третий вариант. В этом случае территориально фирма едина, но административно – достаточно жёстко разделена. И по этому же самому признаку имеет смысл поделить ЛВС. Тогда в рамках развёртывания АД каждому отделу фирмы поднимается свой домен и, для объединения их всех в лес, создаётся ГК. В таком случае работы системного администратора над сегментом одного отдела фирмы никак не скажутся на работоспособности всех остальных отделов. Напротив, если бы у нас здесь был один самостоятельный домен, то падение какого-нибудь важного сервера могло парализовать работу всего предприятия, что едва ли приемлемо.
Разумеется, все описанные выше модели могут быть скомбинированы в зависимости от структуры конкретного предприятия и вам, как системному администратору, предстоит решить, какую именно схему АД строить и из каких частей она будет состоять. Тем не менее, практика показывает, что чаще всего ЛВС мелкого и среднего бизнеса построена по модели АД с одним самостоятельным доменом. И именно об этой модели мы и будем говорить в дальнейшем.

Контроллер домена.

Итак, у нас имеется локальная вычислительная сеть (ЛВС) с каким-то количеством серверов, но не объединённая АД. Мы решили развернуть в этой сети АД и поднять один самостоятельный домен. Стало быть, нам понадобится некий сервер, который будет содержать в своих железных недрах копию АД и станет всему головой. Это – контроллер домена. Так какой же он – контроллер домена?
Прежде всего, это должен быть именно сервер. То есть, на нём должна быть установлена серверная операционная система. Замечание кажется излишним, но… Напомним, что в сети на основе рабочих групп каждый компьютер – сам себе голова. Как правило, выделенных серверов в такой сети нет и понятие «сервера» там – исключительно номинальное. То есть, вполне возможно, что за нашим предполагаемым сервером сидит какой-то сотрудник и увлечённо строчит свои отчёты. При этом в качестве ОС у него, скорее всего, стоит Windows 2000 Professional или Windows XP Home Edition. На такой ОС домен не поднять. Нам нужен именно сервер с серверной ОС. Поскольку мы говорим о доменах Windows, то в качестве серверной ОС мы можем рассматривать MS Windows NT, MS Windows 2000 Server и MS Windows 2003 Server. При этом есть подозрение, что ОС MS Windows NT несколько устарела. Я бы даже сказал – тотально устарела, так что домены на её основании здесь рассматриваться не будут.
Второе замечание касается мощности той машины, которая станет контроллером домена (КД). Аппаратное обеспечение следует подбирать, исходя из основных соображений по серверам. К примеру, файловый сервер должен обладать объёмистыми дисками, хорошо защищёнными и достаточно быстрыми, чтобы быть в состоянии с приемлемой скоростью отдавать всем желающим в любой момент любые файлы любого объёма. Зато, к примеру, мощный процессор (и высокая вычислительная мощность, соответственно) ему без нужности – он же ничего не считает. А вот сервер базы данных, напротив, к объёму диска и его скорости не очень чувствителен. Объём передаваемой информации при работе с базой данных, как правило, не так уж и велик. Объём самой базы может быть огромен, спору нет, но в каждый момент времени из этой базы требуется лишь маленькая её часть. А вот задача найти эту часть и соответствующим образом её обработать и отдать клиенту (провести транзакцию) возложена как раз на вычислительные мощности сервера. Причём таких транзакций может в каждый момент времени потребоваться много и одновременно. Таким образом, на роль сервера базы данных требуется машинка с могучим процессором (и лучше не с одним) и приличным объёмом оперативной памяти. Сервер печати принимает по сети задание печати (которое, заметим, может значительно превышать объём печатаемого файла) и отдаёт это задание принтеру. Определённая вычислительная мощность на это уходит, но не столь большая, как у сервера баз данных. Иными словами, сервер печати стоит где-то между сервером базы данных и файловым сервером.
Короче, совсем коротко – аппаратное обеспечение каждого сервера выбирается на основании задач, какие будут возложены на этот сервер. Но какие же задачи будут возложены на наш КД? Как уже говорилось, на КД хранится копия АД. И эта копия АД описывает всю нашу сетку и все взаимодействия между её элементами. А это значит, что данная копия АД – едва ли не самое ценное в нашей сети. Собственно, для системного администратора это и есть самое ценное. Если вы обрушите файловый сервер, ваш админ вас отругает, если вы обрушите КД – он вас убьёт с особой жестокостью и цинизмом. Таким образом, наш КД должен быть надёжно защищён от всего, включая прямое попадание атомной бомбы. Прежде всего, речь идёт о дисках КД. Разумеется, даже самый крутой современный диск тут не годится (хотя можно, очень даже можно). Для КД подходит только и исключительно RAID. Самый лучший, разумеется, но рассматривать разные модели RAID нам тут не с руки – не наша тема.
Далее, оперативка и процессор. Коль скоро наш КД содержит в себе всю инфраструктуру нашей сети, то эта инфраструктура (наша АД) представляет собой базу данных. Несколько специфическую, но тем не менее. А это значит, что КД должен уметь обработать данные этой базы и предоставить их клиенту в любой момент времени. То есть, провести транзакцию. Причём следует помнить, что клиенты трясут КД на предмет этих самых данных ежесекундно. Таким образом, на КД ложится функция сервера базы данных, да ещё и интенсивно использующегося всеми членами сети. Отсюда повышенные требования к процессору и памяти. Конкретные рекомендации предлагать не буду, но отмечу, что лично я в настоящий момент ищу возможности приобрести на сеть из 30 машин КД с двумя процессорами на 3ГГц и с не менее 4Гб оперативной памяти. И опасаюсь, что это будет впритык…
Далее, сетевое оборудование. Собственно, сетевая карточка. Пропускная её способность должна быть велика и с лихвой перекрывать потребности сети. С другой стороны, ставить гигабитную карточку в КД при наличии сети на витой паре категории 5 со скоростью 100 мегабит едва ли будет разумно – КД станет отдавать информацию настолько быстро, что клиенты просто не справятся с ним. Или же, напротив, сетевой адаптер приспособится к скорости ЛВС и станет работать на 100 мегабитах, так что всё преимущество гигабитной сети пропадёт. А вот поставить две сетевые карты, к примеру, и настроить их на параллельную работу, может оказаться вполне разумным шагом.
Материнская плата должна быть самой надёжной. Достаточно порыться в Интернете и выяснить, чьи изделия этого класса сейчас пользуются признанием, и принять решение. Видеокарта и звуковая карта для сервера, вполне очевидно, без надобности.
Блок питания. Одна из самых важных частей любого вообще компьютера. От его мощности зависит, насколько сильно он будет греться при работе (а ведь сервер включён круглосуточно семь дней в неделю!) и насколько стабильным он будет при возможных экивоках нашей электрической сети. Сильно сомневаюсь, что стандартный блок на 250 ватт пригоден для сервера. Но даже и при мощном блоке питания присутствие ИБП обязательно. В конце концов, наши энергетики способны на всё и было бы просто обидно из-за их экспериментов потерять самое ценное в сети – её голову.
Про такие мелочи, как отдельное помещение с кондиционированием и ключик, не позволяющий непосвящённым прикоснуться к этой святыне ЛВС, я не говорю – настолько очевидны эти вещи.

Итак, сервер куплен, подключён, настроен, находится в сети (в рабочей группе – другого пока нет) и видит прочие машины. Установлена ОС, всё готово. Или не всё?
Домен есть одно из средств формирования пространства имён в АД. И в локальной сети каждая машина задаётся своим именем и своим IP-адресом. Нетрудно сообразить, что именно об этих именах и идёт речь. И тогда встречный вопрос – как имя машины относится к её IP-адресу? Ответ известен любому системному администратору – как в базе DNS написано, так и относится. Соответственно, в нашей сети должна быть такая база и должна быть запущена служба, способная с этой базой работать. Проще говоря, в нашей сети должен быть DNS-сервер. И на этом сервере должен быть зарегистрирован наш будущий КД. Причём, что важно, все сетевые интерфейсы нашего будущего КД должны иметь статические IP-адреса. При этом на самом КД должен быть прописан адрес предпочитаемого DNS-сервера, т.к. в процессе развёртывания АД пространство имён будет создано на основе базы DNS этого сервера и сам наш КД будет зарегистрирован на этом сервере. Надеюсь, не требует специального уточнения, что этот DNS-сервер должен реально присутствовать в сети и работать.
Если же DNS-сервера в сети ещё нет, имеет смысл организовать его на нашем будущем КД, совместив, таким образом, эти две функции в одном сервере. В принципе, на стадии установки контроллера домена Windows способна проверить наличие и работоспособность существующих в сети DNS-серверов. Если указанный в параметрах сетевого подключения DNS-сервер будет работоспособен и сможет доказать своё соответствие требованиям АД к DNS-серверам, то Windows начнёт построение домена с использованием этого сервера. Если же удовлетворяющего требованиям АД сервера обнаружено не будет, Windows способна автоматически создать и настроить с нуля новый DNS-сервер, который будет физически совмещён с вновь создаваемым контроллером домена.

Этапы установки контроллера домена

Для создания контроллера домена необходимо иметь готовый сервер с установленной и настроенной ОС MS Windows 2003 Server. В меню Administrative Tools (Администрирование) находим пункт Configure Your Server (Управление данным сервером) . Из открывшегося окна можно легко и просто запустить Мастер Установки Active Directory (Active Directory Installation Wizard).
Работа мастера установки АД осуществляется по четырём сценариям:

1. Создание нового леса доменов;

2. Создание нового дерева доменов в рамках существующего леса доменов;

3. Создание нового домена в рамках существующего дерева доменов;

4. Установка дополнительного контроллера домена в уже существующем домене.

Вторая и третья схемы используются в случаях, когда сеть организационно имеет более одного домена. Как мы договорились выше, мы рассматриваем случай установки самого первого домена и, поэтому, вторая и третья схемы нам не подходят. Четвёртая схема применяется при установке резервного контроллера домена и о ней мы здесь говорить не будем. Таким образом, на этой стадии поднятия домена следует выбирать первый сценарий. При этом словосочетание «лес доменов» не должно никого пугать. В конце концов, любой лес начинается с одного – самого первого – дерева, и только от нас зависит, разрастётся ли это дерево до леса, или же так и останется стоять в одиночестве.
Итак, выбираем первый сценарий установки. После этого мастер потребует от нас ввести доменное имя и NetBIOS-имя будущего контроллера домена. Что это за имена?

Собственно, все знают о существовании домена microsoft.com. То есть, где-то имеется сервер, содержащий копию АД и являющийся контроллером домена microsoft.com. Доменным именем, в данном случае, является сочетание символов «microsoft.com».
При создании своего нового домена мы вольны выбрать ему любое доменное имя, но... Необходимо, всё же, учитывать некоторые тонкости. Во-первых, доменное имя пишется латинскими буквами и только ими. Допускаются некоторые специальные символы (тире, знак подчёркивания и, кажется, всё). Во-вторых, необходимо избежать пересечения с уже существующими доменными именами. К примеру, компания, для которой мы создаём домен, носит гордое название РОГА. Совершенно очевидно, что присутствие этого слова в доменном имени более, чем оправдано. Кроме того, фирма-то наша, русская. Казалось бы, доменное имя напрашивается само собой – roga.ru. Ан нет!
Как только мы зададим такое доменное имя, в нашем локальном DNS-сервере появится запись о домене roga.ru и его содержимом. А где физически находится это содержимое? В нашей ЛВС, ибо где же ещё ему быть? И если пользователь нашего домена в своём веб-браузере наберёт http://www.roga.ru с целью ознакомиться с содержимым корпоративного веб-сайта, то попадёт ли он на этот сайт? Отнюдь нет! Ведь нашего пользователя обслуживает наш локальный DNS-сервер, а в нём нет записи об IP-адресе хоста, содержащего веб-сайт компании. И не может быть, потому что хост этот находится за пределами нашей ЛВС3. Таким образом, DNS-сервер даст ответ о невозможности разрешить имя данного хоста и браузер пользователя сообщит о невозможности открыть страницу – хост не найден. Сайт не найден в нашей ЛВС потому, что искать его следует в глобальной сети, а источником проблемы является тот факт, что доменное имя нашей ЛВС совпадает с доменным именем, зарегистрированным в глобальной сети интернет.
Конечно, можно осведомиться на соответствующих интернет-сервисах, не занято ли столь подходящее нам доменное имя roga.ru, но есть гораздо более простой и, одновременно, изящный вариант. В интернете имеется зона RU для регистрации доменов рунета – русскоязычной части интернета. Но в интернете нет зоны LOCAL. Вместе с тем суффикс LOCAL указывает на то, что речь ведётся о локальной сети. Соответственно, для компании с гордым названием РОГА имеет смысл зарегистрировать в интернете домен roga.ru и создать локальный домен roga.local для обслуживания ЛВС. Такой подход снимет все проблемы пересекающихся доменных имён и, одновременно, выглядит вполне логичным.

Далее следует NetBIOS-имя будущего контроллера домена. Это – то самое имя, которое выводится в Сетевом Окружении. Проще говоря, это – имя компьютера. Как назвать свой КД – дело каждого админа. Можно обозвать его PDC (Primary Domain Cotroller – Первый Контроллер Домена). Я, например, в своё время слышал такую схему: домен назвать universe.local (universe – вселенная). Каждому серверу в этом домене присвоить имя какой-нибудь звезды. Обозвать, к примеру, КД именем sun (Солнце). А каждую клиентскую машину назвать именем планеты или её спутника – к примеру, Pluto (Плутон). Здесь нет никаких чётких рекомендаций кроме правил для NetBIOS-имён. Более того, если не полениться и приложить к имени компьютера его краткое описание (для этого предусмотрена отдельная строка при именовании компьютера ещё на стадии установки ОС), то пользователь, вошедший в Сетевое Окружение, и без необходимости запоминать имена компьютеров легко и мгновенно в нём сориентируется.
Заметим в скобках, что кроме NetBIOS-имени компьютера имеется и его полное имя. Оно складывается из NetBIOS-имени компьютера и имени домена, которому этот компьютер принадлежит. К примеру если КД домена universe.local называется pluto, то полное имя этого КД будет pluto.univere.local . Если же компьютер pluto никакому домену не принадлежит, то его полное имя будет выглядеть как pluto . (именно так, с точкой на конце).
Таким образом, будем считать, что доменное имя и имя будущего КД выбраны и введены.

Следующий этап поднятия домена состоит в том, что мастер предложит выбрать место под файлы хранилища АД и журналов, равно как и место системного тома. Проще говоря, вам предложат выбрать папки, в которые будет установлена АД. Как правило, едва ли имеет смысл менять предложенные мастером умолчания, но если на будущем КД имеется несколько локальных томов, у вас может возникнуть желание выбрать наиболее подходящий из них для этой цели. Собственно, требований тут несколько:

1. Хранилище АД, журналы и системный том (SYSVOL) могут располагаться исключительно на томах, отформатированных в файловую систему NTFS.4

2. Имеет смысл разместить хранилище АД, журналы и системный том на самом защищённом и надёжном жёстком диске или RAID, если в компьютере содержится несколько физических дисков.

3. Совершенно само собой разумеется, что ни хранилище АД, ни журналы, ни системный том не могут располагаться на сетевых дисках. В конце концов, сетевые диски сами являются элементами сетевой инфраструктуры и едва ли могут содержать в себе начало всей этой инфраструктуры.

Следующий этап – общение с DNS-сервером. В сетевых настройках вашего будущего КД должен быть прописан предпочитаемый DNS-сервер. Имея эту информацию, мастер установки АД способен послать этому серверу запрос и протестировать его на предмет пригодности для развёртывания АД. К этому серверу будут предъявлены следующие требования:

1. Наличие в сети (реальное наличие и работоспособность).

2. Поддержка ресурсных записей SRV-типа.

3. Возможность динамической регистрации имён.

Если сервер удовлетворяет этим требованиям, он будет использован при построении АД. Иначе мастер предложит на выбор несколько вариантов:

· Повторное тестирование DNS-сервера. Предполагается, что системный администратор понял намёк, вмешался и исправил все проблемы с существующим DNS-сервером. Он готов протестировать его ещё раз, чтобы убедиться в его пригодности.

· Установка и конфигурирование нового DNS-сервера на данном компьютере. Самый удобный вариант – Windows не станет разбираться с имеющимися серверами и создаст себе новый, полностью удовлетворяющий её требованиям и настроенный должным образом, совместив его с будущим КД.5

· Настройка DNS-сервера после установки АД. Предполагается, что системный администратор учёл наличие проблемы с DNS-сервером и исправит её по завершении установки АД.
При возникновении ошибки я советую воспользоваться вторым вариантом. Ну а если ошибки не возникло, то можно оставить всё, как есть, и использовать существующий DNS-сервер.

И, наконец, заключительный этап – определение уровня разрешений для системы безопасности. В вашей сети могут присутствовать другие сервера под управлением Windows, равно как и сервера под управлением других ОС. Возможны два варианта:

1. В сети присутствуют только сервера под управлением MS Windows 2000 Server и MS Windows 2003 Server.

2. В сети присутствуют сервера под управлением MS Windows NT и прочих серверных ОС (к примеру, семейства *nix), тогда как наш будущий КД управляется MS Windows 2003 Server.

Соответственно, существуют две модели работы системы безопасности. Первая модель позволяет анонимный доступ к информации в доменном разделе каталога. Эта модель использовалась в доменах под управлением MS Windows NT. Таким образом, если в нашей сети будут присутствовать сервера (это могут быть любые сервера, не обязательно КД) под управлением MS Windows NT, нам необходимо в мастере установки АД отметить галку Permissions compatible with pre-Windows 2000 operating system (Разрешения, совместимые с более старыми, нежели Windows 2000, ОС) . Точно так же следует поступить и в том случае, если в домене планируется использовать сервера под управлением ОС семейста Unix, т.к. они общаются с КД именно по этой схеме.
Если же в нашем новоиспечённом домене будут только сервера под управлением MS Windows 2000 Server и MS Windows 2003 Server, то выбирать уровень совместимости с более старыми ОС не стоит. И даже не рекомендуется, поскольку отключение анонимного доступа куда бы то ни было – один из главных элементов информационной безопасности.
Если же вы при установке домена совместимость разрешений с предыдущими версиями ОС не задали, а впоследствии сервер, требующий такой совместимости, в сети всё же появился, то этот уровень можно установить командой:

net localgroup «Pre-Windows 2000 Compatible Access» everyone /add

Заметим в скобках, что установка уровня совместимости разрешений имеет отношение только к серверам. Иными словами, наличие в домене клиентских станций под управлением сколь угодно древних версий любых ОС на выбор уровня совместимости не влияет. И наоборот – выбор уровня совместимости не влияет на поведение клиентских станций с любыми версиями ОС в домене.

Этап выбора уровня совместимости был последним. После его завершения потребуется перезагрузить систему. В процессе последующей загрузки в базе DNS будет зарегистрировано доменное имя и на нашем КД будет создана учётная запись администратора домена. Точнее, не создана.
Установку АД и поднятие КД следует производить от имени локального администратора нашего сервера – это очевидно. И именно его учётная запись будет преобразована в учётную запись Administrator и включена в следующие группы:

· Administrators . Встроенная локальная группа.

· Domain Admins . Группа АД, члены которой имеют право управлять доменом.

· Domain Users . Группа АД, членами которой являются все создаваемые пользователи домена.

· Enterprise Admins. Группа АД, члены которой имеют право управлять инфраструктурой каталога.

· Group Policy Creator Owners . Группа АД, имеющие право редактировать параметры групповых политик в пределах данного домена.

· Schema Admins . Группа АД, члены которой имеют право изменять схему каталога.

Соответственно, по окончании этого этапа вам останется вписать в ваш домен все компьютеры вашей ЛВС и создать учётные записи для пользователей вашей ЛВС. И домен готов.

Дополнительные соображения

Разумеется, простой установкой КД системный администратор не отделается. Ведь в каждой компании имеется своя политика использования ЛВС, её ресурсов. Как минимум, свой набор этих самых ресурсов и свои права пользователей на эти ресурсы. Соответственно, в круг обязанностей админа входит создание в домене групп пользователей, распределение ресурсов по этим группам. Внесение этих ресурсов в АД, ведь тот же сетевой принтер сам от себя в каталоге не пропишется. Но всё это – тема отдельного разговора.

1 А.Чекмарев, А.Вишневский, О.Кокарева. / Microsoft Windows Server 2003 в подлиннике. Наиболее полное руководство. // «БХВ-Петербург», С-Пб., 2003.

2 Разделяй и властвуй! (лат.)

3 Разумеется, существуют случаи, когда веб-сайт расположен на серверах корпоративной ЛВС. Но всё же гораздо чаще веб-сайт компании располагается на платном внешнем хостинге и никакого отношения к корпоративной ЛВС не имеет.

4 Строго говоря, данное требование может показаться избыточным, поелику серверные версии Windows по умолчанию форматирую свои тома в NTFS. Тем не менее, разные причины могут привести к тому, что на сервере появятся тома с файловой системой FAT32. Таким образом, отследить данное требование всё же надо, т.к. АД не может быть инсталлирована в отличную от NTFS файловую систему.

5 Я настоятельно рекомендую начинать установку АД, не имея в сети готового DNS-сервера или же не занимаясь конфигурированием имеющегося. Что бы ни говорили о творениях Microsoft, но пусть уж лучше Windows настроит необходимый ей DNS-сервер с нуля и автоматически. Она сделает это быстрее и лучше человека, да и с меньшими затратами.

Настройка Active Directory представляет из себя достаточно простой процесс и рассматривается на множестве ресурсов в интернете, включая официальные. Тем не менее на своем блоге я не могу не затронуть этот момент, поскольку большинство дальнейших статей будет так или иначе основано на окружении, настройкой которого я планирую заняться как раз сейчас.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу на моем блоге. Также рекомендую ознакомиться с основной статье по Active Directory —

Разворачивать роль AD я планирую на двух виртуальных серверах (будущих контроллерах домена) по очереди.

  1. Первым делом нужно задать подходящие имена серверов , у меня это будут DC01 и DC02;
  2. Далее прописать статические настройки сети (подробно этот момент я рассмотрю ниже);
  3. Установите все обновления системы , особенно обновления безопасности (для КД это важно как ни для какой другой роли).

На этом этапе необходимо определиться какое имя домена у вас будет . Это крайне важно, поскольку потом смена доменного имени будет очень большой проблемой для вас, хоть и сценарий переименования официально поддерживается и внедрен достаточно давно.

Примечание: н екоторые рассуждения, а также множество ссылок на полезный материал, вы можете найти в моей статье . Рекомендую ознакомиться с ней, а также со списком использованных источников.

Поскольку у меня будут использоваться виртуализованные контроллеры домена, необходимо изменить некоторые настройки виртуальных машин, а именно отключить синхронизацию времени с гипервизором . Время в AD должно синхронизироваться исключительно с внешних источников. Включенные настройки синхронизации времени с гипервизором могут обернуться циклической синхронизацией и как следствие проблемами с работой всего домена.

Примечание: отключение синхронизации с хостом виртуализации — самый простой и быстрый вариант. Тем не менее, это не best practic. Согласно рекомендациям Microsoft, нужно отключать синхронизацию с хостом лишь частично. Для понимания принципа работы читайте официальную документацию, которая в последние годы радикально подскочила вверх по уровню изложения материала .

Вообще сам подход к администрированию виртуализованных контроллеров домена отличается в виду некоторых особенностей функционирования AD DS:

Виртуальные среды представляют особую трудность для распределенных рабочих потоков, зависящих от логической схемы репликации по времени. Например, репликация AD DS использует равномерно увеличивающееся значение (которое называется USN, или номер последовательного обновления), назначенное транзакциям в каждом контроллере домена. Каждый экземпляр базы данных контроллера домена также получает идентификатор под названием InvocationID. InvocationID контроллера домена и его номер последовательного обновления вместе служат уникальным идентификатором, который связан с каждой транзакцией записи, выполняемой на каждом контроллере домена, и должны быть уникальны в пределах леса.

На этом основные шаги по подготовке окружения завершены, переходим к этапу установки.

Установка Active Directory

Установка производится через Server Manager и в ней нет ничего сложного, подробно все этапы установки вы можете увидеть ниже:


Сам процесс установки претерпел некоторые измененияпо сравнению с предыдущими версиями ОС:

Развертывание доменных служб Active Directory (AD DS) в Windows Server 2012 стало проще и быстрее по сравнению с предыдущими версиями Windows Server. Установка AD DS теперь выполняется на основе Windows PowerShell и интегрирована с диспетчером серверов. Сократилось количество шагов, необходимых для внедрения контроллеров домена в существующую среду Active Directory.

Необходимо выбрать только роль Доменные службы Active Directory , никакие дополнительные компоненты устанавливать не нужно. Процесс установки занимает незначительно время и можно сразу переходить к настройке.

Когда установится роль, справа вверху Server Manager вы увидите восклицательный знак — требуется провести конфигурацию после развертывания. Нажимаем Повысить роль этого сервера до контроллера домена .

Повышение роли сервера до контроллера домена

Этапы работы мастера подробно описаны в документации. Тем не менее, пройдемся по основным шагам.

Поскольку мы разворачиваем AD с нуля, то нужно добавлять новый лес. Не забудьте надежно сохранить пароль для режима восстановления служб каталогов (DSRM). Расположение базы данных AD DS можно оставить по умолчанию (именно так и рекомендуют. Однако для разнообразия в своей тестовой среде я указал другой каталог).

Дожидаемся установки.

После этого сервер самостоятельно перезагрузится.

Создание учетных записей администраторов домена/предприятия

Залогиниться нужно будет под учетной записью локального администратора, как и прежде. Зайдите в оснастку Active Directory — пользователи и компьютеры , создайте необходимые учетные записи — на этом этапе это администратор домена.

Настройка DNS на единственном DC в домене

Во время установки AD также была установлена роль AD DNS, поскольку других серверов DNS у меня в инфраструктуре не было. Для правильно работы сервиса необходимо изменить некоторые настройки. Для начала нужно проверить предпочитаемые серверы DNS в настройках сетевого адаптера. Необходимо использовать только один DNS-сервер с адресом 127.0.0.1. Да, именно localhost. По умолчанию он должен прописаться самостоятельно.

Убедившись в корректности настроек, открываем оснастку DNS. Правой кнопкой нажимаем на имени сервера и открываем его свойства, переходим на вкладку «Сервер пересылки». Адрес DNS-сервера, который был указан в настройках сети до установки роли AD DS, автоматически прописался в качестве единственного сервера пересылки:

Необходимо его удалить и создать новый и крайне желательно, чтобы это был сервер провайдера, но никак не публичный адрес типа общеизвестных 8.8.8.8 и 8.8.4.4. Для отказоустойчивости пропишите минимум два сервера. Не снимайте галочку для использования корневых ссылок, если нет доступных серверов пересылки. Корневые ссылки — это общеизвестный пул DNS-серверов высшего уровня.

Добавление второго DC в домен

Поскольку изначально я говорил о том, что у меня будет два контроллера домена, пришло время заняться настройкой второго. Проходим также мастер установки, повышаем роль до контроллера домена, только выбираем Добавить контроллер домена в существующий домен :

Обратите внимание, что в сетевых настройках этого сервера основным DNS-сервером должен быть выбран настроенный ранее первый контроллер домена ! Это обязательно, иначе получите ошибку.

После необходимых настроек логиньтесь на сервер под учетной записью администратора домена, которая была создана ранее.

Настройка DNS на нескольких DC в домене

Для предупреждения проблем с репликацией нужно снова изменить настройки сети и делать это необходимо на каждом контроллере домена (и на существовавших ранее тоже) и каждый раз при добавлении нового DC:

Если у вас больше трех DC в домене, необходимо прописать DNS-серверы через дополнительные настройки именно в таком порядке. Подробнее про DNS вы можете прочитать в моей статье .

Настройка времени

Этот этап нужно выполнить обязательно, особенно если вы настраиваете реальное окружение в продакшене. Как вы помните, ранее я отключил синхронизацию времени через гипервизор и теперь нужно её настроить должным образом. За распространение правильного время на весь домен отвечает контроллер с ролью FSMO PDC эмулятор (Не знаете что это такая за роль? Читайте статью ). В моем случае это конечно же первый контроллер домена, который и является носителем всех ролей FSMO изначально.

Настраивать время на контроллерах домена будем с помощью групповых политик. Напоминаю, что учетные записи компьютеров контроллеров домена находятся в отдельном контейнере и имеют отдельную групповую политику по умолчанию. Не нужно вносить изменения в эту политику, лучше создайте новую.

Назовите её как считаете нужным и как объект будет создан, нажмите правой кнопкой — Изменить . Переходим в Конфигурация компьютера\Политики\Административные шаблоны\Система\Служба времени Windows\Поставщики времени . Активируем политики Включить NTP-клиент Windows и Включить NTP-сервер Windows , заходим в свойства политики Настроить NTP-клиент Windows и выставляем тип протокола — NTP , остальные настройки не трогаем:

Дожидаемся применения политик (у меня это заняло примерно 5-8 минут, несмотря на выполнение gpupdate /force и пару перезагрузок), после чего получаем:

Вообще надо сделать так, чтобы время с внешних источников синхронизировал только PDC эмулятор, а не все контроллеры домена под ряд, а будет именно так, поскольку групповая политика применяется ко всем объектам в контейнере. Нужно её перенацелить на конкретный объект учетной записи компьютера-владельца роли PDC-эмулятор. Делается это также через групповые политики — в консоли gpmc.msc нажимаем левой кнопкой нужную политику и справа у вас появятся её настройки. В фильтрах безопасности нужно добавить учетную запись нужного контроллера домена:

Подробнее о принципе работы и настройке службы времени читайте в официальной документации.

На этом настройка времени, а вместе с ней и начальная настройка Active Directory, завершена.

человек со стажем 5 января 2011 в 01:22

Установка контроллера домена Active Directory в Windows Server 2008 R2 для начинающих

Я всех приветствую и предлагаю вашему вниманию эту статью. Надеюсь, что она будет полезна начинающим системным администраторам Windows. Мы познакомимся с основами Active Directory и поднимем контроллер домена.

Преимущества использования домена в локальных сетях довольно очевидны: это и централизованная система авторизации пользователей, и удобный мощный аппарат для администрирования (управление учетными записями пользователей, разграничение прав и т. д) и ряд других полезных возможностей. Кроме того, домен логически объединяет все ресурсы сети и обеспечивает доступ авторизованным пользователям к ним. И это может быть масштабировано от небольшой локальной сети на полтора десятка машин и до весьма внушительной и протяженной территориально.

Установка DNS-сервера

И так, нам потребуется установить и настроить DNS-сервер и контроллер домена. Замечу, что настройка DNS и его корректная работа в сети жизненно необходимы для успешного функционирования домена. Мы установим обе роли на один сервер, хотя это и не является обязательным. Подробно настройку DNS мы рассматривать здесь не станем и остановимся лишь на основных моментах. В нашей сети используется DHCP, но для сервера DNS нужно назначить статический адрес вручную.

После этого перейдем к назначению роли:

После установки воспользуемся диспетчером DNS для настройки. Мы создадим зоны прямого и обратного просмотра. Первая служит для преобразования DNS-имен в IP-адрес, а вторая - наоборот.

Поскольку это первый и единственный DNS-сервер у нас в сети, мы создадим основную зону.

Далее нам нужно указать имя зоны. Я использовал testnet.local, хотя сейчас рекомендуется не использовать несуществующих доменных имен первого уровня даже для приватных сетей. Но в нашем примере это несущественно.

Нам нужно разрешить динамические обновления для успешной работы домена.
Нажав далее и прочитав сообщение об успешном завершении мы продолжим настройку.
Впишем полное доменное имя для нашего сервера и почтовый адрес для связи с ответственным лицом (обратите внимание на важность наличия точки в конце – корня. Также вместо значка @ используется точка.)

Поскольку у нас единственный сервер имен, отключим передачу зон из соображений безопасности.

И пропишем наш сервер:

Всё. Настройка зоны прямого просмотра завершена.

Теперь создадим зону обратного просмотра, хотя это делать и не обязательно.
Действия аналогичные:

Укажем идентификатор сети:

Обратите внимание на имя зоны: октеты нашей сети записаны справа налево. Так и должно быть.
Создаем новый файл, разрешаем динамические обновления и жмем «Готово». Дальнейшая донастройка полностью идентична манипуляциям, проделанным для зоны прямого просмотра. Запись типа A в основной зоне для нашего сервера есть, так что воспользуемся этим для создания PTR-записи автоматически здесь:

Настройка нашего DNS-сервера завершена.

Установка контроллера домена

Теперь установим роль контроллера домена Active Directory. Для этого нужно выполнить команду dcpromo.

Последует запуск мастера:

Появляется несколько предупреждений и возможность выбора включить наш контроллер домена в уже существующий домен, добавить новый домен в существующий лес или же создать новый домен в новом лесу. Нас интересует последний вариант и его мы и выберем.
После некоторых проверок нам будет предложено NetBIOS-имя домена, которое мы вполне можем оставить.

Далее перед нами выбор режима работы леса. Как и многие другие тонкости, я опускаю пояснения и предлагаю интересующимся ознакомиться с документацией. Для нас будет достаточно выбрать Windows Server 2008 R2 (разумеется, если нет планов на использование в качестве контроллеров домена в нашем лесу предыдущих версий операционных систем Microsoft) и двинуться далее.

У нас уже есть настроенный сервер DNS и мы создадим делегирование, указав логин и пароль администраторской учетной записи.

На следующем шаге мы укажем расположение каталогов, в которых будут хранится БД, файлы журнала и папка SYSVOL. Далее указываем пароль для восстановления и мы почти у цели.

Теги: системное администрирование

ОС Windows поставляется вместе с утилитой DCPPROMO.EXE, которая используется для повышения отдельного сервера до контроллера домена и наоборот.

В Windows домены основаны на структуре имен DNS, что означает возможность создания иерархии доменов по типу родитель–потомок. Преимущество такой схемы заключается в применении двунаправленного транзитивного доверия. Это означает, что если домен b является дочерним по отношению к домену a, а домен c, в свою очередь, - дочерним по отношению к домену b, то домен c по умолчанию доверяет домену a.

Поскольку домены Windows основаны на службе DNS, для создания домена важно правильно настроить сервер DNS (если создается домен верхнего уровня).

Последнее условие состоит в использовании файловой системы NTFS для хранения тома SYSVOL, поэтому необходимо удостовериться в наличии как минимум одного тома NTFS (для получения информации о версии файловой системы воспользуйтесь командой CHKNTFS).

С целью модернизировать отдельный сервер до контроллера домена сделайте следующее.

1. Откройте утилиту DCPROMO (Пуск > Выполнить > DCPROMO (Start > Run > DCPROMO)).

3. После этого будет предоставлена возможность выбора между командами New domain или Replica domain controller in existing domain. В Windows не существует концепции резервных доменов (BDC -Backup Domain Controller) и все контроллеры доменов равны между собой. Выберите команду New domain и кликните на кнопке Next.

4. Новым понятием Windows стали деревья (trees), которые позволяют реализовывать отношение родитель-потомок между доменами. Если создается новый домен верхнего уровня, выберите команду Create new domain tree. Для создания дочернего домена, выберите параметр Create new child domain. Кликните на кнопке Next.

5. Если выбрано создание нового дерева доменов, будет выдан запрос на создание нового леса деревьев доменов или размещение нового дерева в существующем лесу доменов. Лес позволяет соединить несколько отдельных деревьев доменов и обеспечить между ними транзитивное доверие. Если создается первое дерево доменов Windows, необходимо создать новый лес. Кликните на кнопке Next.

6. Затем следует ввести имя DNS для нового домена, например, windows.com является действительным именем домена. Важно, чтобы эта информация совпадала с конфигурационными параметрами сервера DNS. Кликните на кнопке Next.

7. Будет выдан запрос на ввод доменного имени NetBIOS, которым по умолчанию является самая левая часть имени DNS (длинной до 15-ти символов). В данном случае используется имя windows, что, однако, можно изменить. Кликните на кнопке Next.

8. Теперь необходимо предоставить область хранения для службы каталогов и журнала Active Directory. Примите значения, принятые по умолчанию, и кликните на кнопке Next.

9. Наконец, следует указать область жесткого диска на разделе NTFS для хранения тома SYSVOL, в котором содержатся общедоступные файлы сервера. По умолчанию используется каталог %systemroot%\SYSVOL. Кликните на кнопке Next.

10. В следующем окне предоставляется возможность уменьшить уровень безопасности служб, использовавшихся до Windows, например, сервера RAS 4.0. Укажите необходимые параметры и кликните на кнопке Next.

11. Будет выдан запрос на ввод пароля администратора, предназначенный для режима восстановления Directory Server. Кликните на кнопке Next.

12. Появится окно с итоговой информацией. Кликните на кнопке Next для проведения модернизации сервера, при которой определяются необходимые параметры безопасности и создается контейнер схемы Directory Server. Если модернизация производится до основного контроллера домена, требуемая информация считывается из файла службы каталогов, принятого по умолчанию, а также из старого файла SAM.

13. Кликните на кнопке Finish и перезагрузите компьютер.

Теперь компьютер будет выполнять роль контроллера домена Windows. Дополнительные контроллеры домена (старые резервные контроллеры) могут быть добавлены при повторении приведенной выше последовательности действий и выборе опции Replica domain controller in existing domain на шаге 3. При этом мастер настройки выдаст запрос на ввод имени домена, который необходимо реплицировать.