Красивые обещания и некрасивые последствия: почему «объединение» доменов — это архитектурная авантюра

На рынке импортозамещения сложился устойчивый жанр — назову его «решение одним слайдом». Вендор рисует красивую схему: линуксовый контроллер домена встраивается в существующую Windows-инфраструктуру, пользователи работают как прежде, переход происходит плавно и все совместимо. Звучит убедительно, особенно на фоне того, что реальная миграция долгая, дорогая и требует серьезной подготовки.

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

Ряд отечественных вендоров предлагает следующий подход: их каталог, построенный на базе Samba DC, эмулирует контроллер домена Microsoft и встраивается в цепочку репликации существующего Active Directory. Формально это выглядит как гибридная инфраструктура, когда два типа контроллеров работают в одном домене. На пилотном стенде с небольшим количеством объектов это работает и вполне убедительно.

Но чтобы понять, почему в продуктивной среде это решение опасно, нужно разобраться в понятии уровня функциональности леса (forest functional level):

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

Microsoft Active Directory существует с 2000 года, и каждая версия Windows Server вводила новый уровень функциональности. Текущий минимальный (Windows 2000, актуальный на сегодня) Windows Server 2016, и большинство крупных российских корпоративных заказчиков к 2026 году находятся на уровне Windows Server 2016. Примечательно, что Microsoft не вводила новых уровней функциональности для Windows Server 2019 и 2022 — оба работают на уровне 2016, который остается максимально возможным даже в полностью современных инфраструктурах.

Samba DC, на которой базируются упомянутые решения, поддерживала встройку в домен Windows и репликацию по протоколу MS-DRSR (Directory Replication Service Remote Protocol). Однако эта поддержка имеет принципиальное ограничение по уровню функциональности: Samba DC корректно работает только с определенными уровнями леса, а совместимость с Windows Server 2016 и выше — предмет постоянных технических вопросов в профессиональном сообществе.

Допустим, на момент внедрения все работает. Линуксовый контроллер домена реплицируется, пользователи аутентифицируются, ИТ-директор доволен. Что происходит дальше?

Microsoft продолжает выпускать обновления для Windows Server. Это штатный процесс, включающий патчи безопасности, исправления и плановые обновления. И каждое из этих обновлений потенциально меняет детали реализации протокола репликации — не обязательно кардинально и не обязательно намеренно, но достаточно, чтобы Samba DC перестала корректно обрабатывать изменения от обновленного контроллера Microsoft.

Перед нами разворачиваются несколько сценариев:

Линуксовый контроллер выпадает из цепочки репликации. Домен становится неконсистентным (inconsistent) — фактически распадается на два независимых контура с разными состояниями базы данных. Пользователи, аутентифицированные через линуксовый контроллер, видят одну картину прав доступа; те, кто попал на Windows-контроллер, — другую. Администраторы обнаруживают это, как правило, не сразу, и к моменту обнаружения расхождения в данных уже значительные.

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

В результате конфликта репликации повреждается Windows-часть домена. Active Directory — распределенная база данных, и конфликты репликации в ней разрешаются по определенным правилам. Если в цепочке появляется участник, который обрабатывает изменения некорректно, последствия могут распространиться на весь домен, включая его виндовую часть. Восстановление домена Active Directory из подобной ситуации — это операция с непредсказуемым временем и гарантированными потерями данных или состояния объектов.

Samba DC — зрелый и по-своему уважаемый проект с открытым исходным кодом. Он решает конкретные задачи и решает их неплохо в тех сценариях, для которых создавался, но встройка в репликацию продуктивного Windows-домена точно не тот сценарий, для которого он проектировался как надежное промышленное решение. Это, скорее, эксплуатация пограничных возможностей, которые Microsoft никогда не документировала как поддерживаемые для сторонних реализаций.

Иными словами, каталоги на базе Samba DC несут в себе архитектурную особенность, которую я бы назвала родовой травмой в данном контексте: они изначально зависят от того, насколько точно Samba успевает отслеживать закрытые изменения в протоколах Microsoft. Это гонка, в которой у Samba нет доступа к технической документации оппонента и нет гарантий, что следующее обновление не сломает то, что работало вчера.

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

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

Импортозамещение корпоративного каталога — это задача миграции из одной среды в другую с сохранением управляемости, прав доступа и непрерывности сервисов, а не встройки Linux-контроллера в существующий Windows-домен. Эти задачи принципиально разные по архитектуре и по рискам.

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

Красивый слайд с объединенной инфраструктурой — это обещание, за которым стоит чужой риск. А когда наступает момент выяснять, чей именно, оказывается, что у каждого участника есть веские доводы в пользу того, что виноват кто-то другой.

Так что же делать, чтобы минимизировать риски?

Все просто: выбирая подход к миграции, заранее задайте себе один простой вопрос: что произойдет, когда Microsoft выпустит следующее обновление?