FreeIPA вместо Active Directory на Astra Linux: пилот у госзаказчика

Вышла очередная директива - правительство конкретизировало сроки перевода государственных информационных систем на отечественное ПО: к 2024 году ведомства обязаны выйти на утверждённые показатели по ключевым категориям. Для заказчиков, у которых ещё не запущен пилот, это уже не «вопрос повестки», а задача с дедлайном. Один из наших региональных клиентов - орган исполнительной власти - решил не откладывать и попросил нас разобраться с заменой Active Directory на FreeIPA в связке с Astra Linux. Про первый пилот с Astra Linux и РЕД ОС мы писали раньше; здесь - отдельный заказчик с иным акцентом: не просто «завести машины в домен», а полноценно заменить AD как точку управления политиками.

Архитектура: без AD как primary

Сразу зафиксировали принципиальное решение: AD остаётся только как источник учётных записей на переходный период через Kerberos cross-realm trust, но управление Linux-машинами - полностью в FreeIPA. Никакого «sssd смотрит в AD напрямую» - это даёт зависимость от Windows-контроллера домена навсегда, а не временно.

[AD Windows Server 2019]  <-- cross-realm trust --> [FreeIPA 4.9 / Astra Linux]
                                                            |
                                    +-----------------------+-----------------------+
                                    |                                               |
                              [Astra Linux SE]                             [Astra Linux SE]
                              рабочие места                                серверный сегмент
                              (sssd + ipa-client)                          (sssd + ipa-client)

FreeIPA 4.9 входит в состав Astra Linux Common Edition через стандартные репозитории. Для Special Edition картина сложнее: пакетная база там консервативнее, и мы в итоге разворачивали сервер FreeIPA на отдельной машине с Astra CE, а рабочие места - на SE с подключением через ipa-client-install.

GPO-аналоги: что реально закрывает FreeIPA

Это был главный вопрос у службы безопасности заказчика. В AD групповые политики (GPO) - привычный инструмент: развернул объект, применил к OU, всё. В Linux-мире прямого аналога нет, и это важно проговорить честно.

FreeIPA закрывает часть сценариев:

• HBAC (Host-Based Access Control) - кто на какие машины может входить. Настраивается через ipa hbacrule-add, реплицируется на клиентов через sssd. Это работает надёжно.
• sudo-правила - централизованное управление sudo-привилегиями через IPA, без /etc/sudoers на каждой машине. Работает, синхронизация занимает несколько минут после изменения правила.
• Настройки паролей и блокировок - password policy в FreeIPA покрывает длину, сложность, историю, блокировку после неудачных попыток.

Что FreeIPA не покрывает из типичных GPO-сценариев: тонкая настройка рабочего стола, политики монтирования, часть параметров ядра и сетевых настроек. Здесь выходит связка с Ansible: пишем роли для конфигурации, которую GPO делал «сам». Это другая операционная модель - декларативная через код, а не точечные изменения через GUI консоли AD. Заказчику объяснять пришлось дольше, чем настраивать.

Kerberos и MIT Kerberos: где ждать боли

Astra Linux использует MIT Kerberos - тот же стек, что в upstream FreeIPA и большинстве Linux-дистрибутивов. Технически это хорошо; на практике несколько моментов требовали внимания.

Синхронизация времени - банальность, но в реальном пилоте это первое, что стреляет. Kerberos нетерпим к расхождению часов больше пяти минут. У заказчика NTP был настроен, но пара машин тянула время с недоступного сервера - kinit падал с KRB5KRB_AP_ERR_SKEW без очевидного объяснения для пользователя.

UPN-суффиксы из AD. Когда в AD несколько доменов или нестандартные UPN-суффиксы, аутентификация через trust может ломаться на стороне sssd. Параметр krb5_use_enterprise_principal = true в sssd.conf решает это, но он не стоит по умолчанию - пришлось прописывать явно.

Keytab для сервисов. Корпоративные приложения, которые сами участвуют в Kerberos (например, веб-сервисы с SPNEGO-аутентификацией), требуют keytab. Выписывается через ipa service-add и ipa-getkeytab. Ничего экзотического, но для каждого сервиса нужен отдельный проход - это нужно закладывать в план работ.

Совместимость приложений

Набор у этого заказчика типичный для госсектора: веб-приложения, 1С, ЮЗДО, несколько специфических внутренних систем.

Браузерные приложения с Kerberos SSO - заработали после настройки krb5.conf и прописывания negotiate в Firefox. Chromium потребовал дополнительного флага --auth-server-whitelist. Мелко, но отнимает время.

1С:Предприятие 8.3 - тонкий клиент через браузер работает. С толстым клиентом на Astra SE пришлось разбираться с локалью и несколькими библиотеками совместимости - это уже знакомая история из прошлого пилота.

ЮЗДО и системы документооборота - хуже. Два продукта из набора официально поддерживают только Windows. Один вендор предоставил неофициальный deb-пакет, который на Astra встал после ручного разрешения зависимостей. Второй честно сказал «ждите следующего релиза». Это не техническая проблема FreeIPA или Kerberos - это проблема экосистемы, и директива её не решает автоматически.

Где сейчас

Пилот охватывает около тридцати машин. Базовая схема - FreeIPA + AD trust + sssd на клиентах - работает. Пользователи логинятся с доменными учётками, HBAC и sudo-политики применяются, SSO через Kerberos в браузере работает.

Открытые вопросы: автоматизация того, что раньше делали GPO (доделываем Ansible-роли), документооборот без нативного Linux-клиента, и поведение Astra SE с мандатным управлением доступом на сетевых ресурсах - это отдельная тема, которая заслуживает отдельного разбора.

О том, как выстраивается регуляторная рамка для КИИ по методичке ФСТЭК, мы писали отдельно - там своя логика приоритизации, которая не всегда совпадает с тем, что заказчик хочет делать в первую очередь.

Интеграция такого уровня не бывает быстрой. Технически FreeIPA + MIT Kerberos на Astra Linux работает; операционно - это смена модели управления, к которой команда заказчика должна привыкнуть. Пилот продолжается.