Глава 6. Миграция в Active Directory 2022

Содержание

В своих предыдущих главах мы рассматривали компоненты инфраструктуры AD (Active Directory) и изучали как применяя их проектировать некую инфраструктуру идентификации. Теперь самое время рассмотреть установку AD DS (Active Directory Domain Services). Это прекрасно когда мы можем спроектировать и реализовать некую инфраструктуру идентификацию с нуля, однако основная масса организаций уже обладает некой средой Active Directory. По этой причине, для нас как для инженеров, в большинстве случаев будет рассматриваться миграция вместо установки совершенно нового проекта. Помимо миграции мы также работать над расширением своего текущего проекта AD для его соответствия новым требованиям ведения дел (к примеру, создание нового домена, введение новой площадки AD, интеграция с Azure AD и тому подобное) или же исправление имеющихся проблем решения (скажем, изменение имеющегося имени домена, работа со слияниями и поглощениями). Во всех этих ситуациях нам может потребоваться добавлять новые Контроллеры домена и эти шаги установки во многом одни и те же. Помимо различных ситуаций развёртывания AD DS мы также рассмотрим в этой главе такие темы:

Предварительные требования установки AD DS
Проверка жизнеспособности AD DS
Как планировать миграцию некого Active Directory
Как выполнять миграцию в AD DS 2022 из Windows Server 2008 R2
Как подтверждать успешность установки и миграции

Установка роли AD DS достаточно простой процесс. Однако существуют определённые предварительные требования, которые нам необходимо рассмотреть прежде чем продолжать установку и настройку роли AD DS.

Предварительные требования установки AD DS

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

Требования к оборудованию

В современных инфраструктурах большинство рабочих нагрузок запускается в виде виртуализированных сред. Кое- кто всё ещё полагает, что лучше содержать в инфраструктуре AD по крайней мере один физический Контроллер домена, но это не так. В ранние дни виртуализации я бы до некоторой степени согласился, но теперь технологии сильно продвинулись. Мы можем содержать все Контроллеры домена в качестве виртуальных Контроллеров домена. Однако, если такое потребуется, ниже приводятся минимальные требованиями к оборудованию для AD DS 2022 :

64- битный процессор 1.4ГГц
2ГБ ОЗУ
Некий адаптер хранилища, который поддерживает архитектуру PCI Express (Windows Server 2022 не поддерживает для загрузки, данных или устройств страниц IDE/ATA/PATA/EIDE)
32ГБ свободного пространства
1х сетевой адаптер
Устройство DVD или поддержку сетевой/ USB загрузки

Требования к виртуальной среде

В наши дни виртуальные решения позволяют организациям варианты для выбора когда речь заходит о виртуализации. Они могут либо построить свои собственные частные облачные решения применяя такие решения как Hyper-V или VMware, либо воспользоваться поставщиками общедоступных облачных решений, таких как Microsoft Azure или AWS. Если требуется, они также имеют возможность поддержки "гибридной" установки или установки со "множеством облачных решений", когда они могут воспользоваться всем лучшим из обоих (частного и общедоступного облачного решений). AD DS 2022 поддерживает оба указанных сценария.

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

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

64- битный процессор 1.4ГГц
2ГБ ОЗУ
Виртуальный контроллер хранилища SCSI
32ГБ свободного пространства
1х виртуальный сетевой адаптер

В зависимости от вашего поставщика виртуальных услуг, будут иметься особые руководства для виртуальных контроллеров домена. Всегда следуйте им, чтобы воспользоваться большинством из них. Это применимо также и к общедоступному облачному решению. Давайте двинемся далее и рассмотрим что нам следует принимать во внимание при развёртывании Контроллера домена в Azure/

В Главе 3, Проектирование инфраструктуры Active Directory мы рассмотрели за и против для того когда мы развёртываем виртуальные контроллеры домена. За дополнительными сведениями обратитесь к этой главе.

Рекомендации по установке контроллера домена в Microsoft Azure

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

Мы можем установить роль AD DS в ВМ, запущенной в Azure. Это полностью поддерживаемое развёртывание. Тем не менее, есть ряд моментов, которые надлежит принять о внимание прежде чем развёртывать виртуальные Контроллеры домена в Azure. Когда вы применяете Межсетевой экран Azure или естественную Network Security Group (NSG), убедитесь что вы разрешили относящиеся к делу порты, которые применяет AD DS. Необходимые требования к портам доступны в следующем документе: https://bit.ly/3HIU60i.
Вы можете выбрать любой размер ВМ, который удовлетворяет вашим потребностям работы и бюджета.
Для базы данных NTDS, папок SYSVOL и файлов журналов пользуйтесь отдельным диском данных.
Установите для этого диска данных Host Cache Preference в значение None для отключения кэширования обратной записи, которое может вызывать конфликты с работой AD DS.
Для своего Контроллера домена назначайте статичный IP адрес. Настройку значения статического IP адреса необходимо выполнять на уровне настройки ВМ, а не на уровне настроек операционной системы. После завершения настройки обновите установки DNS виртуальной сети значением этого IP адреса Контроллера домена. Это позволит вам добавлять ВМ в этот домен применяя ту же самую виртуальную сетевую среду:

Рисунок 6-1

Источники времени
НЕ назначайте общедоступные IP адреса Контроллеру домена, по причине риска безопасности.
Azure Availability Zones предлагает высокую доступность для данных и приложений. В регионе Azure могут иметься один или более Центров обработки данных (ЦОД). Azure Availability Zones собирается из одного или более ЦОД в одном и том же регионе Azure, что имеет независимость электропитания, оборудования, сетевой среды и охлаждения. Все службы избыточных зон будут реплицировать данны и приложения по Availability Zones (Зонам доступности) для высокой надёжности. Каждый регион Azure содержит минимум три Azure Availability Zones.
Azure также обладает множествами доступности, которые вы можете применять для репликации ВМ на различное оборудование в одних и тех же Availability Zones. Оба эти решения снабжают ВМ Azure высокой доступностью. Рекомендуется запускать по крайней мере два Контроллера домена и добавлять их в Availability Zones или в множество доступности.
Площадка AD может быть физическим расположением или отдельной сетевой средой. Площадки AD помогают компьютерам находить ближайший Контроллер домена. Дополнительные сведения об этом вы можете обнаружить в Главе 11, Службы Active Directory - Часть 01. Для представления Контроллеров домена и подсетей Azure рекомендуется создавать отдельную площадку AD.
Microsoft также рекомендует не помещать роли Flexible Single Master Operation (FSMO) в Контроллерах домена на основе Azure. Однако я не смог найти веских причин для этой рекомендации, если только вы не работаете в гибридной среде и большинство рабочих нагрузок по- прежнему выполняются локально. Кроме того, если связь между локальной средой и Azure нестабильна, это также является хорошей причиной не переносить роли FSMO на контроллеры домена на базе Azure.
Не останавливайте запущенный в Azure Контроллер домена при помощи портала Azure. Всегда выполняйте останов/ перезапуск на уровне гостевой операционной системы. Это предотвратит такие проблемы, как переполнение пула Relative ID (RID).

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

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

Версия операционной системы и режим установки: Windows Server 2022 обладает версиями Стандартной и Датацентра. AD DS доступны под обеими версиями, однако важно принять решение и подобрать лицензии с учётом на будущее. Windows Server 2022 поддерживает два режима установки. Сервер с практикой работы рабочего стола выступает стандартным методом установки {Прим. пер.: Так в тексте, видимо, автор подразумевает, что этот метод обычно выбирают операторы. Методом по умолчанию для установки Windows Server 2016/2019/2022 выступает Сервер ядра}. Ролями и операциями сервера можно управлять также при помощи GUI или команд. Метод Сервера ядра (Server Core) также поддерживает AD DS. Сервер ядра не обладает графическим интерфейсом и это снижает размер отпечатка операционной системы. Это также снижает поверхность атак на установленную инфраструктуру идентификации.

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

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

