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

Содержание

Глава 6. Миграция в Active Directory 2016
Предварительные требования установки AD DS
Требования к оборудованию
Требования к виртуальной среде
Дополнительные требования
Методы установки AD DS
Сценарии развёртывания AD DS
Установка нового домена корня леса
Контрольный список установки AD DS для самого первого контроллера домена
Проектирование топологии
Этапы установки
Установка дополнительного контроллера домена
Контрольный список установки AD DS для дополнительного контроллера домена
Проектирование топологии
Этапы установки
Установка нового дерева доменов
Контрольный список установки AD DS для нового дерева доменов
Проектирование топологии
Этапы установки
Установка нового дочернего домена
Контрольный список установки AD DS для нового дочернего домена
Проектирование топологии
Этапы установки
Как планировать миграцию Active Directory
Жизненный цикл миграции
Аудит
Логическая и физическая топологии Active Directory
Проверка жизнеспособности Active Directory
SCOM и Монитор Azur
Аудит приложений
Планирование
Реализация
Контрольный список миграции Active Directory
Разработка топологии
Этапы установки
Верификация
Сопровождение
Выводы

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

Данная глава в основном сосредоточена на получении практического опыта на кончиках пальцев при разнообразных сценариях AD DS. По этой причине мы рассмотрим таике темы:

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

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

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

  • Как выполнять миграцию в AD DS 2016

  • Как подтверждать успешность установки и миграции

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

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

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

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

  • 64- битный процессор 1.4ГГц

  • 2ГБ ОЗУ

  • Некий адаптер хранилища, который поддерживает архитектуру PCI Express (Windows Server 2016 не поддерживает для загрузки, данных или устройств страниц IDE/ATA/PATA/EIDE)

  • 32ГБ свободного пространства

  • 1х сетевой адаптер

  • Устройство DVD или поддержку сетевой/ USB загрузки

[Замечание]Замечание

Это самые минимальные требования для установки AD DS 2016; однако это не означает что они могут вмещать некие требования инфраструктуры идентификации организации. Размер системы должен основываться на установленных ролях AD DS, общем числе объектов и требованиях к работе.

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

В наши дни виртуальные решения позволяют организациям строить свои собственные частные облачные решения при помощи поставщиков общедоступных облаков, таких как Microsoft Azure и Amazon AWS. AD DS 2016 поддерживает оба сценария. Если это частное облако, это позволит вам обладать большим контролем над выделенными ресурсами, однако в общедоступном облаке это зависит от подписки и суммы, которую организация способна потратить.

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

  • 64- битный процессор 1.4ГГц

  • 2ГБ ОЗУ

  • Виртуальный контроллер хранилища SCSI

  • 32ГБ свободного пространства

  • 1х виртуальный сетевой адаптер

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

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

[Совет]Совет

