Коли облікові записи розкидані по всіх вузлах, підтримка доступів перетворюється на хаос. Лікуємо це через OpenLDAP + SSSD: один каталог, єдині правила доступу, інтеграція з PAM і SSH. Нижче — безпечний мінімум, щоб ваш сервер Linux впевнено працював з централізованими користувачами та групами, не порушуючи права доступу Linux. 🔐

Що ми будуємо і які передумови

Мета: зберігати облікові записи в OpenLDAP, а на клієнтських вузлах (Linux) використовувати SSSD для резолву користувачів/груп і аутентифікації через PAM, дозволяючи SSH підключення LDAP-користувачам. Мінімальні вимоги:

  • 1 вузол із OpenLDAP (slapd) з TLS (ldaps:// або StartTLS), статичне ім’я DNS.
  • Клієнти Linux з SSSD, NSS/PAM інтеграцією, SSHd з UsePAM yes.
  • Продумана схема UID/GID (послідовний діапазон), базовий OU-поділ: people, groups, system.

Встановлення і безпечна конфігурація OpenLDAP (сервер)

Інсталяція

На Debian/Ubuntu:


sudo apt update
sudo apt install slapd ldap-utils
# За потреби повторно налаштуйте майстер:
sudo dpkg-reconfigure slapd

На RHEL/AlmaLinux/Rocky:


sudo dnf install openldap-servers openldap-clients
sudo systemctl enable --now slapd

Увімкнення TLS і заборона анонімних bind

Сертифікати розташуйте як:

  • /etc/ssl/certs/ldap-example.pem — повний ланцюжок (сертифікат сервера + CA)
  • /etc/ssl/private/ldap-example.key — приватний ключ (600, root:root)

cat > /tmp/ldap-tls.ldif <<'EOF'
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap-example.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap-example.key
-
replace: olcDisallows
olcDisallows: bind_anon
-
add: olcSecurity
olcSecurity: tls=1
EOF
sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/ldap-tls.ldif

Базова структура каталогу і приклад користувача

Припустимо, ваш DN — dc=example,dc=com. Додаємо OU, групу для SSH та сервісний обліковий запис для SSSD:


# Згенеруйте захешований пароль для сервісного облікового запису і користувача
ADMIN_HASH=$(slappasswd -s 'ChangeMe-Admin-2024!')
SVC_HASH=$(slappasswd -s 'ChangeMe-SSSD-2024!')
USER_HASH=$(slappasswd -s 'ChangeMe-User-2024!')

cat > /tmp/base.ldif << 'EOF'
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
dc: example
o: Example Org

# OU

dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people

dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups

dn: ou=system,dc=example,dc=com
objectClass: organizationalUnit
ou: system

# Група для SSH доступу

dn: cn=sshusers,ou=groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: sshusers
gidNumber: 20000

# Сервісний акаунт для SSSD bind

dn: uid=svc_sssd,ou=system,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
cn: SSSD Service
sn: Service
uid: svc_sssd
userPassword: REPLACE_SVC_HASH

# Приклад користувача

dn: uid=alice,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: Alice Example
sn: Example
givenName: Alice
uid: alice
uidNumber: 11001
gidNumber: 11001
homeDirectory: /home/alice
loginShell: /bin/bash
mail: alice@example.com
userPassword: REPLACE_USER_HASH

# Додаємо alice до групи sshusers через memberUid

dn: cn=sshusers,ou=groups,dc=example,dc=com
changetype: modify
add: memberUid
memberUid: alice
EOF

# Підставимо хеші паролів (спрощено sed'ом)
sed -i "s|REPLACE_SVC_HASH|$SVC_HASH|" /tmp/base.ldif
sed -i "s|REPLACE_USER_HASH|$USER_HASH|" /tmp/base.ldif

# Додаємо записи під адміністратором каталогу (введіть його пароль)
ldapadd -H ldaps://127.0.0.1 -x -D "cn=admin,dc=example,dc=com" -W -f /tmp/base.ldif

Тут ми заклали чіткий поділ на користувачі та групи Linux, і окремий сервісний акаунт для безпечних bind від SSSD.

Клієнт Linux: SSSD + PAM/NSS + SSH

Пакети

Debian/Ubuntu:


sudo apt update
sudo apt install sssd-ldap sssd-tools libnss-sss libpam-sss libpam-mkhomedir

RHEL/AlmaLinux/Rocky:


sudo dnf install sssd sssd-ldap sssd-tools authselect oddjob-mkhomedir
sudo authselect select sssd with-mkhomedir --force

Конфігурація SSSD


sudo bash -c 'cat > /etc/sssd/sssd.conf << "EOF" 
[sssd]
services = nss, pam, ssh
config_file_version = 2
domains = example.com

autofs_provider = none

[domain/example.com]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
cache_credentials = True
enumerate = False

ldap_uri = ldaps://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-example.pem

ldap_default_bind_dn = uid=svc_sssd,ou=system,dc=example,dc=com
ldap_default_authtok = ChangeMe-SSSD-2024!

# Пускаємо лише членів групи sshusers
ldap_access_filter = (|(memberOf=cn=sshusers,ou=groups,dc=example,dc=com)(uid=admin))

fallback_homedir = /home/%u
ldap_user_shell = /bin/bash
EOF'
sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl enable --now sssd

NSS і PAM


# NSS: додаємо sss
sudo sed -i 's/^passwd:.*/passwd:         files systemd sss/' /etc/nsswitch.conf
sudo sed -i 's/^group:.*/group:          files sss/' /etc/nsswitch.conf

# PAM: автоматичне створення домашніх каталогів
sudo pam-auth-update --enable mkhomedir || true

SSH інтеграція

Увімкніть PAM та, за бажання, ключі з LDAP через SSSD (sss_ssh_authorizedkeys):


sudo bash -c 'printf "\nUsePAM yes\nAuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys\nAuthorizedKeysCommandUser nobody\n" >> /etc/ssh/sshd_config'
sudo systemctl reload sshd

Тепер LDAP-користувачі з групи sshusers можуть виконувати SSH підключення. Перевірка:


getent passwd alice
id alice
ssh alice@client.example.com

Альтернативні способи

  • nslcd (nss-pam-ldapd): простіший за SSSD, але без кешування та розширених функцій доступу. Я рекомендую SSSD.
  • FreeIPA/IdM: комплексне рішення (LDAP + Kerberos + DNS + CA). Швидший старт для середніх/великих інфраструктур.
  • Samba AD: якщо вже є AD, можна підключити Linux-клієнти через SSSD до AD.

GUI-спосіб керування записами

Щоб зручно редагувати записи, використовуйте Apache Directory Studio або phpLDAPadmin. Наприклад, phpLDAPadmin на Debian/Ubuntu:


sudo apt install phpldapadmin
# Обмежте доступ до інтерфейсу (наприклад, через firewall або VPN) і використовуйте HTTPS.

GUI пришвидшує рутину, але не забувайте: лише захищений доступ і мінімальні привілеї. 🧩

FAQ

id alice не повертає дані

Перевірте sssd: sssctl config-check, журнали journalctl -u sssd -b. Часто винні ldap_uri (DNS), ldap_search_base або TLS CA.

SSSD не стартує

Неправильні права на /etc/sssd/sssd.conf (має бути 600), помилка у форматі, або немає доступу bind DN. Перевірте sssctl config-check.

TLS/сертифікати: "Can't contact LDAP server"

Переконайтеся, що ldap.example.com відповідає CN/SAN сертифікату, і клієнт довіряє CA (ldap_tls_cacert). Спробуйте ldapsearch -H ldaps://… -d 1.

Домашня тека не створюється

Увімкніть pam_mkhomedir (pam-auth-update або authselect with-mkhomedir) і перевірте помилки в auth.log/secure.

"Permission denied" при SSH

Додайте користувача до групи sshusers, перевірте ldap_access_filter і налаштування AllowGroups у sshd_config (якщо використовується).

Як дати sudo для LDAP-користувача?

Варіант: пакет sudo-ldap і схема sudoRole у LDAP. Або додайте користувача/групу до локальної групи sudo/admin, якщо це прийнятно для ваших політик.

Офлайн-логіни

SSSD кешує облікові дані (cache_credentials=True). Очистити кеш: sss_cache -E.

UID/GID: як узгодити?

У каталозі явно задавайте uidNumber/gidNumber. Тримайте окремі діапазони для людей/сервісів. Не змінюйте їх після видачі.

Failover LDAP

Вкажіть кілька URI: ldap_uri = ldaps://ldap1.example.com, ldaps://ldap2.example.com.

LDAPS vs StartTLS

Оберіть одне: ldaps:// на 636 або ldap:// + StartTLS. Головне — шифрування і валідація сертифікату.

Порада від Kernelka

Тримайте сервісний bind-обліковий запис з мінімальними правами читання лише потрібних OU, забороняйте анонімні bind, ведіть аудит змін у каталозі. Тестуйте політики на стейджингу: sssctl domain-list, sssctl user-show alice, і обов’язково моніторте невдалі логіни. Малими кроками — від чіткої схеми до надійного продакшена! 🚀

Підсумок

  • OpenLDAP з TLS і забороною анонімних bind — основа безпеки.
  • SSSD інтегрує NSS/PAM і забезпечує кешування та контроль доступу.
  • SSH підключення для LDAP-користувачів працює через PAM і (опційно) sss_ssh_authorizedkeys.
  • Чіткі користувачі та групи Linux спрощують політики доступу і підтримку.
  • Регулярно перевіряйте журнали, сертифікати і права доступу Linux.