🐧 Linux 📅 31.03.2026 ⏱️ 20 мин чтения ✍️ АйТи Фреш

150 сотрудников без Microsoft: внедрение FreeIPA для госконтрактора

Задача клиента

В феврале 2026 года к нам в АйТи Фреш обратилась компания из Новосибирска — государственный подрядчик, выполняющий проекты в сфере строительства и инфраструктуры. Штат — 150 сотрудников, из которых 40 работают с серверной инфраструктурой (разработчики, инженеры, администраторы).

Клиент столкнулся с рядом серьёзных проблем:

  • Отсутствие централизованной аутентификации — на каждом из 25 Linux-серверов учётные записи создавались вручную, пароли не синхронизировались
  • Увольнение сотрудника = аудит всех серверов — при уходе человека администратор должен был обойти каждый сервер и удалить учётку
  • Нет разграничения доступа — все инженеры имели sudo на всех серверах, что противоречит принципу наименьших привилегий
  • Требование импортозамещения — государственный контракт требовал отказа от Microsoft Active Directory, а бюджет не предусматривал лицензии Windows Server
  • Прохождение аудита ИБ — для получения нового контракта требовалось подтвердить централизованное управление доступом

Наши инженеры предложили развернуть FreeIPA — полнофункциональный open-source аналог Active Directory для Linux-инфраструктуры. Решение включало централизованную аутентификацию, управление sudo-правилами, HBAC-политики контроля доступа к хостам и встроенный центр сертификации.

Почему FreeIPA — идеальный выбор для данного проекта

FreeIPA (Identity, Policy, Audit) — это решение для централизованного управления идентификацией пользователей, аутентификацией, авторизацией и аудитом в Linux/UNIX-среде. По сути, это аналог Microsoft Active Directory для мира Linux, объединяющий несколько технологий: 389 Directory Server (LDAP), MIT Kerberos (SSO), Dogtag Certificate System (PKI), DNS и SSSD.

Для нашего клиента FreeIPA позволяет управлять всеми 25 серверами из единой точки: создавать пользователей, назначать права sudo, контролировать доступ к хостам через HBAC-политики и автоматически выпускать TLS-сертификаты — и всё это без единой лицензии Microsoft.

Компоненты FreeIPA, которые мы использовали

  • 389 Directory Server — LDAP-каталог для хранения данных о пользователях, группах, хостах, сервисах
  • MIT Kerberos KDC — центр распределения ключей для Single Sign-On (SSO)
  • Dogtag Certificate System — встроенный центр сертификации (CA) для выпуска X.509 сертификатов
  • BIND DNS — интегрированный DNS с автоматическим управлением зонами
  • SSSD — клиентский демон для кеширования и аутентификации
  • Certmonger — автоматическое обновление сертификатов

Требования к инфраструктуре, которые мы определили

Для развёртывания FreeIPA нам потребовалось:

  • Сервер: минимум 2 CPU, 4 ГБ RAM, 20 ГБ диска (рекомендуется 4 CPU, 8 ГБ RAM)
  • ОС: Rocky Linux 9 — оптимальный выбор для enterprise-окружений
  • Полностью настроенное FQDN (hostname.domain.example.com)
  • DNS — встроенный в FreeIPA
  • Порты: 80, 443, 389, 636, 88, 464, 53 (TCP/UDP)
  • Синхронизация времени (chronyd) — критически важно для Kerberos

Установка FreeIPA-сервера

Мы развернули FreeIPA на Rocky Linux 9 — наиболее распространённый выбор для enterprise-окружений, полностью совместимый с RHEL.

Подготовка сервера

# Устанавливаем FQDN
sudo hostnamectl set-hostname ipa.company.local

# Проверяем
hostname -f
# ipa.company.local

# Добавляем запись в /etc/hosts
echo "10.0.1.10 ipa.company.local ipa" | sudo tee -a /etc/hosts

# Настраиваем синхронизацию времени
sudo dnf install -y chrony
sudo systemctl enable --now chronyd
chronyc tracking

# Открываем необходимые порты
sudo firewall-cmd --permanent --add-service={freeipa-ldap,freeipa-ldaps,dns,ntp,http,https,kerberos,kpasswd}
sudo firewall-cmd --reload

# Обновляем систему
sudo dnf update -y

Установка и инициализация FreeIPA

# Устанавливаем пакеты FreeIPA-сервера
sudo dnf install -y @idm:DL1
sudo dnf install -y ipa-server ipa-server-dns ipa-server-trust-ad

