Предлагаем чек-лист, который поможет подготовить домен с функциональным уровнем ниже 2008_R2 к обновлению и проверить корректность настроек перед переносом данных в РЕД АДМ.
Этап 1. Проверка версии домена Microsoft Active Directory
Компания Microsoft, выпустив обновление Active Directory с 2003 на 2008 версию, внесла много глобальных изменений. Изменилась схема построения домена, сменились места хранения отдельных элементов (например, зон DNS), появились новые инструменты администрирования.
Функциональный уровень домена определяет, какие возможности доступны администратору для управления каталогом. Это важный аспект для миграции. Уровень, с которым работает РЕД АДМ, начинается с версии 2008_R2. Создавая продукт, мы взяли за основу более современный и безопасный подход к работе с доменом.
Соответственно, нужно определить текущий уровень домена.
Чтобы узнать текущий уровень домена, воспользуйтесь командой:
Get-ADForest | Select-Object ForestMode
или посмотрите информацию в Active Directory Domains and Trusts → свойства домена/леса.
Итак, определили «отправную точку». Если уровень домена ниже 2008_R2 — понимаем, на сколько «ступеней» предстоит поднять домен. Так, с 2003 версии windows server нельзя подняться сразу на 2016. Требуется последовательное обновление 2003 → 2008 → 2008 R2 и так далее.
| [ ! ] Опциональный путь. Если ИТ-инфраструктура существует более 10-15 лет, возможно, внутри домена скопились ошибки за годы его существования. В некоторых случаях оптимальным вариантом станет создание новой инфраструктуры с нуля: выбор правильной логики построения, грамотная настройка и избавление от «подводных камней». |
Этап 2. Обновление домена Microsoft Active Directory до версии 2008_R2
Шаг 1. Инвентаризация контроллеров домена
После того, как определён уровень домена, приступим к его планомерному обновлению до нужного функционального уровня.
Функциональный уровень домена — это «потолок», определяемый самым старым контроллером в домене. Если в домене остался хоть один контроллер на Server 2003, поднять уровень до 2008 R2 невозможно. Поэтому для начала нужно либо обновить все старые контроллеры, либо вывести их из эксплуатации.
Несколько полезных команд, которые ускорят процесс инвентаризации:
Вывести список всех контроллеров домена
Get-ADDomainController -Filter *
Подробная информация о контроллерах (плоский домен)
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem, OperatingSystemVersion, Site, IPv4Address
Информация о лесе (включая все домены)
Get-ADForest | Select-Object Name, Domains, Sites
Детальная информация с версиями операционной системы
Get-ADDomainController -Filter * | Format-Table Name, OperatingSystem, OperatingSystemVersion -AutoSize
|
Проверка по итогам шага: — Все контроллеры должны работать под Windows Server 2008 R2 или выше — Удалены или декомиссированы контроллеры на базе 2000/2003 |
Шаг 2. Проверка репликации
Повышение уровня домена записывается как изменение в Active Directory и реплицируется на все контроллеры домена. Если процесс репликации сломан, то часть контроллеров не узнает о повышении. В домене возникнет рассогласование, которое может привести к непредсказуемым сбоям аутентификации и применения политик. Чинить такое — крайне болезненно.
Поэтому проверим работу репликации следующей командой:
repadmin /replsummary
repadmin /showrepl
|
Проверка по итогам шага: — Ошибок репликации нет / обнаруженные ошибки репликации устранены (в этом поможет мануал от Microsoft) |
Шаг 3. Проверка FSMO-ролей
Пять ролей FSMO (Schema Master, Domain Naming Master, PDC Emulator, RID Master, Infrastructure Master) — это точки принятия решений в Active Directory.
За что отвечает каждая роль:
● Schema Master — отвечает за внесение изменений в схему Active Directory.
● Domain Naming Master — отвечает за проверку корректности наименования доменов в лесу.
● PDC Emulator — необходим для синхронизации времени.
● RID Master — обеспечивает обработку запросов пула RID от всех контроллеров домена и отвечает за удаление объекта из домена.
● Infrastructure Master — поддерживает идентификаторы удаляемых или перемещаемых объектов на время репликации между контроллерами домена.
Если хотя бы одна из ролей живёт на старом контроллере, то при повышении уровня этот контроллер некорректно обработает изменения схемы. Особенно критичен Schema Master — именно он фиксирует изменения, связанные с новым функциональным уровнем.
Список ролей можно вывести командой:
netdom query fsmo
|
Проверка по итогам шага: — Все роли должны находиться на контроллерах 2008 R2+. Если нет, то можно обратиться к инструкции |
Шаг 4. Резервная копия системного состояния всех контроллеров домена
Повышение уровня домена — это необратимая операция. Единственный способ быстро и безболезненно «откатиться» — восстановление из бэкапа.
Резервную копию можно сделать через команду wbadmin или VSS:
wbadmin start systemstatebackup -backupTarget:E:
|
Проверка по итогам шага: — Бэкапы контроллеров домена готовы |
Шаг 5. Проверка приложений
Некоторые приложения завязаны на конкретный функциональный уровень домена. Классический пример — старые версии Exchange, которые могут требовать уровень домена не выше 2003. После повышения такие приложения перестанут работать, и откатить уровень обратно уже нельзя. Поэтому сначала обновляем или мигрируем приложения, потом — домен.
Важно учесть и legacy-приложения, которые не поддаются миграции. Для них нужно выбрать отечественный аналог, как опция — сохранить эти сервисы в старой инфраструктуре и обращаться к ним через доверительные отношения на период поиска аналога.
Подборка legacy-приложений, на которые стоит обратить внимание:
■ SQL Server 2000 / 2005 с использованием Windows Authentication ― редко требует низкого FFL, но могут быть проблемы с атрибутами схемы
■ Системы репликации через Windows accounts ― есть зависимость от legacy-атрибутов (sIDHistory, primaryGroupID)
■ Legacy SSO-решения: CA Single Sign-On (SiteMinder) < 12.x, Oracle Access Manager < 11g ― использовали устаревшие атрибуты (userParameters, legacyExchangeDN)
■ Системы федерации: Novell Access Manager, IBM Tivoli Access Manager, ― зависели от схемы 2003 для маппинга атрибутов
■ IBM Security Identity Manager (ISIM) < 6.0 ― зависимость от objectSid, sIDHistory в формате 2003
■ Oracle Internet Directory (OID) с синхронизацией ― некорректная обработка новых атрибутов AD
■ Кастомные приложения с «жёсткой» привязкой к схеме
|
Проверка по итогам шага: — Приложения обновлены и готовы к миграции — Для legacy-приложений найдены аналоги или предусмотрен доступ через доверительные отношения |
Подробнее о миграции приложений в РЕД АДМ >>
Шаг 6. Повышение функционального уровня
На данном шаге рекомендуем обратиться к наиболее актуальному руководству Microsoft по повышению функционального уровня домена Microsoft Active Directory на сайте.
Этап 3. Проверка корректности повышения функционального уровня
Проверка 1. Подтверждение нового уровня домена
На этом шаге важно убедиться, что повышение прошло корректно. Бывают ситуации, когда команда повышения отрабатывает без ошибок, но уровень не поднимается (например, из-за проблем с репликацией PDC Emulator).
Команда для проверки:
(Get-ADDomain).DomainMode -eq "Windows2008R2Domain"
(Get-ADForest).ForestMode -eq "Windows2008R2Forest"
Проверка 2. Работоспособность аутентификации
Новый функциональный уровень активирует новые механизмы безопасности (например, AES-шифрование для Kerberos на уровне 2008+). Если клиенты или службы не поддерживают новые механизмы, нарушится система аутентификации.
Проверка klist tickets покажет, какой тип шифрования используется в выданных билетах. Используем команду:
klist
Затем нужно осуществить тестовый вход пользователей с разных клиентов.
Проверка 3. Групповые политики
Некоторые GPO-настройки становятся доступны (или меняют поведение) только на определённом функциональном уровне. Например, Fine-Grained Password Policies впервые появляются на уровне 2008. Нужно убедиться, что существующие политики не «сломались», а новые возможности работают как ожидается.
Проверка проходит в два шага:
— Применение критичных GPO на тестовых машинах
— Отсутствие ошибок в gpresult /h report.html
Проверка 4. Репликация после повышения
Осуществим принудительную синхронизацию всех контроллеров домена, чтобы убедиться, что информация о новом уровне домена дошла до каждого контроллера. Команда:
repadmin /syncall /AdeP
Расшифровка /AdeP:
|
A |
All partitions — синхронизировать все разделы каталога (Schema, Configuration, Domain, Application и т.д.), а не только один конкретный. |
|
d |
Identify servers by Distinguished Name — в выводе серверы будут отображаться по их различающемуся имени (DN). Делает вывод более информативным. |
| e | Enterprise — синхронизировать между сайтами (inter-site), а не только внутри текущего сайта Active Directory. Без этого флага синхронизация ограничена локальным сайтом. |
| P | Push — вместо того, чтобы запрашивать изменения у партнёров (pull), контроллер домена отправляет (push) свои изменения партнёрам. |
Проверка 5. Расположение зон DNS
При повышении уровня домена могут измениться параметры репликации DNS-зон, интегрированных в Active Directory. Например, появляется возможность реплицировать зоны на все DNS-серверы в лесу, а не только в домене.
Важно убедиться, что DNS-разрешение работает: сервера доступны по именам, все данные отображаются корректно.
Для этого нужно:
Зайти в «Свойства» всех зон DNS. Во вкладке «Общие» в пункте «Репликация» нажать «Изменить» и убедиться, что не выбран пункт «Для всех контроллеров домена в этом домене (для совместимости с Windows 2000)».
Проверка 6. Логи событий
Нужно убедиться в отсутствии критических ошибок в Directory Service и DFS Replication.
Даже если всё выглядит рабочим, в логах могут появиться предупреждения или ошибки, указывающие на скрытые проблемы: конфликты репликации, ошибки обновления схемы, проблемы с SYSVOL. Лучше обнаружить их сейчас, пока резервная копия свежая, чем через неделю, когда откат станет невозможен.
Теперь, когда все проверки пройдены успешно, домен готов к переезду. Следующим этапом станет выбор стратегии миграции и обязательное пилотирование перед внедрением. Об этих важных шагах расскажем в последующих материалах.
