Как сделать контроллер домена основным

Обновлено: 08.07.2024

UPD2: Микрософт традиционно меняет привычный синаксис в командной строке, поэтому роли в кажлый версии Windows Server могут звучать по-разному. Они вообще теперь не fsmo называются а operation masters. Так вот, для корректных команд в консоли после fsmo maintenance напишите просто ? и он вам покажет доступные команды.

У меня в апрельский журнал "Системный администратор" взяли статью на тему "Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server"

И даже сто долларов заплатили и дали пакет с мозгами)) Я теперь Онотоле.

Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server. (кому вдруг надо - картинки пришлю)

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

Подготовка серверов к повышению/понижению роли

Фактически можно сделать вывод – если у вас примитивный домен на 30-50 машин, без расширенной инфраструктуры, не включающий в себя поддомены - то отсутствие доступа к владельцу/владельцам первых двух ролей вы можете не заметить. Кроме того, мне несколько раз попадались организации, работающие больше года вообще без контроллера домена, но в доменной инфраструктуре. То есть все права были розданы давно, при работающем контроллере домена, и не нуждались в изменении, пароли пользователи себе не меняли и спокойно работали.

Определение текущих владельцев ролей fsmo.

Уточняю - мы грамотно хотим заменить контроллер домена, не потеряв никаких его возможностей. В том случае, если в домене два или более контроллеров, нам необходимо выяснить кто является обладателем каждой из ролей fsmo. Это достаточно просто сделать, использовав следующие команды:

dsquery server –hasfsmo schema
dsquery server – hasfsmo name
dsquery server – hasfsmo rid
dsquery server – hasfsmo pdc
dsquery server – hasfsmo infr
dsquery server –forest -isgc

Каждая из команд выводит нам информацию о том, кто является владельцем запрашиваемой роли (рис.1). В нашем случае владелец всех ролей – основной контроллер домена dcserver.

Добровольная передача ролей fsmo при помощи консолей Active Directory.

regsvr32 schmmgmt.dll

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

Добровольная передача ролей fsmo при помощи консолей ntdsutil.exe.

Итак первый случай – основной контроллер домена существует и функционирует нормально. Тогда мы заходим на основной контроллер домена и набираем следующие команды:

ntdsutil.exe
roles
connections
connect to server имя_сервера (того кому хотим отдать роль)
q

После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance), и можем начать передавать роли :
- transfer domain naming master
- transfer infrastructure master
- transfer rid master
- transfer schema master
- transfer pdc master

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

Роль хранителя глобального каталога передаётся способом, описанным в предыдущем разделе.

Принудительное присваивание ролей fsmo при помощи ntdsutil.exe.

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

seize domain naming master
seize infrastructure master
seize rid master
seize schema master
seize pdc

Обратите внимание – если вы отобрали роль у контроллера домена, отсутствующего в данный момент, то при его появлении в сети контроллеры начнут конфликтовать, и проблем в функционировании домена вам не избежать.

Работа над ошибками.

Самое главное, о чём не следует забывать – новый основной контроллер домена сам себе настройки TCP/IP не исправит: ему адресом первичного DNS сервера теперь желательно (а если старый контроллер домена + DNS сервер будут отсутствовать, то обязательно) указать 127.0.0.1 .
При этом если у вас в сети есть DHCP сервер, то нужно заставить его выдавать адресом первичного DNS сервера ip вашего нового сервера, если DHCP нет – пройтись по всем машинам и прописать им этот первичный DNS вручную. Как вариант, можно назначить новому контроллеру домена тот же ip что был у старого.

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

Установить эту утилиту можно с оригинального диска Windows 2003 из папки /support/tools. Утилита позволяет проверить работоспособность всех служб контроллера домена, каждый её этап должен оканчиваться словами successfully passed. Если у вас выходит failed (чаще всего это тесты connection или systemlog) то ошибку можно попробовать вылечить в автоматическом режиме:

dcdiag /v /fix

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