Совет

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

Имена домена и Леса: В процессе установки AD DS нам требуется задать значения имени домена и названия Леса. В организации важно согласовать эти названия с управлением прежде чем начинать процесс установки. Эти сведения могут быть добавлены в ваш документ проекта Active Directory и предоставлены на утверждение. В давнем 2015 я написал статью в своём блоге относительно процесса переименования. Удивительно, но это всё ещё топовый пост в моём блоге. Наиболее частая причина для изменения имени домена заключается в исправлении неких наследуемых ошибок в именовании, либо по причине действий слияния и приобретения. В любом случае, следует по возможности избегать переименования домена. Когда требуется переименование домена, основная рекомендация состоит в применении метода миграции. Некоторые организации применяют для именования своих доменов .local (non-routable domain, домен без маршрутизации). Если мы расширим локальную инфраструктуру AD с доменом без маршрутизации, нам придётся добавлять дополнительные User Principle Names (UPN, начальные имена пользователей) с маршрутизированным доменным именем и заставлять пользователей применять их. Поэтому хорошей практикой в первую очередь является применение маршрутизируетмых.
Выделенные IP адреса: Контроллеры домена должны использовать выделенные статические IP адреса. Прежде чем приступать к установке, назначьте Контроллерам домена статические IP адреса и проверьте связь с ними. IP адреса контроллера домена Active Directory в случае необходимости могут быть изменены позднее, однако рекомендуется избегать этого как можно дольше.
Мониторинг: После того как AD DS установлен, нам требуется отслеживать производительность системы, жизнеспособность репликации и целостность компонентов и служб для выявления потенциального воздействия на службу и узкие места. Рекомендуемыми инструментами мониторинга являются Microsoft SCOM (System Center Operations Manager) и Azure Sentinel, ибо они содержат модули, которые целенаправленно были спроектированы для выявления как проблем уровня служб, так и проблем уровня безопасности.
Резервное копирование/ восстановление при сбоях: Наличие высокой доступности инфраструктуры идентификации обязательно для работы организации, так как от неё зависят многие службы, приложения и прочие компоненты компании. Следовательно, нам требуется планировать как оставлять свою инфраструктуру идентификации работающей при возникновении бедствий, причём с минимальным воздействием на деятельность. Существуют различные технологии и службы, которые могут применяться для резервного копирования контроллеров домена Active Directory, причём некоторые из них оцениваются в Главе 11, Службы Active Directory - Часть 01. После того как вы определите какое именно решение вы намерены применять, вам также потребуется спланировать периодические проверки DR (восстановления в случае сбоя) чтобы проверять допустимость данного решения. Общеупотребимой практикой для сопровождения высокой доступности является запуск по крайней мере двух Контроллеров домена на одной физической площадке. Необходимость полного восстановления Контроллера домена из резервной копии это крайне редкое событие для кого бы то ни было.
Защита от вирусов в Контроллерах домена: Как и любая иная система, Контроллеры домена также могут подвергаться воздействию вредоносного кода. Существуют дискуссии относительно того должны ли Контроллеры домена Active Directory иметь установленным антивирусное программное обеспечение или нет, однако в имеющейся документации Microsoft я никогда не находил ничего говорящего о том, что им не следует иметь антивирусного программного обеспечения. Всегда проверяйте у своего поставщика антивирусного решения будет ли это решение поддерживать защиту контроллеров домена Active Directory. В зависимости от производителя, мы можем исключать определённые файлы каталоги из проводимого сканирования.

Методы установки AD DS

Существует два метода, которые мы можем применять для установки контроллеров домена Active Directory;

При помощи графического интерфейса Windows: После того как Microsoft представил Диспетчер сервера (Sever Manager) в Windows Server 2008, весь процесс установки AD DS упростился. Чтобы установить необходимый AD DS при помощи GUI Windows, вам требуется установить соответствующую роль AD DS при помощи Диспетчера сервера. После завершения этого мы можем запустить соответствующий мастер настройки AD DS:

Рисунок 6-2

Роль сервера AD DS

Следующий снимок экрана отображает такой Active Directory Domain Services Configuration Wizard (Мастер настройки служб домена Active Directory):

Рисунок 6-3
Применяя PowerShell: Вплоть до Windows Server 2012, AD DS можно было настраивать при помощи файлов DCPromo unattended (не сопровождаемого DCPromo). Этот инструмент DCPromo применялся для настройки AD DS и, применяя некий текстовый файл, имелась возможность передавать необходимые значения настроек. Это избавляло от взаимодействия с пользователем при настройке AD DS. В Windows Server 2012 DCPromo был заменён на PowerShell. Теперь для установки и настройки AD DS мы можем применять сценарий PowerShell. В данной главе для развёртываний мы будем пользоваться PowerShell.

Сценарии развёртывания AD DS

В этом разделе мы намерены рассмотреть различные сценарии установки AD DS.

Установка нового домена корня Леса

Для своего первого сценария я намерен продемонстрировать как установить совершенно новый Лес Active Directory. Это будет самый первый Контроллер домена в некой новой инфраструктуре идентификации. Чтобы убедиться что вы выполнили свою домашку прежде чем кликнуть по кнопке установки, вы можете свериться со следующим контрольным списком.

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

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

Выработать документ проекта Active Directory.
Подготовить физические/ виртуальные ресурсы для своего контроллера домена.
Установить Windows Server 2022 Standard/Datacenter.
Внести в свои серверы самые последние обновления Windows.
Назначить выделенный IP адрес для своего контроллера домена.
Установить роль AD DS.
Настроить AD DS в соответствии со своим проектом.
Просмотреть имеющиеся журналы для проверки жизнеспособности установки и настройки AD DS.
Настроить мониторинг службы и производительности.
Настроить резервное копирование/ DR (восстановление после сбоев) AD DS.
Разработать системную документацию.

Предыдущий контрольный список охватывает основные моменты, которые необходимо принимать во внимание при развёртывании новых AD DS. Однако, в зависимости от бизнес- требований и политик вам может потребоваться добавить в этот список дополнительные шаги.

Проектирование топологии

Как мы можем видеть из следующей схемы, в данном сценарии rebeladmin.com будет корневым доменом нашего леса:

Рисунок 6-4

Топология проекта - свежая установка AD DS

Самый первый контроллер домена, который устанавливается в первом лесу будет содержать все пять ролей FSMO (Flexible Single Master Operation, Гибких операций с единственным хозяином). В своей предыдущей главе мы изучили размещение ролей FSMO, а также как эти роли могут мигрировать в лучшее местоположение по мере того как в этот домен добавляются дополнительные Контроллеры домена.

Этапы установки

Здесь я продемонстрирую как устанавливать самый первый контроллер в первом Лесе. Эти шаги демонстрации основываются на Windows Server 2022:

Зарегистрировать этот сервер как участника группы локального администратора.
В этот момент проверить значение выделения статического адреса IP применив ipconfig /all.
Запустить консоль PowerShell от имени администратора.
Перед собственно процессом настройки нам требуется установить в этом конкретном сервере роль AD DS. Для этого мы можем воспользоваться такой командой:
```
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
		
```
Для завершения установок служб этой роли нам не требуется перезагрузка.

Теперь, когда у нас имеется установленной роль AD DS, наш следующий шаг состоит в выполнении необходимых настроек:


Install-ADDSForest
-DomainName "rebeladmin.com"
-CreateDnsDelegation:$false
-DatabasePath "C:\Windows\NTDS"
-DomainMode "7"
-DomainNetbiosName "REBELADMIN"
-ForestMode "7"
-InstallDns:$true
-LogPath "C:\Windows\NTDS"
-NoRebootOnCompletion:$True
-SysvolPath "C:\Windows\SYSVOL"
-Force:$true

Совет

	Совет
Для нашей предыдущей команды нет никаких разделителей строк; я перечислил их таким образом чтобы вы ясно увидели все параметры. В нашей предыдущей команде можно заменить значения `-DomainName` и `-DomainNetbiosNames` именами домена и NetBIOS из вашей среды.