Microsoft ATA (Advanced Threat Analytics, Расширенная аналитика угроз) является приложением, которое позволяет администраторам обнаруживать угрозы безопасности инфраструктуры Active Directory. Более подробно это обсуждается в Главе 18, Аудит и мониторинг Active Directory. Как часть этого решения, вам может потребоваться некий обособленный шлюз или Легковесный шлюз ATA, который может быть установлен в контроллерах домена. Для его установки в контроллере домена вам потребуется для данной службы минимум в ОЗУ, который составляет 6ГБ. Таким образом, когда вы намерены применять в своей инфраструктуре ATA, контроллерам домена требуется обладать по крайней мере 8ГБ выделенной им оперативной памяти.

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

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

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

    Режим Нано сервера был введён в Windows Serfver 2016. Он аналогичен Серверу ядра, но оптимизирован для частных облаков. {Прим. пер.: На самом деле, взгляд на его место претерпел изменения с момента выпуска и теперь он рассматривается как применяемый исключительно для контейнерных решений.} Его отпечаток ОС ещё меньше чем у Сервера ядра Windows и он допускает лишь 64- битные приложения. Он также позволяет удалённое администрирование. На момент написания книги Нано сервер Microsoft не поддерживал AD DS. Перед установкой необходимого контроллера домена важно принять решение о версии операционной системы сервера и режиме установки. В зависимости от этого также могут изменяться требования к системе и лицензированию.

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

    [Совет]Совет

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

  • Имена домена и леса: В процессе установки AD DS нам требуется задать значения имени домена и названия леса. В некой организации важно согласовать эти названия с управлением прежде чем начинать процесс установки. Эти сведения могут быть добавлены в ваш документ проекта Active Directory и предоставлены на утверждение. В давнем 2015 я написал статью в своём блоге относительно процесса переименования и мне всегда забавно узнавать причину переименования домена, так как это не нормально. Один из экземпляров был очень интересным. Это была крупная организация с примерно 500 пользователей. Они изменили своё бизнес название и хотели создать отдельный лес и структуру домена и переместить пользователей в них, причём совместно с ресурсами в некой компании с которой они объединялись. Они наняли для выполнения этого некого инженера. Этот инженер создал некую новую структуры Active Directory и переместил более 400 пользователей и устройств в эту новую структуру.

    Через несколько недель управляющие вернулись обратно и сказали что вместо применения .com в своём первичном домене они бы предпочли применять имя домена со значением .ca. Даже после длительного обсуждения эта компания всё же не изменила своего мнения, и желала удалить установленное имя домена со значением .com. Некоторые организации применяют .local (non-routable domain, домен без маршрутизации) для своих доменных имён. Когда мы расширяем свою локальную инфраструктуру AD с доменом без маршрутизации на Azure AD, нам приходится добавлять добавлять дополнительные UPN (User Principle Names, Названия правил пользователей) с какими- то маршрутизируемыми доменными именами и принуждать пользователей к их применению. Тем самым, рекомендуется применять в самом первом местоположении применять доменные имена с маршрутизацией.

  • Выделенные IP адреса: Если вы намерены работать со статическими IP адресами, рекомендуются контроллеры домена. Прежде чем начинать установку, назначьте статические IP адреса контроллерам домена и проверьте связь с ними. IP адреса контроллера домена Active Directory могут быть изменены изменены позднее в случае необходимости, однако рекомендуется избегать этого как можно дольше.

  • Мониторинг: После того как AD DS установлен, нам требуется отслеживать производительность системы, жизнеспособность репликации и целостность компонентов и служб для выявления потенциального воздействия на службу и узкие места. Рекомендуемыми инструментами мониторинга являются Microsoft SCOM (System Center Operations Manager) Microsoft OMS (Operations Management Suite), ибо они содержат модули, которые целенаправленно были спроектированы для выявления как проблем уровня служб, так и проблем уровня безопасности.

  • Резервное копирование/ восстановление при сбоях: Наличие высокой доступности инфраструктуры идентификации обязательна для операций организации, так как многие службы, приложения и прочие компоненты бизнеса зависят от неё. Следовательно, нам требуется планировать как удерживать свою инфраструктуру идентификации работающей при возникновении бедствий, причём с минимальным воздействием на работу. Существуют различные технологии и службы, которые могут применяться для резервного копирования контроллеров домена Active Directory, причём некоторые из них оцениваются в Главе 11, Службы Active Directory. После того как вы определите какое именно решение вы намерены применять, вам также потребуется спланировать периодические проверки DR (восстановления в случае сбоя) чтобы проверять обоснованность данного решения.

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

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

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

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

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

     

    Рисунок 6-1



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

     

    Рисунок 6-2



  • Применяя 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 2016 Standard/Datacenter.

  • Внести в свои серверы самые последние обновления Windows.

  • Назначить выделенный IP адрес для своего контроллера домена.

  • Установить роль AD DS.

  • Настроить AD DS в соответствии со своим проектом.

  • Просмотреть имеющиеся журналы для проверки жизнеспособности установки и настройки AD DS.

  • Настроить мониторинг службы и производительности.

  • Настроить резервное копирование/ DR (восстановление после сбоев) AD DS.

  • Разработать системную документацию.

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

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

 

