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

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

Перенос ролей контроллера домена

Active Directory насчитывает 5 FSMO ролей, которые отвечают за корректную работу службы каталогов. Смотрим, на каких серверах запущены данные роли с помощью команд в Powershell:

Get-ADForest dmosk.local | ft DomainNamingMaster, SchemaMaster

Get-ADDomain dmosk.local | ft InfrastructureMaster, PDCEmulator, RIDMaster

* где dmosk.local — домен, для которого нужно узнать назначенные роли FSMO.

Если какие-то роли назначены на сервере, который планируется понизить, то необходимо с помощью команды типа:

Проверка состояния AD

На любом из контроллеров домена вводим команду:

Данная команда запустит проверку состояния среды AD и выдаст ошибки, если такие будут. Необходимо обратить внимание на сообщения и, по возможности, решить проблемы.

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

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

С помощью команды get-netadapter -physical узнаем какие интерфейсы присутствуют в системе.

В нашем примере сетевой адаптер Ethernet 2 принадлежит внутренней корпоративной сети, поэтому будем настраивать именно его.

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

Назначим данному интерфейсу статический IP адрес. В нашем примере у нас сеть с префиксом 24 (255.255.255.0), поэтому задаем prefixlength.

Назначим DNS серверы для внутреннего интерфейса Int

Настроим DNS суффикс, чтобы сервер увидел домен ithz.ru

Переименуем компьютер как DC2 и перезагрузим его.

Повышение функционального уровня домена и леса

Теперь мы можем повысить уровень домена и уровень леса до Windoes Server 2012 R2.

Сначала повысим уровень домена:

1. Откроем оснастку “Active Directory Users and Computers”.

2. В контекстном меню домена выберем соответствующий пункт:

3. Выберем уровень “Windows Server 2012 R2”.

4. Мастер предупредит нас о том, что эта операция не обратима:

5. В случае успешного повышения мастер сообщит об этом:

Теперь нам необходимо повысить функциональный уровень леса:

1. Запустим оснастку “Active Directory Domains and Trusts”.

2. В контекстном меню выберем соответствующий пункт:

3. Выберем уровень “Windows Server 2012 R2”:

4. Мастер предупредит о необратимости операции.

5. В случае успешного завершения операции мастер сообщит об этом:

Повышение функционального уровня домена и леса завершено.

После всех предыдущих манипуляций, ждем минут 15-20, чтобы дать новому серверу перенести все настройки и записи в AD со старого. После чего, запускаем на обоих серверах уже знакомые нам утилиты dcdiag и netdiag и убеждаемся в отсутствии ошибок.

Теперь настала очередь перенести Global Catalog на новый сервер. Открываем на новом сервере Active Directory — сайты и службы (Sites and Services) —> Сайты (Sites) —> имя_сайта —> Серверы (Servers). Выбираем новый контроллер домена и в правом окне на объекте NTDS Settings выбираем Свойства (Properties). В появившемся окне ставим галку Global Catalog.

Ждем минут 5-10, в логах должно будет появиться сообщение This domain controller is now a global catalog, после чего можно удалять Global Catalog на старом сервере. Процедура таже, только теперь выбираем старый сервер и снимаем галку Global Catalog.

Как сделать бекап домен контроллера Server 2012 R2

это происходит очень редко, то жить без этой роли инфраструктура тоже может годами.

Кроме того, без Domain naming master не будет работать добавление и удаление разделов каталогов приложений, а также перекрестные ссылки – но это уже совсем экзотика, не думаю что есть смысл об этом писать в рамках этой статьи.

На уровне домена располагаются такие роли:

RID Master

Для каждого Security Principal в домене, генерируется уникальный идентификатор безопасности – SID. В отличии от GUID, SID может меняться, например, при миграции между доменами.

В пределах одного домена, SIDы будут отличаться последним блоком – он называется RID (относительный идентификатор).

При создании нового Security Principal, SID, и, соответственно, RID выдается тем контролером, на котором выполняется создание.

Для того, чтобы предотвратить создание одинаковых RID, каждому контролеру RID marster назначает пул (по-умолчанию 500, но значение можно изменить). Когда у контролера пул приближается к концу (по-умолчанию 100 адресов, также можно изменить) он обращается к RID master, который выдает еще 500 значений.

Всего доступно 2 30 (это 1,073,741,823) RIDов – на первый взгляд это очень много, но если принять во внимание тот факт, что RID не мог быть назначен повторно (создание – удаление – создание объета отнимало 2 RIDa) в ряде случаев разблокировали 31й бит и получали 2,147,483,647 RID’ов.

Об улучшениях, которые были сделаны в 2012 Вы можете подробно узнать тут – http://blogs.technet.com/b/askds/archive/2012/08/10/managing-rid-issuance-in-windows-server-2012.aspx