# Запускаем интерактивную установку
sudo ipa-server-install \
    --realm=COMPANY.LOCAL \
    --domain=company.local \
    --ds-password='DirectoryM@nager1' \
    --admin-password='Adm1nP@ssw0rd!' \
    --hostname=ipa.company.local \
    --ip-address=10.0.1.10 \
    --setup-dns \
    --forwarder=8.8.8.8 \
    --forwarder=1.1.1.1 \
    --no-reverse \
    --mkhomedir \
    --unattended

# Установка занимает 10-15 минут
# После завершения проверяем

# Получаем Kerberos-билет администратора
kinit admin
Password for admin@COMPANY.LOCAL:

# Проверяем работу
ipa user-find --all
ipa config-show

Важно: мы сохранили пароли Directory Manager и admin в корпоративном менеджере паролей клиента. Пароль Directory Manager даёт полный доступ к LDAP-каталогу напрямую.

Создание пользователей и групп для всех 150 сотрудников

# Создаём группы по отделам
ipa group-add developers --desc="Отдел разработки"
ipa group-add sysadmins --desc="Системные администраторы"
ipa group-add managers --desc="Менеджеры"

# Создаём пользователя
ipa user-add ivanov \
    --first="Иван" \
    --last="Иванов" \
    --email="ivanov@company.local" \
    --shell=/bin/bash \
    --homedir=/home/ivanov \
    --password

# Добавляем в группу
ipa group-add-member developers --users=ivanov
ipa group-add-member sysadmins --users=petrov

# Массовое создание пользователей из CSV
# users.csv: login,first,last,email,group
while IFS=',' read -r login first last email group; do
    ipa user-add "$login" --first="$first" --last="$last" --email="$email" --password <<< 'TempP@ss123'
    ipa group-add-member "$group" --users="$login"
    echo "Создан: $login"
done < users.csv

# Просмотр информации о пользователе
ipa user-show ivanov --all

Подключение 25 серверов к FreeIPA

Самый масштабный этап проекта — подключение всех 25 Linux-серверов к домену FreeIPA. Для этого мы использовали утилиту ipa-client-install, которая автоматически настраивает SSSD, Kerberos и PAM.

Установка IPA-клиента на каждый сервер

# На клиентской машине (Rocky/CentOS/RHEL)
sudo dnf install -y ipa-client

# На Debian/Ubuntu
sudo apt install -y freeipa-client

# Настраиваем DNS на IPA-сервер
nmcli con mod eth0 ipv4.dns 10.0.1.10
nmcli con up eth0

# Устанавливаем FQDN
sudo hostnamectl set-hostname web01.company.local
echo "10.0.1.20 web01.company.local web01" | sudo tee -a /etc/hosts

# Подключаем к домену FreeIPA
sudo ipa-client-install \
    --domain=company.local \
    --realm=COMPANY.LOCAL \
    --server=ipa.company.local \
    --principal=admin \
    --password='Adm1nP@ssw0rd!' \
    --mkhomedir \
    --enable-dns-updates \
    --unattended

# Проверяем подключение
id ivanov
# uid=1234(ivanov) gid=1234(ivanov) groups=1234(ivanov),5001(developers)

# Проверяем аутентификацию
su - ivanov
Password:
# Creating home directory for ivanov
ivanov@web01:~$

Оптимизация SSSD для надёжной работы

# /etc/sssd/sssd.conf
[sssd]
domains = company.local
config_file_version = 2
services = nss, pam, ssh, sudo

[domain/company.local]
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_domain = company.local
ipa_server = ipa.company.local
ipa_hostname = web01.company.local

# Кеширование (критично при потере связи с сервером)
cache_credentials = True
entry_cache_timeout = 600

# Автоматическое создание домашних директорий
override_homedir = /home/%u
default_shell = /bin/bash

# Поддержка sudo через SSSD
sudo_provider = ipa

# SSH-ключи из LDAP
ipa_host_dyndns_update = True

[nss]
homedir_substring = /home

[pam]

[sudo]

[ssh]
# Перезапускаем SSSD
sudo systemctl restart sssd

# Проверяем кеш
sssctl domain-status company.local
sssctl user-show ivanov

HBAC-политики: кто куда имеет доступ

Ключевое требование аудита ИБ — чёткое разграничение доступа: разработчики не должны иметь доступ к серверам баз данных, а менеджеры — к production-серверам. Мы реализовали это через Host-Based Access Control (HBAC).

Применённые HBAC-правила

