Active Directory на WS2019: первый DC поднят, functional level пока 2016, AAD Connect работает

Первый контроллер домена на Windows Server 2019 в продакшн-среде клиента мы подняли на прошлой неделе. Это не катастрофическое событие и не повод для торжеств - один DC в существующем лесу, рядом с двумя WS2016. Но вопросов по дороге набралось достаточно, чтобы зафиксировать что реально изменилось и где мы притормозили.

Что с functional level

Первый вопрос который задаёшь себе при добавлении нового DC - поднимать ли forest functional level до WS2019. Ответ в нашем случае - нет, по крайней мере сейчас.

Forest functional level 2019 добавляет поддержку Privileged Access Workstation (PAW) через механизм Authentication Policy Silos и ряд улучшений вокруг fine-grained password policies. Это реальные вещи, не маркетинг. Но переход на новый functional level необратим - откатить нельзя, только если держишь все DC на целевой версии ОС. У клиента есть несколько второстепенных систем с зависимостями от Domain Services, которые мы ещё не успели проверить на совместимость. Поэтому оставили 2016. Потеряем? Нет - DC на WS2019 в лесу с functional level 2016 работает нормально, все стандартные функции AD доступны.

Один нюанс который несколько удивил: прочитать итоговый список изменений в functional level WS2019 оказалось нетривиально. Документация Microsoft на этот момент разбросана по нескольким статьям TechNet и частично противоречит сама себе в части поддержки RODCs. Пришлось сверяться с реальным поведением, а не только с документацией.

AAD Connect и Pass-through Authentication: это теперь основной сценарий

Параллельно с DC настроили гибридную идентификацию через Azure AD Connect с Pass-through Authentication. Это не новинка WS2019 как таковая, но именно сейчас у клиента созрело понимание что PTA - правильный выбор для их ситуации.

Схема простая:

• Azure AD Connect синхронизирует объекты из on-premises AD в Azure AD. Пользователи, группы, устройства.
• Pass-through Authentication - агент на нескольких серверах в корпоративной сети принимает запросы аутентификации от Azure AD и проверяет их напрямую у on-premises AD-контроллера. Пароль не хранится и не синхронизируется в облако.
• Seamless SSO - через Kerberos-тикеты на доменных машинах, пользователи прозрачно аутентифицируются в облачных сервисах без повторного ввода пароля.

Альтернатива PTA - AD FS, и именно от него клиент отказался после оценки. AD FS требует отдельной инфраструктуры: минимум два Federation Service-сервера, WAP для DMZ, собственные сертификаты, отдельный monitoring. Для организации без выделенной команды, которая будет это сопровождать, это лишняя точка отказа. PTA в этом смысле проще: агенты устанавливаются на существующие серверы, отказоустойчивость достигается числом агентов, сложной инфраструктуры нет.

Третий вариант - Password Hash Synchronization - тоже рассматривали. Технически проще PTA, но хеши паролей всё-таки уходят в Azure. Клиент с этим не согласился.

Как разворачивали PTA

На двух серверах в периметре - не DC, отдельные члены домена - установили PTA Agents через мастер AAD Connect. Агент регистрируется в Azure AD, создаёт исходящее соединение к облаку, никаких входящих портов открывать не нужно. Это важно с точки зрения периметральной безопасности: агент сам инициирует соединение через 443, входящий трафик на периметр не добавляется.

Проверка работы выглядит так: берём тестового пользователя, заходим на portal.azure.com, вводим on-premises пароль. Агент на сервере получает запрос, передаёт в AD, ответ возвращается в Azure AD, пользователь аутентифицирован. Всё это в реальном времени - если пользователя заблокировали в on-premises AD, блокировка мгновенно работает и в облаке. В Password Hash Sync задержка была бы.

Один неприятный момент: первый агент установился без проблем, второй завис на этапе регистрации. Причина оказалась банальной - proxy в корпоративной сети, который не пропускал запросы без явной настройки исключений для Microsoft-endpoint-ов. Полчаса на диагностику, пять минут на правило в proxy - всё заработало.

Что фактически даёт DC на WS2019

Если честно, для большинства функций AD разница между WS2016 и WS2019 DC на forest functional level 2016 - минимальная. Большинство изменений WS2019 в части AD завязаны именно на повышение functional level. То что работает прямо сейчас без повышения - улучшения в производительности репликации и более стабильная работа SYSVOL через DFSR, которую в WS2016 иногда приходилось принудительно пинать.

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

Что дальше

Functional level оставим 2016 минимум до весны - хотим пройтись по всем приложениям с Kerberos-интеграцией и убедиться что ничего не сломается. Это не драма, просто аккуратность.

PTA работает в продакшн уже несколько дней, Authentication Agents живые, запросы проходят. В AAD Connect настроили password writeback - пользователи смогут менять пароль через Azure AD (через SSPR), и новый пароль запишется обратно в on-premises AD. Это снизит нагрузку на поддержку по теме «забыл пароль» - посмотрим насколько.

Управление всем этим в рамках managed-инфраструктуры клиента: AAD Connect требует мониторинга и периодического обновления, Authentication Agents обновляются автоматически, но знать об этом надо. Это не разовое развёртывание, а работающая система, за которой нужно следить.