OpenLDAP на Ubuntu 24.04: пошаговая установка

MAATRIX

Когда пользователей и серверов становится больше десятка, локальные /etc/passwd на каждой машине превращаются в кошмар: уволенного сотрудника забыли удалить с трёх серверов из пяти, а новому дали доступ только туда, куда вспомнили. OpenLDAP решает это старым, скучным и от этого надёжным способом — единый каталог, откуда пароли и группы подтягивают SSH, Samba, VPN, корпоративная почта и десятки других сервисов. Ниже — рабочая установка на Ubuntu 24.04 с нуля: от apt install до первого пользователя, который логинится по LDAP-паролю.

Что такое OpenLDAP и когда он реально нужен

LDAP (Lightweight Directory Access Protocol) — это не база данных в привычном смысле, а иерархический каталог, оптимизированный под чтение: тысячи запросов «кто этот пользователь и в какой он группе» в секунду, а не сложные джойны. OpenLDAP — открытая реализация протокола, которая живёт в инфраструктуре с конца 90-х и до сих пор остаётся стандартом де-факто для Linux-окружений, Samba-доменов и части legacy-приложений на Java (JNDI из коробки умеет в LDAP).

Стоит ли ставить его в 2026 году, если есть Keycloak с OIDC/SAML? Смотря для чего. Keycloak — про современные веб-приложения и SSO через браузер. OpenLDAP — про классическую POSIX-аутентификацию: ssh user@server должен спросить пароль из каталога, sudo — проверить группу оттуда же, NFS — взять UID/GID. Если у вас парк Linux-серверов, где логин идёт через PAM, а не через веб-форму, LDAP по-прежнему самый простой инструмент. Про смежный вариант с современным SSO у нас есть отдельный разбор — Keycloak на Ubuntu 24.04, многие компании в итоге держат оба: LDAP для системных логинов, Keycloak — для приложений.

Дальше собираем каталог на одном сервере (мастер), без репликации — для старта и для окружений на 5-200 пользователей этого достаточно с запасом.

Подготовка Ubuntu 24.04 и установка пакетов

Понадобится VPS с минимум 1 vCPU и 1 ГБ RAM — OpenLDAP не тяжёлый, и даже на скромной конфигурации спокойно обслуживает сотни пользователей. Заранее решите вопрос с именем хоста: LDAP-каталог строится вокруг DNS-домена, и лучше сразу задать реальный FQDN.

sudo hostnamectl set-hostname ldap.example.com
sudo apt update && sudo apt upgrade -y

Проверьте, что /etc/hosts резолвит имя сервера в его собственный IP — иначе установщик slapd может зависнуть на попытке определить домен:

127.0.1.1   ldap.example.com ldap

Ставим сам сервер и утилиты клиента:

sudo apt install -y slapd ldap-utils

В процессе установки apt спросит пароль администратора каталога — введите временный, его всё равно нужно будет переопределить на следующем шаге через dpkg-reconfigure, где конфигурация получится полнее. Если экран с паролем не появился (бывает при неинтерактивной установке), не страшно — переходим к следующему пункту.

Базовая настройка: домен, суффикс, пароль администратора

Главный шаг — dpkg-reconfigure, который пересоздаёт базовую конфигурацию slapd в интерактивном мастере:

sudo dpkg-reconfigure slapd

По шагам мастера:

• Omit OpenLDAP server configuration? — No (иначе получите пустую установку без базы).
• DNS domain name — например, example.com. Отсюда автоматически строится суффикс базы dc=example,dc=com.
• Organization name — произвольное, например Example LLC.
• Administrator password — задайте нормальный пароль, он понадобится для всех административных операций.
• Database backend — MDB (это дефолт и рекомендуемый вариант с Ubuntu 20.04+, старый hdb считается устаревшим).
• Remove the database when slapd is purged? — No, если не хотите потерять данные при случайном apt purge.
• Move old database? — Yes, если это переустановка поверх существующей.

После мастера проверяем, что каталог отвечает:

ldapsearch -x -b "dc=example,dc=com" -H ldap://localhost