# Сначала отключаем правило по умолчанию (allow_all)
ipa hbactest --user=ivanov --host=web01.company.local --service=sshd
# Пока allow_all активно — все имеют доступ везде

ipa hbacrule-disable allow_all

# Создаём группы хостов
ipa hostgroup-add web-servers --desc="Веб-серверы"
ipa hostgroup-add db-servers --desc="Серверы баз данных"
ipa hostgroup-add all-servers --desc="Все серверы"

# Добавляем хосты в группы
ipa hostgroup-add-member web-servers --hosts=web01.company.local
ipa hostgroup-add-member web-servers --hosts=web02.company.local
ipa hostgroup-add-member db-servers --hosts=db01.company.local

# Создаём HBAC-правило: разработчики могут входить на веб-серверы
ipa hbacrule-add developers-web-access \
    --desc="Разработчики — доступ к веб-серверам"
ipa hbacrule-add-user developers-web-access --groups=developers
ipa hbacrule-add-host developers-web-access --hostgroups=web-servers
ipa hbacrule-add-service developers-web-access --hbacsvcs=sshd
ipa hbacrule-add-service developers-web-access --hbacsvcs=login

# Администраторы — доступ ко всем серверам
ipa hbacrule-add sysadmin-all-access \
    --desc="Администраторы — полный доступ"
ipa hbacrule-add-user sysadmin-all-access --groups=sysadmins
ipa hbacrule-add-host sysadmin-all-access --hostgroups=all-servers
ipa hbacrule-add-service sysadmin-all-access --hbacsvcs=sshd
ipa hbacrule-add-service sysadmin-all-access --hbacsvcs=login
ipa hbacrule-add-service sysadmin-all-access --hbacsvcs=sudo

# Тестируем правило
ipa hbactest --user=ivanov --host=web01.company.local --service=sshd
# Access granted: True

ipa hbactest --user=ivanov --host=db01.company.local --service=sshd
# Access granted: False

Полная матрица доступа, которую мы разработали

Вот структура HBAC-правил, которую мы реализовали для клиента:

  • sysadmin-all-access — группа sysadmins → все серверы → ssh, login, sudo
  • developers-web-access — группа developers → веб-серверы → ssh, login
  • dba-db-access — группа dba → серверы БД → ssh, login, sudo
  • monitoring-access — группа monitoring → все серверы → ssh (для Zabbix/Nagios агентов)
  • emergency-access — аварийная учётная запись → все серверы (отключена по умолчанию)

Централизованные sudo-правила

Вместо редактирования /etc/sudoers на каждом из 25 серверов мы настроили централизованные sudo-правила через FreeIPA.

Применённые sudo-правила

# Создаём sudo-команды
ipa sudocmd-add /usr/bin/systemctl
ipa sudocmd-add /usr/bin/journalctl
ipa sudocmd-add /usr/bin/docker
ipa sudocmd-add /usr/sbin/reboot
ipa sudocmd-add '/usr/bin/apt *'
ipa sudocmd-add '/usr/bin/dnf *'

# Группы sudo-команд
ipa sudocmdgroup-add service-management --desc="Управление сервисами"
ipa sudocmdgroup-add-member service-management \
    --sudocmds=/usr/bin/systemctl \
    --sudocmds=/usr/bin/journalctl

ipa sudocmdgroup-add package-management --desc="Управление пакетами"
ipa sudocmdgroup-add-member package-management \
    --sudocmds='/usr/bin/apt *' \
    --sudocmds='/usr/bin/dnf *'

# Правило: разработчики могут управлять сервисами на веб-серверах
ipa sudorule-add developers-services \
    --desc="Разработчики — управление сервисами"
ipa sudorule-add-user developers-services --groups=developers
ipa sudorule-add-host developers-services --hostgroups=web-servers
ipa sudorule-add-allow-command developers-services \
    --sudocmdgroups=service-management
ipa sudorule-add-option developers-services --sudooption='!authenticate'

# Правило: администраторы — полный sudo
ipa sudorule-add sysadmin-full-sudo \
    --desc="Администраторы — полный sudo" \
    --cmdcat=all
ipa sudorule-add-user sysadmin-full-sudo --groups=sysadmins
ipa sudorule-add-host sysadmin-full-sudo --hostgroups=all-servers

# Проверяем
ipa sudorule-show developers-services --all

Проверка sudo на клиентских машинах

# Очищаем кеш SSSD для немедленного применения
sudo sssctl cache-expire -E

# Проверяем правила sudo для пользователя
sudo -l -U ivanov