Рисунок 6-3



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

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

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

  1. Зарегистрировать этот сервер как участника группы локального администратора.

  2. В этот момент проверить значение выделения статического адреса IP применив ipconfig /all.

  3. Запустить консоль PowerShell от имени администратора.

  4. Перед собственно процессом настройки нам требуется установить в этом конкретном сервере роль AD DS. Для этого мы можем воспользоваться такой командой:

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

    Нам не требуется перезагрузка для завершения установок служб этой роли.

  5. Теперь, когда у нас имеется установленной роль 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 из вашей среды.

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

    Таблица 6-1. Cmdlet PowerShell установки AD DS
    Cmdlet Описание

    Install-WindowsFeature

    Этот cmdlet позволяет нам установить роли Windows, роль служб или свойства Windows в неком локальном или удалённом сервере. Он аналогичен Диспетчеру сервера Windows для их установки.

    Install-ADDSForest

    Этот cmdlet позволяет нам настроить некий новый лес Active Directory.

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

    Windows Server 2016.

    Таблица 6-2. Параметры Cmdlet 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

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

  8. После своего выполнения эта команда выдаст вам приглашение для SafeModeAdministratorPassword. Он применяется в DSRM (Directory Services Restore Mode, Режиме восстановления Служб каталога). Убедитесь что вы применяете сложный пароль (в соответствии с рекомендациями к сложности паролей Windows). Отказ в выполнении этого остановит настройку.

  9. После завершения настройки перезагрузите свой контроллер домена и зарегистрируйтесь в нём снова в качестве Администратора его домена.

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

    
Get-Service adws,kdc,netlogon,dns

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

     

    Рисунок 6-4



  11. Наша следующая команда перечислит подробности настроек данного контроллера домена:

    
Get-ADDomainController

    Приводимый далее снимок экрана отображает вывод такой команды:

     

    Рисунок 6-5



  12. Представляемая далее команда выдаст список сведений относительно текущего домена Active Directory:

    
Get-ADDomain rebeladmin.com

  13. Точно так же Get-ADForest rebeladmin.com выдаст перечень всех подробностей установленного леса Active Directory.

  14. Приводимая ниже команда покажет будет ли этот контроллер домена разделять свою папку 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.

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

    • Название этого домена Active Directory

    • Название площадки Active Directory

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

    • Изначальный источник синхронизации данных Active Directory (некий особый контроллер домена Active Directory, либо установочный носитель)

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

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

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

  • Подготовить физические/ виртуальные ресурсы для своего контроллера домена.

  • Установить Windows Server 2016 Standard/Datacenter.

  • Внести в свои серверы самые последние обновления Windows.

  • Назначить выделенный IP адрес для своего контроллера домена.

  • Добавить этот контроллер домена в уже имеющийся домен Active Directory в качестве некого участника домена

  • Отыскать сведения относительно имеющихся площадок домена и установленном первоначальном методе репликации

  • Зарегистрироваться в этом сервере с некой привилегированной учётной записью (такой как Администратор схемы - Schema Admin или Администратор предприятия - Enterprise Admin)

  • Установить роль AD DS.

  • Настроить AD DS.

  • Просмотреть имеющиеся журналы для проверки жизнеспособности установки и настройки AD DS.

  • Настроить мониторинг службы и производительности.

  • Настроить резервное копирование/ DR (восстановление после сбоев) AD DS.

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

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

 

Рисунок 6-6



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

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

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

  1. Зарегистрируйтесь в выбранном сервере от имени участника группы Администраторов Схемы или Предприятия.

  2. На данном этапе проверьте выделение статического IP адреса при помощи ipconfig /all.

  3. Запустите от имени администратора консоль PowerShell.

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

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

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

    
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. Параметры Cmdlet PowerShell установки дополнительного контроллера домена
    Параметр Описание

    Install-ADDSDomainController

    Данный cmdlet установит необходимый контроллер домена в имеющейся инфраструктуре Active Directory.

    -NoGlobalCatalog

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

    -SiteName

    Этот параметр может применяться для задания необходимого названия площадки Active Directory. Значением по умолчанию выступает Default-First-Site-Name.

    -DomainName

    Данный параметр определяет значение FQDN для домена Active Directory.

    -ReplicationSourceDC

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

  6. После своего исполнения данная команда запросит значение SafeModeAdministratorPassword. Воспользуйтесь для ввода неким сложным паролем. Он будет применяться для DSRM {восстановления в случае сбоя}.

  7. По завершению настройки перезапустите эту систему и зарегистрируйтесь в ней снова в качестве Администратора для проверки состояния этого AD DS.

  8. Следующая команда подтвердит значение состояния запущенной службы AD DS:

    