Для нашей предыдущей команды нет никаких разделителей строк; я перечислил их таким образом чтобы вы ясно увидели все параметры. В нашей предыдущей команде можно заменить значения -DomainName и -DomainNetbiosNames именами домена и NetBIOS из вашей среды.

Приводимая далее таблица поясняет команды PowerShell и что они делают:

Таблица 6-1. Командлет PowerShell установки AD DS
Командлет	Описание
`Install-WindowsFeature`	Этот командлет позволяет нам установить роли Windows, роль служб или свойства Windows в неком локальном или удалённом сервере. Он аналогичен Диспетчеру сервера Windows для их установки.
`Install-ADDSForest`	Этот командлет позволяет нам настроить некий новый лес Active Directory.

Наша следующая таблица поясняет значения параметров для команд и что они выполняют:

Windows Server 2016.

Таблица 6-2. Параметры командлета PowerShell установки AD DS
Параметр	Описание
`-IncludeManagementTools`	Устанавливает необходимые инструменты управления для выбранной службы роли.
`-DomainName`	Данный параметр определяет значение FQDN для домена Active Directory.
`-CreateDnsDelegation`	При помощи этого параметра мы можем задать будем ли мы создавать делегирование DNS, которое ссылается на интегрированный DNS Active Directory.
`-DatabasePath`	Этот параметр определяет значение пути папки для хранения файла базы данных Active Directory (`ntds.dit`).
`-DomainMode`	Данный параметр задаёт функциональный уровень домена Active Directory. В своём предыдущем примере я применяю режим `7`, которым выступает Windows Server 2016.
`-DomainNetbiosName`	Выставляет значение имени NetBIOS для данного корневого домена леса.
`-ForestMode`	Этот параметр определит функциональный уровень домена Active Directory. В своём предыдущем примере и применил режим `7`, которым выступает Windows Server 2016.
`-InstallDns`	Применяя это мы способны задавать будет ли требоваться установка роли DNS в данном контроллере домена. Для некого нового леса необходимо чтобы вы устанавливали значение в `$true`.
`-LogPath`	Путь журнала может применяться для задания значения местоположения, в которм вы храните файлы журналов домена.
`-SysvolPath`	Применяется для определения значения папки `SYSVOL`. Устанавливаемым по умолчанию местоположением будет `C:\Windows`.
`-NoRebootOnCompletion`	По умолчанию данная система перезапустит свой сервер после настройки контроллера домена. При помощи данной команды можно предотвращать автоматическую перезагрузку системы.
`-Force`	Данный параметр принудит команду выполняться, игнорируя получаемые предупреждения. Для устанавливаемой системы типично передавать предупредительные сообщения относительно наилучших практических приёмов и рекомендаций.

После своего выполнения эта команда выдаст вам приглашение для SafeModeAdministratorPassword. Он применяется в DSRM (Directory Services Restore Mode, Режиме восстановления Служб каталога). Убедитесь что вы применяете сложный пароль (в соответствии с рекомендациями к сложности паролей Windows). Отказ в выполнении этого остановит настройку.
После завершения настройки перезагрузите свой Контроллер домена и зарегистрируйтесь в нём снова в качестве Администратора его домена.
Давайте осуществим дальнейшую проверку чтобы убедиться в успешности установки всех служб:
```
Get-Service adws,kdc,netlogon,dns
		
```
Наша предыдущая команда перечислит текущее состояние запущенных служб, относящихся к Active Directory в этом контроллере домена:

Рисунок 6-5

Состояние относящихся к AD служб
Наша следующая команда перечислит подробности настроек данного контроллера домена:
```
Get-ADDomainController
		
```
Приводимый далее снимок экрана отображает вывод такой команды:

Рисунок 6-6

Подробности Контроллера домена AD
Представляемая далее команда выдаст список сведений относительно текущего домена Active Directory:
```
Get-ADDomain rebeladmin.com
		
```
Точно так же Get-ADForest rebeladmin.com выдаст перечень всех подробностей установленного леса Active Directory.
Приводимая ниже команда покажет будет ли этот контроллер домена совместно использовать свою папку SYSVOL:

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

Установка дополнительного контроллера домена

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

Имеющаяся установка: Прежде чем предлагать соответствующий физический сервер или ВМ, которые вы намерены использовать в качестве некого дополнительного Контроллера домена, его требуется добавить в уже имеющийся домен Active Directory. Когда такой дополнительный Контроллер домена намерен выступать в роли некого DNS сервера, установите его собственный IP адрес в качестве первичного сервера DNS в установках NIC, а IP адрес уже имеющегося Контроллера домена в качестве вторичного сервера DNS. В процессе установки это потребуется для наличия подключения к уже имеющимся Контроллерам домена (через LAN или WAN) для репликации имеющихся данных Active Directory.

Замечание

По умолчанию, в процессе установки ваша система попытается выполнить репликацию с уже имеющихся разделов Active Directory из любого из доступных Контроллеров домена. Когда это происходит через некое медленное WAN соединение, это окажет воздействие на сам процесс установки. Следовательно, при таком сценарии Active Directory может устанавливаться при помощи установочного носителя. Он аналогичен некой резервной копии Active Directory с существующего Контроллера домена. Далее система воспользуется локальным носителем для репликации всех изначальных сведений Active Directory. Это подробно поясняется в Главе 11, Службы Active Directory - Часть 01.

Для добавления некого дополнительного контроллера домена нам требуется знать определённую информацию относительно имеющейся инфраструктуры Active Directory, например, следующее:

Название этого домена Active Directory
Название площадки Active Directory
Будет ли необходим этот дополнительный контроллер домена в качестве некого сервера глобального каталога, сервера DNS или RODC (read-only domain controller, Доступного только на чтение контроллера домена)
Изначальный источник синхронизации данных Active Directory (некий особый контроллер домена Active Directory, либо установочный носитель)

Подготовка схемы и подготовка домена: Давайте предположим, что у нас имеется некая инфраструктура Active Directory на основе Windows Server 2012 R2. В этом случае нам требуется добавить некий контроллер домена, но он нам требуется для применения Windows Server 2022. Всякая версия Active Directory имеет отличающуюся схему. По умолчанию схема AD DS 2012 R2 не будет распознаваться тем контроллером домена, который запущен под Windows Server 2022.

Прежде чем начнётся реальная настройка, необходимо видоизменить имеющуюся схему для поддержки такого нового требования. Это выполняется при помощи файла adprep.exe, который поступает в самих исходных файлах операционной системы. Вплоть до Windows Server 2012 этот файл приходилось копировать в имеющегося хозяина схемы, а для подготовки соответствующих домена и Леса нам приходилось запускать /domainprep и /forestprep. Однако, на момент написания книги, он поставляется как часть имеющейся настройки AD DS и он будет выполнять эти команды в фоновом режиме. Для осуществления этого сам процесс настройки данного домена следует запускать от имени Администратора схемы (Schema Admin) или Администратора предприятия (Enterprise Admin).

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

Когда вы желаете установить некий дополнительный контроллер домена, можно воспользоваться следующим контрольным списком:

Подготовить физические/ виртуальные ресурсы для своего контроллера домена.
Установить Windows Server 2022 Standard/Datacenter.
Внести в свои серверы самые последние обновления Windows.
Назначить выделенный IP адрес для своего Контроллера домена.
Добавить этот Контроллер домена в уже имеющийся домен Active Directory в качестве участника домена
Отыскать сведения относительно имеющихся площадок домена и установленном первоначальном методе репликации
Зарегистрироваться в этом сервере с некой привилегированной учётной записью (такой как Администратор схемы - Schema Admin или Администратор предприятия - Enterprise Admin)
Установить роль AD DS.
Настроить AD DS.
Просмотреть имеющиеся журналы для проверки жизнеспособности установки и настройки AD DS.
Настроить мониторинг службы и производительности.
Настроить резервное копирование/ DR (восстановление после сбоев) AD DS.

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