И её полезным инструментом устранения ошибок:

netdiag /v /fix

Если и после этого остаются ошибки связанные с DNS – проще всего удалить из него все зоны и создать вручную. Это довольно просто – главное создать основную зону по имени домена, хранящуюся в Active Directory и реплицируемую на все контроллеры домена в сети.
Более подробную информацию об ошибках DNS даст ещё одна команда:

dcdiag /test:dns

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

Настройка сетевых интерфейсов Active Directory 2019

И так. У нас было 2 сервера виртуализации, 50 пользователей домена, 5 марок сетевых коммутаторов, полсотни групповых политик и гора CD-дисков, и всего такого, всех цветов. Не то, чтобы это всё было нужно в настройке резервного контроллера доменов, но раз начал наводить порядок в конторе, то иди в своём деле до конца.

На самом деле всё не так страшно, даже наооборот. Основной сервер будет называться AD-01, а резервный AD-02. Логично же :) ? На сервере AD-01 прописываем в Альтернативный DNS-сервер ip адрес нашего будующего резервного контроллера домена. Так как у меня он находится в другом офисе, то и подсеть у него отличается, если бы он был в местной локальной сети, то имел ту же подсеть.

Вводим сервер резервный контроллер домена AD-02 в домен, а затем добавляем в Предпочтительный DNS-сервер ip адрес нашего основного сервера AD-01.

Установка и настройка сервиса Active Directory 2019 через Диспетчер серверов

На резервном контроллере домена через Диспетчер серверов вызываем Мастер добавление ролей и компонентов. Отмечаем чекбоксы DNS-сервер и Доменные службы Active Directory.

Далее ничего особенного, проходим до пункта Подтверждение, соглашаемся и начинаем установку.

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

Отмечаем Добавить контроллер домена в существующий домен, через кнопку Выбрать вибираем наш основной сервер и чуть ниже вводим наши учётные данные от домена.

В разделе Дополнительные параметры указываем источник репликации основной сервер AD-01. Вот и всё, репликация сервера Active Directory готова!

Проверка. Запускаем принудительное реплицирование домена

Для того чтобы сразу протестировать настройку реплецирования резервного контроллера домена открываем Диспетчер серверов и запускаем Средства / Active Directory — сайты и службы

В открывшемся окне переходим Sites / Default-First-Site-Name / Servers / AD-02 / NTDS Settings, выбираем в окне справа наше подключение Правая кнопка мыши / Реплицировать сейчас.

А после мы должны увидеть уведовление об успешном реплицировании нашего каталога. Надеюсь помог и вы настроили свой резервный контроллер домена Active Directory! Спасибо за внимание!

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

Описание процедуры замены одного контроллера домена на другой можно найти на разных форумах. Информация, как правило, даётся отрывками и применима только к конкретной ситуации, поэтому общего плана действий не даёт. Кроме того, даже вдоволь начитавшись форумов [1], баз знаний [2, 3] и прочих ресурсов, я смог грамотно провести процедуру замены контроллера домена без ошибок только с третьего или четвёртого раза.

Подготовка серверов к повышению/понижению роли

Дальше, если мастер сам не предложил, запускаем установку DNS-сервера. Никаких настроек изменять не надо, зону создавать также не надо – она хранится в AD, и все записи автоматически реплицируются на резервный контроллер. Хочется обратить внимание на то, что основная зона в DNS появится только после репликации, для ускорения которой сервер можно перезагрузить. В настройках TCP/IP сетевой карты резервного контроллера домена адресом первичного DNS-сервера должен быть указан IP-адрес основного контроллера домена.

Теперь можно легко проверить работоспособность резервного контроллера домена pserver. Мы можем создать учетную запись как на основном, так и на резервном контроллере домена. Сразу после создания она появляется на дублирующем сервере, но где-то в течение минуты (пока происходит репликация) она видна как отключенная, после чего начинает отображаться одинаково на обоих контроллерах.