Get-Service adws,kdc,netlogon,dns

  9. Ещё одна команда перечислит все контроллеры домена, причём вместе с их IP адресами и названиями площадок, к которым они относятся:

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

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

    
Get-ADDomainController -Discover -Service "GlobalCatalog"

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

    
Move-ADDirectoryServerOperationMasterRole
-Identity REBEL-SDC-02
-OperationMasterRole InfrastructureMaster

  12. Воспользовавшись командой netdom query fsmo мы можем удостовериться в этом изменении:

     

    Рисунок 6-7



Это завершает наш сценарий. Нашим следующим этапом будет дальнейшее расширений имеющегося домена добавлением некого дополнительного домена.

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

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

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

  • Установка окружения: В качестве необходимого контроллера домена необходимо предложить определённый новый физический сервер или ВМ. Он обязан иметь сетевую досягаемость к уже имеющемуся корневому домену леса. Это могут быть некие различные сетевые сегменты, однако чтобы добавить его в уже имеющийся лес, требуется некое подключение. Нам также требуются установленными для такого нового сервера полномочия локального администратора, а также сведения для регистрации учётной записи в уже имеющемся лесу некого Администратора схемы (когда требуется изменение схемы) или Администратора предприятия.

  • Сведения: Для установки необходимого нового дерева доменов нам потребуется получить следующую информацию:

    • FQDN для своего нового домена

    • Название леса

    • Полномочия Администратора схемы или Администратора предприятия для уже имеющегося корневого домена леса

  • Подготовка схемы: Когда наш новый контроллер домена намерен иметь более новую версию, нежели версия уже имеющегося AD DS, потребуется изменение имеющейся схемы леса при помощи adprep /forestprep для поддержки такой новой версии. Как я уже пояснял в своём предыдущем сценарии, это теперь некая часть процесса настройки соответствующего Active Directory. Однако, для осуществления этого нам требуются полномочия Администратора схемы.

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

Приводимый ниже список охватывает все этапы, которые подлежат рассмотрению для развёртывания некого нового дерева доменов:

  • Подготовить физические/ виртуальные ресурсы для своего контроллера домена.

  • Установить Windows Server 2016 Standard/Datacenter.

  • Внести в свои серверы самые последние обновления Windows.

  • Назначить выделенный IP адрес для своего контроллера домена.

  • Отыскать сведения относительно имеющегося леса AD и регистрационных сведений Администратора схемы/ предприятия для уже имеющегося корневого домена леса.

  • Зарегистрироваться в этом сервере в качестве Локального администратора.

  • Установить роль AD DS.

  • Настроить необходимое новое дерево доменов AD DS.

  • Просмотреть имеющиеся журналы для проверки жизнеспособности установки и настройки AD DS.

  • Настроить мониторинг службы и производительности.

  • Настроить резервное копирование/ DR (восстановление после сбоев) AD DS.

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

Мы намерены добавить rebeladmin.net, который выступает новым деревом доменов, согласно приводимой ниже схеме:

 

Рисунок 6-8



rebeladmin.com является тем деревом леса, которое мы создали в своём предыдущем сценарии. Оба дерева доменов будут находиться в одном Лесу Active Directory. Наша система автоматически создаст двусторонние доверительные отношения между этими двумя деревьями домена. Давайте приступим.

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

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

  1. Зарегистрируйтесь в выбранном сервере от имени Локального администратора.

  2. Теперь убедитесь в выделении необходимого статического IP адреса при помощи ipconfig /all.

  3. От имени администратора запустите консоль PowerShell.

  4. Установите службу роли AD DS:

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

  5. После успешной установки службы роли, наш следующий этап настроит необходимое новое дерево домена:

    
