Почему Active Directory нужно обновлять, пока домен ещё работает

Пользователи входят в систему, 1С открывается, файловые ресурсы доступны. С Active Directory, кажется, всё в порядке — и замена контроллеров на Windows Server 2008 или 2012 R2 снова откладывается. Более заметные задачи всегда найдутся.

Проблемы вылезают, когда инфраструктуру нужно изменить. Добавить современный контроллер, ужесточить LDAP, восстановить политики или автоматизировать выпуск сертификата. Тогда выясняется, что репликация каталога и SYSVOL живут своей жизнью, резервное копирование пропускает обработку гостевой ОС, время задаётся конфликтующими GPO, а приложения завязаны на давно устаревшие настройки.

Ниже — два обезличенных случая. В первом готовили домен с двумя виртуальными контроллерами Windows Server 2012/2012 R2. Во втором задача с HTTPS привела к проверке домена на 2008 и 2012 R2. На этих примерах видно, зачем разбирать AD заранее и почему новая Windows Server решает только часть задачи.

Что именно меняется при «обновлении AD»

Под этими словами скрываются разные операции. Они связаны, но не заменяют друг друга.

Установка обновлений Windows на контроллере исправляет ОС и компоненты, включая AD DS. Она не трогает ошибочные ACL, лишние привилегии или устаревшие зависимости приложений.

Замена контроллеров на поддерживаемую Windows Server даёт новую платформу. Состояние каталога и политики, которые реплицируются со старых DC, остаются прежними.

Подготовка схемы добавляет атрибуты и классы, нужные новой версии DC или продукту. Она не чинит сбои репликации и содержимое SYSVOL.

Повышение уровней домена и леса (DFL/FFL) открывает возможности AD DS соответствующего уровня. Совместимость каждого приложения и фактически действующие настройки защиты при этом не проверяются автоматически.

Пересмотр GPO, прав и сервисных аккаунтов устраняет конкретные опасные настройки. Окончание поддержки ОС и отсутствие доступных исправлений он не отменяет.

Новый контроллер получает учётные записи, группы, разрешения, делегирование и те AD‑интегрированные DNS‑разделы, которые должен реплицировать. После инициализации SYSVOL на него попадают файлы групповых политик. Избыточные права сервисного аккаунта сохраняются при смене ОС. Повреждённые или неверные политики тоже не становятся правильными от появления нового DC.

Функциональные уровни задают возможности AD DS и допустимые версии контроллеров. Они не устанавливают минимальную версию ОС для рабочих станций и рядовых серверов. Повышение DFL само по себе не требует переустановки всех компьютеров, но совместимость приложений и протоколов всё равно нужно проверять отдельно. Матрица функциональных уровней Microsoft это прямо показывает.

Почему откладывание увеличивает объём следующей миграции

Обычная расширенная поддержка Windows Server 2012 и 2012 R2 закончилась 10 октября 2023 года. Extended Security Updates для них заканчиваются 13 октября 2026 года. Программа даёт определённые обновления безопасности при выполнении условий, но не включает новые функции и обычные исправления, не связанные с безопасностью. Даты проверены на 10 октября 2026 года.

Возраст ОС сам по себе не доказывает отсутствие конкретного патча. Для такого вывода нужны версия, сборка и сведения об установленных обновлениях. Отсутствие одного старого KB тоже недостаточно: исправление могло войти в последующий пакет. Но после окончания доступных обновлений устранить новую уязвимость привычной установкой патча может оказаться невозможно.

Одновременно накапливаются зависимости. МФУ использует SMBv1, приложение выполняет простой LDAP bind без TLS, сервис запускается от доменного администратора, DNS‑клиенты знают IP только одного DC. Каждая такая настройка добавляет условие к следующему изменению.

Меняется и маршрут перехода. Целевая версия DC может потребовать предварительного повышения DFL/FFL и миграции SYSVOL с FRS на DFSR. Если на старом контроллере ещё работает центр сертификации, к замене AD DS добавится перенос PKI.

Старая Windows не создаёт неправильную запись DNS автоматически. Задержка опасна тем, что настройки и зависимости остаются без ревизии, а сведения об их назначении теряются. В аварийном окне приходится восстанавливать эти сведения одновременно с ремонтом сервиса.

