FreeIPA для Linux-парка: централизованная аутентификация без Microsoft на 150 сотрудников

Я, Евгений Семёнов, директор ITFresh. За 15 лет работы с гибридными инфраструктурами мы в ITFresh запустили около двух десятков FreeIPA-инсталляций. Были среди них и совсем небольшие, всего на десяти узлах, и по-настоящему крупные распределённые системы — с репликами, раскиданными аж по трём дата-центрам. В этой статье поделюсь деталями одного из таких проектов. Наш клиент? Это государственный подрядчик из Новосибирска: 150 сотрудников, 25 Linux-серверов. Их основная головная боль? Полностью вывести Microsoft Active Directory из контура, но при этом сохранить всю необходимую дисциплину доступа. Задача не из лёгких, правда?

Почему клиент пришёл именно к FreeIPA

Представьте себе: до нашего появления там творился настоящий хаос. На каждом из 25 серверов была своя, уникальная копия /etc/passwd. Пароли, конечно, не совпадали. SSH-ключи? Они просто валялись в authorized_keys, и никто даже не думал об их ротации! Уволили сотрудника? Админ каждый раз вручную лез на все 25 машин. Доходило до того, что однажды про два сервера вообще забыли, и учётка без проблем провисела полгода. Это же прямо приглашение для проблем, верно?

На переговорах мы быстро выявили пять основных проблем, которые буквально кричали о решении:

• Нет единой точки аутентификации. Разработчики таскали в чат пароли, потому что на каждой ноде они были разные.
• Увольнение превращалось в ночной квест. Обход 25 хостов + хранилище ключей в Gitea + VPN-аккаунт — минимум два часа.
• Все в sudoers wheel. Принцип наименьших привилегий отсутствовал в принципе.
• Требование импортозамещения. Госконтракт напрямую запрещал Microsoft-инфраструктуру.
• Предстоящий аудит ИБ. Без централизованной аутентификации новый контракт они бы не подписали.

Наша рекомендация была однозначна: FreeIPA. Мы сразу же приступили к проекту. Всего восемь рабочих дней, бюджет — 240 000 рублей. Всё чётко.

Архитектура и компоненты стека

FreeIPA по сути — это не один продукт, а пачка open-source компонентов, собранная в единый инсталлятор. Под капотом работают 389 Directory Server, MIT Kerberos KDC, Dogtag CA для PKI, интегрированный BIND DNS и клиентский SSSD для кеширования. Всё это управляется через CLI ipa и веб-интерфейс на 443-м порту.

Какой сайзинг мы выбрали для этого клиента? Основной сервер — 4 vCPU и 8 ГБ RAM, конечно, на Rocky Linux 9. Для реплики взяли точно такие же параметры, но её разместили на отдельном гипервизоре для надёжности. По диску: 40 ГБ оказалось с головой. Почему? База 389 DS, как мы знаем, растёт крайне медленно, а логи Dogtag вообще крутятся по расписанию, автоматически. Так что лишнее место там просто не нужно. Все эти виртуалки мы развернули на нашем кластере Dell Xeon Platinum 8280, который находится в дата-центре МТС Москва, а с офисом клиента всё связали через надёжный VPN-туннель. Работает как часы!

Установка сервера FreeIPA на Rocky Linux 9

Первый шаг, но очень важный: подготовка машины. Это четверть всего успеха! Что делаем? Выставляем полный FQDN, затем настраиваем синхронизацию времени — Kerberos, как известно, на дух не переносит дрейф часов больше пяти минут. И, конечно, открываем нужные порты:

hostnamectl set-hostname ipa.gk.local
echo "10.0.1.10 ipa.gk.local ipa" >> /etc/hosts

dnf install -y chrony
systemctl enable --now chronyd
chronyc tracking

firewall-cmd --permanent --add-service={freeipa-ldap,freeipa-ldaps,dns,ntp,http,https,kerberos,kpasswd}
firewall-cmd --reload
dnf update -y

Затем идёт установка серверного модуля IDM и запуск инсталлятора. Лично я всегда предпочитаю unattended-режим. Зачем? Чтобы не тратить время на бесконечные вопросы в процессе и не допустить зависаний, мы используем заранее выставленные пароли.

dnf install -y @idm:DL1
dnf install -y ipa-server ipa-server-dns ipa-server-trust-ad

ipa-server-install \
    --realm=GK.LOCAL \
    --domain=gk.local \
    --ds-password='DirMgr-Str0ng!' \
    --admin-password='Adm1n-Str0ng!' \
    --hostname=ipa.gk.local \
    --ip-address=10.0.1.10 \
    --setup-dns \
    --forwarder=8.8.8.8 \
    --forwarder=1.1.1.1 \
    --no-reverse \
    --mkhomedir \
    --unattended

Сама инсталляция занимает всего 12-15 минут. За это время система успевает сгенерировать корневой сертификат Dogtag, инициализировать Kerberos-реалм, запустить 389 DS и поднять DNS-зону. А сразу после завершения — обязательная проверка:

kinit admin
ipa user-find --all
ipa config-show

Пользователи, группы и массовый импорт

Создаём базовые группы под отделы, а пользователей заливаем пачкой из CSV. У нашего клиента был экспорт из 1С:ЗУП — пригодилось. Скрипт на баше по файлу users.csv:

while IFS=',' read -r login first last email group; do
    ipa user-add "$login" --first="$first" --last="$last" --email="$email" --password <<< 'Temp-P@ss2025!'
    ipa group-add-member "$group" --users="$login"
done < users.csv

# Строгая политика паролей для админов
ipa pwpolicy-add sysadmins \
    --maxlife=60 --minlife=1 --history=12 \
    --minclasses=4 --minlength=14 \
    --maxfail=3 --lockouttime=600 --priority=10

И вот, по щелчку пальцев: 150 аккаунтов уже в LDAP! С временным паролем Temp-P@ss2025! и принудительной сменой при первом же входе, разумеется.

Подключение 25 серверов командой ipa-client-install

А вот этот этап — чистая механика. На каждом клиентском хосте нужно проделать, по сути, одно и то же: меняется лишь FQDN. Чтобы не тратить уйму времени на рутину, мы заботливо завернули все действия в Ansible-плейбук. В итоге смогли прогнать всю операцию буквально за час! Базовый сценарий выглядит так:

# На клиенте меняем DNS-резолвер на FreeIPA
nmcli con mod eth0 ipv4.dns 10.0.1.10
nmcli con up eth0

hostnamectl set-hostname web01.gk.local
echo "10.0.1.20 web01.gk.local web01" >> /etc/hosts

# Rocky/AlmaLinux
dnf install -y ipa-client
# Ubuntu/Debian
# apt install -y freeipa-client

ipa-client-install \
    --domain=gk.local --realm=GK.LOCAL \
    --server=ipa.gk.local \
    --principal=admin --password='Adm1n-Str0ng!' \
    --mkhomedir --enable-dns-updates --unattended

Как только хост зарегистрирован, он моментально появляется в базе FreeIPA. SSSD в свою очередь автоматически подтягивает всю необходимую конфигурацию. После этого обязательно проверяем: пользователь корректно резолвится и без проблем может залогиниться.

id ivanov
# uid=1234(ivanov) gid=1234(ivanov) groups=1234(ivanov),5001(developers)
ssh ivanov@web01.gk.local

HBAC и sudo — разграничение доступа

Без HBAC (Host-Based Access Control) любой пользователь FreeIPA получает шелл на любой машине, присоединённой к домену. Это классическая ошибка при первом развёртывании. Первым делом гасим дефолтное правило allow_all и строим матрицу групп.

ipa hbacrule-disable allow_all
ipa hostgroup-add web-servers --desc="Веб-серверы"
ipa hostgroup-add-member web-servers --hosts=web01.gk.local --hosts=web02.gk.local

ipa hbacrule-add developers-web --desc="Devs -> web hosts"
ipa hbacrule-add-user developers-web --groups=developers
ipa hbacrule-add-host developers-web --hostgroups=web-servers
ipa hbacrule-add-service developers-web --hbacsvcs=sshd --hbacsvcs=login

# Проверка до применения
ipa hbactest --user=ivanov --host=db01.gk.local --service=sshd
# Access granted: False  — то, что нужно

Sudo-правила строятся аналогично — через sudocmd, sudocmdgroup и sudorule. Например, дать разработчикам перезапускать только nginx и php-fpm на веб-узлах:

ipa sudocmd-add "/usr/bin/systemctl restart nginx"
ipa sudocmd-add "/usr/bin/systemctl restart php-fpm"
ipa sudocmdgroup-add nginx-restart
ipa sudocmdgroup-add-member nginx-restart \
    --sudocmds="/usr/bin/systemctl restart nginx" \
    --sudocmds="/usr/bin/systemctl restart php-fpm"

ipa sudorule-add dev-restart-web --hostcat=
ipa sudorule-add-user dev-restart-web --groups=developers
ipa sudorule-add-host dev-restart-web --hostgroups=web-servers
ipa sudorule-add-allow-command dev-restart-web --sudocmdgroups=nginx-restart

Dogtag CA и автовыпуск TLS-сертификатов

Встроенный удостоверяющий центр — это, пожалуй, один из самых крутых и любимых нами бонусов FreeIPA. Только представьте: сертификаты для внутренних веб-сервисов выпускаются с помощью команды certmonger. Мало того, что они продлеваются автоматически, так ещё и не приходится каждый год тратиться на аналоги Let's Encrypt или мучиться с acme.sh там, где сервис попросту не доступен из интернета. Экономия времени и нервов!

# Регистрируем service principal
ipa service-add HTTP/web01.gk.local

# Запрашиваем сертификат и команду перезагрузки nginx
ipa-getcert request \
    -K HTTP/web01.gk.local \
    -D web01.gk.local \
    -f /etc/pki/tls/certs/web01.pem \
    -k /etc/pki/tls/private/web01.key \
    -N CN=web01.gk.local \
    -C '/usr/bin/systemctl reload nginx'