# Пример вывода:
# User ivanov may run the following commands on web01:
#     (root) NOPASSWD: /usr/bin/systemctl, /usr/bin/journalctl

# Проверяем от имени пользователя
su - ivanov
sudo systemctl restart nginx  # Работает
sudo reboot                    # Sorry, user ivanov is not allowed

Политики паролей и TLS-сертификаты

Для прохождения аудита ИБ нам также потребовалось настроить строгие политики паролей для разных групп пользователей и организовать автоматический выпуск TLS-сертификатов.

Настроенные политики паролей

# Просмотр текущей политики
ipa pwpolicy-show

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

# Стандартная политика для сотрудников
ipa pwpolicy-add developers \
    --maxlife=90 \
    --minlife=1 \
    --history=6 \
    --minclasses=3 \
    --minlength=10 \
    --maxfail=5 \
    --failinterval=600 \
    --lockouttime=300 \
    --priority=20

# Глобальная политика (по умолчанию)
ipa pwpolicy-mod \
    --maxlife=180 \
    --minlife=1 \
    --history=4 \
    --minclasses=3 \
    --minlength=8 \
    --maxfail=5 \
    --failinterval=600 \
    --lockouttime=300

# Параметры:
# --maxlife: максимальный срок действия пароля (дней)
# --minclasses: минимум классов символов (строчные, заглавные, цифры, спецсимволы)
# --maxfail: попыток до блокировки
# --lockouttime: время блокировки (секунд)

Автоматический выпуск TLS-сертификатов

# FreeIPA включает полноценный центр сертификации (CA)

# Запрос сертификата для веб-сервера
ipa service-add HTTP/web01.company.local
ipa-getcert request \
    -K HTTP/web01.company.local \
    -D web01.company.local \
    -f /etc/pki/tls/certs/web01.pem \
    -k /etc/pki/tls/private/web01.key \
    -N CN=web01.company.local \
    -C '/usr/bin/systemctl reload nginx'

# Проверяем статус сертификата
ipa-getcert list

# Пример вывода:
# Request ID '20260331120000':
#   status: MONITORING
#   stuck: no
#   key pair storage: type=FILE,location='/etc/pki/tls/private/web01.key'
#   certificate: type=FILE,location='/etc/pki/tls/certs/web01.pem'
#   CA: IPA
#   expires: 2028-03-31 12:00:00

# Certmonger автоматически обновит сертификат до истечения срока
# и выполнит команду reload nginx

# Экспорт корневого CA-сертификата для клиентов
ipa-cacert-manage list
cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt
update-ca-certificates

Интеграция FreeIPA с сервисами клиента

Помимо SSH-доступа, мы интегрировали FreeIPA с Nginx и PostgreSQL, чтобы все внутренние сервисы клиента использовали единую систему аутентификации.

Интеграция с Nginx (LDAP-аутентификация)

# Устанавливаем модуль nginx-ldap
sudo apt install -y nginx libnginx-mod-http-auth-pam

# Или используем nginx-auth-ldap (при компиляции из исходников)
# Конфигурация Nginx с LDAP-аутентификацией через PAM

# /etc/pam.d/nginx
auth    required    pam_sss.so
account required    pam_sss.so

# /etc/nginx/conf.d/protected.conf
server {
    listen 443 ssl;
    server_name admin.company.local;

    ssl_certificate /etc/pki/tls/certs/web01.pem;
    ssl_certificate_key /etc/pki/tls/private/web01.key;

    location / {
        auth_pam "FreeIPA Authentication";
        auth_pam_service_name "nginx";
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Remote-User $remote_user;
    }
}

Интеграция с PostgreSQL

# В pg_hba.conf — LDAP-аутентификация через FreeIPA
host all all 10.0.0.0/8 ldap ldapserver=ipa.company.local ldapbasedn="cn=users,cn=accounts,dc=company,dc=local" ldapbinddn="uid=pg_bind,cn=sysaccounts,cn=etc,dc=company,dc=local" ldapbindpasswd="BindP@ss" ldapsearchattribute="uid" ldaptls=1

# Или через GSSAPI (Kerberos) — более безопасный метод
host all all 10.0.0.0/8 gss include_realm=0 krb_realm=COMPANY.LOCAL

# Создаём сервисный аккаунт для LDAP bind
ldapmodify -x -D "cn=Directory Manager" -W <

Подготовка к интеграции с Active Directory

# Установка компонентов для trust
sudo dnf install -y ipa-server-trust-ad samba-client

# Подготовка FreeIPA для trust
ipa-adtrust-install --add-sids --add-agents