Первый случай: что обнаружилось до ввода нового DC

В домене работали два виртуальных контроллера — назовём их DC‑A и DC‑B. ВМ находились в VMware vCloud Director, резервные копии создавал Veeam.

Полная резервная копия с пропущенной обработкой Windows

В журнале задания одного из DC была строка:

Guest processing skipped (check VMware Tools status)

Резервные данные существовали, но гостевая обработка была пропущена. После установки VMware Tools в следующих заданиях появился этап подготовки гостевой системы; задания завершились без ошибок.

Здесь легко смешать два свойства копии. Active Full описывает создание полной резервной копии, а Application‑Aware Processing — согласование состояния приложений внутри гостевой ОС. Для Windows Veeam использует VSS. Сам по себе полный объём скопированных дисков ничего не говорит об успешном согласовании состояния AD.

Строки о подготовке гостевой системы показывают, что поведение задания изменилось. Для вывода об успешной обработке AD нужны также настройки Application‑Aware Processing и результат этого этапа для конкретного DC. Проверка восстановления в изолированной среде даёт ещё один, отдельный результат; в этом кейсе она пока не зафиксирована.

Копия GPO и файлов SYSVOL полезна перед ремонтом политик, но не заменяет резервное копирование каталога. Снимок гипервизора тоже нельзя принимать за универсальный откат DC: способ восстановления зависит от ОС, платформы виртуализации и средства резервного копирования.

Репликация каталога не подтверждала состояние SYSVOL

Данные групповой политики в AD и её файлы в SYSVOL реплицируются разными механизмами. Поэтому результат repadmin /replsummary без ошибок не исключает неисправность распространения файлов политик.

В этом домене выполнили авторитетную и неавторитетную синхронизацию DFSR. Источник выбирали по доверенному содержимому SYSVOL. Владение PDC Emulator полезно учитывать, но оно не доказывает, что именно на этом DC сохранился правильный набор файлов.

В процедуре Microsoft событие 4114 отмечает отключение репликации SYSVOL, 4602 — инициализацию авторитетного участника. На неавторитетном участнике 4614 указывает на ожидание первоначальной синхронизации, а 4604 — на её завершение. Одного 4614 для подтверждения готовности недостаточно. BurFlags D2/D4 из FRS к DFSR неприменимы.

После синхронизации DC‑B публиковал SYSVOL, но NETLOGON отсутствовал. Проверили службу Netlogon и каталоги scripts; после контролируемого перезапуска службы ресурс появился. Это наблюдение подтверждает публикацию NETLOGON после перезапуска, но не устанавливает первоначальную причину нарушения SYSVOL.

В контрольных проверках репликация AD DS не показывала ошибок, оба ресурса были опубликованы, очередь DFSR в обоих направлениях была пустой. Совпадение количества каталогов GPO использовали как дополнительное наблюдение: одинаковое число каталогов не доказывает совпадение файлов и версий политик.

Первоначальная причина сбоя SYSVOL по приведённым данным не установлена. Успешная переинициализация подтверждает результат ремонта, но не объясняет происхождение неисправности. Выбирать эту процедуру только по отсутствию ресурса тоже нельзя: Microsoft рекомендует сначала проверить состояние DFSR и события, поскольку во многих случаях переинициализация не требуется.

W32Time работал, но время не синхронизировалось

Тест Advertising указал, что DC‑B не объявляет себя сервером времени. W32Time показывал Free-running System Clock; успешной синхронизации не было.

Проверка эффективных настроек обнаружила внешний NTP‑источник, навязанный обоим контроллерам двумя общими GPO. Его имя возвращало NXDOMAIN. Исправлять только локальную конфигурацию W32Time в такой ситуации недостаточно: значения из политик перекрывают локальные настройки.

После пересмотра GPO PDC получал время от внешнего источника, второй DC использовал доменную иерархию NT5DS. В контрольном измерении смещение между контроллерами составляло около 16 мс. Это результат измерения в конкретный момент, а не подтверждение постоянной точности.