ipa-getcert list
# status: MONITORING — certmonger сам продлит за 28 дней до истечения

Корневой CA раздаётся клиентам через ipa-client-install автоматически — он ложится в /etc/ipa/ca.crt и добавляется в системный доверенный bundle. Браузеры на рабочих местах красного экрана не показывают.

Результаты внедрения и цифры

Мы успешно завершили проект ровно в запланированные 8 рабочих дней. Как распределилось время? Два дня ушло на развёртывание основной пары серверов с репликой. Ещё четыре дня мы потратили на подключение абсолютно всех клиентских машин и ювелирную настройку политик доступа. И последние два дня? Тщательное тестирование, а также обучение персонала. В итоге вот что мы имеем:

• Централизация 150 учёток в одной точке. Увольнение теперь — одна команда ipa user-disable, 30 секунд.
• Представьте: у нас в домене целых 25 серверов. Каждая операция, будь то доступ по SSH, права суперпользователя через sudo или даже управление сертификатами — всё это централизовано берется прямо из LDAP. Разве не удобно, когда всё под контролем из одного источника?
• Мы гордимся: аудит информационной безопасности успешно пройден. Но самое интересное впереди: всего через три недели после внедрения нашего решения клиент смог подписать новый госконтракт. Представляете, как быстро окупились их инвестиции в надежность?
• Хотите цифры? Тогда поговорим об экономии на лицензиях. Представьте, сколько бы стоил аналогичный проект на базе Microsoft AD, включая Server+CAL: это минимум 520 000 рублей. Чувствуете разницу в бюджете? Мы помогли нашим клиентам сохранить эти деньги.
• Что произойдет, если IPA-сервер вдруг ляжет? Не волнуйтесь! Благодаря умному кешу SSSD пользователи смогут продолжать логиниться без проблем. Эта система обеспечивает бесперебойный доступ, пока срок действия кеша не истечёт. Мы всегда думаем о стабильности вашей работы.

Грабли, на которые я наступал

За годы нашей практики мы собрали внушительный список типичных ошибок. Если вы впервые взялись за FreeIPA, рекомендую присмотреться — это поможет сэкономить вам не часы, а целые дни!

• Неправильный FQDN. Если hostname возвращает короткое имя — инсталлятор упадёт на середине. Проверяйте hostname -f ДО запуска.
• SELinux в permissive. Некоторые админы тушат SELinux — FreeIPA после этого глючит странно. Оставляйте enforcing.
• Конфликт DNS. Если в сети уже есть BIND/Windows DNS, продумайте делегирование поддомена. Я обычно беру ipa.office.local и делаю subdomain-delegation.
• Забытый allow_all. Не отключили — все юзеры ходят куда угодно. Стандартная дыра при первой инсталляции.
• Реплика без отдельного диска. 389 DS любит много мелких IOPS. Дайте SSD, не шпиндель.
• Забыли бэкап CA. Потеря корневого ключа Dogtag = переразвёртывание всего PKI. Скрипт ipa-backup в cron, результат — в офсайт.

FAQ — вопросы по FreeIPA

Чем FreeIPA отличается от OpenLDAP?

OpenLDAP — это просто каталог. FreeIPA — готовый стек из 389 Directory Server, MIT Kerberos, Dogtag CA, интегрированного DNS и SSSD. То есть вы получаете не только LDAP-хранилище, но и SSO, встроенный удостоверяющий центр, веб-панель управления и клиентскую часть из коробки.

Что произойдёт при падении FreeIPA-сервера?

Ранее вошедшие пользователи продолжат работать благодаря кешу SSSD (cache_credentials = True). Новые логины и изменения политик не применятся. Для продакшена я всегда поднимаю вторую реплику командой ipa-replica-install — отказоустойчивость становится штатной.

Можно ли подключить к FreeIPA Ubuntu или Debian?

Да. Ставите freeipa-client через apt, затем ipa-client-install с параметрами домена и realm. Клиентская часть на Ubuntu 22.04/24.04 работает стабильно, хотя сам сервер FreeIPA я рекомендую поднимать только на RHEL-совместимых дистрибутивах — Rocky Linux 9 или AlmaLinux 9.

Поддерживает ли FreeIPA двухфакторку?

Да, TOTP из коробки. Включается через ipa user-mod ivanov --user-auth-type=otp и добавление токена ipa otptoken-add. Пользователь привязывает Google Authenticator или FreeOTP по QR-коду. При логине пароль вводится слитно: пароль+6 цифр кода.

Как перенести пользователей из /etc/passwd в FreeIPA?

Парсите /etc/passwd скриптом на awk, выбираете учётки с UID >= 1000, затем скармливаете в ipa user-add. UID и GID сохраняются через параметры --uid и --gidnumber. Пароли придётся сбросить всем разом — хеши из shadow в FreeIPA напрямую не загружаются.