Install-ADDSDomain
-Credential (Get-Credential)
-ParentDomainName "rebeladmin.com"
-NewDomainName "rebeladmin.net"
-NewDomainNetbiosName "REBELNET"
-DomainMode "WinThreshold"
-DomainType "TreeDomain"
-CreateDnsDelegation:$false
-NoGlobalCatalog:$false
-InstallDns:$true
-SiteName "Default-First-Site-Name"
-DatabasePath "C:\Windows\NTDS"
-LogPath "C:\Windows\NTDS"
-NoRebootOnCompletion:$true
-SysvolPath "C:\Windows\SYSVOL"

  6. В приводимой далее таблице я перечисляю соответствующие описания новых параметров PowerShell:

    Таблица 6-4. Параметры Cmdlet PowerShell установки нового дерева доменов
    Параметр Описание

    Install-ADDSDomain

    Данный cmdlet установит необходимый новый домен Active Directory.

    -Credential (Get-Credential)

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

    -ParentDomainName

    Этот параметр задаёт необходимый имеющийся родительский домен в имеющемся лесу AD.

    -NewDomainName

    Данный параметр определяет значение FQDN для вновь создаваемого домена AD.

    -NewDomainNetbiosName

    Данный параметр задаёт имя Netbios для создаваемого нового домена.

    -DomainType

    Применение этого параметра определяет значение типа создаваемого домена. В качестве варианта это может быть дочерний домен или дерево доменов. Значением параметра по умолчанию выступает Child Domain.

  7. Когда это выполнено, система выдаст вам приглашение на ввод полномочий Администратора схемы/ предприятия с тем, чтобы она смогла подключиться к своему родительскому домену. Если это не определено в данной команде, она воспользуется учётной записью уже зарегистрировавшегося пользователя.

  8. Она также запросит ввод SafeModeAdministratorPassword. Для его задания применяйте сложный пароль. Он будет использоваться при необходимости DSRM.

  9. Когда настройка завершена, перезагрузите свой контроллер домена и зарегистрируйтесь в качестве нового Администратора домена.

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

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

    
netdom query fsmo

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

    
Get-ADTrust -Filter *

    Отображаемый ниже снимок экрана показывает вывод нашей предыдущей команды:

     

    Рисунок 6-9



  13. Ещё одна команда подтверждает все контроллеры домена в этом новом дереве доменов:

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

  14. Приводимая далее команда выводит перечень сведений относительно нашего нового домена Active Directory:

    
Get-ADDomain

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

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

В неком дереве доменов домены поддерживают какое- то смежное пространство имён. Выбранный домен в неком дереве доменов имеет некий родительский домен, а все прочие домены в нём именуются дочерними доменами (child domains). Точно так же как дети используют фамилию своих родителей, дочерние домены также используют имя своего домена предка. Например, когда родительским доменом является rebeladmin.com, его доменами- потомками могут быть europe.rebeladmin.com или asia.rebeladmin.com. Дочерние домены способствуют организационной структуре и предоставляют гибкое управление ИТ.

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

  • Сведения: Для настройки дочернего домена нам потребуется получить следующую информацию:

    • FQDN для такого домена- потомка

    • Название леса

    • Полномочия Администратора схемы/ Администратора предприятия для уже имеющегося корневого домена леса

  • Настройку окружения: Требования к необходимым ресурсам для выполняемой установки аналогичны созданию нового дерева доменов. Этот сервер не обязан быть подключённым к имеющемуся домену, однако, в процессе его установки, он потребует подключения к своему родительскому домену. Это также потребует наличия полномочий учётной записи Администратора схемы или Администратора предприятия от такого родительского домена.

  • Подготовка схемы: Как мы уже поясняли в своих предыдущих сценариях, когда наш новый контроллер домена намерен быть более новым нежели уже имеющаяся версия AD DS, это потребует изменения схемы его леса при помощи adprep.exe /forestprep и adprep.exe /domainprep для поддержки этой новой версии. Эти действия теперь являются частью процесса настройки создаваемого Active Directory. Тем не менее, для этого нам потребуются полномочия Администратора схемы/ предприятия.

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

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

  • Подготовить физические/ виртуальные ресурсы для своего контроллера домена.

  • Установить Windows Server 2016 Standard/Datacenter.

  • Внести в свои серверы самые последние обновления Windows.

  • Назначить выделенный IP адрес для своего контроллера домена.

  • Отыскать сведения относительно имеющегося леса AD и регистрационных сведений Администратора схемы/ предприятия для уже имеющегося корневого домена леса.

  • Зарегистрироваться в этом сервере в качестве Локального администратора.

  • Установить роль AD DS.

  • Настроить необходимое новое дочернего домена AD DS.

  • Просмотреть имеющиеся журналы для проверки жизнеспособности установки и настройки AD DS.

  • Настроить мониторинг службы и производительности.

  • Настроить резервное копирование/ DR (восстановление после сбоев) AD DS.

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

