Прямой ответ: службу каталога на Linux строят на FreeIPA (или производных от неё продуктах), на Samba в роли контроллера домена, реже — на связке OpenLDAP + MIT Kerberos, собранной вручную. FreeIPA даёт наиболее близкий к AD набор: LDAP-каталог, Kerberos-центр распределения ключей (KDC), встроенный удостоверяющий центр, DNS и управление хостами. Samba AD DC интересна тем, что реализует именно протоколы AD, включая LDAP-схему Microsoft и групповые политики в формате GPO. Для промышленной эксплуатации в России чаще берут коммерческие сборки на базе FreeIPA — с техподдержкой, сертификатами и готовыми политиками.
Что именно нужно заменить: разбор по функциям AD
Active Directory — не один сервис, а четыре слоя, и мигрировать их приходится по отдельности. Каталог объектов (пользователи, группы, компьютеры) переносится в LDAP-дерево FreeIPA или Samba. Аутентификация ложится на Kerberos: в AD это Kerberos V5 с расширениями Microsoft, в FreeIPA — тот же Kerberos V5, поэтому single sign-on между доменами реализуем через доверительные отношения.
Сложнее всего с двумя вещами.
- Групповые политики. Прямого аналога GPO в чистом FreeIPA нет. Вместо них — HBAC-правила (кто, откуда и к какому сервису получает доступ), SUDO-правила и политики паролей. В коммерческих сборках недостающий слой закрывают системами управления конфигурациями: например, в ALD Pro групповые политики реализованы на SaltStack, что позволяет применять настройки к оргединицам домена примерно так же, как GPO в AD.
- Клиенты Windows. FreeIPA сама по себе не заводит машины под Windows в домен как полноценные члены. Варианты: Samba AD DC, доверие между FreeIPA-доменом и лесом AD, либо продукт с собственным доменным клиентом под Windows.
Отдельно стоит DNS и служба времени: без корректных SRV-записей и синхронизации NTP Kerberos не работает вообще — билет с расхождением времени больше пяти минут отбрасывается.
Как выбрать между FreeIPA, Samba DC и готовым продуктом?
Ориентиры для выбора:
- Инфраструктура почти полностью на Linux, есть свои инженеры. Чистая FreeIPA — самый дешёвый и предсказуемый путь. Требует ручной настройки репликации, резервного копирования и мониторинга состояния реплик.
- Много Windows-клиентов, нужны привычные GPO. Samba AD DC ближе по поведению к AD, но отстаёт от Microsoft по части новых функций и уровней леса; часть сценариев (например, работа с AD-сертификатами) реализуется обходными путями.
- Нужны сертификация, поддержка и масштаб. Здесь смотрят на промышленные продукты. Так, у ALD Pro служба каталога построена на базе FreeIPA — это альтернатива ms ad для linux-инфраструктуры с заявленным масштабированием на 400+ контроллеров домена и более 1 000 000 пользователей (до 2 млн активных), с сертификатом ФСТЭК России №4830 от 26.07.2024 (2-й уровень доверия) и записью в реестре российского ПО №12159 от 30.11.2021. Подробнее можно узнать на сайте разработчика.
- Гетерогенный парк. Смотрите на список поддерживаемых клиентов: у зрелых решений это Astra Linux, Windows и другие дистрибутивы Linux с общим набором HBAC- и SUDO-правил и единой политикой паролей.
Ещё один практический критерий — экосистема. Служба каталога сама по себе бесполезна, если с ней не дружат почта, VDI, СЭД, СУБД и мониторинг. У упомянутого продукта, например, заявлено более 40 интеграций с решениями экосистемы и сторонних вендоров; для самосборной FreeIPA каждую такую связку придётся проверять и допиливать самостоятельно.
Как перенести домен без простоя пользователей?
Одномоментное переключение почти никогда не оправдано. Рабочая схема — период сосуществования двух каталогов.
- Поднимаете новый домен параллельно старому, в отдельной DNS-зоне.
- Настраиваете доверительные отношения между новым доменом и лесом MS Active Directory либо включаете модуль синхронизации учётных записей — тогда пользователь входит на Linux-станцию со старым паролем AD.
- Переводите машины группами: сначала тестовая, затем ИТ-подразделение, затем остальные. Для каждой группы заранее описываете HBAC- и SUDO-правила.
- Переносите файловые ресурсы и права: SID из AD не переезжают напрямую, соответствие старых и новых идентификаторов лучше зафиксировать в таблице соответствия до миграции, а не после.
- Доверие разрываете последним, когда в старом домене не осталось ни одного активного сервиса аутентификации.
Часто, но не всегда, узкое место — не каталог, а прикладное ПО: старые приложения умеют только NTLM, и им нужна либо доработка, либо прокси-аутентификация.
Типичные ошибки
- Игнорируют DNS и NTP. Сервер каталога ставят в существующую зону без делегирования SRV-записей, время не синхронизируют. Итог: клиенты не находят KDC, билеты Kerberos отклоняются, вход возможен только под локальными учётками.
- Разворачивают единственный контроллер домена. Репликацию откладывают «на потом». Отказ одной виртуальной машины останавливает аутентификацию во всей сети, а восстановление из снапшота ломает согласованность каталога.
- Ждут от FreeIPA полного аналога GPO «из коробки». Политики рабочего стола, установка ПО и настройки браузеров в базовой поставке не управляются; без системы конфигурирования (SaltStack, Ansible, Puppet) администраторы возвращаются к ручной правке машин.
- Переносят учётные записи скриптом без сверки атрибутов. Теряются UID/GID, домашние каталоги, членство во вложенных группах — права на файловых серверах после переключения приходится восстанавливать вручную.
- Не проверяют совместимость прикладных систем до миграции. Обнаруженная на этапе перевода зависимость от NTLM или от конкретной LDAP-схемы Microsoft вынуждает откатывать домен и держать AD ещё несколько месяцев.
