Astra Linux и РЕД ОС в госзаказчике: пилотируем FreeIPA вместо AD

Минцифры в очередной раз затянуло гайки: расширенный реестр отечественного ПО теперь не рекомендация, а обязательное условие для государственных закупок. Госзаказчики, которые откладывали переход, получили внятный сигнал - откладывать дальше себе дороже. Один из наших клиентов, региональный орган исполнительной власти, решил не ждать и попросил нас провести пилот с Astra Linux и РЕД ОС.

Задача звучит просто: поднять несколько рабочих мест и серверов на отечественных ОС, встроить их в существующую инфраструктуру на базе Windows Server и Active Directory, убедиться что корпоративные приложения работают. На деле каждый из этих пунктов - отдельная история.

Что пилотируем и зачем два дистрибутива

Astra Linux Special Edition (версия Орёл, 1.6) и РЕД ОС 7.3 - оба в реестре Минцифры, оба сертифицированы ФСТЭК по разным классам защиты. Клиент хочет сравнить не абстрактно, а на конкретных задачах: серверная часть (контроллер FreeIPA, файловый сервер) и клиентские рабочие места.

Astra несёт за собой историю плотной работы с госсектором - сертификаты на защищённые исполнения, обязательные мандатные метки в SE-редакции. РЕД ОС базируется на Fedora-пакетной базе, что даёт более узнаваемый для инженеров ландшафт. Astra - Debian-мир (deb-пакеты), РЕД ОС - RPM; обе поддерживают SELinux (или его аналог в случае Astra).

FreeIPA как замена Active Directory: что работает, что скрипит

Архитектурное решение - не пытаться сохранить AD как primary directory и навесить на него SSSD-коннектор снизу, а поднять FreeIPA как центр управления для Linux-машин с доверием (trust) к существующему AD. Схема давно отработана в Red Hat-мире, но в связке с отечественными ОС нюансов хватает.

[AD Windows Server]  <-- Kerberos cross-realm trust --> [FreeIPA Server (РЕД ОС)]
                                                                |
                                          +---------------------+---------------------+
                                          |                                           |
                               [Astra Linux клиент]                       [РЕД ОС клиент]
                               (sssd + ipa-client)                        (sssd + ipa-client)

Kerberos trust поднялся без серьёзных проблем - ipa trust-add с флагом --type=ad отработал штатно на РЕД ОС после установки ipa-server-trust-ad. AD-пользователи видны через id ad_user@ad.domain.ru, единый вход из браузера через Kerberos-тикет работает. Базовый сценарий - рабочий.

Проблемы начались на уровне Astra Linux. Astra SE в максимальной конфигурации имеет собственный MAC-уровень (мандатное управление доступом), который взаимодействует с SELinux не совсем очевидным образом. SSSD в сборке под Astra - пропатченная версия, и несколько параметров sssd.conf, которые работают в РЕД ОС из коробки, требовали корректировки. Конкретно: krb5_use_enterprise_principal и обработка UPN-суффиксов из AD при аутентификации пользователей с несколькими доменами.

sudo-политики через IPA HBAC. Host-based access control в FreeIPA - один из главных аргументов за этот стек: управляешь из одного места кто на какие машины может заходить и с какими правами. Настройка sudo-правил через ipa sudorule-add работает, правила реплицируются на клиентов через sssd. Нюанс: время синхронизации политик не мгновенное, при первом тесте несколько минут возникало ощущение что правила не применяются - они просто ещё не дошли до клиента.

Корпоративные приложения: кто прошёл, кто завис

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

Браузерные веб-приложения - без проблем. Firefox ESR есть в репозиториях обоих дистрибутивов, Chromium тоже. КриптоПро CSP 5.0 под Linux устанавливается, плагин для браузера - отдельная песня с разной степенью везения в зависимости от дистрибутива и версии. На РЕД ОС поставили чище.

1С:Предприятие 8.3 - клиентская часть под Linux существует, тонкий клиент через браузер работает. Толстый клиент на Astra потребовал установки нескольких библиотек совместимости и пляски с локалью - /etc/locale.conf должен содержать корректный LANG=ru_RU.UTF-8, иначе 1С молча падает при запуске без внятного сообщения об ошибке. После того как нашли причину - завелось.

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

Про Ansible и автоматизацию

Разворачивать это руками на десятках машин - нереально. Написали роли для автоматизации: ipa-client на оба дистрибутива, конфигурация sssd, установка прикладного ПО. Здесь переход на collections-only модель в Ansible сыграл свою роль: роли пишутся сразу с FQCN, freeipa.ansible_freeipa - отдельная коллекция, ставится через ansible-galaxy collection install.

Коллекция ansible_freeipa содержит модули ipahost, ipagroup, ipahbacrule, ipasudorule - управление FreeIPA-объектами из Ansible без ручного ipa host-add. Работает, хотя документация местами опережает реализацию: несколько параметров, упомянутых в README, на деле либо не работали, либо вели себя иначе.

Где сейчас

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

Открытые вопросы: документооборот без Linux-клиента, производительность SSSD при большом числе групп в AD (у заказчика структура AD разветвлённая), и поведение Astra SE при мандатном управлении доступом на сетевых ресурсах. Это не блокеры для принятия решения, но работу завершённой не назовёшь.

Интеграция такого уровня - это не «поставили ОС, поехали». Каждый слой инфраструктуры требует отдельного разбора. Пилот продолжается.