На первый взгляд, все манипуляции по созданию исправной схемы взаимодействия как минимум двух контроллеров домена выполнены, и теперь в случае выхода из строя основного контроллера домена резервный контроллер будет автоматически выполнять его функции. Однако, хотя разница между основным и резервным контроллерами домена AD чисто номинальная, основной контроллер имеет ряд особенностей (роли FSMO), о которых не стоит забывать. Таким образом, вышеприведенных операций для нормального функционирования службы каталогов при отказе основного контроллера недостаточно, и действия, которые надо произвести для грамотной передачи/захвата роли основного контроллера домена, будут описаны дальше.

Нужно знать, что контроллеры домена Active Directory исполняют несколько видов ролей. Эти роли называются FSMO (Flexible single-master operations):

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

Фактически можно сделать вывод: если у вас примитивный домен на 30-50 машин, без расширенной инфраструктуры, не включающий в себя поддомены, то отсутствие доступа к владельцу/владельцам первых двух ролей вы можете не заметить.

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

Определение текущих владельцев ролей FSMO

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

Это достаточно просто сделать, использовав следующие команды:

dsquery server -hasfsmo schema

dsquery server -hasfsmo name

dsquery server -hasfsmo rid

dsquery server -hasfsmo pdc

dsquery server -hasfsmo infr

dsquery server -forest -isgc

Каждая из команд выводит нам информацию о том, кто является владельцем запрашиваемой роли (см. рис. 1). В нашем случае владелец всех ролей – основной контроллер домена dcserver.

Рисунок 1. Владелец роли rid master – dcserver

Добровольная передача ролей FSMO при помощи консолей Active Directory

Рисунок 2. Процесс передачи роли хозяина именования доменов серверу pserver

Рисунок 3. Теперь глобальный каталог лежит на pserver

Итог – мы поменяли владельца ролей FSMO для нашего домена. Кому нужно окончательно избавиться от старого контроллера домена – понижаем его до рядового сервера. Однако в ряде ситуаций проведение операции по передаче ролей вышеописанным способом невозможно. В этих случаях нам поможет ntdsutil.exe.

Добровольная передача ролей FSMO при помощи утилиты ntdsutil

Итак, первый случай – основной контроллер домена существует и функционирует нормально. Тогда мы заходим на основной контроллер домена и набираем следующие команды:

connect to server имя_сервера (того, кому хотим отдать роль)

Если выскакивают ошибки, нужно проверить связь с тем контроллером домена, к которому мы пытаемся подключиться. Если ошибок нет – значит мы успешно подключились к указанному контроллеру домена с правами того пользователя, от имени которого вводим команды.

Я же путём проб и ошибок выяснил, что при передаче ролей в данном порядке гарантируется корректное завершение всех шагов:

хозяин операции именования доменов;
хозяин инфраструктуры;
хозяин идентификаторов;
хозяин схемы;
контроллер домена.

После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance) и можем начать передавать роли:

transfer domain naming master;
transfer infrastructure master;
transfer rid master;
transfer schema master;
transfer pdc master.

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

Рисунок 4. Так выглядит корректная передача роли rid master серверу pserver

Роль хранителя глобального каталога передаётся способом, описанным в предыдущем разделе.

Принудительное присваивание ролей FSMO при помощи ntdsutil.exe

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

Работа над ошибками

Самое главное, о чём не следует забывать: новый основной контроллер домена сам себе настройки TCP/IP не исправит – ему адресом первичного DNS-сервера теперь желательно (а если старый контроллер домена + DNS-сервер будут отсутствовать, то обязательно) указать 127.0.0.1.

При этом если у вас в сети есть DHCP-сервер, то нужно заставить его выдавать адресом первичного DNS-сервера IP вашего нового сервера, если DHCP нет – пройтись по всем машинам и прописать им этот первичный DNS вручную. Как вариант, можно назначить новому контроллеру домена тот же IP, что был у старого.

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

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