Проектирование топологии

Мы намерены добавить в rebeladmin.com некий дополнительный Контроллер домена в соответствии со следующей схемой:

Рисунок 6-7

Топология проекта - дополнительный Контроллер домена

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

Этапы установки

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

Зарегистрируйтесь в выбранном сервере от имени участника группы Администраторов Схемы или Предприятия.
На данном этапе проверьте выделение статического IP адреса при помощи ipconfig /all.
Запустите от имени администратора консоль PowerShell.

Установите необходимую службу роли AD DS:


Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

После успешной установки службы роли, следующий шаг преследует цель настройки этого Контроллера домена:


Install-ADDSDomainController
-CreateDnsDelegation:$false
-NoGlobalCatalog:$true
-InstallDns:$true
-DomainName "rebeladmin.com"
-SiteName "Default-First-Site-Name"
-ReplicationSourceDC "REBEL-SDC01.rebeladmin.com"
-DatabasePath "C:\Windows\NTDS"
-LogPath "C:\Windows\NTDS"
-NoRebootOnCompletion:$true
-SysvolPath "C:\Windows\SYSVOL"
-Force:$true

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

Таблица 6-3. Параметры командлета PowerShell установки дополнительного контроллера домена
Параметр	Описание
`Install-ADDSDomainController`	Данный командлет установит необходимый Контроллер домена в имеющейся инфраструктуре Active Directory.
`-NoGlobalCatalog`	Когда вы не желаете создавать свой Контроллер домена как некий сервер Глобального каталога, можно применить данный параметр. По умолчанию ваша система разрешает функциональность Глобального каталога.
`-SiteName`	Этот параметр может применяться для задания необходимого названия площадки Active Directory. Значением по умолчанию выступает `Default-First-Site-Name`.
`-DomainName`	Данный параметр определяет значение FQDN для домена Active Directory.
`-ReplicationSourceDC`	Вы можете применять данный параметр для определения необходимого источника репликаций Active Directory. По умолчанию будет применяться любой доступный Контроллер домена, хотя вы можете предписать своё пожелание.

После своего исполнения данная команда запросит значение SafeModeAdministratorPassword. Воспользуйтесь для ввода неким сложным паролем. Он будет применяться для DSRM {восстановления в случае сбоя}.
По завершению настройки перезапустите эту систему и зарегистрируйтесь в ней снова в качестве Администратора для проверки состояния этого AD DS.
Следующая команда подтвердит значение состояния запущенной службы AD DS:
```
Get-Service adws,kdc,netlogon,dns
		
```
Ещё одна команда перечислит все Контроллеры домена, причём вместе с их IP адресами и названиями площадок, к которым они относятся:
```
Get-ADDomainController -Filter * | Format-Table Name, IPv4Address, Site
		
```
Приводимая далее команда выдаст список имеющихся серверов Глобального каталога, которые доступны в этом домене и подтвердит что данный сервер Контроллера домена не является сервером Глобального каталога:
```
Get-ADDomainController -Discover -Service "GlobalCatalog"
		
```
В соответствии с нашим планом, наш следующий шаг состоит в перемещении роли Хозяина инфраструктуры в наш новый контроллер домена:
```
Move-ADDirectoryServerOperationMasterRole
-Identity REBEL-SDC-02
-OperationMasterRole InfrastructureMaster
		
```
Воспользовавшись командой netdom query fsmo мы можем удостовериться в этом изменении.

Это завершает наш сценарий.

Как планировать миграцию Active Directory

Миграция Active Directory с более старой версии на новую это одно из распространённых требований для любой инфраструктуры идентификации. С течением времени операционные системы прекращают поддерживаться. Даже если организация не ищет реализации новых функциональных возможностей, порой им приходится мигрировать на более новую версию когда применяемая операционная система прекращает поддерживаться. При типичном процессе миграции некая новая версия AD DS будет устанавливаться на какой- то новый сервер. Затем все роли FSMO выполнят миграцию в такие новые Контроллеры домена.

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

Может иметься множество причины почему организации пожелают рассмотреть миграцию Active Directory. Я перечислил несколько причин, вот они:

Для реализации новых свойств в имеющейся инфраструктуре идентификации: Всякая новая версия Active Directory поступает с новыми свойствами и расширениями. Некоторые из таких изменений меняют всю игру. В качестве примера, управление привилегиями AD DS 2016 является поворотной точкой для инфраструктур идентификации. Для реализации этих новых свойств компании и рассматривают возможность миграции AD DS.

На момент написания этой книги на горизонте имеется новая версия Windows Server. Я чокнутый и я всегда предпочитаю запускать всё самое новое и самое великое. В то же самое время я наблюдал что некоторые организации просто любят запускать самое последнее, однако не придают большого значения тому как реализованы какие- то новейшие функции. Простая миграция на некую новую версию не даст вам никаких преимуществ, если не будет применяться как следует. Нет никакого смысла покупать Феррари просто чтобы подбрасывать своих ребятишек в школу. Таким образом, "миграция" хороший момент для оценки имеющейся установки и чтобы посмотреть на то, как мы можем дополнительно улучшиться при помощи новой версии Active Directory.
Для решения проблем поддержки и проблем совместимости: В далёком 2015 Microsoft завершил поддержку Windows Server 2003. Со временем у организаций, которые работали с AD DS 2003 не осталось иного выбора, кроме как выполнить миграцию на более новую версию. Некоторым предприятиям необходимо соблюдать это для осуществления своей деятельности. Хорошим образцом этого является бизнес в финансовом секторе. Такие соответствия имеют стандарты, связанные с ИТ системами. Просто для примера, у предприятий, подчинённых требованиям индустрии платёжных карт (PCI, Payment Card Industry), имелись правила, которые устанавливали, что они не могут применять операционные системы с истекшим сроком жизни для своей деятельности. Такие виды бизнес- требований принуждают организации переходить с одной версии AD DS на другую.
Для исправления имеющихся проблем: Хорошая жизнеспособность инфраструктуры идентификации является ключом для операций и безопасности всякой организации. Как и для любой иной системы, существует вероятность наличия проблем и для установленной инфраструктуры идентификации. Это может быть обусловлено неверным проектом, проблемами с настройкой, разрушениями системы и тому подобным. Исправление таких проблем также может повлечь за собой миграцию. Когда я обслуживаю свою машину, порой персонал сообщает мне что некоторые детали следует поменять. Однако прежде чем такие детали будут заменены, хороший механик обычно предоставит мне несколько вариантов. Некоторые детали являются той же самой моделью, в то время как прочие могут иметь некую новую версию. Следовательно этому механику несомненно следует пояснить те преимущества такой новой модели и что они способны мне предоставить, вместо того чтобы просто решить имеющуюся проблему. В большинстве случаев я в конечном счёте применяю новую модель, так как она не просто решает имеющуюся проблему, но и делает это наилучшим образом. Поэтому, когда имеющаяся проблема инфраструктуры идентификации может быть исправлена лучшим способом через миграцию на более новую версию, не сомневайтесь чтобы сделать именно так. Однако, в то же самое время, существует ряд базовых требований жизнеспособности AD, которым необходимо полностью соответствовать прежде чем выполнить такую миграцию. Они будут рассмотрены позднее в этой главе.
Рабочие требования: В предприятии могут иметься разнообразные рабочие требования, которые могут повлечь за собой миграцию. Новые реализации приложения являются хорошим примером этого. Некоторые приложения поддерживают лишь определённые версии схемы AD DS. В таком случае у предприятия нет никакой иной возможности помимо обновления. Существуют и прочие сценарии, которые применимы к организациями, в которых работают леса AD со множеством деревьев доменов. Как пример, Rebeladmin Corp. имеет три дерева доменов с единственным лесом. Каждое дерево домена представляет собой отдельную дочернюю компанию со своим собственным ИТ подразделением.