Посмотреть, что у Вас происходит сейчас можно так:

Таким образом, если контролер с этой ролью будет недоступен, контролеры исчерпавшие выданные им RID-пулы не смогут создавать новых Security Principals.

PDC Emulator

Несмотря на то, что PDC/BDC это термины из далекого NT-прошлого, это наиболее важная FSMO роль в операционной деятельности.

Опустим описание того, как быть с NT машинами, и перейдем к реальным вещам:

1. Источник времени. Синхронизация времени важна для работы Kerberos (и не только), поэтому все контролеры (и, соответственно, клиенты) синхронизируют свое время с PDC, который должен синхронизироваться с внешним NTP. Подробнее о настройке времени в домене я уже писал, можно почитать тут.
2. Сохранение групповых политик по-умолчанию происходит на контролер с ролью PDC, и с него реплицируется на другие контролеры (начиная с 2008 используется DFS).
3. Репликация паролей. Коль уже смена пароля признана важной, реплицируется она не стандартным методом, а так называемым urgent (подробнее о репликации Active Directory – ищите мою статью поиском). Это значит, что контролер, на котором был сменен пароль, срочно реплицируется с контролером, который PDC Emulator. На практике выглядит так: пользователь вводит новый пароль, который ближайший контролер еще не знает. Этот контролер обратится к PDC, и тот подтвердит что пароль правильный, таким образом, предотвращается ряд проблем.

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

Infrastructure Master

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

После всех предыдущих манипуляций, ждем минут 15-20, чтобы дать новому серверу перенести все настройки и записи в AD со старого. После чего, запускаем на обоих серверах уже знакомые нам утилиты dcdiag и netdiag и убеждаемся в отсутствии ошибок.

Теперь настала очередь перенести Global Catalog на новый сервер. Открываем на новом сервере Active Directory — сайты и службы (Sites and Services) —> Сайты (Sites) —> имя_сайта —> Серверы (Servers). Выбираем новый контроллер домена и в правом окне на объекте NTDS Settings выбираем Свойства (Properties). В появившемся окне ставим галку Global Catalog.

Ждем минут 5-10, в логах должно будет появиться сообщение This domain controller is now a global catalog, после чего можно удалять Global Catalog на старом сервере. Процедура таже, только теперь выбираем старый сервер и снимаем галку Global Catalog.

Проверяем содержимое файла hosts

Для сервера с именем ag-dc-2, содержимое должно выглядеть следующим образом:

Убеждаемся что команды

резолвятся на IP 192.168.1.101

резолвится на 127.0.0.1

Проверяем что IP адрес сервера статический.

Для сервера с IP адресом 192.168.1.101, шлюзом расположенном на роутере 192.168.1.1 и днс сервером на контроллере домена, они должны выглядеть следующим образом:

Резервный контроллер домена Linux – Валидный resolv.conf

Никакие утилиты не должны модифицировать файл /etc/resolv.conf.
Команда

должна выводить следующее. Полноценный независимый фаел:

Если вместо нормального вывода вы видите симлинк:

Необходимо отключить и убрать из автозапуска systemd-resolved

И создать чистый файл

Указав в нём адрес локального DNS сервера способного разрешать имена локальной зоны. Для сервера ag-dc-2, находящегося в домене adminguide.lan. Под управлением контроллера с именем ag-dc-1 и IP 192.168.1.100. На данном этапе, содержимое /etc/resolv.conf должно быть следующим:

192.168.1.100 – адрес уже работающего в сети DNS сервера поднятого на первом контроллере домена.
Обязательно перезагрузите сервер и убедитесь что resolv.conf и его содержимое остались на месте.

Убеждаемся в отсутствии самбовых процессов

Если что-то есть – на нож. Весь сервер. Потом переходим к пункту “Устанавливаем Ubuntu Server 18.04”

Убеждаемся что вы настраиваете Ubuntu Server 18.04.

Чистый, только что установленный. Который не использовался ранее ни под какие нужды. Что это не ваша домашняя станция на какой-нибудь богомерзкой макоси. Не сервер в продакшене под полезной нагрузкой. Что вы знаете что делаете и зачем это делаете. А то мало ли. Были прецеденты. Потом люди обижаются. В стиле “У вас тут написано “На только что развёрнутом сервере, зайдите в домашнюю папку и выполните sudo rm rf ./*”. Я сделал ровно это же только на своём домашнем NAS сервере в папке где у меня хранятся все все все мои самые ценные данные за всю мою жизнь и всё удалилось! Как вы можете писать такое в мануалах!”. Потому убедитесь что это ваш чистый, только что поднятый сервер. Если вы делаете всё в первые, убедитесь что это не прод!