В условиях ограничений на использование зарубежного ПО все больше российских компаний начинают масштабные проекты по переходу на отечественные решения. Один из таких кейсов — пилотное внедрение нашей системы управления каталогами Dynamic Directory в территориально распределенной организации с десятками филиалов и тысячами рабочих мест.
В этой статье мы расскажем о технической стороне проекта: как была устроена инфраструктура заказчика, как мы проектировали пилот, какие решения принимали на ходу и какие технические возможности Dynamic Directory помогли достичь результата.
Исходные условия: гетерогенная и фрагментированная ИТ-среда
К нам обратился заказчик с разветвленной ИТ-инфраструктурой, включающей офисы в пяти регионах: Москве, Санкт-Петербурге, Екатеринбурге, Краснодаре и Новосибирске. Всего — более 10 000 автоматизированных рабочих мест (АРМ), часть из которых работает под управлением Astra Linux, RED OS, РОСА Хром, а часть — на Windows 10 и Windows 7.
На стороне серверов использовались Windows Server 2012 R2 и 2016, Red Hat Enterprise Linux 8, а в качестве систем виртуализации — VMware vSphere и Microsoft Hyper-V. Исторически инфраструктура заказчика формировалась за счет поглощений. В результате в компании существовал один основной лес Active Directory и несколько унаследованных доменов, не объединенных в единое пространство имен. В ряде филиалов — слабые или нестабильные каналы связи. В некоторых офисах не было серверных помещений, и сервисы размещались на рабочих станциях.
Цели проекта
Целью заказчика было замещение следующих компонентов:
MS Active Directory — Службой каталогов Dynamic Directory с поддержкой групповых политик.
MS WSUS — Платформой для централизованного управления ИТ-инфраструктурой РОСА Центр управления, в состав которой входит система обновления и распространения программного обеспечения;
MS SCCM — Платформой для централизованного управления ИТ-инфраструктурой РОСА Центр управления (о ней расскажем в следующий раз).
Дополнительные задачи включали централизованное управление АРМ как под управлением ОС Windows, так и под управлением ОС семейства Linux, создание единого домена с возможностью взаимодействия с унаследованными доменами на этапе миграции, обеспечение отказоустойчивости и устойчивости к нестабильным сетям, а также реализацию механизмов безопасной репликации.
Почему Dynamic Directory
До начала пилота заказчик тестировал другие решения, но столкнулся с ограничениями в скорости, масштабируемости, количестве групповых политик "из коробки", возможности применения групповых политик пользователя для пользователей из доверенных доменов, интеграции с российскими ОС и других. В ходе демонстрации возможностей Dynamic Directory были показаны высокая производительность при работе с организационными единицами (OU), применение политик к АРМ на Astra Linux и RED OS, поддержка доверительных отношений с лесами MS AD, возможность безопасной и быстрой миграции пользователей и OU, а также встроенная двухфакторная аутентификация и поддержка расширенных атрибутов и динамических групп.
После демонстрации было принято решение развернуть пилотный стенд, который стал полноценной зоной эксплуатации.
Архитектура пилота
На этапе пилота заказчик отказался от развертывания инфраструктуры во всех регионах,чтобы минимизировать время и сосредоточиться на отработке сценариев использования. Основная инфраструктура пилота была развернута на 2 площадках, имеющих отказоустойчивую сетевую связность и широкий канал связи в Москве и Санкт-Петербурге. В каждом из ЦОД было развернуто по 2 контроллера домена Dynamic Directory, также был развернут дополнительный контроллер домена в удаленном филиале для проверки поведения системы в более сложных условиях. Архитектура строилась исходя из потребности заказчика иметь возможность работы на импортозамещенных АРМ как пользователями создаваемого домена, так и пользователями имеющихся доменов MS Active Directory.
В тестовую зону заказчик перенёс 50 АРМ на Astra Linux Орёл 1.7 и 50 АРМ на RED OS 8 — они были подключены через клиент dd-client. Часть машин на Windows 10 подключили к нашему домену с помощью утилиты ksetup.exe, входящей в состав ОС Windows. Также заказчик выделил 10 АРМ с установленной ОС РОСА Хром — установка выполнялась по сети из РОСА Центр управления.
Каталог и модель хранения
Dynamic Directory реализует LDAP-совместимую структуру, в качестве хранилища объектов используется база данных MDB, которая превосходит по производительности BDB, применяемую в более ранних версиях продукта. Ключевая особенность организации иерархии организационных единиц заключается в отказе от ссылочной модели. В большинстве решений, имеющих в основе продукт FreeIPA, объекты OU реализованы как логические ссылки, что замедляет массовые выборки, отрицательно сказывается на безопасности и отказоустойчивости системы, ограничивает возможности делегирования прав на основе организационных единиц. В Dynamic Directory объекты физически хранятся в контейнерах, к которым относятся, в отличие от других решений на базе FreeIPA, где они хранятся в одном контейнере и только ссылочными атрибутами относятся к тем или иным контейнерам. Все данные доступны напрямую, что дает кратное ускорение выборок и отказоустойчивость решения.
Репликация
Репликация между контроллерами выполняется в режиме “Мультимастер”. Каждый сервер содержит полную копию данных службы каталога. Данные передаются инкрементно и шифруются. В случае плохой связности используется отложенная репликация: обновления применяются локально и отправляются на остальные узлы при восстановлении связи. Именно это позволило заказчику не развертывать дополнительные каналы связи в каждом филиале.
Политики и управление рабочими станциями
Политики описаны на декларативном языке описания состояний, в том числе с поддержкой ERB-шаблонов. Сами же параметры групповых политик хранятся в LDAP-каталоге, а специальный шлюз на рабочей станции обеспечивает сложение полученных из каталога групповых политик и формирование результирующей групповой политики для АРМ и пользователя, выполнившего вход в систему. Например, можно централизованно задать запрет на использование USB, указать параметры прокси-сервера, назначить обои для рабочего стола, реализовать полностью автоматическую смену паролей локальных администраторов на конечных устройствах (аналог MS LAPS) и еще более 1600 параметров и значений параметров групповых политик для пользователей и компьютеров. Политики получаются и применяются раздельно для хоста, используя для получения собственный кейтаб, и для пользователя, используя полученный при входе в систему билет Kerberos. В рамках пилота заказчик использовал политики для блокировки съемных носителей, задания дополнительных сетевых параметров и автоматической настройки пользовательской среды.
Доверие и миграция из AD
Dynamic Directory поддерживает Kerberos cross-realm trust, что позволило заказчику построить двустороннее доверие между новым доменом и унаследованными MS AD-доменами. Это доверие обеспечивало доступ пользователей из старых доменов к ресурсам нового и наоборот. Утилита dd-migrate подключалась к AD через LDAP, выгружала структуру OU, пользователей, группы. В результате заказчик перенес каталоги, включая вложенные группы, без необходимости вручную пересоздавать структуру.
Ролевая модель
Заказчику требовалось, имея единый домен, организовать каталог по территориальному принципу и ограничить доступ администраторов из филиалов к администрированию объектов других филиалов и подразделений.
Служба каталогов Dynamic Directory отлично подошла для этой задачи, т.к. имеет реальную иерархическую структуру организационных единиц, а в качестве основной ролевой модели был создан механизм делегирования прав на организационные единицы. Стандартная ролевая модель FreeIPA для этого не подходит, т.к. она разрабатывалась с учётом того, что в FreeIPA объекты хранятся в стандартных контейнерах и их расположение зависит только от типа объекта.
Делегирование прав на организационные единицы позволяет предоставить пользователю или группе пользователей права на управление объектами в организационных единицах. Для каждого типа объекта права задаются отдельно. Права могут быть даны на чтение/добавление/изменение/удаление, дополнительно можно указать будут ли наследоваться права вниз по иерархии или нет и можно ли делегировать выданные права по цепочке (от пользователя A к пользователю B, затем от пользователя B к пользователю C). Также возможно установить запрет,например, разрешив доступ на верхнем уровне одним делегированием и запретив доступ к нижнему уровню - другим. Права могут быть даны как на объекты, так и на отдельные атрибуты объектов. В качестве объектов могут быть указаны: Пользователь, Подразделение, Общий принтер (оставлено для совместимости), Общая папка (оставлено для совместимости), Компьютер, Динамическая группа пользователей, Динамическая группа компьютеров, Делегирование, Группа пользователей, Группа компьютеров. Также для удобства администрирования предусмотрено сохранение шаблонов прав доступа: администратор может настроить необходимые права, сохранить шаблон, затем применить его при создании делегирования на другие организационные единицы.
Помимо возможности предоставления прав на объекты, которые содержат организационные единицы, мы добавили и возможность запрета доступа к объектам. Это удобно, когда мы даём разрешения на верхнем уровне иерархии, но хотим запретить доступ к объектам на нижних уровнях.
Расширенные возможности
Dynamic Directory позволяет добавлять кастомные поля к объектам, поддерживать до 20 расширенных атрибутов для основных типов записей службы каталогов, а также использовать штатный механизм расширения схемы данных LDAP. В пилоте это применялось для хранения информации о семейном положении, паспортных данных и ИНН.
Также заказчик активировал встроенную двухфакторную аутентификацию для администраторов службы каталогов: с помощью групповой политики на рабочие места администраторов были распространены скрипты для быстрой генерации QR-кодов и ярлыки для быстрого доступа к ним. После создания QR-кода и добавления его в приложение FreeOTP для администратора активировалась двухфакторная аутентификация, после чего при входе на рабочее место стала необходима дополнительная верификация с использованием одноразовых кодов из приложения FreeOTP, при этом обычные пользователи входили по паролю.
Аудит, мониторинг и отказоустойчивость
Все действия пользователей, изменения политик, ошибки репликации и обращения к каталогу фиксировались в журналах. Журналы с серверов службы каталогов пересылались по протоколу syslog в Opensearch, благодаря чему заказчику был доступен их централизованный просмотр. Благодаря интеграции РОСА Центр управления с Opensearch просмотр журналов также был доступен из веб-интерфейса сервиса. Для мониторинга использовались Zabbix и Grafana, тоже интегрированные с Центром.
Выводы по пилоту
Пилот позволил отработать ключевые сценарии: включение рабочих станций в домен, применение политик, репликация между площадками, работа доверительных отношений и миграция из AD. Dynamic Directory показал высокую скорость, отказоустойчивость, совместимость с российскими ОС и MS Windows, функционал, не имеющий аналогов в других решениях. По результатам пилота было принято решение о переходе в продуктив, расширении домена, переводе более 3000 АРМ в этом году, ещё более 7000 АРМ до конца 2026 года и поэтапном отказе от MS AD.
Dynamic Directory продемонстрировал, что может стать не просто заменой Active Directory, а полноценным ядром современной инфраструктуры. Система обеспечивает отказоустойчивость, прозрачную интеграцию, централизованное управление политиками и поддержку российских ОС. Работа продолжается: мы развиваем продукт, расширяем документацию и готовим новые инструменты для миграции и мониторинга. В следующих статьях мы расскажем о переходе заказчика в продуктивную эксплуатацию и технических деталях архитектуры в финальной версии.