Одна компания имеет бизнес- требования на обновления своих функциональных уровней домена и леса на более новую версию. Однако для выполнения этого прочие двум доменам также требуется обновлять их версии AD DS. Хотя это и не является рабочими требованиями для этих двух компаний, для поддержки обновления уровня их Леса нет никакого иного варианта кроме обновления их AD DS.

Жизненный цикл миграции

Миграция ролей FSMO на новый сервер и обновление уровней функциональности Леса и домена не отнимает более нескольких минут, однако когда дело доходит до миграции, имеется ряд прочих моментов, которые нам надлежит рассмотреть. Таким образом, я суммировал процесс миграции конкретного AD DS в соответствующий жизненный цикл. Я назвал его жизненным циклом, потому как организации продолжают выполнять миграцию по крайней мере для освобождения от устаревших операционных систем:

Рисунок 6-8

Жизненный цикл миграции AD

Следование обозначенным здесь этапам гарантирует что будут охвачены все стороны самого процесса миграции.

Аудит

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

Логическая и физическая топологии Active Directory

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

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

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

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

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

Логическая топология Active Directory
Физическая топология Active Directory
Сетевая топология организации
Соединения между площадками Active Directory
Полосы пропускания между площадками Active Directory

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

Проверка жизнеспособности Active Directory

Моей первой машиной была Honda Civic (я любил эту маленькую бестию). После приобретения машины я заметил небольшие пятна ржавчины на капоте. Я отправил её в цех покраски и, проверявший её специалист сказал, что ей требуется новый слой покраски. Я согласился и мы сделали это. Через несколько месяцев я вновь начал наблюдать пузыри на капоте. Я опять сдал её в магазин, поскольку у меня имелась шестимесячная гарантия на выполненную работу. Они сказали, что переделают работу по покраске. Но угадайте что произошло дальше - через несколько месяцев вновь возникла та же самая проблема. Больше я не хотел тратить своё время впустую, а потому сдал машину в другое место, которое специализировалось именно на работах по покраске. Когда я пояснил суть проблем, с которыми я столкнулся, их инженеры провели ряд тестов и сказали, что вначале им требуется удалить всю покраску и нанести антикоррозионное покрытие, что они и выполнили. После этого на капоте больше не появлялись пузырьки. Простое нанесение нового слоя краски не решало проблему. Это была лишь трата времени и средств.

Когда в имеющейся инфраструктуре Active Directory возникли проблемы, связанные с её основными операциями (такими как репликация, DNS и связи между площадками), их требуется выявить и исправить до осуществления миграции. Не существует раз и навсегда заданной предварительно последовательности для проверок работоспособности Active Directory. У вас может иметься свой собственный список для контроля. Ниже приводятся некоторые ключевые области, которые необходимо учитывать при всякой проверке жизнеспособности Active Directory:

Работоспособность репликаций: Жизнеспособность репликаций критически важна для любой инфраструктуры Active Directory. Все контроллеры домена в имеющейся инфраструктуре должны иметь сведения относительно всех изменений в установленной базе данных Active Directory. Для выявления имеющихся проблем в репликациях между контроллерами домена Active Directory имеются различные инструменты и техники. Встроенным инструментом Microsoft для диагностики проблем репликаций Active Directory является Repadmin.exe. Начиная с Windows Server 2008, он поступает встроенным в саму операционную систему и он может применяться при установленной роли AD DS. Этот инструмент требуется запускать от имени Администратора предприятия (Enterprise Admin). Когда он запускается от имени Администратора домена, его можно применять лишь для обзора репликаций уровня домена:
```
Repadmin /showrepl
		
```
Наша предыдущая команда отобразит значение состояния самой последней внутренней репликации имеющегося раздела Active Directory. Она перечислит лишь значение состояния репликации того контроллера домена, с которого выполняется данная команда.

Когда вам требуется проверить состояние репликации определённого контроллера домена, вы можете воспользоваться аналогичной приводимой ниже командой. REBEL-SDC-03 можно заменить названием интересующего вас контроллера домена:
```
Repadmin /showrepl REBEL-SDC-03
		
```
Параметр /replicate можно применять для включения некой репликации между указанными контроллерами домена, чтобы вы могли наблюдать получаемые результаты в реальном масштабе времени:
```
Repadmin /replicate REBEL-SDC-03.rebeladmin.com REBEL-PDC-01.rebeladmin.com DC=rebeladmin,DC=com
		
```
Наша предыдущая команда инициирует репликацию соответствующего контекста с названием rebeladmin с REBEL-PDC-01 на REBEL-PDC-03.

Приводимая далее команда инициирует полную репликацию всех имеющихся изменений с REBEL-PDC-01 на REBEL-PDC-03:
```
Repadmin /replicate REBEL-SDC-03.rebeladmin.com REBEL-PDC-01.rebeladmin.com DC=rebeladmin,DC=com /full
		
```
Параметр /replsummary может применяться с тем, чтобы вы могли видеть общий итог полученного состояния репликации всех имеющихся контроллеров домена:
```
Repadmin /replsummary
		
```
Наша предыдущая команда предоставит резюме всех контроллеров домена в установленной инфраструктуре.

Ещё одна приводимая далее команда перечислит лишь те контроллеры домена, которые имеют проблемы репликаций с прочими контроллерами:
```
Repadmin /replsummary /errorsonly
		
```
Контроллеры домена Windows Server 2022 могут добавляться только в среду AD, которая для репликации SYSVOL применяет DFSR. Если всё ещё применяется FSR, прежде чем добавить такой Контроллер домена нам потребуется выполнить миграцию репликации SYSVOL с FSR на DFSR.

Мы можем проверить применяет ли SYSVOL репликацию DFSR применив следующее:
```
dfsrmig /getmigrationstate
		
```
Если предыдущая команда возвращает состояние в виде eliminated, это означает что DFSR уже заняла своё место.

Обозреватель событий: Event Viewer также может применяться для оценки жизнеспособности репликаций установленной среды Active Directory. Существуют определённые идентификаторы событий, которые вы можете применять для фильтрации этих сведений. Вы можете обнаружить эти события в Event Viewer | Application and Service Logs | Directory Services.

Здесь я перечисляю некоторые ключевые идентификаторы событий, которые отображают имеющиеся проблемы репликаций:

Таблица 6-4. Некоторые идентификаторы событий, связанные с проблемами репликаций
ID события	Причина
`1925`	Отказ в попытке установления соединения репликации для какого- то доступного на запись раздела каталога. Это может быть вызвано проблемами сетевой среды, отказами контроллера домена или проблемами DNS.
`1988`	Данный локальный контроллер домена попытался выполнить репликацию какого- то объекта из контроллера домена источника, который не представлен в этом контроллере домена, так как он мог быть удалён, либо уже собран в мусорном ведре. Для данного раздела каталога с этим партнёром репликация не будет осуществлена, пока не будет разрешена возникшая ситуация. Это происходит в случае останова некого контроллера домена на продолжительный срок (более длительный чем время жизни надгробия) прежде чем опять вернуться в рабочее состояние. После этого, тем не менее, он может иметь не существующие объекты (затяжные - lingering - объекты). Для инициации репликации заново их следует очистить.
`2087`	AD DS не способен разрешить соответствующий DNS имени хоста контроллера домена источника в некий IP адрес и репликация отказывает. Это обнаружится в контроллере домена получателя когда он не способен разрешить надлежащее название DNS для своего контроллера домена источника. Когда поиск DNS отказывает в самом первом месте, он также попытается разрешить данное название через FQDN и NetBIOS. Это препятствует репликации до разрешения причины.
`2088`	AD DS не способен разрешить соответствующий DNS имени хоста контроллера домена источника в некий IP адрес, но репликация успешна. В данной ситуации этот контроллер домена получателя получил отказ в разрешении названия своего источника через просмотр DNS, однако он оказался способным соединиться через имя FQDN или NetBIOS.
`1311`	Имеющиеся в AD DS сведения не отражают в точности установившуюся топологию в имеющейся сетевой среде. Обычно это происходит из- за неверной настройки подключений площадки Active Directory. Она может иметь неверно назначенные в ней подсети.

