OpenLDAP на openSUSE как центральный каталог: схемы, ACL, syncrepl-репликация и интеграция клиентов через SSSD

Центральный каталог на базе LDAP обычно выбирается, когда требуется единая точка управления учетными записями и группами для нескольких Linux-систем: серверов приложений, рабочих станций администраторов, jump-хостов, CI-агентов. Локальные файлы /etc/passwd и /etc/group перестают масштабироваться, а ручная синхронизация пользователей приводит к несоответствиям UID/GID и проблемам с правами на файлы.

Ниже описан прикладной сценарий развертывания OpenLDAP 2.4 на openSUSE в роли центрального каталога с тремя ключевыми требованиями:

• корректные схемы для Linux-учетных записей, групп и (опционально) sudo/SSH-ключей
• ACL по принципу минимально необходимых прав
• syncrepl-репликация на резервный узел и подключение клиентов через SSSD (NSS/PAM)

Сценарий рассчитан на типовую инфраструктуру, где LDAP-серверы размещаются на двух узлах (provider и consumer). В реальных внедрениях это нередко два виртуальных сервера (VPS/VDS) в одном сегменте сети. Для тестового стенда под openSUSE иногда используется VPS.house – https://vps.house, чтобы быстро поднять пару машин под репликацию и отработать ACL/SSSD без риска для продуктивной среды.

1. Архитектура и базовые договоренности

Роли:

• Provider – основной LDAP-сервер, на котором выполняются изменения данных
• Consumer – реплика, получающая изменения через syncrepl и обслуживающая чтение (а также работающая как резерв)
• Клиенты – Linux-хосты с SSSD, получающие пользователей/группы/правила sudo/SSH-ключи из каталога

Имена и структура каталога (пример):

• Базовый DN: dc=example,dc=net
• Организационные единицы: ou=People, ou=Groups, ou=Sudoers, ou=System
• Сервисные учетные записи: cn=sssd,ou=System,dc=example,dc=net (поиск), cn=replicator,ou=System,dc=example,dc=net (репликация)

Почему именно SSSD: это распространенный подход для Linux-клиентов, потому что SSSD дает кеширование, офлайн-режим, единое место для NSS/PAM, failover по нескольким LDAP URI и дополнительные провайдеры (sudo, ssh, autofs).

Почему syncrepl: это штатный механизм репликации OpenLDAP с поддержкой режима refreshAndPersist (подписка на изменения). Он подходит для схемы «один writer – несколько reader» и обеспечивает актуальность данных без внешних cron-задач.

2. Подготовка openSUSE: пакеты, сеть, время

Установка пакетов (на обоих LDAP-узлах):

zypper refresh
zypper in openldap2 openldap2-client

Для backend MDB и overlays в зависимости от выпуска openSUSE могут требоваться дополнительные пакеты (часто это отдельные подпакеты вида openldap2-backend-mdb и набор модулей/оверлеев). Практически полезный контроль – убедиться, что доступны модули back_mdb и syncprov в каталоге модулей OpenLDAP.

Синхронизация времени: для репликации критично отсутствие заметного дрейфа времени между узлами (CSN/entryCSN). Обычно включается chrony:

zypper in chrony
systemctl enable —now chronyd

DNS и имена: рекомендуется иметь устойчивые имена узлов (например, ldap01.example.net и ldap02.example.net) и корректные A/AAAA-записи. Для TLS желательно, чтобы сертификат соответствовал DNS-именам.

Файрвол: часто используется StartTLS на 389/tcp и, при необходимости, LDAPS на 636/tcp. Важно ограничить доступ к LDAP извне (например, только из подсетей серверов/рабочих станций администраторов или через VPN).

3. Конфигурация OpenLDAP на openSUSE: cn=config и TLS

В современных установках OpenLDAP обычно используется динамическая конфигурация cn=config (каталог slapd.d) и управление через ldapmodify по ldapi:/// с SASL/EXTERNAL. Если сервер изначально настроен через slapd.conf, его можно конвертировать в slapd.d утилитой slaptest; после конвертации изменения удобнее вносить в формате LDIF.

Локальная административная сессия (типовой шаблон):

ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b cn=config dn

3.1. TLS: StartTLS vs LDAPS