Мы намерены добавить новый дочерний домен в имеющемся дереве доменов rebeladmin.com в соответствии с приводимой ниже схемой:

 

Рисунок 6-10



Устанавливаемым названием нашего нового домена будет europe.rebeladmin.com. Он всё ещё будет в том же самом лесу Active Directory. Аналогично некому новому дереву доменов, наш дочерний и родительский домены будут иметь двусторонние доверительные отношения, создаваемые автоматически. Такой контроллер домена собирается выступать в роли самого первого контроллера домена в этом домене- потомке, а потому он не может быть неким RODC.

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

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

  1. Зарегистрируйтесь в выбранном сервере от имени Локального администратора.

  2. Теперь убедитесь в выделении необходимого статического IP адреса при помощи ipconfig /all.

  3. От имени администратора запустите консоль PowerShell.

  4. Установите службу роли AD DS:

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

  5. После успешной установки службы роли, наш следующий этап настроит необходимое новое дерево домена:

    
Install-ADDSDomain
-Credential (Get-Credential)
-ParentDomainName "rebeladmin.com"
-NewDomainName "europe"
-NewDomainNetbiosName "EUROPE"
-DomainMode "WinThreshold"
-DomainType "ChildDomain"
-CreateDnsDelegation:$true
-NoGlobalCatalog:$false
-InstallDns:$true
-SiteName "Default-First-Site-Name"
-DatabasePath "C:\Windows\NTDS"
-LogPath "C:\Windows\NTDS"
-NoRebootOnCompletion:$true
-SysvolPath "C:\Windows\SYSVOL"

  6. В приводимой далее таблице я перечисляю соответствующие описания некоторых параметров PowerShell:

    Таблица 6-5. Параметры Cmdlet PowerShell установки нового дочернего домена
    Параметр Описание

    -DomainType

    Вы можете применить этот параметр для задания значение типа создаваемого домена. В качестве варианта это может быть дочерний домен или дерево доменов. В данном сценарии выбрано значение по умолчанию Child Domain.

    -CreateDnsDelegation

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

  7. Когда это выполнено, система выдаст вам приглашение на ввод полномочий. Вам требуется предоставить регистрационные сведения Администратора схемы/ предприятия для его родительского домена.

  8. Она также запросит ввод SafeModeAdministratorPassword. Для его задания применяйте сложный пароль. Он будет использоваться при необходимости DSRM.

  9. Когда настройка завершена, перезагрузите свой контроллер домена и зарегистрируйтесь в качестве нового Администратора домена.

  10. Давайте выполним проверку выполненной настройки. Здесь я зарегистрировался в имеющемся родительском контроллере домена. В диспетчере DNS я могу видеть, что для моего нового домена настроено значение новой зоны делегирования:

     

    Рисунок 6-11



  11. Мы можем применить свою следующую команду для проверки размещения имеющихся ролей FSMO своего нового дочернего домена:

    
netdom query fsmo

    Рекомендуется выполнить предыдущую команду с установленного контроллера дочернего домена.

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

    
Get-ADTrust -Identity europe.rebeladmin.com

  13. Следующая команда выдаст список сведений относительно нового подчинённого домена:

    
Get-ADDomain europe

    Приводимый ниже снимок экрана отображает вывод нашей предыдущей команды:

     

    Рисунок 6-12



  14. Для проверки состояния полученного AD DS мы можем применить такую команду:

    
Get-Service adws,kdc,netlogon,dns

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

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

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

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

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

  • Для реализации новых свойств в имеющейся инфраструктуре идентификации: Всякая новая версия Active Directory поступает с новыми свойствами и расширениями. Некоторые из таких изменений меняют всю игру. В качестве примера, управление привилегиями AD DS 2016 является поворотной точкой для инфраструктур идентификации. Для реализации этих новых свойств компании и рассматривают возможность миграции AD DS. На момент написания этой книги прошло несколько месяцев с выпуска AD DS 2019 и я уже завершил несколько крупных проектов по миграции на эту новую версию, что является хорошей тенденцией. Я чокнутый и я всегда предпочитаю запускать всё самое новое и самое великое. В то же самое время я наблюдал что некоторые организации просто любят запускать самое последнее, однако не придают большого значения тому как реализованы какие- то новейшие функции. Простая миграция на некую новую версию не даст вам никаких преимуществ, если не будет применяться как следует. Нет никакого смысла покупать Феррари просто чтобы подбрасывать своих ребятишек в школу. Таким образом, для организации важно полностью определять свои цели прежде чем выполнять миграцию 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.

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