Замечание

После того как некий объект удалён из данного Каталога, он не будет сразу удалён из его базы данных Active Directory прямо сразу. Он будет перемещён в установленное ведро для мусора после того как истечёт срок жизни его надгробия. По умолчанию это значение установлено в 180 дней.

Работоспособность контроллера домена: В своём предыдущем разделе мы изучали как оценивать жизнеспособность имеющихся репликаций. Нашим следующим этапом будет оценка работоспособности самих Контроллеров домена. В Контроллерах домена рекомендуется устанавливать только роли и функциональные возможности AD DS. Однако многие пользуются в Контроллерах домена и такими ролями как DHCP и NPS. В качестве части проверки жизнеспособности нам следует проверить какие дополнительные роли являются установленными в нашем Контроллере домена. Это выполняется при помощи:
```
Get-WindowsFeature -ComputerName DC01 | Where Installed
		
```
В приведённой выше команде указанное значение -ComputerName следует заменить вашим именем хоста Контроллера домена.

Вам также следует избегать установки в Контроллерах домена дополнительного программного обеспечения (только если оно не служит целям резервного копирования). Мы можем выявить дополнительно установленное программное обеспечение в Контроллере домена воспользовавшись:
```
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | select DisplayName
		
```
Рисунок 6-9

Перечень установленного в Контроллере домена программного обеспечения

Соответствующий инструмент Dcdiag.exe может применяться для предварительно заданных тестов оценки жизнеспособности определённых контроллеров домена:
```
Dcdiag /e
		
```
Наша предыдущая команда проверит все контроллеры домена в текущем лесу.
```
Dcdiag /s:REBEL-SDC-03
		
```
Эта приведённая выше команда запустит проверку в конкретном контроллере домена REBEL-SDC-03.

Вместо выполнения всех проверок, наша следующая команда проверит только тест на репликации в REBEL-SDC-03:
```
Dcdiag /test:replications /s:REBEL-SDC-03
		
```
Последняя приводимая здесь команда может применяться для проверки служб Active Directory в текущем локальном контроллере домена:
```
Dcdiag /test:Services
		
```
Жизнеспособность DNS: Мы не можем обсуждать работоспособность Active Directory без того чтобы затрагивать жизнеспособность инфраструктуры DNS. Active Directory во многом полагается на функциональность DNS.

Для начала я предпочитаю просмотреть относящиеся к серверу DNS события в рассматриваемом контроллере домена. Мы можем выполнить доступ к регистрационным записям DNS пройдя в Event Viewer | Application and Service Logs | DNS Server.

Утилита Dcdiag также может применяться для проверки жизненности DNS:
```
Dcdiag /test:DNS /DNSBasic
		
```
Наша предыдущая команда запустит базовую проверку DNS чтобы гарантировать что служба DNS исполняется, имеющиеся записи ресурса зарегистрированы, а также что представлены все зоны DNS.

Наша следующая команда проверит будет ли установленный DNS передавать надлежащим образом функционирование:
```
Dcdiag /test:DNS /DnsForwarders
		
```
Ещё одна команда проверит регистрацию записей локатора DC:
```
Dcdiag /test:DNS /DnsRecordRegistration
		
```
Мы также можем выполнить весь отчёт о жизнеспособности применив:
```
dcdiag /v /c /e /s:DC01 | Out-File C:\healthreport.txt
		
```
В нашей предыдущей команде /v означает подробность и будет выдавать на печать расширенные сведения. Аргумент /c подразумевает что ваша система выполнит все проверки за исключением DCPromo и RegisterInDNS. При помощи /e проверки выполнятся на всех серверах корпорации (enterprise). Аргумент /c применяется для определения значения имени Контроллера домена для запуска на нём команды. Вывод выполненной команды будет записан в файл C:\healthreport.txt fle. Этот файл включает в себя богатые сведения относительно жизнеспособности вашей инфраструктуры AD.

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

SCOM и Sentinel Azur

SCOM обладает Active Directory Management Packs и DNS Management Packs, которые отслеживают события жизнеспособности имеющегося уровня приложения.

Sentinel Azure способен собирать события из Контроллеров домена и эти сведения могут применяться для оценки состояний жизнеспособности и безопасности поддерживаемой среды AD. при помощи Sentinel мы можем пользоваться запросами KQL для поиска конкретных событий безопасности и жизнеспособности.

Здесь я перечисляю применяемый мной список моментов, который я применяю для рассмотрения в процессе проверки жизнеспособности Active Directory:

Просмотр состояния соединения между контроллерами домена.
Если данная организация обладает некой системой мониторинга, просматриваю отчёты и самые последние события относительно контроллеров домена, ролей AD DS, жизнеспособности репликаций, а также служб DNS.
Просматриваю самые последние отчёты резервного копирования.
Просматриваю проблемы и события DNS.
Просматриваю работоспособность имеющихся Контроллеров домена Active Directory.
Проверяю репликации Active Directory.
Просматриваю журналы Active Directory на предмет поиска всех повторяющихся проблем.
Просматриваю производительность существующих Контроллеров домена.
Просматриваю использование полосы пропускания соединений между площадками.

После подобной проверки жизнеспособности нашим следующим шагом в общем процессе будет проверка зависимостей приложений.

Аудит приложений

Когда в организации запущена AD DS, очевидно, что они обладают интегрированными с Active Directory приложениями. некоторые из них могут пользоваться лишь LDAP аутентификацией, в то время как прочие применяют расширенную интеграцию с какой- то видоизменённой схемой Active Directory. При миграции Active Directory, некоторые из таких приложений могут потребовать изменений или обновлений для соответствия новой версии AD DS.

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

Изменения строки подключения LDAP: Для применения в приложениях SSO (single sign-on, единственной подписи) для определённого Контроллера домена может применяться подключение LDAP. Порой, приложения используют жёстко кодированные имена хостов или IP адреса Контроллеров домена для задания таких подключений. Когда миграция домена сопряжена с изменением адресов IP и имён хостов, требуется планирование альтернатив для таких записей.
Изменения версии схемы: Некоторые наследуемые приложения поддерживают лишь определённые версии схемы Active Directory. Это является отличительной особенностью индивидуально выполненных приложений с Active Directory интеграцией. Следовательно, когда имеется некое не досконально известное приложение, убедитесь что оно будет поддерживать устанавливаемую вами новую версию схемы AD DS у производителя такого приложения.
Миграции приложений: Некоторые организации имеют унаследованные версии приложений, которые больше не поддерживаются или не разрабатываются их производителями. Как- то я работал над проектом миграции с AD DS 2003 в AD DS 2012 R2. Эта организация имела наследуемое приложение, которое исполнялось в системе Windows Server 2000. AD DS 2012 R2 не поддерживает серверы участники Windows Server 2000. Тот производитель, который создал данное приложение, больше не был в деле. Как результат, нам пришлось выполнить миграцию пользователей в аналогичный тип приложения, которое поддерживало такие новые ОС, прежде чем мы приступили к реальным миграциям Active Directory.
Установленные роли, приложения сервера в контроллерах домена: В подавляющем большинстве случаев, когда роли FSMO мигрируют в новые контроллеры домена, их старые контроллеры домена списываются. Даже хотя Microsoft и рекомендует чтобы вы не устанавливали приложения или прочие роли сервера в контроллерах домена, персонал всё же делает это. Некоторыми из распространённых ролей, устанавливаемыми в контроллерах домена являются DHCP, RADIUS и серверы лицензирования.

Когда такие контроллеры домена являются предметом списания, эти приложения и роли сервера следует мигрировать в новые серверы. Некоторые из таких ролей и приложений могут и вовсе отсутствовать на текущем рынке. К примеру, Windows IAS (Internet Authentication Service) из Windows Server 2003 был заменён NPS (Network Policy Server) в Windows Server 2008. Когда нет возможности применения при миграции тех же самых версий, вам может потребоваться планирование их обновлений или замены неким эквивалентным приложением.