Для обычной доменной иерархии внешний источник настраивают на PDC Emulator корневого домена леса. Остальные участники следуют иерархии AD. Поэтому после переноса PDC нужно проверить и эффективную конфигурацию, и фактический источник времени.

Исправная репликация и безопасность домена проверяются отдельно

Первичный health check PingCastle в том же контуре показал 100/100 и 31 правило с ненулевым баллом.

Итоговая оценка — максимум четырёх категорий: Privileged Accounts, Trusts, Stale Objects и Security Anomalies. Значение 100 означает достижение верхней границы модели; из него нельзя получить вероятность взлома или сделать вывод о присутствии атакующего.

Для плана работ нужно разбирать условия срабатывания правил. Автоматический отчёт полезен как очередь проверок. Отсутствие LAPS не доказывает одинаковые пароли на всех ПК. Возраст пароля krbtgt не доказывает наличие Golden Ticket. Сработавшее правило, связанное со старым бюллетенем, требует проверки применимости уязвимости.

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

Есть и прямые зависимости от DFL. Шифрование паролей Windows LAPS при хранении в AD требует уровня домена Windows Server 2016 или выше. Повышение уровня открывает эту возможность, но для её использования нужны настройка LAPS, поддерживаемые устройства и корректные права доступа.

Для LDAP отдельно проверяют подпись, шифрование и channel binding. Подпись обеспечивает целостность SASL‑сеансов без TLS; конфиденциальность даёт TLS или SASL sealing. Для simple bind нужен TLS, поскольку LDAP signing не защищает его пароль. Channel binding связывает SASL‑аутентификацию с конкретным TLS‑сеансом. Проверки открытого порта 636 для оценки этих условий недостаточно.

Перед обязательным требованием подписи используют события 2887 и 2889 журнала Directory Service. 2887 даёт суточную сводку разрешённых неподписанных SASL bind и simple bind без TLS. Для подробных событий 2889 отдельно включают диагностический уровень 2 у 16 LDAP Interface Events. После обследования возвращают прежний уровень журналирования. Отсутствие 2889 при выключенной диагностике ничего не доказывает.

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

Второй случай: HTTPS восстановили, модернизация AD осталась в плане

В другом контуре работали DC на Windows Server 2008 и 2012 R2; уровни домена и леса оставались на Windows Server 2003. Для выпуска TLS‑сертификата старому IIS подготовили отдельную машину с Windows Server 2022.

Сводка репликации не показывала ошибок, но DNS‑проверка dcdiag обнаружила неправильные делегирования: NS ссылались на выведенные серверы, а соответствующие адресные записи отсутствовали. Перед очисткой сверили состав действующих DC и ответы обоих DNS‑серверов. Затем исправили делегирование и удалили подтверждённые устаревшие NS, SRV и CNAME.

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

После очистки исходные DNS‑ошибки не повторились; repadmin не показывал ошибок в проверенных направлениях. Сертификат выпустили вручную, переключили нужные HTTPS‑привязки и проверили TLS.

Здесь два независимых результата. Исправление AD DNS устранило найденные дефекты внутренней инфраструктуры. Выпуск и установка сертификата восстановили HTTPS. DNS-01 подтверждает владение именем через публичную DNS‑зону; обнаруженные ошибки внутреннего AD DNS не доказывали причину истечения сертификата.

Автоматическое продление оставалось незавершённым. Старые контроллеры и веб‑сервер также требовали модернизации. Отдельная машина для выпуска сертификатов помогла решить срочную задачу сервиса, но не заменила эти работы.

Какие проверки нужны перед вводом нового контроллера

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

Ниже — стартовый набор. Для административной машины нужны Windows PowerShell 5.1, модуль ActiveDirectory и средства AD DS/RSAT. Для проверки backlog нужен также модуль DFSR. Локальный CIM‑запрос на DC требует PowerShell 3.0 или новее. Консоль запускают с повышением прав; учётная запись должна иметь доступ к обследуемым контроллерам. Имена и адреса в примерах заменяют своими значениями.

Сначала — состав DC, роли и уровни:

Import-Module ActiveDirectory

Get-ADDomainController -Filter * |
    Select-Object HostName, OperatingSystem,
        OperatingSystemVersion, IsGlobalCatalog, Site

