Учётные записи Linux централизованно: FreeIPA и SSSD

Типичная картина на десяти серверах Linux: на каждом свои локальные пользователи, часть из них давно уволены, ключи SSH разбросаны по authorized_keys, а чтобы убрать администратора, нужно пройти по всем машинам и не пропустить ни одну. Централизованный каталог решает это: пользователь заводится один раз, сервер спрашивает его у каталога, отзыв происходит в одном месте и сразу действует везде. Ниже два рабочих пути: FreeIPA (если у вас много Linux и нет Active Directory) и присоединение к Active Directory (если домен Windows уже есть). Затем правила доступа, sudo, ключи SSH, второй фактор и охват.

Доступ к самим серверам должен идти через jump-хост: jump-хост. Настройка прав sudo без каталога: sudo и sudoers. Полный жизненный цикл учётных записей: жизненный цикл учётных записей.

Что выбрать

Ситуация	Решение	Замечания
Есть Active Directory, Linux-серверов немного	Присоединить серверы к AD через `realmd` и SSSD	Один каталог для всех, но правила доступа Linux (sudo, ограничения по узлам) приходится настраивать отдельно
Много Linux, Windows почти нет	FreeIPA	Каталог, Kerberos, DNS, центр сертификации, правила доступа к узлам и sudo в одной системе
Есть и то и другое	AD как основной каталог, Linux присоединён к AD; либо FreeIPA с доверием к AD	Доверие между лесами сложнее, начните с присоединения к AD
Три сервера и один администратор	Локальные учётные записи, но под управлением Ansible	Каталог для такого масштаба — лишняя нагрузка: GPO и Ansible

Сервер каталога становится самой критичной машиной: взлом FreeIPA или контроллера домена означает доступ ко всем серверам. Защищайте его как уровень 0: уровни администрирования, отдельный сегмент, резервные копии, не меньше двух реплик.

Шаг 1. Сервер FreeIPA

Требования: имя узла полное (ipa1.example.com), статический адрес, синхронизированное время, свободные порты 80, 443, 389, 636, 88, 464, 53. Пример для Rocky Linux или AlmaLinux:

sudo hostnamectl set-hostname ipa1.example.com
sudo dnf install -y ipa-server ipa-server-dns
sudo ipa-server-install --realm=EXAMPLE.COM --domain=example.com --setup-dns --no-forwarders

Установщик спросит пароли администратора каталога и менеджера каталога: задавайте их интерактивно, а не в командной строке, чтобы они не попали в историю. Ожидаемо: через 10–20 минут сообщение об успешной установке и запущенные службы. Проверка:

kinit admin
ipa user-find --sizelimit=3
sudo ipactl status

Ожидаемо: билет Kerberos получен, команда ipa отвечает, все службы в состоянии RUNNING. Второй сервер (реплика) ставится командой ipa-replica-install и защищает от остановки всех входов при потере основного.

Шаг 2. Присоединить сервер как клиент

sudo dnf install -y ipa-client
sudo ipa-client-install --mkhomedir --domain=example.com --realm=EXAMPLE.COM

Установщик попросит учётную запись с правом добавлять узлы. После успешного присоединения вход под пользователем каталога должен работать: ssh ivanov@srv-web-01. Параметр --mkhomedir создаёт домашний каталог при первом входе. Откат: ipa-client-install --uninstall. Перед присоединением производственных серверов проведите проверку на тестовом, и держите открытой отдельную сессию с локальной учётной записью, чтобы не потерять доступ при ошибке.

Шаг 3. Пользователи и группы

kinit admin
ipa group-add web_admins --desc="Администраторы веб-серверов"
ipa user-add ivanov --first=Иван --last=Иванов --password
ipa group-add-member web_admins --users=ivanov

Ожидаемо: ipa user-show ivanov показывает пользователя и членство в группе. Пользователи создаются именные, по ролям группы, а не по принципу «один общий администратор». Запись попадает в каталог один раз, и дальше доступ определяется правилами, а не файлами на серверах.

Шаг 4. Правила доступа к узлам (HBAC)

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

ipa hostgroup-add webservers
ipa hostgroup-add-member webservers --hosts=srv-web-01.example.com
ipa hbacrule-add web_admins_ssh
ipa hbacrule-add-user web_admins_ssh --groups=web_admins
ipa hbacrule-add-host web_admins_ssh --hostgroups=webservers
ipa hbacrule-add-service web_admins_ssh --hbacsvcs=sshd
ipa hbacrule-disable allow_all

ipa hbactest --user=ivanov --host=srv-web-01.example.com --service=sshd
ipa hbactest --user=ivanov --host=srv-db-01.example.com --service=sshd

Ожидаемо: первый тест показывает Access granted: True, второй — False. Риск: отключение allow_all до создания правил оставит вас без входа везде, поэтому порядок такой: сначала правила и проверка hbactest, затем отключение.

Шаг 5. Права sudo централизованно

ipa sudocmd-add "/usr/bin/systemctl restart nginx"
ipa sudorule-add web_restart
ipa sudorule-add-user web_restart --groups=web_admins
ipa sudorule-add-host web_restart --hostgroups=webservers
ipa sudorule-add-allow-command web_restart --sudocmds="/usr/bin/systemctl restart nginx"