Пустой, но успешный ответ (# search result / search: 2 / result: 0 Success) означает, что база создана и слушает. Если получаете Can't contact LDAP server, проверьте, что служба вообще запущена:

sudo systemctl status slapd
sudo journalctl -u slapd -n 50 --no-pager

Отдельно откройте порт в файрволе, если он у вас включён (подробно про сам ufw — в статье про установку файрвола на Ubuntu 24.04):

sudo ufw allow from 10.0.0.0/8 to any port 389 proto tcp
sudo ufw allow from 10.0.0.0/8 to any port 636 proto tcp

Обратите внимание: правило разрешает доступ только из внутренней сети — открывать 389/636 в интернет без крайней необходимости не стоит, об этом ниже в разделе про безопасность.

Структура каталога: организационные единицы через LDIF

OpenLDAP всё конфигурируется и наполняется через LDIF (LDAP Data Interchange Format) — текстовый формат записей. Это непривычно после привычных веб-форм, но зато каждое изменение воспроизводимо и попадает в git.

Создаём организационные единицы (OU) для людей и групп — стандартная структура, которую понимают почти все клиенты:

cat > base.ldif <<'EOF'
dn: ou=people,dc=example,dc=com
objectClass: organizationalUnit
ou: people

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

ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f base.ldif

-D задаёт bind DN (от чьего имени выполняется операция — здесь администратор каталога), -W попросит ввести пароль интерактивно вместо того, чтобы светить его в истории команд.

Проверить структуру можно так:

ldapsearch -x -b "dc=example,dc=com" -H ldap://localhost "(objectClass=organizationalUnit)" dn

Дальше нам понадобится схема posixAccount/posixGroup — это часть стандартных схем nis, которая обычно уже подгружена в Ubuntu-сборке slapd по умолчанию. Проверить, что она есть, можно так:

ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn | grep -i nis

Если строки cn={n}nis,cn=schema,cn=config нет — добавьте схему из /etc/ldap/schema/nis.ldif через ldapadd с тем же -Y EXTERNAL (root на локальной машине через сокет ldapi:/// — единственный способ менять конфигурацию cn=config, обычный bind по паролю сюда не пускают).

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

Заводим группу разработчиков и первого пользователя. Пароль сначала нужно захешировать — не храните его в LDIF в открытом виде:

slappasswd
# New password:
# Re-enter new password:
# {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Дальше сама запись пользователя — обратите внимание на uidNumber/gidNumber: эти ID должны быть уникальны в пределах каталога и не пересекаться с системными UID (обычно начинают с 10000, чтобы точно не столкнуться с локальными аккаунтами на серверах):

cat > group.ldif <<'EOF'
dn: cn=developers,ou=groups,dc=example,dc=com
objectClass: posixGroup
cn: developers
gidNumber: 10000
EOF

cat > user.ldif <<'EOF'
dn: uid=ivan,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: ivan
sn: Petrov
givenName: Ivan
cn: Ivan Petrov
displayName: Ivan Petrov
uidNumber: 10001
gidNumber: 10000
userPassword: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
gecos: Ivan Petrov
loginShell: /bin/bash
homeDirectory: /home/ivan
mail: ivan@example.com
EOF

ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f group.ldif
ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f user.ldif

Смена пароля пользователем (не администратором) без прямого доступа к каталогу делается через ldappasswd, что удобнее для интеграции с self-service-формами:

ldappasswd -x -D "uid=ivan,ou=people,dc=example,dc=com" -W -S "uid=ivan,ou=people,dc=example,dc=com" -H ldap://localhost

Для массового добавления сотрудников проще написать небольшой скрипт, который генерирует LDIF из CSV — руками через ldapadd реально заводить первых 5-10 тестовых аккаунтов, дальше это должно быть автоматизировано.

Клиенты: подключаем сервер к каталогу через SSSD

Каталог сам по себе бесполезен, пока к нему не подключены сервера, которые должны в нём авторизовывать пользователей. Современный стандартный способ на Ubuntu — sssd (System Security Services Daemon), который заменил связку libnss-ldap/libpam-ldap и умеет кэшировать ответы, переживая кратковременную недоступность каталога.

sudo apt install -y sssd-ldap libnss-sss libpam-sss

Конфиг /etc/sssd/sssd.conf (обязательно chmod 600, иначе служба откажется стартовать):

[sssd]
services = nss, pam
domains = example.com

[domain/example.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_tls_reqcert = demand
cache_credentials = true
enumerate = false

sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl enable --now sssd

Добавьте sss в источники в /etc/nsswitch.conf (passwd, group, shadow), а для автосоздания домашней папки при первом логине включите pam_mkhomedir:

sudo pam-auth-update --enable mkhomedir

После этого ssh ivan@server спросит пароль из LDAP-каталога, а id ivan покажет UID/GID оттуда же. Проверка на самом клиентском сервере:

getent passwd ivan
id ivan

TLS и базовая безопасность каталога

Без шифрования пароли при аутентификации по умолчанию (simple bind) уходят по сети практически в открытом виде — это никуда не годится даже во внутренней сети, не говоря об аренде сервера с публичным IP. Минимум — StartTLS на 389-м порту или отдельный порт 636 (ldaps).

Если у вас уже есть сертификат (например, от Let's Encrypt на домен сервера), подключаем его через cn=config:

cat > tls.ldif <<'EOF'
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/letsencrypt/live/ldap.example.com/cert.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/letsencrypt/live/ldap.example.com/privkey.pem
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/letsencrypt/live/ldap.example.com/chain.pem
EOF

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif

Права на приватный ключ должны позволять читать его пользователю openldap, иначе служба не запустится — самый частый источник ошибок здесь:

sudo usermod -aG ssl-cert openldap
sudo systemctl restart slapd

Ещё три вещи, которые стоит сделать сразу, а не после инцидента:

• Запретить анонимный bind, если он не нужен приложениям — иначе кто угодно может листать структуру каталога:

  olcDisallows: bind_anon

• Ограничить доступ к паролям через ACL — по умолчанию userPassword не должен быть читаем никем, кроме владельца записи и администратора; проверьте текущие правила через ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b cn=config "(olcAccess=*)" olcAccess.
• Регулярный бэкап базы через slapcat (это дамп именно из /var/lib/ldap, не из LDIF-файлов, которые вы применяли вручную):

  sudo slapcat -n 1 > /root/backups/ldap-$(date +%F).ldif

Firewall остаётся первой линией обороны — 389/636 не должны торчать в публичный интернет без крайней необходимости; если удалённым сотрудникам нужен доступ к каталогу извне, разумнее завести VPN и пускать LDAP-трафик только через него.

Частые вопросы