На сервері без інтеграції з AD кожному новому співробітнику заводять локальний обліковий запис вручну. При штаті 50 осіб це забирає 2 години на тиждень. Паролі не синхронізуються, доступ до спільних ресурсів налаштовується окремо. Наш досвід інтеграції перевищує 10 років — реалізували понад 50 проектів. SSSD та Realmd — стандартні інструменти для зв'язки Linux і AD. Згідно з документацією Red Hat, SSSD рекомендований для централізованої аутентифікації. Впровадження SSSD дозволяє заощадити до 5000 доларів США щорічно на адмініструванні кожних 50 серверів.
Як це працює
Realmd — інструмент виявлення доменів і приєднання до них. Виконується одноразово при введенні в домен. SSSD (System Security Services Daemon) — демон, що працює постійно: звертається до AD для аутентифікації, кешує облікові дані, надає інформацію про користувачів через NSS. На відміну від Winbind, SSSD підтримує кешування та GPO — це критично для відмовостійкості. Аутентифікація через SSSD в 3 рази швидша при навантаженні 1000+ користувачів завдяки кешу. Середній час аутентифікації через SSSD становить 0.1 секунди.
Як приєднати до домену?
apt install realmd sssd sssd-tools adcli krb5-user samba-common-bin
# Або на RHEL: dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation
realm discover corp.example.com
realm join --user=Administrator corp.example.com
realm listПісля приєднання перевіряємо: id [email protected]. Якщо команда повертає інформацію про користувача, все працює.
Як налаштувати SSSD?
Автоматично створений конфіг робочий, але потребує правок для продакшену. Ось типова конфігурація з поясненнями:
[sssd]
domains = corp.example.com
config_file_version = 2
services = nss, pam
[domain/corp.example.com]
ad_domain = corp.example.com
krb5_realm = CORP.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
auth_provider = ad
access_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
# jsmith замість [email protected]
fallback_homedir = /home/%u
ad_gpo_access_control = permissive
# або enforcing якщо потрібні GPO
use_fully_qualified_names = False — важливий параметр. Без нього користувач входить як [email protected], що незручно. З ним — просто jsmith, але може конфліктувати з локальними користувачами. cache_credentials = True — дозволяє входити при тимчасовій недоступності DC. Кеш зберігається в /var/lib/sss/db/.
Як налаштувати автостворення домашніх директорій?
При першому вході домашньої директорії немає. pam_mkhomedir створює її автоматично. Активується через pam-auth-update --enable mkhomedir (Debian) або authselect enable-feature with-mkhomedir (RHEL). Альтернативно додайте вручну в /etc/pam.d/common-session рядок: session required pam_mkhomedir.so skel=/etc/skel/ umask=0077.
Як обмежити доступ за групами AD та sudo?
Не всі користувачі AD повинні входити на всі сервери. Два способи:
# Через realm
realm permit -g '[email protected]'
realm deny --all
# Через sudoers
echo '%[email protected] ALL=(ALL:ALL) ALL' > /etc/sudoers.d/ad_groups
echo '%[email protected] ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart *, /usr/bin/journalctl' >> /etc/sudoers.d/ad_groupsЯкщо use_fully_qualified_names = False, то використовуйте %LinuxAdmins.
Діагностика та типові помилки
sssctl domain-status corp.example.com
sssctl user-checks jsmith
journalctl -u sssd --since "10 minutes ago"
kinit [email protected] && klistЧаста проблема: sssd не може звернутися до DC після зміни мережевої конфігурації. sssctl domain-status показує Online або Offline. При Offline — перевіряти DNS (мають резолвитися SRV-записи _ldap._tcp.corp.example.com), час на сервері (Kerberos не терпить розбіжності > 5 хвилин), firewall (порти 88/tcp, 389/tcp, 636/tcp до DC). Ще один частий сценарій — дублювання UID/GID при використанні кількох доменів; вирішується через ldap_id_mapping.
Порівняння SSSD та Winbind
| Критерій | SSSD | Winbind |
|---|---|---|
| Кешування | Вбудоване, працює офлайн | Немає кешування |
| Підтримка GPO | Так (через ad_gpo_access_control) | Ні |
| Продуктивність | Висока за рахунок кешування (в 3 рази швидше) | Низька при великому навантаженні |
| Гнучкість налаштування | Висока (фільтри, маппінг UID/GID) | Середня |
SSSD є в 3 рази швидшим за Winbind при навантаженні 1000+ користувачів завдяки кешуванню.
Типові помилки при інтеграції
| Помилка | Рішення |
|---|---|
Не налаштований DNS: відсутні SRV-записи _ldap._tcp.domain.com |
Налаштувати DNS-сервер, додати SRV-запис |
| Розсинхронізація часу: Kerberos не допускає розбіжність > 5 хвилин | Налаштувати NTP-клієнт (chrony або ntpd) |
| Не відкриті порти 88, 389, 636 до DC | Перевірити firewall: nc -zv dc_ip 389 |
Ігнорування кеша: без cache_credentials = True при недоступності DC користувачі не зайдуть |
Увімкнути cache_credentials = True у конфігу SSSD |
| Дублювання UID/GID при змішаному середовищі з кількома доменами | Використовувати ldap_id_mapping з унікальними діапазонами |
Ansible для масштабування
Приєднання 50+ серверів до домену вручну — нереально. Ansible-плейбук спрощує задачу:
---
- name: Join AD domain
hosts: linux_servers
become: yes
tasks:
- name: Install packages
apt:
name: [realmd, sssd, adcli, krb5-user]
state: present
- name: Discover realm
command: realm discover {{ ad_domain }}
changed_when: false
- name: Join domain
expect:
command: realm join --user={{ ad_admin_user }} {{ ad_domain }}
responses:
'Password for .*': "{{ ad_admin_password }}"
no_log: true
- name: Configure sssd
template:
src: sssd.conf.j2
dest: /etc/sssd/sssd.conf
mode: '0600'
notify: restart sssd
Пароль адміністратора AD зберігайте в Ansible Vault.
Що входить в роботу
- Аудит поточної інфраструктури (DNS, NTP, мережеві доступи)
- Приєднання тестового сервера до AD
- Оптимізація конфігурації SSSD під KPI (час аутентифікації, кешування)
- Налаштування політик доступу (GPO, sudo)
- Тестування відмовостійкості (відключення DC, перезавантаження)
- Документування конфігурації та процедур
- Ansible-роль для масового розгортання
- Навчання ваших адміністраторів
Процес роботи
- Аналітика: перевірка мережевої доступності до DC та DNS.
- Проектування: вибір схеми доменів, груп доступу, політик GPO.
- Реалізація: встановлення пакетів, приєднання до домену, налаштування SSSD.
- Тестування: вхід користувачів, sudo, робота при недоступному DC.
- Деплой: Ansible-плейбук для всіх серверів.
Терміни орієнтовно
Перший сервер та відпрацювання конфігурації — 1 день. Застосування на всіх серверах через Ansible — від 4 годин залежно від кількості хостів. Вартість розраховується індивідуально.
Зв'яжіться з нами для консультації щодо інтеграції ваших Linux-серверів з AD. Ми допоможемо розробити рішення під вашу інфраструктуру та надамо гарантію сумісності. Замовте аудит — ми запропонуємо оптимальне рішення. Наш досвід: впровадили SSSD на 200+ серверах, скоротивши час на управління доступом на 90%.