На основании необходимых этапов процесса миграции AD DS, я пришёл к следующему жизненному циклу:

 

Рисунок 6-13



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

Аудит

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

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

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

Точно так же, в проектах миграции Active Directory, одним из моих первоначальных запросов потребителю является предоставление некой схемы топологии Active Directory. Однако, в большинстве случаев я получаю обратно лишь основные сведения, такие как общее число контроллеров домена, общее число площадок и тому подобное. Этого не достаточно для понимания имеющихся деревьев доменов, топологии репликаций, соединений площадок, а также размещения ролей FSMO. В большинстве случаев мне приходится создавать с нуля некую схему топологии Active Directory как часть своего занятия. Неким инструментом, который может применяться для автоматической выработки некой схемы со множеством важных сведений, таких как деревья доменов, системные сведения серверов и организационные подразделения, выступает Microsoft Active Directory Topology Diagrammer. Он подключается к необходимому установленному Active Directory с помощью подключения LDAP и вырабатывает некую схему Visio. Для выполнения этого вам потребуется некий подключённый к домену компьютер с установленным Microsoft Visio. У этого инструмента нет большого числа обновлений, но он способен справиться с этим заданием. Его можно выгрузить с https://www.microsoft.com/en-gb/download/details.aspx?id=13380. Выработанную им схему можно изменить в соответствии с прочими требованиями.

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

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

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

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

  • Физическая топология Active Directory

  • Сетевая топология организации

  • Соединения между площадками Active Directory

  • Полосы пропускания между площадками Active Directory

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

Моей первой машиной была модель 2004 года 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

    Наша предыдущая команда предоставит резюме всех контроллеров домена в установленной инфраструктуре:

     

    Рисунок 6-14



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

    
Repadmin /replsummary /errorsonly

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

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

    Таблица 6-6. Некоторые идентификаторы событий, связанные с проблемами репликаций
    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 дней.

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

    Соответствующий инструмент 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

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

SCOM и Монитор Azur

SCOM обладает Active Directory Management Packs и DNS Management Packs, которые отслеживают события жизнеспособности имеющегося уровня приложения. Монитор Azure содержит модули, которые оценивают значение работоспособности и безопасности установленной среды Active Directory, а также саму репликацию её жизнеспособности. Когда у организации настроены эти инструменты, они могут снабжаться сведениями в реальном масштабе времени относительно жизненности AD. При выявлении некой проблемы, они способны предоставлять руководящие правила по её исправлению (общий анализ оценки эффективности AD Монитора Azure).

Здесь я перечисляю применяемый мной в проектах список проверок 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. Когда нет возможности применения при миграции тех же самых версий, вам может потребоваться планирование их обновлений или замены неким эквивалентным приложением.

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

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

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

Таблица 6-7. Данные для плана реализации
Данные Описание

Обзор имеющейся инфраструктуры 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 2016 Standard/Datacenter.

  • Внесите в свои серверы самые последние обновления Windows для исправления ошибок.

  • Назначьте создаваемому контроллеру домена выделенный IP адрес.

  • Установите необходимую роль AD DS.

  • Выполните миграцию приложений и ролей сервера с имеющихся контроллеров домена.

  • Выполните миграцию установленных ролей FSMO в новые контроллеры домена.

  • Добавьте новые контроллеры домена в имеющуюся систему мониторинга.

  • Добавьте новые контроллеры домена в имеющееся решение DR.

  • Спишите свои старые контроллеры домена (все).

  • Повысьте значения уровней функциональности своих домена и леса.

  • Осуществите текущие работы по сопровождению (просмотр Групповых политик, реализацию новых свойств, выявление и исправление проблем инфраструктуры Active Directory и тому подобное).

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

Разработка топологии

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

 

Рисунок 6-15