Планирование

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

В таком плане следует охватить такую информацию:

Таблица 6-5. Данные для плана реализации
Данные	Описание
Обзор имеющейся инфраструктуры AD DS	На основании тех сведений, которые были собраны в процессе аудита, вам требуется представить некое резюме по существующей инфраструктуре. Оно должно содержать информацию относительно логической и физической топологий Active Directory.
Обзор предлагаемого решения	На основании собранных в процессе аудита данных и исходя из требований бизнеса мы способны представить подробный проект своего предлагаемого решения. Он должен содержать сведения относительно изменений в топологии, размещениях новых контроллеров домена, помещении ролей FSMO, новых соединениях площадок, IP адресации, названий хостов, требуемого оборудования и ресурсов виртуальных машин, необходимых изменений в правилах межсетевого экрана и тому подобное.
Риски	Одним из основных предметов занятия аудитом является выявление потенциальных рисков, которые способны оказать влияние на нашу миграцию AD DS. Они могут быть обусловлены неверным проектированием, плохой работоспособностью служб Active Directory, либо прочими проблемами инфраструктуры или приложения. Все осознаваемые риски можно разбить по категориям на основании воздействия (к примеру, высокое, среднее и низкое).
План рисков миграции	После того как были выявлены все риски, нам требуется предоставить некий план описания какие действия можно предпринять для их решения. Если это возможно, включите в данном плане перечень рисков, оценку временного интервала и бюджет.
Прерывания службы	В процессе нашей реализации, могут иметься прерывания службы. Это может быть вызвано, например, миграцией приложения или изменениями IP сервера. В этом разделе создайте перечень таких прерываний обслуживания, совместно с ожидаемым временным диапазоном, с тем, чтобы все зависимые участники могли бы быть проинформированы перед процессом миграции.
Рекомендации	В процессе выполнения аудита вы могли обнаружить моменты, которые способны улучшить производительность, безопасность или управляемость AD DS. То что не охвачено в изначальных требованиях бизнеса, может перечисляться в качестве рекомендаций. Отметим, что они не должны оказывать непосредственного воздействия на сам процесс миграции AD DS. Если это сделано, оно должно быть предложено в разделе решения.
Список задач и расписание	Ваш план обязан иметь подробный список задач и расписание для самого процесса реализации миграции AD DS. Он также должен содержать роли и ответственности для выполнения каждой из задач.
План проверки	Также требуется чтобы у вас имелся подробный план проверок чтобы протестировать все функции Active Directory после выполнения процесса миграции AD DS с тем, чтобы вы имели возможность удостовериться в её работоспособности и целостности. Его требуется применить в процессе самой реализации и он обязан содержать очевидные доказательства успешного завершения каждой из проверок (таких как снимки экранов, события, отчёты и тому подобное).
План восстановления	После успешных процессов аудита и планирования имеется очень низкая вероятность провала проекта. Тем не менее, ваш план всё же требует представления какого- то плана восстановления, который будет применяться в случае какой- то неприятности. Он также обязан содержать некий процесс проверки уже имеющегося решения DR или резервного копирования, которые можно применить в процессе восстановления, причём перед тем как приступать к данному проекту.

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

Реализация

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

Контрольный список миграции Active Directory

На основании наших предыдущих этапов я создал приводимый ниже контрольный список, который вы можете применять для своего процесса миграции Active Directory:

Выполните оценку бизнес- требований миграции Active Directory
Выполняйте аудит уже имеющейся инфраструктуры Active Directory
Предоставьте некий план реализации
Подготовьте необходимые физические/ виртуальные ресурсы для необходимого контроллера домена.
Установите Windows Server 2022 Standard/Datacenter.
Внесите в свои серверы самые последние обновления Windows для исправления ошибок.
Назначьте создаваемому Контроллеру домена выделенный IP адрес.
Установите необходимую роль AD DS.
Выполните миграцию приложений и ролей сервера с имеющихся Контроллеров домена.
Выполните миграцию установленных ролей FSMO в новые Контроллеры домена.
Добавьте новые Контроллеры домена в имеющуюся систему мониторинга.
Добавьте новые Контроллеры домена в имеющееся решение DR.
Спишите все свои старые Контроллеры домена.
Повысьте значения уровней функциональности своих домена и леса.
Осуществите текущие работы по сопровождению (просмотр Групповых политик, реализацию новых свойств, выявление и исправление проблем инфраструктуры Active Directory и тому подобное).

В качестве части упражнения, я намерен продемонстрировать как осуществлять миграцию с AD DS 2012 R2 на AD DS 2022.

Операционные системы Windows Server 2008 и Windows Server 2008 R2 достигли конца своего цикла поддержки 14 января 2020 года. по причине этого многие организации пожелали выполнить миграцию с этих устаревших операционных систем. Операционные системы с истекшим сроком службы оказывают прямое воздействие на различные отраслевые соответствия, ИТ-аудиты, тесты на проникновение и т.п. Даже если у компании нет бизнес-требований к обновлению, устаревшие операционные системы не оставляют нам иного выбора, кроме как обновить их.

Проектирование топологии

Согласно приводимой ниже схеме, наш домен rebeladmin.com обладает двумя контроллерами домена:

Рисунок 6-10

Проект топологии - миграция с AD DS 2008 R2

Как поясняется на Рисунке 6-10, держатель роли FSMO DC08 это Контроллер домена Windows Server 2008 R2. В настоящее время значения уровней функциональности домена и Леса работают с Windows Server 2008 R2. Будет введён некий новый Контроллер домена с Windows Server 2022 и именно он будет нашим новым держателем роли FSMO для данного домена. После того, как миграция роли FSMO завершится, наш Контроллер домена под управлением Windows Server 2008 R2 будет отключён. После этого будут подняты уровни функционирования Леса и домена до Windows Server 2016.

Здесь DC08 это Контроллер домена с Windows Server 2008 R2, в то время как DC22 это Контроллер домена с Windows Server 2022.

	Замечание
	Когда вы вводите новые контроллеры домена в некую уже имеющуюся инфраструктуру, рекомендуется чтобы вы вводили вначале уровень корня Леса, а потом уже переходили к уровням деревьев доменов.

Этапы установки

Применяя следующие шаги, мы можем установить свой новый контроллер домена и осуществить миграцию ролей FSMO в него:

Зарегистрируйтесь в своём сервере в качестве участника его группы локальных администраторов.
Добавьте этот сервер в качестве участника в уже имеющемся домене.
Зарегистрируйтесь в установленном Контроллере домена DC08 (Windows Server 2008 R2) в качестве Администратора домена.
Затем откройте консоль PowerShell от имени Администратора и исполните dfsrmig /getmigrationstate. Если эта команда возвратит значением состояния eliminated, это означает, что DFSR уже применяется для репликации SYSVOL. Если это не так, вам надлежит выполнить миграцию репликации SYSVOL на DFSR, поскольку Windows Server 2022 не поддерживает репликацию FSR. Шаги репликации FSR на DFSR описаны мной в написанном мной блог посте, доступ к которому можно выполнить через https://bit.ly/3CM8VeG.

В данной среде демонстрации наш контроллер домена уже применяет DFSR:

Рисунок 6-11

Состояние DFSR
Зарегистрируйтесь в DC22 в качестве Enterprise Admin.
Перед процессом конфигурирования нам требуется установить роль AD DS в этом определённом сервере. Для выполнения этого откройте консоль PowerShell 7 запустите следующую команду:
```
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
		
```
Затем выполните приводимую ниже команды для проверки текущего держателя роли FSMO:
```
Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster
		
```
Как мы можем видеть, все пять ролей FSMO в настоящее время подпадают под Контроллер домена DC08 (Windows Server 2008 R2):

Рисунок 6-12