В подобных сценариях предпочтение часто отдается StartTLS (389/tcp) – он работает поверх стандартного LDAP-порта, удобен для failover и проще для сетевых политик. LDAPS (636/tcp) тоже используется, но в практических внедрениях нередко оставляется как дополнительный вариант совместимости.

Базовые требования к TLS:

• у сервера есть ключ и сертификат (с корректным CN/SAN)
• клиенты доверяют CA, подписавшему сертификат сервера
• на стороне OpenLDAP прописаны пути к файлам сертификатов в cn=config

Пример LDIF для задания TLS-параметров в cn=config:

dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/ca.crt
—
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/ldap01.crt
—
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap01.key

Применение:

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

Для openSUSE важно, чтобы права на ключевой файл позволяли чтение пользователю сервиса OpenLDAP (часто это ldap), а CA-сертификат был доступен также клиентам (через системное хранилище или файл ldap_tls_cacert в SSSD).

4. Схемы: учетные записи Linux, группы, sudo и SSH-ключи

Чтобы OpenLDAP стал центральным каталогом для Linux, обычно требуется набор objectClass и атрибутов для POSIX-аккаунтов и групп. В OpenLDAP это достигается подключением схем:

• core, cosine, inetorgperson – базовые учетные записи и атрибуты человека
• nis – posixAccount, posixGroup (UID/GID, домашние каталоги, shell)
• sudo (опционально) – sudoRole для централизованного управления sudo
• sshPublicKey (опционально) – хранение публичных ключей для SSH (часто через схему openssh-lpk)

Практический нюанс: в режиме cn=config схемы подключаются как LDIF-записи в cn=schema,cn=config. На разных дистрибутивах схемы могут поставляться в формате .schema (текст) или .ldif. Универсальный способ – конвертация через slaptest в отдельный временный каталог конфигурации и последующее добавление полученного LDIF.

Упрощенный алгоритм конвертации schema → ldif:

1. Создается временный конфиг, в котором подключаются нужные include
2. Запускается slaptest с выводом в временный slapd.d
3. Из полученного каталога берется файл cn={X}имя,cn=schema,cn=config.ldif и добавляется через ldapadd по ldapi:///

Контроль наличия схем:

ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn | grep -E «inetorgperson|nis|sudo|openssh»

На consumer должны быть подключены те же схемы, что и на provider. syncrepl переносит данные, но не переносит сами описания схем, поэтому несоответствие схем – частая причина ошибок репликации и отказа в добавлении записей.

5. База каталога и сервисные учетные записи

Рекомендуется заранее зафиксировать «скелет» каталога: базовый DN, OU и служебные записи. Это упрощает ACL и интеграцию клиентов.

Пример базовых объектов (base.ldif):

dn: dc=example,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: Example
dc: example

dn: ou=System,dc=example,dc=net
objectClass: top
objectClass: organizationalUnit
ou: System

Добавление (на provider):

ldapadd -x -D «cn=ldapadmin,dc=example,dc=net» -W -H ldap://ldap01.example.net -f base.ldif

Для сервисных аккаунтов обычно заводятся отдельные записи в ou=System с сильными паролями. Пароли целесообразно хранить как SSHA/ARGON2-хэши (в зависимости от сборки OpenLDAP и политик) и передавать по сети только поверх TLS.

Пример сервисной учетной записи для SSSD (service account только на поиск):

dn: cn=sssd,ou=System,dc=example,dc=net
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: sssd
description: Bind account for SSSD lookups
userPassword: {SSHA}…хэш…

Пример учетной записи для репликации:

dn: cn=replicator,ou=System,dc=example,dc=net
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
description: syncrepl bind account
userPassword: {SSHA}…хэш…

Генерация хэша обычно выполняется утилитой slappasswd:

slappasswd

6. ACL: минимально необходимые права без «дыр»

ACL в OpenLDAP работают по порядку: первое совпавшее правило определяет результат. Ошибки чаще всего возникают из-за неправильного порядка (например, общий доступ «read» стоит раньше запрета) или из-за того, что забыты атрибуты репликации (entryCSN, entryUUID, contextCSN).

Цели ACL в рассматриваемом сценарии:

• запрет анонимного чтения каталога (минимизация утечек и перебора учетных записей)
• разрешение анонимного auth к userPassword (чтобы bind работал корректно, если выбран соответствующий режим)
• разделение прав: администратор каталога, replicator, bind-аккаунт SSSD
• возможность пользователю менять собственный пароль
• разрешение replicator на чтение всего необходимого для syncrepl

Шаблон ACL для базы данных (пример, адаптируется под DN и OU):

dn: olcDatabase={X}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword by dn.exact=«cn=ldapadmin,dc=example,dc=net» write by self write by dn.exact=«cn=sssd,ou=System,dc=example,dc=net» auth by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by dn.exact=«cn=ldapadmin,dc=example,dc=net» write by self write by * read
olcAccess: {2}to dn.subtree=«ou=System,dc=example,dc=net» by dn.exact=«cn=ldapadmin,dc=example,dc=net» write by * none
olcAccess: {3}to dn.subtree=«dc=example,dc=net» by dn.exact=«cn=replicator,ou=System,dc=example,dc=net» read by dn.exact=«cn=sssd,ou=System,dc=example,dc=net» read by users read by * none

Пояснения к примеру:

• SSSD-аккаунту обычно достаточно read к большинству атрибутов (поиск UID/GID, групп, домашнего каталога), а к userPassword – только auth (чтобы сервер мог корректно проводить проверку при bind, если используется соответствующая схема аутентификации)
• OU System закрывается от чтения обычным пользователям, чтобы не раскрывать сервисные DN
• replicator получает read ко всему дереву, что упрощает репликацию. В более строгих вариантах доступ ограничивается конкретными OU, но тогда требуется внимательно учитывать все необходимые атрибуты репликации

Как узнать DN базы данных в cn=config:

ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b cn=config ‘(olcDatabase=*)’ dn olcDatabase

В LDIF выше используется olcDatabase={X}mdb,cn=config – вместо {X} подставляется номер из вывода. После применения ACL полезно проверить, что анонимный поиск закрыт, а bind от имени SSSD возможен:

ldapsearch -x -H ldap://ldap01.example.net -b «dc=example,dc=net» -s base dn
ldapsearch -x -H ldap://ldap01.example.net -D «cn=sssd,ou=System,dc=example,dc=net» -W -b «ou=People,dc=example,dc=net» «(uid=user01)» uid uidNumber gidNumber

7. Индексы и backend MDB: минимум для производительности

Центральный каталог быстро начинает упираться в индексы, особенно когда клиентов становится много и SSSD делает регулярные запросы. Для MDB обычно задаются индексы по атрибутам, участвующим в поиске идентификаторов и групп.

Типовой набор индексов для Linux-учетных записей:

• objectClass – eq
• uid, uidNumber, gidNumber – eq
• cn, sn – eq,sub (если используется поиск по имени)
• memberUid или member – eq (в зависимости от модели групп)

Пример добавления индексов (адаптировать DN базы):

dn: olcDatabase={X}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: objectClass eq
olcDbIndex: uid,uidNumber,gidNumber eq
olcDbIndex: cn,sn eq,sub
olcDbIndex: memberUid eq

После изменения индексов на существующей базе обычно выполняется переиндексация (в зависимости от размеров каталога и режима обслуживания – онлайн или с остановкой сервиса). В MDB также важно контролировать olcDbMaxSize, чтобы база не уперлась в лимит по размеру файла.

8. syncrepl: репликация provider → consumer

8.1. Минимальные условия для стабильной репликации

• на provider включен overlay syncprov для реплицируемой базы
• на обоих узлах совпадают схемы
• на consumer настроен olcSyncrepl в базе
• у пользователя replicator на provider есть права чтения требуемых данных
• время синхронизировано (chrony/ntpd)

8.2. Настройка provider: syncprov и ServerID

ServerID полезен для однозначной идентификации инстанса (особенно если в перспективе появится multi-master). Для одиночного provider это не строго обязательно, но на практике помогает избежать неоднозначностей при расширении схемы репликации.

Пример задания ServerID (на provider):

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://ldap01.example.net

Подключение overlay syncprov к MDB-базе:

dn: olcOverlay=syncprov,olcDatabase={X}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionLog: 100

Применение:

ldapadd -Q -Y EXTERNAL -H ldapi:/// -f syncprov.ldif

olcSpSessionLog помогает при кратковременных обрывах связи (consumer догоняет изменения из sessionlog). Значения подбираются по объему и интенсивности изменений.