# Создание trust с AD
ipa trust-add --type=ad ad.company.com --admin=Administrator --password

# Проверка trust
ipa trust-show ad.company.com
ipa trustdomain-find ad.company.com

# Теперь пользователи AD могут логиниться на Linux-серверы
id administrator@ad.company.com

# Создание HBAC-правил для AD-пользователей
ipa group-add ad-developers --external
ipa group-add-member ad-developers --external "AD\\Developers"

ipa group-add mixed-developers
ipa group-add-member mixed-developers --groups=ad-developers --groups=developers

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

Проект был выполнен за 8 рабочих дней: 2 дня на развёртывание серверной части FreeIPA с репликой, 4 дня на подключение всех 25 серверов и настройку политик, 2 дня на тестирование и обучение администраторов клиента. Вот измеримые результаты:

  • 150 учётных записей централизованно управляются из единой точки
  • 25 серверов подключены к домену — аутентификация, sudo и SSH-ключи синхронизируются автоматически
  • Время блокировки уволенного сотрудника — 30 секунд вместо 2-3 часов обхода серверов
  • Экономия на лицензиях — стоимость аналогичного решения на Microsoft AD составила бы от 500 000 руб. (серверные лицензии + CAL)
  • HBAC-политики — чёткое разграничение доступа по группам: разработчики видят только веб-серверы, DBA — только БД
  • Централизованные sudo-правила — единая точка управления привилегиями, соответствие принципу наименьших привилегий
  • Автоматический выпуск TLS-сертификатов — Certmonger обновляет сертификаты без участия администратора
  • Аудит ИБ пройден успешно — клиент получил подтверждение соответствия требованиям централизованного управления доступом
  • Кеширование SSSD — сотрудники могут входить на серверы даже при кратковременной недоступности FreeIPA-сервера

Клиент успешно прошёл аудит информационной безопасности и получил новый государственный контракт. Администраторы отмечают, что управление 25 серверами стало значительно проще: добавление нового сотрудника или изменение прав доступа занимает минуты вместо часов.

Часто задаваемые вопросы

FreeIPA — это open-source решение для Linux/UNIX-инфраструктуры, использующее LDAP (389 DS), Kerberos и Dogtag CA. Active Directory — проприетарное решение Microsoft для Windows-инфраструктуры. FreeIPA нативно управляет Linux-хостами, sudo-правилами и SELinux-контекстами, в то время как AD ориентирован на групповые политики Windows. Оба решения могут сосуществовать через механизм trust. В нашем проекте для господрядчика FreeIPA полностью заменил потребность в AD.

Клиенты продолжат работать благодаря кешированию в SSSD (параметр cache_credentials = True). Пользователи, которые ранее входили на хост, смогут аутентифицироваться из кеша. Однако новые пользователи не смогут войти, а изменения политик не применятся. Для отказоустойчивости настройте минимум 2 реплики FreeIPA: ipa-replica-install на втором сервере. Мы развернули реплику для нашего клиента.

Установите пакет freeipa-client: sudo apt install -y freeipa-client, затем выполните sudo ipa-client-install --domain=company.local --realm=COMPANY.LOCAL --server=ipa.company.local --mkhomedir. На Debian/Ubuntu поддержка FreeIPA-клиента полноценная, хотя серверную часть рекомендуется разворачивать на RHEL-совместимых дистрибутивах.

FreeIPA поддерживает OTP (One-Time Password) из коробки. Включите OTP для пользователя: ipa user-mod ivanov --user-auth-type=otp, затем добавьте OTP-токен: ipa otptoken-add --owner=ivanov --type=totp. Пользователь сканирует QR-код приложением Google Authenticator или FreeOTP. При входе пароль вводится как: [обычный пароль][OTP-код] без пробела.

Используйте утилиту ipa migrate-ds для миграции из другого LDAP или скрипт для массового создания из файлов. Извлеките пользователей: awk -F: '$3 >= 1000 {print $1}' /etc/passwd, затем создайте их через ipa user-add. Для сохранения UID/GID используйте параметры --uid и --gidnumber. После миграции обновите пароли пользователей.

Нужна помощь с настройкой?

Специалисты АйТи Фреш помогут с внедрением и настройкой — 15+ лет опыта, обслуживание от 15 000 ₽/мес

📞 Связаться с нами
#FreeIPA настройка#LDAP аутентификация Linux#FreeIPA сервер установка#ipa-client-install#HBAC политики FreeIPA#sudo правила FreeIPA#централизованная аутентификация#FreeIPA сертификаты