Текущий держатель ролей FSMO
Настройте свой новый сервер в качестве дополнительного Контроллера домена (эти шаги обсуждаются в разделе Установка дополнительного контроллера домена).
Выполните миграцию всех пяти ролей FSMO в свой новый Контроллер домена применив в DC22 такую команду:
```
Move-ADDirectoryServerOperationMasterRole -Identity DC22 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
		
```
В нашей предыдущей команде DC22 это тот Контроллер домена, который работает под управлением Windows Server 2022.

Рисунок 6-13

Миграция ролей FSMO
После выполнения этого мы можем проверить своих держателей ролей FSMO применив следующие команды:
```
Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster
		
```
Рисунок 6-14

Новый держатель ролей FSMO

Как и ожидалось, теперь роли FSMO успешно перемещены в Контроллер домена DC22(Windows Server 2022).
Наш следующий шаг состоит в списании наших старых Windows Контроллеров домена под управлением Windows Server 2008 R2. Для этого запустите мастер DCPromo от имени Администратора предприятия (Enterprise Admin) с соотвествующего Контроллера домена.

После выполнения этого, DC08будет сервером участником домена rebeladmin.net:

Рисунок 6-15

Новый держатель ролей FSMO

В Windows Server 2012 или выше для деинсталляции AD DS вы можете воспользоваться от имени Администратора предприятия с надлежащего Контроллера домена:
```
Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartition
		
```
Нашим следующим шагом является повышение уровней функциональности домена и леса до Windows Server 2016. Как я уже пояснял в Главе 2, Службы домена Active Directory Windows 2022, Windows Server 2022 не обладает новыми уровнями функциональности домена или Леса. Для изменения уровней функциональности доменов до уровня Windows Server 2016 применяйте такую команду:
```
Set-ADDomainMode -identity rebeladmin.com -DomainMode Windows2016Domain
		
```
Рисунок 6-16

Обновление уровня функциональности нашего домена

Чтобы обновить уровни функциональности Леса воспользуйтесь следующей командой:
```
Set-ADForestMode -Identity rebeladmin.com -ForestMode Windows2016Forest
		
```
Рисунок 6-17

Обновление уровня функциональности нашего Леса

Теперь вы завершили миграцию с AD DS 2008 R2 до AD DS 2022. Те же самые шаги применяются когда вы осуществляете миграцию с Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 и Windows Server 2019.

Верификация

Хотя наша миграция и выполнена, нам всё ещё требуется проверить выполнена ли она успешно. Наша следующая команда отобразит текущий уровень функциональности данного домена после осуществлённой миграции:


Get-ADDomain | fl Name,DomainMode

Ещё одна команда покажет значение текущего уровня функциональности Леса для этого домена после миграции:


Get-ADForest | fl Name,ForestMode

Рисунок 6-18

Проверка значений уровней функциональности наших Леса и домена

Чтобы проверить обновления значений уровней функциональности для Леса и домена вы можете применять такую команду:


Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 2039 -or $_.eventID -eq 2040} | Format-List

Наш следующий снимок экрана показывает события 2039 и 2040 из журнала Directory Service, которые подтверждают обновления и уровня функциональности леса, и уровня функциональности домена:

Рисунок 6-19

Проверка значений уровней функциональности наших Леса и домена - журнал событий

Замечание

Get-EventLog не распознаётся в качестве команды в PowerShell 7. Для этого мы пользуемся Windows PowerShell {Прим. пер.: подробнее о применении совместимости PowerShell 7 и Windows PowerShell в переводе Главы 3, Изучаем совместимость с Windows PowerShell, а об использовании Get-WinEvent наравне с Get-EventLog в переводе раздела Исследование регистраций приложений и служб из 4го издания Книги рецептов автоматизации Windows Server при помощи PowerShell Томаса Ли, Packt Pub, Июль 2021}.

Идентификатор события 1458 подтверждает передачу установленных ролей FSMO:


Get-EventLog -LogName 'Directory Service' | where {$_.eventID -eq 1458} | Format-List

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


Get-ADDomainController -Filter * | Format-Table Name, IPv4Address

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

Сопровождение

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

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

Добавление в имеющуюся систему мониторинга: Наши новые Контроллеры теперь взяли на себя ответственность за вашу инфраструктуру идентификации. Важно получать уведомления когда какая- то часть оборудования или системной службы испытала отказ, который окажет воздействие на работу компании. Для этой задачи я предпочитаю применять некую современную систему отслеживания прикладного уровня, такую как SCOM или Azure Sentinel, которые не просто уведомляют вас относительно отказов служб или систем, но также и предсказывают проблемы в будущем и позволяют инженерам регулировать их.
Добавление к имеющемуся решению DR: В случае отказа оборудования или природного чрезвычайного происшествия, ваша компания обязана иметь возможность восстановить свои рабочие процессы для продолжения своей работы. Имеется множество различных решений для этого, которые можно применять в качестве решений восстановления после сбоев (DR) для некой среды AD. Моим предпочтением является поддержка неких дополнительных Контроллеров доменов на площадках DR, совместно с какой- то резервной копией. В случае происшествия это позволит прочим приложениям продолжать свою работу с минимальным воздействием. Когда вы добавляете некие новые Контроллеры домена в решение резервной копии или DR, убедитесь что вы периодически проверяете их достоверность.
Реализация новых свойств: После обновления уровней функциональностей домена и Леса вы можете начать использовать полученные новые функции AD DS 2022, которые я описывал в Главе 2, Службы домена Active Directory 2022. Применение таких новых свойств является одним из основных поводов любого проекта миграции AD DS.

Когда вы применяете новую функциональность, попробуйте сначала проверить её на тестовых устройствах или группах пользователей готовых к тестированию, прежде чем применять их ко всей организации. Это минимизирует их влияние если вам потребуется изменять их ил целиком удалять. Те свойства, которые вы можете применять для своей организации, зависят от модели бизнеса и работы самой организации.
Пересмотр Групповых политик: Для управления системами, приложениями и установками безопасности пользователей, устройств и прочих ресурсов в имеющейся инфраструктуре Active Directory могут применяться Групповые политики. Раз ваши системы выполнили миграцию с одной версии AD DS на другую, Возможности Групповой политики также изменились. В некой инфраструктуре также могут иметься групповые политики, которые содержат унаследованные настройки, которые больше не допускаются для работы вашей организации. Или же иначе, более новая версия AD DS может обладать лучшим способом выполнения этого. Таким образом, по завершению миграции AD DS пересмотрите свои групповые политики и внесите все необходимые поправки или реализации. Для проверки Групповой политики всегда пробуйте её на какой- то тестовой группе и тестовом устройстве, прежде чем применять её в промышленном решении.
Документирование: Документирование требуется для любой реализации системы. После завершения процесса миграции подготовьте некий документ, который содержит сведения относительно архитектуры, этапов реализации, изменений настроек, результатов проверок, тех ресурсов, которые применялись, изменений Групповых политик, настроек новых свойств и тому подобного. Это послужит хорошей отправной точкой для инженеров и управляющих с тем чтобы они смогли спланировать последующие миграции AD DS. Это также поможет инженерам при устранении неисправностей.

Выводы

Наши первые несколько глав данной книги были сосредоточены на основах AD DS и её возможностей. Данная глава отличалась от них и была более сосредоточена на самой реализации AD DS. В самой первой части данной главы мы изучили саму реализацию контроллеров доменов в разных обстоятельствах. Вторая часть этой главы была сосредоточена на миграции AD DS с более старых версий AD DS до AD DS 2022. Здесь мы изучили как надлежащим образом спланировать миграцию AD. Как часть этого опыта обучения мы рассмотрели как осуществлять проверки работоспособности Active Directory, аудит приложений, сбор сведений и пересмотр архитектуры AD. И последнее, но не по отношению к важности, мы изучили как выполнять миграцию с AD DS 2008 R2 до AD DS 2022.

В своей следующей главе мы намерены изучить управление объектами Active Directory.