Переход на отечественный каталог редко заканчивается в момент успешного развертывания контроллера домена. Настоящие сложности начинаются тогда, когда новая служба каталогов сталкивается с корпоративной экосистемой – десятками приложений, сервисов и интеграций, которые годами строились под Microsoft Active Directory. Тут-то и обнаруживаются конфликты, которые не были заметны ни на пилотном стенде, ни в документации вендора.
Разберем наиболее типичные из них проявления в реальных проектах.
Плоская структура против иерархии
Microsoft Active Directory строится на иерархической модели объектов. Организационные подразделения (OU – organizational units) в ней образуют дерево (компания, регион, отдел, группа), групповые политики назначаются на любой уровень этого дерева и наследуются вниз по иерархии. За двадцать лет работы с AD администраторы привыкли к этой логике.
OU (Organizational Unit) – организационное подразделение в Active Directory, предназначенное для логической группировки объектов домена, например пользователей и компьютеров, и применения к ним политик и делегирования полномочий.
Каталоги на базе FreeIPA (Free Identity, Policy and Audit) – а к ним относятся ALD Pro, Dynamic Directory и ряд других отечественных решений – изначально построены на плоской модели.
В службе каталога FreeIPA нет подразделений:
- все объекты расположены в плоской структуре;
- для назначения групповых политик используются обычные группы пользователей и компьютеров.
ALD Pro частично решает эту проблему, добавляя собственную реализацию организационных подразделений поверх FreeIPA, однако при назначении OU на объект найденные подразделения отображаются плоским списком, что усложняет работу при наличии одноименных подразделений в нескольких офисах.
На практике это выглядит следующим образом: если у организации сложная филиальная структура с подразделениями одного названия в разных регионах (например, «Бухгалтерия» в Москве и «Бухгалтерия» в Самаре), при миграции неизбежно возникают конфликты имен. В Microsoft AD эти объекты сосуществуют без проблем, потому что находятся в разных ветках иерархии, а в целевом каталоге имена должны быть уникальными в пределах всего домена.
Решение этой задачи требует заблаговременной подготовки данных и настройки правил трансформации имен.
Кириллица, пробелы и спецсимволы
Следующий конфликт менее очевиден, но не менее болезнен. Microsoft AD исторически допускает широкий набор символов в именах объектов (пробелы, кириллицу, специальные символы). В российских инфраструктурах это использовалось активно, а имена пользователей, группы и названия компьютеров на русском языке давно стали нормой.
Отечественные каталоги на базе FreeIPA имеют ограничения по допустимым символам в атрибутах объектов. LDAP-стандарт и реализации на его основе значительно строже в этом отношении: кириллица в ряде атрибутов либо не поддерживается, либо поддерживается с ограничениями, а пробелы в именах учетных записей (samAccountName) – распространенная причина ошибок при миграции.
LDAP-стандарт – набор правил и протоколов, определяющих взаимодействие с каталогом по LDAP (Lightweight Directory Access Protocol), в том числе поиск, чтение и изменение данных каталога.
samAccountName – атрибут учетной записи в Active Directory, содержащий ее имя для совместимости с более ранними версиями Windows и используемый, в частности, при аутентификации в некоторых сценариях.
То есть перед переносом данных необходима очистка и транслитерация. Масштаб этой работы напрямую зависит от того, насколько «свободно» организация использовала символы в AD.
Например, в крупных инфраструктурах с тысячами объектов ручная обработка нереалистична – нужны автоматизированные правила преобразования с возможностью предварительного просмотра результата до фактического переноса.
Глобальный каталог и поиск между доменами
Одно из ключевых различий между Microsoft AD и каталогами на базе FreeIPA касается глобального каталога (Global Catalog, GC).
Global Catalog (GC) – распределенный каталог Active Directory, содержащий сведения об объектах всех доменов леса и позволяющий выполнять поиск по лесу без обращения к каждому домену отдельно.
В Active Directory глобальный каталог – это специальная роль контроллера домена, которая хранит частичные копии всех объектов леса и обеспечивает быстрый поиск пользователей и групп между доменами. Многие корпоративные приложения (почтовые клиенты, системы документооборота, ERP) обращаются именно к глобальному каталогу для поиска адресатов и проверки прав доступа.
ERP (Enterprise Resource Planning) – корпоративная информационная система для управления ключевыми бизнес-процессами компании, включая финансы, закупки, производство, продажи, складской учет и другие связанные процессы.
В базовой комплектации FreeIPA нет модуля глобального каталога, поэтому поддержка двусторонних доверительных отношений без доработок оказывается неполной. А в ALD Pro нет глобального каталога, то есть не работает поиск пользователей домена ALD Pro из стандартных форм в домене MS AD.
Для организаций с несколькими доменами или с приложениями, активно использующими поиск по GC, это становится серьезным ограничением. Почтовые клиенты не находят адресатов, системы документооборота не могут получить список пользователей через стандартный LDAP-запрос к порту 3268* (стандартный порт глобального каталога в AD).
Порт 3268 – стандартный TCP-порт, через который клиенты обращаются к Global Catalog Active Directory по LDAP без шифрования; для защищенного подключения к Global Catalog обычно используется порт 3269 по LDAPS.
Эти интеграции требуют перенастройки – и в ряде случаев доработки самих приложений.
Kerberos и задержки аутентификации в больших инфраструктурах
Еще один конфликт, который проявляется не сразу, а по мере роста нагрузки.
При входе пользователя в систему служба SSSD не только проверяет аутентичность пользователя с помощью Kerberos-тикетов, но и запрашивает у контроллера домена авторизационную информацию через расширенную операцию LDAP, что может приводить к появлению задержек в больших инфраструктурах, если пользователь является участником большого числа групп.
Протокол Kerberos – сетевой протокол аутентификации, который позволяет пользователю или сервису подтвердить свою подлинность и безопасно получить доступ к ресурсам без передачи пароля по сети.
Такая проблема распространена в крупных организациях, где права доступа исторически раздавались щедро. В Microsoft AD это работало без видимых задержек благодаря Kerberos PAC (Privilege Attribute Certificate) – структуре, которая хранит информацию о членстве в группах непосредственно в самом тикете. В FreeIPA-каталогах архитектура иная, и при большом числе групп на пользователя время аутентификации может заметно возрастать.
Поэтому важен аудит исходной среды до начала миграции. Выявление учетных записей с избыточным членством в группах позволяет заранее оценить масштаб проблемы и принять организационные решения до того, как они проявятся в продуктивной среде.
Переезд по фейсконтролю
Механизм групповых политик (GPO – Group Policy Objects) в Microsoft AD – один из самых мощных инструментов централизованного управления инфраструктурой. Через него управляется буквально все:
- настройки рабочих станций;
- политики паролей;
- конфигурация браузеров;
- установка программного обеспечения;
- параметры безопасности.
Отечественные каталоги реализуют групповые политики по-своему. В основе механизма групповых политик ALD Pro лежит Salt – система управления конфигурациями с открытым исходным кодом, написанная на Python. Это принципиально иная архитектура по сравнению с Windows GPO, поэтому прямого импорта политик из AD в ALD Pro не существует. Каждую политику необходимо анализировать, оценивать применимость к новой среде и при необходимости создавать аналог заново.
Перед миграцией критически важно провести аудит групповых политик:
- какие из них используются?
- на какие объекты применяются?
- какие из них имеют аналог в целевом каталоге?
- какие потребуют отдельной реализации?
Без этого анализа организации нередко обнаруживают после миграции, что часть настроек рабочих станций перестала применяться, и начинают разбираться с последствиями уже в продуктивной среде.
Как работать с такими конфликтами
На самом деле, все перечисленное не означает, что интеграция с корпоративной экосистемой невозможна. Зато означает другое: ее нужно планировать в упреждение.
Практический подход выглядит так:
- До начала миграции необходимо составить карту интеграций – все приложения и сервисы, которые обращаются к каталогу, с указанием протокола (LDAP, Kerberos, NTLM), используемых атрибутов и характера запросов.
- Провести аудит исходной среды с учетом требований целевого каталога (такой подход реализован в Pragmatic Tools Migrator, где аудит настроен под особенности каждой целевой платформы).
- Приступить к переносу поэтапно, с тестированием каждой интеграции на выделенном сегменте до перевода в продуктив.
Корпоративная экосистема не прощает сюрпризов. Чем лучше они выявлены до начала работ, тем более управляемым окажется весь переход.
Изображение на обложке: Pragmatic Tools, генерация через ChatGPT
Комментарии