Настройка OpenLDAP сервера для централизованной аутентификации

Когда и зачем нужен OpenLDAP?

Представьте: у вас растёт компания — 50, 100, 500 сотрудников. Каждый день приходят новые люди, и админу нужно создавать учётные записи в почте, VPN, GitLab, Nextcloud, Grafana, SSH и других системах. А когда сотрудник увольняется, отключение доступа превращается в квест по восьми разным интерфейсам. Ошибка — и бывший сотрудник сохраняет доступ к критичным данным. OpenLDAP решает эту проблему раз и навсегда: единый LDAP сервер, одна точка управления, мгновенная блокировка.

Мы развернули OpenLDAP для 50+ организаций — от стартапов до холдингов с тысячами сотрудников. Наш опыт показывает, что правильно спроектированный LDAP-каталог снижает время администрирования учётных записей на 70%, а MTTR при инцидентах — с часов до минут (средний uptime 99.9%). OpenLDAP — это открытая реализация LDAP, соответствующая стандарту RFC 4511. В отличие от Windows Active Directory, он не требует лицензий и работает на любом Linux. Экономия на лицензиях достигает 70% по сравнению с AD.

Но LDAP полезен не только для аутентификации. Его можно использовать как универсальный справочник контактов, централизованное хранилище сертификатов, каталог сетевых ресурсов. В компаниях, где уже есть AD, OpenLDAP часто становится концентратором между Linux- и Windows-инфраструктурами.

Сравнение решений для централизованной аутентификации

Получите консультацию по выбору решения для вашей инфраструктуры — мы поможем избежать типовых ошибок.

Как спроектировать дерево LDAP?

LDAP — это иерархическое дерево объектов (DIT). Перед установкой обязательно спроектируйте структуру. Типичная схема:

dc=example,dc=com
├── ou=users — учётные записи пользователей
├── ou=groups — группы
├── ou=services — сервисные аккаунты для приложений
└── ou=computers — компьютеры (если нужно)

Каждый пользователь — объект с классами inetOrgPerson и posixAccount. Это обеспечивает совместимость с PAM, NSS и большинством веб-приложений.

Пример записи пользователя:

dn: uid=jsmith,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
uid: jsmith
cn: John Smith
sn: Smith
mail: [email protected]
uidNumber: 10001
gidNumber: 10000
homeDirectory: /home/jsmith
loginShell: /bin/bash
userPassword: {SSHA}hashhere

Структура добавляется командой: ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f structure.ldif.

Установка и настройка TLS

Установка: apt install slapd ldap-utils, затем dpkg-reconfigure slapd для задания пароля admin и суффикса. Конфигурация ведётся через OLC (cn=config) — it's live and running, без перезапуска slapd.

Без TLS пароли передаются в открытом виде — это критическая уязвимость. Настраиваем TLS через LDIF:

dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca-certificates.crt
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ldap.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap.key
-
add: olcTLSVerifyClient
olcTLSVerifyClient: never

Применить: ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif. На клиентах в ldap.conf пропишите TLS_CACERT и TLS_REQCERT demand. Мы всегда настраиваем StartTLS или LDAPS в зависимости от требований безопасности.

Репликация для отказоустойчивости

Для production минимум два сервера. Мы используем MirrorMode: изменения применяются на любой сервер, реплицируются асинхронно. При недоступности одного сервера клиенты автоматически переключаются на второй. Время переключения — менее 5 минут. Uptime — 99.9%.

Конфигурация репликации:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://ldap01.example.com bindmethod=simple binddn="cn=replicator,dc=example,dc=com" credentials=replicapassword searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="5 5 300 +"
add: olcMirrorMode
olcMirrorMode: TRUE

Для аварийного восстановления — ежедневный экспорт через slapcat -l /backup/ldap-$(date +%Y%m%d).ldif. Хранение 30 дней. Восстановление через slapadd.

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

Каждому приложению — отдельный сервисный аккаунт в ou=services с минимальными правами (принцип least privilege). ACL ограничивают доступ только к необходимым атрибутам. Например, для GitLab:

olcAccess: to * by dn.base="uid=gitlab-svc,ou=services,dc=example,dc=com" read by * none 

Nextcloud, GitLab, Grafana, Zabbix, OpenVPN — все поддерживают LDAP. Новый сотрудник получает доступ ко всем системам одновременно. Время на создание учётки — 30 секунд.

Реальный кейс: развёртывание для e-commerce с 5000 пользователей

Крупный интернет-магазин обратился к нам для централизации аутентификации. Исходно каждый сервис (1С-Битрикс, Jira, GitLab, Zabbix, Grafana, почта) имел свою базу пользователей. При увольнении сотрудника доступ оставался ещё неделями.

Мы спроектировали дерево: ou=users (5000 записей), ou=groups (200 групп), ou=services (15 аккаунтов). Развернули 2 сервера OpenLDAP в разных дата-центрах с MirrorMode, настроили TLS и ACL. Интегрировали все 15 сервисов, создали веб-интерфейс на LDAP Account Manager для самообслуживания (смена пароля, обновление контактов). Результат: время на администрирование учётных записей сократилось с 20 часов в неделю до 2 часов. Время аутентификации — менее 10 мс. Uptime 99.95% за год.

Процесс работы и сроки

Ориентировочные сроки: от 5 до 10 рабочих дней в зависимости от количества сервисов и объёмов миграции. Стоимость рассчитывается индивидуально. Оценим ваш проект — свяжитесь с нами для консультации.

Что вы получаете в результате

По итогу проекта вы получаете:

• Работающий OpenLDAP-каталог с TLS и репликацией.
• Интеграцию со всеми указанными сервисами (до 20).
• Скрипты резервного копирования и восстановления.
• Документацию: архитектура, инструкции, контакты.
• Обучение ваших администраторов (2-3 часа).
• Поддержку в течение 2 недель после внедрения.

Типичные ошибки и как их избежать

• Пропуск TLS — пароли передаются открытым текстом. Всегда включайте TLS или StartTLS.
• Один аккаунт для всех приложений — каждому сервису свой аккаунт с минимальными правами.
• Отсутствие репликации — единственный сервер — точка отказа. Минимум два сервера.
• Сложная структура — слишком глубокие ou или избыточные objectClass. Проектируйте под реальные задачи, не усложняйте.
• Неучтённые зависимости — перед миграцией проведите аудит. Наш опыт: в 30% проектов обнаруживаются скрытые зависимости, которые без аудита ведут к простою.

Закажите аудит вашей инфраструктуры — мы выявим риски и предложим план миграции.