FreeIPA как замена Active Directory: стенд работает, но Windows - большой вопрос

«А что с FreeIPA вместо AD?» - этот вопрос звучит от клиентов всё чаще, примерно с марта. Поначалу мы отвечали развёрнуто и по памяти, но когда одна и та же тема поднялась на третьей подряд встрече за неделю, стало понятно: надо поднять нормальный стенд и отвечать фактами, а не воспоминаниями о прошлых проектах.

Что такое FreeIPA и почему она всплывает

FreeIPA - это открытая система управления идентификацией, разрабатываемая Red Hat. Внутри: 389 Directory Server (LDAP), MIT Kerberos, встроенный DNS, Dogtag PKI (да, своя Certificate Authority), и веб-интерфейс поверх всего этого. Для Linux-мира это полноценная замена AD на уровне концепции: централизованные учётки, Kerberos-аутентификация, управление sudo-правилами, HBAC (host-based access control) - всё в одном.

Актуальная версия в дистрибутивах - 4.9.x. В Rocky Linux 8 и AlmaLinux 8 ставится из штатных репозиториев без лишних движений.

Что подняли

Стенд: три виртуальных сервера на AlmaLinux 8.6 - два IPA-сервера (master + replica для отказоустойчивости) и один клиент. Плюс несколько Windows 10 для проверки интеграции со стороны Microsoft. Репликацию между двумя IPA-серверами настроили сразу - это не опциональная деталь, а базовая гигиена.

Установка самого сервера укладывается в час, если читать документацию, а не угадывать параметры ipa-server-install. Инсталлятор спрашивает домен, realm, DNS-настройки, пароли - и поднимает весь стек. Веб-интерфейс появляется по адресу сервера и выглядит как нечто среднее между старым phpMyAdmin и ранним Jira: не красивый, но функциональный.

Linux через SSSD: работает хорошо

Подключение Linux-хостов к FreeIPA через SSSD - это история успеха. realm join с пакетом ipa-client прописывает всё нужное в /etc/sssd/sssd.conf сам, почти без ручной правки. После этого:

• Аутентификация. Доменные учётки работают, Kerberos-тикеты выдаются, SSH-вход по Kerberos (GSSAPIAuthentication yes) - без паролей, как положено.
• HBAC-правила. Можно точечно разрешать доступ: «группа ops - только на production-серверах, группа dev - только на staging». Это удобнее, чем тащить ту же логику через GPO.
• sudo через IPA. Sudo-правила описываются в интерфейсе IPA и применяются на клиентах через SSSD автоматически. Работает.
• Встроенный PKI. FreeIPA сама выдаёт сертификаты хостам и сервисам через Dogtag. Для внутреннего PKI это закрывает базовую потребность без отдельного развёртывания.

# Проверка Kerberos-тикета после входа доменного пользователя
klist

# Проверка HBAC с точки зрения клиента
ipa hbactest --user=testuser --host=$(hostname) --service=sshd

Всё это работает стабильно и предсказуемо. Для инфраструктуры, где все серверы - Linux, FreeIPA закрывает потребности идентификации убедительно.

Windows-клиенты: тут всё сложнее

А вот дальше начинается другая история. Интеграция Windows-клиентов с FreeIPA - это не «подключи и работай».

Технически возможны два пути. Первый - поднять Samba AD DC рядом с FreeIPA и настроить двусторонний траст между доменами. Мы делали отдельный стенд с Samba AD DC месяц назад - там своя картина с ограничениями. Связка FreeIPA + Samba с трастом работает, но это два домена, два набора объектов, двойная операционная нагрузка.

Второй - использовать встроенный в FreeIPA контроллер домена на базе Samba (режим --setup-adtrust). Он позволяет Windows-клиентам входить в домен FreeIPA напрямую. На стенде мы это проверили: Windows 10 ввели в домен, вход под доменной учёткой - работает. Но сразу встаёт вопрос про управление.

Групповые политики в FreeIPA отсутствуют как концепция. Нет механизма, который применяет политики на Windows-рабочие станции через доменный механизм GPO. Базовые параметры безопасности, скрипты входа, настройки реестра через политики - всё это в Windows AD берётся из GPO и sysvol. В FreeIPA ничего подобного нет. Ansible может закрыть часть задач управления конфигурацией, но это уже ручная работа, а не доменный механизм.

Поддержка стандартных инструментов администрирования Windows - ADUC, GPMC - тоже ограничена. Часть функций недоступна, часть работает непредсказуемо.

Где мы видим реальный сценарий

Для чисто Linux-инфраструктуры - FreeIPA сильное решение. Централизованные учётки, Kerberos, PKI, HBAC, sudo-правила - всё в одном, хорошо документировано, работает стабильно. Если клиент мигрирует с Windows-серверов на Linux и рабочие места тоже Linux (Astra, AlmaLinux, Rosa) - FreeIPA как центр идентификации смотрится органично.

Для смешанной среды с активным парком Windows-клиентов - FreeIPA не является прямой заменой AD. Это другая система с другой моделью управления. Подключить Windows можно, но управлять ими через привычные инструменты - нельзя. Либо принимаешь, что Windows управляется другими инструментами (Ansible, SCCM, что-то ещё), либо смотришь в сторону Samba AD DC, где Windows-совместимость выше за счёт того, что Samba буквально реализует протоколы AD.

Сопровождение таких гибридных стендов показывает: самая сложная часть не техническая настройка, а операционная модель. Кто и как управляет Windows-клиентами, если GPO выпадает из схемы? Этот вопрос надо закрыть до того, как начинать миграцию, а не после.

Стенд продолжаем держать и тестировать. Следующее, что хотим проверить - интеграция с IdM в составе RHEL-подписки и сравнение с тем, что предлагает FreeIPA upstream. Там могут быть различия в пакетном составе, которые важны для продакшн-развёртывания.