Рисунок 5. Результат успешного выполнения команды dcdiag на pserver

Разобраться в проблемах функционирования домена можно при помощи утилиты (см. рис. 5):

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

И её полезным инструментом устранения ошибок:

Если и после этого остаются ошибки, связанные с DNS, проще всего удалить из него все зоны и создать вручную. Это довольно просто – главное создать основную зону по имени домена, хранящуюся в Active Directory и реплицируемую на все контроллеры домена в сети.

Более подробную информацию об ошибках DNS даст ещё одна команда:

По окончании проделанных работ у меня ушло ещё где-то 30 минут на выяснение причины появления ряда предупреждений – я разобрался с синхронизацией времени, архивацией глобального каталога и прочими вещами, до которых раньше не доходили руки. Теперь всё работает как часы – самое главное, не забудьте завести резервный контроллер домена, если вы хотите удалить старый контроллер домена из сети.

FSMO-роль эмулятор первичного контроллера домена (PDC emulator) является второй ролью (из трех) уровня домена. То есть в одном домене должен быть один PDC emulator , но во всем лесу AD их может быть несколько, в зависимости от количества доменов.

Если вам интересна тематика Windows Server, рекомендую обратиться к рубрике Windows Server на моем блоге.

PDC emulator — Эмулятор первичного контроллера домена

Чтобы лучше понимать функционал данной роли FSMO, необходимо сначала обратиться к истории его появления.

Немного истории

Роль эмулятора PDC необходима прежде всего для обеспечения совместимости с версиями Windows ниже 2000. В смешанной среде с клиентами Windows NT, 95, 98 PDC emulator выполняет следующие задачи 1 :

Участвует в процессе смены паролей учетных записей пользователей и компьютеров;
Реплицирует обновления на резервные контроллеры домена (backup domain controllers);
Выполняет задачи хозяина обозревателя сети домена (Domain Master Browser).

Современное назначение

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

1) Репликация паролей идет на PDC emulator в приоритетном режиме. То есть, если пользователь изменил пароль (а сделать это он может на любом DC), то контроллер домена первым делом обращается к эмулятору PDC, чтобы сообщить о факте смены пароля. В свою очередь другие DC, если авторизация с измененным паролем идет через них, не отказывают пользователю, а обращаются к эмулятору первичного контроллера домена, чтобы просмотреть возможные изменения и получив их, авторизуют пользователя с новым паролем.

При недоступности PDC вы просто не сможете залогиниться в систему c новым паролем при авторизации через другой контроллер домена и получите увеличение счетчика попыток входа. Конечно такая ситуация будет наблюдаться совсем небольшой промежуток времени, пока изменения не реплицируются на другие DC, а в реальности на практике вообще не встречается;

То же касается и блокировок учетных записей — первым делом они реплицируются на эмулятор PDC 5 .

2) Для предупреждения конфликтов изменения групповых политик, все изменения GPO в реальности происходят именно на эмуляторе PDC и не важно где конкретно вы работаете с оснасткой;

3) В Windows Server 2003 включены некоторые дополнительные объекты безопасности по умолчанию. При обновлении инфраструктуры с версии Windows Server 2000 сам процесс обновления вы должны начать непосредственно с эмулятора PDC, чтобы эти группы и учетные записи первым делом появились на нем и уже потом реплицировались на другие контроллеры. Сами объекты хранятся в контейнере CN=WellKnown Security Principals,CN=Configuration,DC= ;

Кстати, вот полный список наиболее важных объектов безопасности для только что созданного домена:

Разумеется учетная запись bissquit создана мной вручную, у вас она будет отличаться;

5) Во время установки первого контроллера домена служба NetLogon создает SRV-запись DNS _ldap._tcp.pdc._msdcs.DnsDomainName. Эта запись позволяет клиентам обнаруживать эмулятор PDC. Только владелец этой роли может изменять эту запись;