Ожидаемо: на сервере группы web_admins выполнение sudo systemctl restart nginx разрешено, остальные команды нет. Проверка на клиенте: sudo -l -U ivanov. Для этого клиент должен получать правила sudo из SSSD: установщик клиента это настраивает автоматически. Принципы выдачи минимальных прав те же, что в статье про sudoers.

Шаг 6. SSH-ключи и второй фактор

Публичные ключи хранятся в каталоге: один пользователь — один набор, на серверах authorized_keys не нужен. Добавление: ipa user-mod ivanov --sshpubkey="ssh-ed25519 AAAA...КЛЮЧ ivanov"; клиент сам запрашивает ключи через sss_ssh_authorizedkeys. Второй фактор поддерживается встроенными токенами OTP:

ipa otptoken-add --owner=ivanov --type=totp
ipa user-mod ivanov --user-auth-type=otp --user-auth-type=password

Ожидаемо: пользователь получает QR-код для приложения и при входе вводит пароль плюс код. Как выбрать и внедрить второй фактор в целом: MFA для SSH и WireGuard.

Вариант: присоединение к Active Directory

sudo dnf install -y realmd sssd adcli oddjob-mkhomedir
realm discover example.com
sudo realm join --user=admin-join example.com
sudo realm permit -g linux-admins@example.com
id ivanov@example.com

Ожидаемо: realm discover находит домен, id показывает пользователя и его группы. Команда realm permit ограничивает вход группой: без неё войти может любой пользователь домена. Правила sudo в этой схеме настраиваются через группы AD и файлы sudoers.d (%linux-admins@example.com), а ограничения по узлам — групповыми политиками или параметром ad_access_filter в sssd.conf.

Отзыв доступа при увольнении

ipa user-disable ivanov
ipa user-find --disabled=TRUE --sizelimit=0

Ожидаемо: пользователь отключён во всей инфраструктуре; существующие сессии закройте отдельно. Это даёт то, ради чего затеяно: отзыв доступа за одну команду, а не обход серверов. Для AD отключение делается в консоли домена или командой Disable-ADAccount: неактивные учётные записи в AD.

Охват: сколько серверов в каталоге

Серверы, которые остались вне каталога, остаются со своими локальными учётными записями. Сравните список узлов в каталоге со списком из реестра активов:

ipa host-find --sizelimit=0 | grep "Host name" | awk '{print $3}' | sort > ipa_hosts.txt
sort servers_registry.txt > registry.txt
echo "Серверы вне каталога:"; comm -13 ipa_hosts.txt registry.txt

Ожидаемо: пустой список или перечень серверов, которые ещё нужно присоединить. Для локальных учётных записей на присоединённых узлах: awk -F: '$3 >= 1000 {print $1}' /etc/passwd показывает пользователей с обычными идентификаторами. Лишних не должно быть, кроме аварийной учётной записи.

Какие артефакты хранить

Что хранить	Что показывает
Техническая документация каталога: схема, реплики, правила резервного копирования	Централизованная система описана и защищена
Журналы создания, изменения и блокировки учётных записей (`/var/log/dirsrv/`, события FreeIPA)	Жизненный цикл записей происходит в системе
Правила HBAC и sudo (выгрузка)	Доступ определяется правилами, а не локальными настройками
Расчёт охвата: серверов в каталоге и в реестре	Покрытие платформ системой централизованного управления

Диагностика

Симптом	Причина и что делать
Вход под пользователем каталога не работает после присоединения	Не синхронизировано время или не проходит DNS. Проверьте `timedatectl` и `dig ipa1.example.com`
После отключения `allow_all` никто не входит	Нет разрешающих правил. Верните `ipa hbacrule-enable allow_all` с консоли и сначала проверьте правила через `hbactest`
Новый пользователь не видит sudo	Клиент не получает правила из SSSD. Проверьте `sssd.conf` и очистите кэш: `sss_cache -E`
Сервер каталога недоступен, и все входы остановились	Нет реплики и локальной аварийной учётной записи. Заведите вторую реплику и аварийную запись
Увольнение отразилось не сразу	Кэш SSSD на клиенте. Закройте активные сессии и сократите время кэширования для привилегированных групп

Где это в модели зрелости

Материал относится к направлению «Управление доступом» (хаб: управление доступом, карта: карта зрелости). На втором уровне для серверных платформ используется система централизованного управления учётными записями, например Active Directory для Windows и FreeIPA для Linux, которая автоматизирует создание, изменение и блокировку. Журналы системы и техническая документация подтверждают этот пункт. Для рабочих станций сходное требование первого уровня закрывает служба каталогов: GPO и Ansible.

Как проверить

Новый тестовый пользователь создаётся в каталоге и входит на разрешённый сервер, на запрещённый — нет (hbactest и реальный вход).
После ipa user-disable вход под этим пользователем невозможен на всех серверах.
Охват: серверов вне каталога нет или список объяснён.
На серверах нет локальных пользователей с идентификаторами от 1000, кроме аварийной записи.
Реплика каталога работает, резервная копия сервера каталога проверена восстановлением.