Get-ADDomain |
    Select-Object DNSRoot, DomainMode, PDCEmulator,
        RIDMaster, InfrastructureMaster

Get-ADForest |
    Select-Object RootDomain, ForestMode,
        SchemaMaster, DomainNamingMaster

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

Репликацию каталога проверяют отдельно:

repadmin /replsummary
repadmin /showrepl *

Нужны сведения по всем ожидаемым DC и разделам каталога, отсутствие необъяснённых ошибок и допустимое время последней успешной репликации с учётом расписания сайтов. Для повторного поиска ошибок удобен repadmin /showrepl * /errorsonly, но пустой вывод не заменяет проверки полноты данных и интервалов репликации.

Затем — выбранные проверки каждого DC:

dcdiag /s:DC-A /test:Advertising /test:SysVolCheck /test:NetLogons
dcdiag /s:DC-B /test:Advertising /test:SysVolCheck /test:NetLogons

SysVolCheck проверяет флаг SysVolReady; NetLogons — доступ текущей учётной записи к SYSVOL и NETLOGON. Эти тесты не сравнивают содержимое политик между контроллерами. DNS тоже нужно запрашивать явно.

На каждом DC проверяют публикацию ресурсов и, если SYSVOL уже использует DFSR, состояние реплицируемой папки:

net share

Get-CimInstance -Namespace 'root\MicrosoftDfs' -ClassName DfsrReplicatedFolderInfo |
    Where-Object { $_.ReplicatedFolderName -eq 'SYSVOL Share' } |
    Select-Object ReplicationGroupName, ReplicatedFolderName, State

Для DFSR состояние 4 означает Normal. Состояния 2 и 5 означают Initial Sync и In Error соответственно. Отсутствие строки требует выяснить, используется ли DFSR для SYSVOL и доступен ли его провайдер.

Для прямой пары партнёров очередь проверяют в обе стороны:

Import-Module DFSR

$sysvol = @{
    GroupName = 'Domain System Volume'
    FolderName = 'SYSVOL Share'
}

Get-DfsrBacklog @sysvol -SourceComputerName 'DC-A' -DestinationComputerName 'DC-B' -Verbose
Get-DfsrBacklog @sysvol -SourceComputerName 'DC-B' -DestinationComputerName 'DC-A' -Verbose

Команда выводит до 100 элементов, полный размер очереди доступен в потоке Verbose. Нужен успешно полученный результат, а не ошибка обращения к партнёру. После завершения синхронизации очередь должна опустеть; при текущих изменениях важна её динамика.

Время проверяют на каждом DC:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration
gpresult /scope computer /r

Проверяют источник, последнюю успешную синхронизацию и происхождение параметров — локальные настройки или Policy. gpresult показывает применённые GPO; конкретные параметры затем сверяют в результирующей политике. Если настройки неверны, перенос PDC сохранит проблему вместо её устранения.

Для серии измерений со второго DC к PDC своего домена:

$pdc = (Get-ADDomain).PDCEmulator
w32tm /stripchart /computer:$pdc /samples:10 /dataonly

Этот запрос измеряет смещение; он не перенастраивает синхронизацию. Полученный offset оценивают вместе с состоянием W32Time, а не вместо него.

DNS проверяют запросами к каждому серверу, обслуживающему зону:

$domain = (Get-ADDomain).DNSRoot
$record = "_ldap._tcp.dc._msdcs.$domain"

Resolve-DnsName -Name $record -Type SRV -Server '192.0.2.10'
Resolve-DnsName -Name $record -Type SRV -Server '192.0.2.11'

В ответах нужны действующие контроллеры; имена из SRV должны разрешаться в правильные адреса. Для базовой проверки, делегирований и регистрации служебных записей используют соответствующие тесты dcdiag.

Приведённые диагностические команды не выполняют ремонт SYSVOL или принудительную репликацию.

У каждой найденной ошибки должна быть связь с планом. Неисправная репликация или неизвестное состояние SYSVOL блокируют ввод следующего DC. Зависимость отдельного приложения от старого протокола требует собственного плана совместимости. Несколько неактивных компьютерных объектов можно разбирать отдельной задачей, если они не создают препятствия текущему этапу.