8.3. Настройка consumer: olcSyncrepl, UpdateRef и ServerID

На consumer в базе данных задается параметр olcSyncrepl. Важно: consumer должен иметь тот же olcSuffix, что и provider, и backend должен быть подготовлен (MDB-директория, права, схемы).

ServerID (на consumer):

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 2 ldap://ldap02.example.net

Пример syncrepl (на consumer, адаптировать DN базы):

dn: olcDatabase={X}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: rid=001 provider=ldap://ldap01.example.net type=refreshAndPersist searchbase=«dc=example,dc=net» bindmethod=simple binddn=«cn=replicator,ou=System,dc=example,dc=net» credentials=«СИЛЬНЫЙ_ПАРОЛЬ» starttls=critical retry=«60 +» timeout=1 schemachecking=on
—
add: olcUpdateRef
olcUpdateRef: ldap://ldap01.example.net

Практические замечания:

• starttls=critical принуждает TLS. Если TLS на provider не настроен или клиент не доверяет CA, репликация не поднимется – это ожидаемое поведение для защищенной схемы
• retry=«60 +» означает бесконечные попытки переподключения раз в 60 секунд. Для нестабильных каналов часто задаются более детальные политики retry
• olcUpdateRef нужен, чтобы клиентские записи на consumer получали ссылку на provider при попытке изменения данных

Проверка состояния репликации:

• поиск contextCSN на consumer и provider (должен сходиться после стабилизации)
• журналы slapd (ошибки bind, TLS, insufficient access)
• наличие реплицируемых объектов на consumer

Пример проверки contextCSN:

ldapsearch -x -H ldap://ldap02.example.net -b «dc=example,dc=net» -s base contextCSN

8.4. Delta-syncrepl: когда имеет смысл и какие ограничения

Delta-syncrepl уменьшает сетевой трафик, перенося не полные записи, а изменения из accesslog-базы. Это полезно при большой интенсивности модификаций и ограниченных каналах связи. Однако настройка заметно сложнее: требуется отдельная база accesslog, overlay accesslog, правильные ACL на accesslog и дополнительный контроль ротации/размеров. В небольших каталогах типовой syncrepl обычно проще и надежнее.

9. Подключение Linux-клиентов через SSSD (NSS/PAM)

Ниже приведен практический вариант интеграции openSUSE-клиента (и, с небольшими отличиями, большинства современных Linux) через SSSD.

9.1. Пакеты и включение службы

Установка:

zypper in sssd sssd-ldap sssd-tools

Включение службы:

systemctl enable —now sssd

9.2. Конфигурация /etc/sssd/sssd.conf

Файл /etc/sssd/sssd.conf должен иметь права 0600, иначе SSSD откажется стартовать.

Пример конфигурации домена LDAP (с failover на реплику):

[sssd]
services = nss, pam, sudo, ssh
config_file_version = 2
domains = example

ldap_schema = rfc2307
ldap_user_object_class = posixAccount
ldap_group_object_class = posixGroup

Пояснения:

• ldap_uri содержит оба узла – это позволяет SSSD переключаться при недоступности provider
• enumerate = false снижает нагрузку: не выполняется полный перебор всех пользователей/групп. Это важно для каталогов, где учетных записей много
• ldap_schema выбирается под модель групп. Если используются группы вида groupOfNames/member (RFC2307bis), параметры меняются соответственно

Права на файл:

chmod 600 /etc/sssd/sssd.conf

9.3. NSS и PAM: включение SSSD в систему

На openSUSE распространенный инструмент – pam-config. Обычно включается NSS/PAM-интеграция и создание домашнего каталога при первом входе.

Пример команд:

pam-config —add —sss
pam-config —add —mkhomedir

Также проверяется /etc/nsswitch.conf – строки passwd, group, shadow должны содержать sss. Конкретный порядок источников зависит от политики, но типовой вариант выглядит так: files sss.

Проверка на клиенте:

getent passwd user01
id user01

При ошибках полезно смотреть логи SSSD (/var/log/sssd/) и выполнить сброс кеша:

sss_cache -E
systemctl restart sssd

9.4. Sudo из LDAP (опционально)

