Импортозамещение Active Directory: кейс перехода на российскую службу каталогов MULTIDIRECTORY

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

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

Рассмотрим типовой сценарий такой миграции.

Исходная инфраструктура

Представим компанию на 5000 пользователей.

Основная часть рабочих мест работает под Windows, при этом активно развивается серверная инфраструктура на Linux. Используются российские операционные системы, разворачиваются новые отечественные приложения и сервисы.

В текущем контуре присутствуют:

• Microsoft Active Directory;
• Core network services (DNS, DHCP);
• файловые ресурсы;
• 1С;
• корпоративная почта;
• VPN;
• терминальные серверы;
• внутренние информационные системы;
• средства мониторинга и ИБ.

Это типичная гибридная инфраструктура, в которой одновременно используются Windows и Linux и постепенно увеличивается доля отечественного ПО. Подобные сценарии неоднократно встречаются в требованиях заказчиков MULTIDIRECTORY. Например, в одном из проектов одновременно используются Microsoft AD, Linux-хосты на Ubuntu и Astra Linux, Ansible и системы, интегрированные с доменом.

При этом Active Directory остаётся действующей системой каталогов и отключить её одномоментно невозможно.

Почему нельзя просто заменить AD

На первый взгляд миграция выглядит просто: Microsoft Active Directory → отечественная служба каталогов. На практике доменная инфраструктура связана с большим количеством корпоративных систем и сервисов.

Кроме хранения учетных записей и аутентификацию по LDAP и Kerberos, Active Directory может отвечать за:

• DNS организации
• применение групповых политик;
• доступ к файловым ресурсам;
• подключение и управление рабочими станциями;
• работу VPN;
• интеграцию с бизнес-приложениями;
• терминальные сервисы;
• взаимодействие с почтовыми и другими корпоративными системами.

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

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

Этап 1. Развёртывание нового каталога

На первом этапе существующая инфраструктура не меняется. Microsoft Active Directory продолжает выполнять свои функции, а рядом разворачивается MULTIDIRECTORY.

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

Именно такой подход используется в пилоте: разворачивается отдельный тестовый контур, выдаются временные Enterprise-лицензии, таким образом получается проверить работу AD и MULTIDIRECTORY совместно.

Этап 2. Настройка доверительных отношений

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

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

Этап 3. Подключение Linux-инфраструктуры

Следующий этап связан с развитием гетерогенной инфраструктуры.

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

Часто встречается сценарий, при котором пользовательские рабочие станции пока остаются на Windows, а серверная инфраструктура постепенно переводится на Linux.

Это позволяет разделить два процесса: миграцию операционных систем и миграцию службы каталогов. Они взаимосвязаны, но не обязательно должны выполняться одновременно.

Этап 4. Перевод Windows-рабочих станций

Следующая задача — работа с Windows-инфраструктурой.

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

Поэтому на этапе миграции необходимо учитывать:

• ввод Windows-машин в новый домен;
• применение политик;
• работу существующих приложений;
• доступ к файловым ресурсам;
• сохранение корпоративных сценариев аутентификации.

Этап 5. Перенос политик управления

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

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

Речь может идти о:

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

Поэтому при переходе с AD необходимо оценивать не только совместимость LDAP и Kerberos, но и то, как будет организовано централизованное управление инфраструктурой после миграции. Этот вопрос особенно актуален для организаций с большим количеством Windows-машин. 

Этап 6. Проверка интеграций

После настройки доменной инфраструктуры необходимо последовательно проверить корпоративные сервисы. В зависимости от архитектуры организации в этот список могут входить:

• 1С;
• VPN;
• RDS;
• файловые сервисы;
• почта;
• корпоративные порталы;
• внутренние приложения;
• SIEM;
• удостоверяющие центры.

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

Этап 7. Поэтапная миграция пользователей

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

Оптимальная модель — постепенное масштабирование: пилотная группа → отдельное подразделение → несколько подразделений → основная часть пользователей.

На каждом этапе проверяются:

• аутентификация;
• доступ к приложениям;
• применение политик;
• доступ к файловым ресурсам;
• работа Windows и Linux;
• интеграции с внешними системами;
• журналирование.

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

Этап 8. Вывод старого домена

И только после того, как основные зависимости переведены на новый каталог, можно планировать вывод Microsoft AD из эксплуатации.

Фактически итоговая последовательность выглядит так:

Основные риски проекта

На практике основные сложности повторяются от проекта к проекту.

Доверительные отношения

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

Управление Windows

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

Групповые политики

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

Интеграция с корпоративными системами

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

DNS и Kerberos

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

Геораспределённая инфраструктура

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

Что необходимо определить до начала миграции

До запуска проекта имеет смысл сформировать карту зависимостей Active Directory.

• Идентификация: LDAP, Kerberos, группы, доверительные отношения, парольные политики.
• Рабочие станции: Windows Join, Linux Join, политики, локальные учётные записи, права пользователей.
• Инфраструктура: DNS, DHCP, NTP, файловые ресурсы, RDS.
• Корпоративные приложения: 1С, VPN, почта, порталы, внутренние информационные системы.
• Средства информационной безопасности: LDAPS, сертификаты, SIEM, журналирование, MFA.

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

Вывод

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

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

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

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

• #MULTIDIRECTORY
• #СЛУЖБА КАТАЛОГОВ