Маршрут со старых контроллеров на современные

Microsoft рекомендует вводить новые DC на чисто установленной ОС и затем штатно понижать старые. Этот путь предпочтительнее обновления Windows поверх действующего контроллера. При вводе первого DC новой версии учитывают подготовку схемы и домена, необходимые права и доступность владельцев FSMO.

Маршрут зависит от целевой версии.

Для Windows Server 2022 минимальный уровень леса — Windows Server 2008, SYSVOL должен использовать DFSR. У 2022 нет отдельного функционального уровня «2022»: максимальный для него — 2016.

Для Windows Server 2025 уровни домена и леса должны быть не ниже Windows Server 2016, SYSVOL — на DFSR. Для повышения DFL до 2025 все DC соответствующего домена должны работать на 2025; для FFL 2025 это условие относится ко всем DC леса.

Для описанного домена с DC 2008/2012 R2 и уровнями 2003 нельзя начать с продвижения DC 2022. Сначала проверяют состав всех доменов и повышают необходимые уровни до совместимых значений. Для миграции SYSVOL с FRS на DFSR нужен DFL не ниже 2008. Наличие службы DFSR на сервере само по себе не говорит, что именно она обслуживает SYSVOL.

В домене, проходящем переход FRS → DFSR, на PDC читают глобальное состояние и проверяют достижение этого состояния всеми DC:

dfsrmig /getglobalstate
dfsrmig /getmigrationstate

/getglobalstate показывает целевое состояние домена, /getmigrationstate — достигли ли его все DC. Перед следующим переходом нужна сходимость всех участников. Финальное состояние Eliminated необратимо. Обе команды читают состояние.

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

1. Ввести новый DC и проверить его. Дождаться инициализации каталога и SYSVOL, проверить DNS, публикацию ресурсов, GC и журналы. Проверить аутентификацию и работу приложений через новый сервер, пока старые доступны.

2. Перенести роли и обращения клиентов. Перенести необходимые FSMO, проверить размещение GC, DNS в DHCP и статических настройках, адреса LDAP‑интеграций. После переноса PDC проверить время. Роль GC не переносится как FSMO: её включают на нужных DC и проверяют готовность.

3. Перенести дополнительные службы. Для AD CS нужны отдельный план, ключ CA, база, конфигурация и сохранение доступности AIA/CDP и CRL. Перенос FSMO не переносит центр сертификации.

4. Штатно понизить старый DC. Выводить узлы по одному, проверяя оставшиеся клиентские обращения, служебные DNS‑записи и состояние остальных контроллеров.

5. Повысить итоговые уровни, когда выполнены условия. Повторить проверки, подтвердить резервное копирование новых DC и обновить документацию.

Для перехода старого домена к DC 2025 могут понадобиться промежуточные контроллеры, например 2022. Через них выводят старые ОС и достигают DFL/FFL 2016 во всём нужном объёме леса. Готовая ВМ с Windows Server 2025 не отменяет этих условий.

Способ восстановления определяют до изменения. Параметр GPO можно вернуть к сохранённому значению; для расширения схемы, завершения миграции SYSVOL и повышения функциональных уровней возможности возврата другие. План «откатим все ВМ» не заменяет поддерживаемую процедуру восстановления AD.

Чем подтверждать завершение модернизации

Результат — поддерживаемые и обновляемые DC, штатно выведенные старые узлы и проверенные зависимости. Репликация каталога и SYSVOL работает, DNS и время соответствуют новой топологии, клиенты обращаются к действующим серверам. Резервные копии создаются предусмотренным способом, а восстановление проверено в изоляции.

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

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

Практический ориентир для сроков — начать замену платформы до окончания доступных обновлений, с запасом на поиск зависимостей и перенос дополнительных ролей. Тогда неисправный SYSVOL, устаревшая LDAP‑интеграция или CA на выводимом DC становятся плановыми задачами с проверяемым результатом. При срочной миграции те же работы никуда не исчезают; для их выполнения остаётся меньше времени.

Какая зависимость сегодня мешает вашему домену перейти на поддерживаемые контроллеры — протокол, приложение, дополнительная роль DC или состояние самой AD?