6) На эмуляторе первичного контроллера домена выполняются изменения пространства имен DFS (Distributed File System). Если PDC emulator не будет найден, то DFS будет работать некорректно 8 ;

7) Процесс повышения функционального уровня домена или леса выполняется на эмуляторе PDC 9 .

8) Пожалуй одной из самых важных функций является распространение времени по всему домену 10 . Подробнее про настройку времени в домене вы можете прочитать в моей статье Настройка Active Directory Domain Services.

Лучшие практики

Многие лучшие практики администрирования эмулятора первичного домена соответствуют другим ролям хозяев операций:

Располагайте PDC emulator и RID master на одном контроллере домена 11;
Обязательно настройте PDC эмулятор на синхронизацию времени с корректного внешнего источника времени 12;
Если вы используете виртуализованные контроллеры домена, позаботьтесь о том, чтобы гостевые ОС виртуальных машин не синхронизировали время с хоста виртуализации, а делали это с контроллеров домена, а те, в свою очередь, с PDC эмулятора;
Не испытывайте судьбу и не вносите изменения в механизм SDProp.

Администрирование

Специальная оснастка для управления работой эмулятора PDC отсутствует.

Изменить владельца роли вы можете с помощью оснастки Active Directory — Пользователи и компьютеры. Для этого:

Открываем оснастку на DC01, правой кнопкой нажимаем на Active Directory — Пользователи и компьютеры и выбираем Сменить контроллер домена Active Directory;
Далее выбираем контроллер домена, на который мы хотим перенести роль (у меня это DC02, по умолчанию всегда выбирается сервер-владелец роли). Подтверждаем предупреждение;
Снова правой кнопкой на Active Directory — Пользователи и компьютеры, но уже выбираем Хозяин операций…;
Нажимаем кнопку Изменить….

После этого необходимо подтвердить выбор и получить уведомление об успешном переносе роли.

Установим роль контроллера домена на Windows Server 2019. На контроллере домена работает служба Active Directory (AD DS). С Active Directory связано множество задач системного администрирования.

AD DS в Windows Server 2019 предоставляет службу каталогов для централизованного хранения и управления пользователями, группами, компьютерами, а также для безопасного доступ к сетевым ресурсам с проверкой подлинности и авторизацией.

Подготовительные работы

Нам понадобится компьютер с операционной системой Windows Server 2019. У меня контроллер домена будет находиться на виртуальной машине:

После установки операционной системы нужно выполнить первоначальную настройку Windows Server 2019:

Хочется отметить обязательные пункты, которые нужно выполнить.

Выполните настройку сети. Укажите статический IP адрес. DNS сервер указывать не обязательно, при установке контроллера домена вместе с ним установится служба DNS. В настройках сети DNS сменится автоматически. Отключите IPv6, сделать это можно и после установки контроллера домена.

Укажите имя сервера.

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

Установка роли Active Directory Domain Services

Работаем под учётной записью локального администратора Administrator (или Администратор), данный пользователь станет администратором домена.

Дополнительно будет установлена роль DNS.

Следующий шаг — установка роли AD DS. Открываем Sever Manager. Manage > Add Roles and Features.

Запускается мастер добавления ролей.

Раздел Before You Begin нас не интересует. Next.

В разделе Installation Type выбираем Role-based or feature-based installation. Next.

В разделе Server Selection выделяем текущий сервер. Next.

В разделе Server Roles находим роль Active Directory Domain Services, отмечаем галкой.

Для роли контроллера домена нам предлагают установить дополнительные опции:

[Tools] Group Policy Management
Active Directory module for Windows PowerShell
[Tools] Active Directory Administrative Center
[Tools] AD DS Snap-Ins and Command-Line Tools

Всё это не помешает. Add Features.

Теперь роль Active Directory Domain Services отмечена галкой. Next.

В разделе Features нам не нужно отмечать дополнительные опции. Next.

У нас появился раздел AD DS. Здесь есть пара ссылок про Azure Active Directory, они нам не нужны. Next.