SSSD умеет получать правила sudo из LDAP, но требуется схема sudoRole и корректная база поиска. Часто выделяется отдельная OU, например ou=Sudoers,dc=example,dc=net.

Дополнение к sssd.conf:

ldap_sudo_search_base = ou=Sudoers,dc=example,dc=net

Пример простого sudoRole (ограничивать следует аккуратно):

dn: cn=admins,ou=Sudoers,dc=example,dc=net
objectClass: top
objectClass: sudoRole
cn: admins
sudoUser: %wheel
sudoHost: ALL
sudoCommand: ALL
sudoOption: !authenticate

В продуктивной среде параметр !authenticate обычно не используется – он приведен только как иллюстрация. Важно также обеспечить чтение этой OU для bind-аккаунта SSSD через ACL.

9.5. SSH-ключи из LDAP (опционально)

SSSD может выдавать SSH-ключи через утилиту sss_ssh_authorizedkeys. На стороне SSHD настраивается вызов команды, а в каталоге хранится атрибут (часто sshPublicKey) в пользовательской записи.

Фрагмент sshd_config:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

После изменения конфигурации SSHD требуется перезапуск сервиса. Также следует убедиться, что SSSD запущен с сервисом ssh (в секции [sssd]).

10. Эксплуатационные заметки: бэкапы, обновления, контроль доступа

10.1. Резервное копирование

Для OpenLDAP на MDB наиболее безопасный универсальный способ резервного копирования – логический дамп через slapcat. Он не зависит от особенностей файловой системы и состояния mmap-файлов MDB.

Пример (дамп базы данных):

slapcat -b «dc=example,dc=net» -l /var/backups/ldap-example.ldif

Восстановление обычно выполняется офлайн (с остановкой slapd) через slapadd. Важно сохранять права на каталоги базы и учитывать, что восстановление поверх реплики может быть перезаписано syncrepl (поэтому операции восстановления следует планировать вместе с остановкой репликации).

10.2. Обновления и совместимость схем

Перед обновлениями пакетов OpenLDAP полезно проверить совместимость схем и оверлеев (особенно если используются нестандартные схемы вроде sudo или openssh-lpk). При несовпадении схем на provider и consumer репликация начнет падать с ошибками разбора атрибутов/objectClass.

10.3. Политика доступа и сетевые границы

Даже при включенном TLS рекомендуется ограничивать доступ к LDAP сетевыми средствами. В случае размещения на виртуальных серверах (VPS/VDS) отдельного провайдера важны приватные сети, фильтрация по источникам и отсутствие прямой публикации LDAP-порта в интернет. Если тестовый стенд поднимается быстро и «на время», полезно заранее продумать минимальные правила файрвола и отдельные сервисные учетные записи. В качестве примера аренды VPS под такой стенд иногда рассматривается VPS.house, но практическая ценность дает не провайдер, а воспроизводимость конфигурации и дисциплина в ACL/TLS.

11. Чек-лист типовых проблем и диагностика

• SSSD не видит пользователей – проверить ACL (есть ли read на нужные OU), корректность ldap_search_base, работу StartTLS и доверие CA
• Bind-аккаунт SSSD не может искать – убедиться, что DN/пароль верны, и что OU System не закрыта слишком жестко для самого bind-аккаунта
• syncrepl не поднимается – смотреть логи slapd на consumer: ошибки TLS, invalid credentials, insufficient access. Проверить права replicator и наличие syncprov на provider
• Реплика «догоняет» бесконечно – проверить время (chrony), индексы и производительность диска, а также размер сессии (sessionlog) при высокой интенсивности изменений
• UID/GID коллизии – заранее выделить диапазоны UID/GID и внедрить процедуру выдачи (вручную, через скрипт/CI или через отдельный инструмент учета)

Вывод

OpenLDAP на openSUSE способен выполнять роль центрального каталога для Linux-инфраструктуры при условии дисциплины в трех областях: корректный набор схем (POSIX, опционально sudo/SSH), продуманные ACL с минимальными правами и защищенный транспорт (TLS). syncrepl-репликация provider/consumer повышает устойчивость, а интеграция клиентов через SSSD дает единый механизм NSS/PAM с кешированием и failover. Такой набор практик позволяет строить предсказуемую и управляемую систему учетных записей как на физических серверах, так и на виртуальных серверах (VPS/VDS) в распределенных средах.