Наш держатель роли FSMO запущен в неком основанном на Windows Server 2012 R2 контроллере домена. Значения уровней функциональности домена и леса в настоящее время работают с Windows Server 2012 R2. Будет введён некий новый контроллер домена с Windows Server 2016 и именно он будет нашим новым держателем роли FSMO для данного домена. После того, как миграция роли FSMO завершится, наш контроллер домена под управлением Windows Server 2012 R2 будет отключён. После этого будут подняты уровни функционирования леса и домена до Windows Server 2016.

Здесь REBEL-WIN-DC01 это контроллер домена с Windows Server 2012 R2, в то время как REBEL-SDC01 это контроллер домена с Windows Server 2016.

[Замечание]Замечание

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

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

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

  1. Зарегистрируйтесь в своём сервере в качестве участника его группы локальных администраторов.

  2. Добавьте этот сервер в качестве участника в уже имеющемся домене.

  3. Зарегистрируйтесь в установленном контроллере домена в качестве Администратора предприятия (Enterprise Admin).

  4. При помощи ipconfig /all проверьте выделение статического IP адреса.

  5. От имени администратора запустите консоль PowerShell.

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

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

  7. Настройте свой новый сервер в качестве некого дополнительного контроллера домена (эти шаги обсуждались в разделе Установка дополнительного контроллера домена).

  8. Осуществите миграцию всех пяти ролей FSMO в свой новый контроллер домена применив такую команду:

    
Move-ADDirectoryServerOperationMasterRole -Identity REBEL-SDC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

    В нашей предыдущей команде REBEL-SDC01 это тот контроллер домена, который работает под управлением Windows Server 2016.

  9. После выполнения этого мы можем проверить своих держателей ролей FSMO применив следующую команду:

    
netdom query fsmo

  10. Наш следующий шаг состоит в списании наших старых Windows контроллеров домена под управлением Windows Server 2012 R2. Для выполнения этого исполните следующую команду от имени Администратора предприятия с надлежащего контроллера домена:

    
Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartition

  11. После выполнения нашей последней команды у вас будет запрошено задание пароля для учётной записи этого локального администратора:

     

    Рисунок 6-16



    После выполнения этого новый сервер станет участником нашего домена rebeladmin.com.

  12. Нашим следующим шагом является повышение уровней функциональности домена и леса до Windows Server 2016. Для этого вы можете воспользоваться приводимыми далее командами. Для обновления уровней функциональности доменов применяйте такую команду:

    
Set-ADDomainMode -identity rebeladmin.com -DomainMode Windows2016Domain

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

    
Set-ADForestMode -Identity rebeladmin.com -ForestMode Windows2016Forest

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

Верификация

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


Get-ADDomain | fl Name,DomainMode

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


Get-ADForest | fl Name,DomainMode

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


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

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

 

Рисунок 6-17



Идентификатор события 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 или OMS, которые не просто уведомляют вас относительно отказов служб или систем, но также и предсказывают проблемы в будущем и позволяют инженерам регулировать их. OMS к тому же предоставляет руководящие правила на основе рекомендаций Microsoft для улучшения производительности и безопасности в имеющейся инфраструктуре идентификации.

  • Добавление к имеющемуся решению DR: В случае отказа оборудования или природного чрезвычайного происшествия, ваша компания обязана иметь возможность восстановить свои рабочие процессы для продолжения своей работы. Имеется множество различных решений для этого, которые можно применять в качестве решений восстановления после сбоев (DR) для некой среды AD. Моим предпочтением является поддержка неких дополнительных контроллеров доменов на площадках DR, совместно с какой- то резервной копией. В случае происшествия это позволит прочим приложениям продолжать свою работу с минимальным воздействием. Когда вы добавляете некие новые контроллеры домена в решение резервной копии или DR, убедитесь что вы периодически проверяете их достоверность.

  • Реализация новых свойств: После обновления уровней функциональностей домена и леса вы можете начать использовать полученные новые функции AD DS 2016, которые я описывал в Главе 2, Службы домена Active Directory 2019. Применение таких новых свойств является одним из основных предметов любого проекта миграции AD DS. Когда вы применяете новую функциональность, попробуйте сначала проверить её на тестовых устройствах или группах пользователей готовых к тестированию, прежде чем применять их ко всей организации. Это минимизирует их влияние если вам потребуется изменять их ил целиком удалять. Те свойства, которые вы можете применять для своей организации, зависят от модели бизнеса и работы самой организации.

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

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

Выводы

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

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