Astra Linux SE 2.0: разворачиваем домен на FreeIPA и не теряем Windows-клиентов

Astra Linux Special Edition 2.0 вышла в стабильном статусе, и главное изменение для нас как сопровождающей команды - это обновлённая доменная подсистема. Если в 1.7 вопрос «как поднять нормальный домен» решался набором патчей и мануальных танцев с бубном, то в 2.0 стек FreeIPA + Samba официально входит в дистрибутив и ставится из коробочных репозиториев. Звучит как хорошие новости - и в целом так и есть, но «из коробки» не значит «без боли».

Что изменилось в доменной части

В Astra SE 2.0 FreeIPA поставляется в составе дистрибутива и сертифицирована в этой конфигурации. Это принципиально: раньше мы разворачивали FreeIPA-сервер на отдельной машине с Astra Common Edition, а рабочие места на SE подключали через ipa-client-install. Теперь контроллер домена можно поднять прямо на SE-машине, и это снимает вопросы к регулятору про «нестандартную конфигурацию».

Samba в роли контроллера домена (Samba AD DC) тоже присутствует - для сценария, когда нужна совместимость на уровне протокола с Windows-клиентами без cross-realm trust. Это важно: у части заказчиков Windows-машины в инфраструктуре никуда не денутся в обозримое время, и вопрос «как Windows-клиент будет жить рядом с Linux-доменом» встаёт практически всегда.

Три режима и какой выбирать

На практике мы видим три варианта доменной архитектуры, и каждый имеет смысл в своём контексте.

FreeIPA как основной домен + Samba-трастовый мост. Windows-клиенты в этой схеме остаются в старом AD, а Linux-машины уходят в FreeIPA с cross-realm trust между ними. Это наименее болезненный переход: пользователи логинятся с теми же учётками, Windows-политики не трогаем, Linux управляется через FreeIPA. Мы разворачивали такую схему у госзаказчика в ноябре - базовая механика работает, но cross-realm trust требует аккуратной синхронизации KDC и часовых поясов.

Samba AD DC как полный заменитель Active Directory. Windows- и Linux-клиенты вместе в одном домене, которым управляет Samba. Привлекательно на бумаге: не нужно поддерживать два домена и трасты. На практике в SE 2.0 это работает, но с оговорками - не весь функционал SYSVOL и GPO-скриптов воспроизводится один в один, и на сложных Windows-окружениях вылезают нюансы.

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

Подводные камни при замене AD

Текущий проект - заказчик с примерно полутора сотнями Windows-машин и задачей поэтапного перехода на Astra SE. AD никуда не уходит прямо сейчас, новые Linux-рабочие места должны работать рядом. Вот что реально доставляло проблемы.

Мандатный контроль доступа (МКД) и сетевые ресурсы. Это специфика SE - мандатные метки уровней конфиденциальности. FreeIPA не понимает МКД нативно, и при доступе к сетевым файловым ресурсам с Samba метки надо прокидывать отдельно через расширенные атрибуты. Документация по этому сценарию в SE 2.0 пока скромная - разбирались через исходники и общение с поддержкой разработчика.

GPO-сценарии, которых нет в FreeIPA. Это не новость - мы писали об этом раньше. Но в SE 2.0 появился astra-policy, собственный механизм применения политик. Он закрывает часть сценариев, которые раньше приходилось делать через Ansible: управление экраном блокировки, часть параметров рабочего стола, политики монтирования. Полноценной заменой GPO это не назвать, но дыра стала заметно меньше.

Kerberos и Windows-клиенты в одной сети. При cross-realm trust Windows-машины периодически пытаются пройти аутентификацию напрямую в FreeIPA KDC - и получают отказ, потому что не зарегистрированы в нём. В логах это выглядит как поток ошибок, который пугает заказчика, хотя реально ничего не ломает. Надо явно объяснять, что это нормальное поведение, и при желании фильтровать эти события на стороне SIEM.

Chrony как обязательный элемент. Казалось бы, азбука - Kerberos требует синхронизированного времени. Но в нескольких случаях у заказчика chrony был установлен, но не включён в автозагрузку после обновления. Итог: KRB5KRB_AP_ERR_SKEW в самый неудобный момент. Сейчас проверка статуса chrony входит в чеклист при подключении каждой машины в домен.

Что с Windows-клиентами

При схеме с cross-realm trust Windows-клиенты продолжают жить в AD и не замечают присутствия FreeIPA. Единственное, что меняется - пользователь с Windows-машиной может обращаться к Linux-ресурсам (файловым шарам на Samba, веб-приложениям с Kerberos SSO) без повторного ввода пароля. SSO через Kerberos работает в обоих направлениях, и это на практике воспринимается пользователями положительно - один из редких случаев, когда миграция что-то улучшает в пользовательском опыте.

Проблема возникает, когда Windows-клиент хочет работать с ресурсом, на котором задействован МКД Astra SE. Здесь нативной прозрачности нет - метки не пробрасываются на Windows-клиент, и приходится либо организовывать промежуточный уровень, либо мириться с ограничениями.

Где мы сейчас

Первый контур на SE 2.0 - около сорока Linux-машин в FreeIPA-домене с cross-realm trust к существующему AD - работает уже три недели. Базовая схема стабильна: логин, HBAC, sudo-политики, Kerberos SSO в браузере - всё функционирует. Открытый вопрос по МКД на сетевых ресурсах находится в работе, решение согласовываем с поддержкой Astra.

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