Раздел Confirmation. Подтверждаем установку компонентов кнопкой Install.

Начинается установка компонентов, ждём.

Configuration required. Installation succeeded on servername. Установка компонентов завершена, переходим к основной части, повышаем роль текущего сервера до контроллера домена. В разделе Results есть ссылка Promote this server to domain controller.

Она же доступна в предупреждении основного окна Server Manager. Нажимаем на эту ссылку, чтобы повысить роль сервера до контроллера домена.

Запускается мастер конфигурации AD DS — Active Directory Domain Service Configuration Wizard. В разделе Deployment Configuration нужно выбрать один из трёх вариантов:

Add a domain controller to an existing domain
Add a new domain to an existing forest
Add a new forest

Первый вариант нам не подходит, у нас нет текущего домена, мы создаём новый. По той же причине второй вариант тоже не подходит. Выбираем Add a new forest. Будем создавать новый лес.

Укажем в Root domain name корневое имя домена. Я пишу ilab.local, это будет мой домен. Next.

Попадаем в раздел Doman Controller Options.

В Forest functional level и Domain functional level нужно указать минимальную версию серверной операционной системы, которая будет поддерживаться доменом.

У меня в домене планируются сервера с Windows Server 2019, Windows Server 2016 и Windows Server 2012, более ранних версий ОС не будет. Выбираю уровень совместимости Windows Server 2012.

В Domain functional level также выбираю Windows Server 2012.

Оставляю галку Domain Name System (DNS) server, она установит роль DNS сервера.

Укажем пароль для Directory Services Restore Mode (DSRM), желательно, чтобы пароль не совпадал с паролем локального администратора. Он может пригодиться для восстановления службы каталогов в случае сбоя.

Не обращаем внимание на предупреждение "A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found. ". Нам не нужно делать делегирование, у нас DNS сервер будет на контроллере домена. Next.

В разделе Additional Options нужно указать NetBIOS name для нашего домена, я указываю "ILAB". Next.

В разделе Paths можно изменить пути к базе данных AD DS, файлам журналов и папке SYSVOL. Без нужды менять их не рекомендуется. По умолчанию:

Database folder: C:\Windows\NTDS
Log files folder: C:\Windows\NTDS
SYSVOL folder: C:\Windows\SYSVOL

В разделе Review Options проверяем параметры установки. Обратите внимание на кнопку View script. Если её нажать, то сгенерируется tmp файл с PowerShell скриптом для установки контроллера домена.

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

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

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

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

Начинается процесс установки.

Сервер будет перезагружен, о чём нас и предупреждают. Close.

Дожидаемся загрузки сервера.

Первоначальная настройка контроллера домена

Наша учётная запись Administrator теперь стала доменной — ILAB\Administrator. Выполняем вход.

Видим, что на сервере автоматически поднялась служба DNS, добавилась и настроилась доменная зона ilab.local, созданы A-записи для контроллера домена, прописан NS сервер.

На значке сети отображается предупреждение, по сетевому адаптеру видно, что он не подключен к домену. Дело в том, что после установки роли контроллера домена DNS сервер в настройках адаптера сменился на 127.0.0.1, а данный адрес не обслуживается DNS сервисом.

Сменим 127.0.0.1 на статический IP адрес контроллера домена, у меня 192.168.1.14. OK.

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

Запускаем оснастку Active Directory Users and Computers. Наш контроллер домена отображается в разделе Domain Controllers. В папкe Computers будут попадать компьютеры и сервера, введённые в домен. В папке Users — учётные записи.

Правой кнопкой на корень каталога, New > Organizational Unit.

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

Внутри создаём структуру нашей компании. Можно создавать учётные записи и группы доступа. Создайте учётную запись для себя и добавьте её в группу Domain Admins.

Рекомендуется убедиться, что для публичного сетевого адаптера включен Firewall, а для доменной и частной сетей — отключен.

Читайте также: