OpenLDAP einrichten: cn=config, TLS, ACLs, Sicherung und Replikation

EdwardMoon

Dieser Leitfaden behandelt OpenLDAP 2.6 mit dynamischer Konfiguration über cn=config und dem MDB-Backend. Er führt durch TLS, ACLs mit minimalen Rechten, Indizes, Sicherung, Wiederherstellung und syncrepl-Hochverfügbarkeit. Bei einem Dienst als Grundlage der Benutzerauthentifizierung sind Verschlüsselung, Berechtigungen, Konsistenz und Wiederherstellbarkeit entscheidende Prüfpunkte.

Unter Rocky Linux 9 hängen Anbieter der Serverpakete und Verzeichnisstruktur vom gewählten Hersteller beziehungsweise Buildverfahren ab. Dieser Artikel setzt OpenLDAP-2.6-Pakete aus geprüfter Quelle voraus. Paketabhängige Pfade zuerst ermitteln und Änderungen anschließend über LDAP-Operationen in cn=config vornehmen. Für die Anmeldung am Host den LDAP-Provider von SSSD anstelle von nss-pam-ldapd prüfen.

Komponenten und Entwurf

Pakete und Pfade vor dem Aufbau prüfen

Paketnamen nicht erraten, sondern ausführbare Dienstdatei, Konfigurations-DIT, Datenverzeichnis und Zertifikatspfade dokumentieren. Bei einem Quellcode-Build des OpenLDAP-Projekts configure-, Test- und Installationsergebnisse sowie Abhängigkeitsversionen aufbewahren. Bei Herstellerpaketen GPG-Signaturen und Supportrichtlinien prüfen.

slapd -VVV 2>&1 | head -n 40
ldapsearch -VV 2>&1 | head -n 20

command -v slapd ldapsearch ldapmodify slapcat slapadd slaptest
systemctl cat slapd
systemctl show slapd -p User -p Group -p ExecStart

findmnt -T /var/lib/ldap
df -hT /var/lib/ldap
df -i /var/lib/ldap

cn=config und MDB prüfen

Lokale Verwaltungsverbindung über LDAPI

sudo ldapwhoami -Q -Y EXTERNAL -H ldapi:///

sudo ldapsearch -LLL -Q -Y EXTERNAL -H ldapi:///   -b cn=config -s base dn cn

sudo ldapsearch -LLL -Q -Y EXTERNAL -H ldapi:///   -b cn=config   '(&(objectClass=olcMdbConfig)(olcSuffix=*))'   dn olcSuffix olcRootDN olcDbDirectory olcDbMaxSize olcDbIndex

-Q -Y EXTERNAL verwendet die Peer-Zugangsdaten des Unix-Sockets, sodass kein cn=config-Verwaltungspasswort in der Befehlszeile erforderlich ist. cn=config nicht für Fernzugriffe veröffentlichen und bestehende Einträge vor Änderungen als LDIF sichern. Die Nummer in {Nummer} des Datenbank-DN unterscheidet sich je nach Installation und darf nicht geraten werden.

Aktuelles cn=config sichern

sudo install -d -m 0700 /var/backups/openldap

sudo ldapsearch -LLL -Q -Y EXTERNAL -H ldapi:///   -b cn=config '(objectClass=*)' '*' '+'   | sudo tee "/var/backups/openldap/cn-config-before-$(date +%F-%H%M%S).ldif"   >/dev/null

sudo chmod 0600 /var/backups/openldap/*.ldif
sudo sha256sum /var/backups/openldap/*.ldif

Suffix und Administrator-DN

Die Beispiele verwenden dc=example,dc=com und cn=admin. Tatsächlichen Organisationsnamen, DNS-Inhaberschaft und Benennungsrichtlinien zuerst festlegen. rootDN umgeht alle ACLs und ist kein Anwendungskonto. Nur für Notfallwiederherstellung einsetzen; alltägliche Änderungen über eine delegierte Administratorengruppe ausführen.

MDB-Datenbank-DN ermitteln und rootPW-Hash erzeugen

MDB_DN=$(sudo ldapsearch -LLL -Q -Y EXTERNAL -H ldapi:///   -b cn=config '(&(objectClass=olcMdbConfig)(olcSuffix=*))' dn   | awk '/^dn: / {print substr($0,5); exit}')

printf 'MDB_DN=%s
' "$MDB_DN"
test -n "$MDB_DN"

# Das Passwort wird interaktiv eingegeben und erscheint nicht im Shell-Verlauf.
ROOT_HASH=$(slappasswd)
test -n "$ROOT_HASH"

Suffix, rootDN und rootPW ändern

sudo install -m 0600 /dev/null /root/openldap-database.ldif
sudo tee /root/openldap-database.ldif >/dev/null <<EOF
dn: ${MDB_DN}
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=com
-
replace: olcRootDN
olcRootDN: cn=admin,dc=example,dc=com
-
replace: olcRootPW
olcRootPW: ${ROOT_HASH}
EOF

unset ROOT_HASH
sudo ldapmodify -Q -Y EXTERNAL -H ldapi:///   -f /root/openldap-database.ldif
sudo shred -u /root/openldap-database.ldif

Grundlegenden DIT und Benutzer anlegen

Base-DN und Organisationseinheiten erstellen

install -m 0600 /dev/null base.ldif
cat > base.ldif <<'LDIF'
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: Example Directory
dc: example

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

dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups
LDIF

ldapadd -x -W -D 'cn=admin,dc=example,dc=com'   -H ldapi:/// -f base.ldif
shred -u base.ldif

Testbenutzer und Administratorengruppe

USER_HASH=$(slappasswd)
install -m 0600 /dev/null people.ldif
cat > people.ldif <<EOF
dn: uid=alice,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
uid: alice
cn: Alice Example
sn: Example
mail: alice@example.com
userPassword: ${USER_HASH}

dn: cn=ldap-admins,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
cn: ldap-admins
member: uid=alice,ou=People,dc=example,dc=com
EOF

unset USER_HASH
ldapadd -x -W -D 'cn=admin,dc=example,dc=com'   -H ldapi:/// -f people.ldif
shred -u people.ldif

Benutzerpasswörter nicht im Klartext in LDIF, Git oder Tickets speichern. Anwendungskonten von persönlichen Konten trennen. Beim Entfernen des ersten member aus groupOfNames die Schemabedingungen berücksichtigen. Eindeutigkeit von uid und mail durch Overlay oder Provisionierungsablauf absichern, statt allein der Anwendung zu vertrauen.

TLS erzwingen und prüfen

olcSecurity: simple_bind=128 verlangt ausreichende Verschlüsselung für passwortbasierte Simple Binds. Vorhandene olcSecurity-Werte unter Erhalt bisheriger Einschränkungen zusammenführen, statt sie ungeprüft zu überschreiben. Liegt der lokale LDAPI-SSF unter 128, kann auch ein Simple Bind über LDAPI abgelehnt werden. Verwaltungsänderungen dann über LDAPI mit SASL EXTERNAL ausführen; Benutzer- und Replikationskonten über StartTLS oder LDAPS mit CA-Prüfung verbinden. Diese Richtlinie verschlüsselt die Passwortübertragung des Clients nicht selbst. Auch der Client muss -ZZ oder ldaps:// verwenden.

Simple Bind schützt Passwörter ohne TLS nicht. Der SAN des Serverzertifikats muss den tatsächlich verwendeten DNS-Namen enthalten; nur das slapd-Dienstkonto darf den privaten Schlüssel lesen. Die Zertifikatskette der Organisations- oder öffentlichen CA auf alle LDAP-Clients und Replikationsknoten verteilen.

Zertifikatsrechte und Gültigkeit prüfen

sudo install -d -o root -g ldap -m 0750 /etc/openldap/certs
sudo install -o root -g ldap -m 0640 ldap01.key /etc/openldap/certs/
sudo install -o root -g ldap -m 0644 ldap01.crt /etc/openldap/certs/
sudo install -o root -g ldap -m 0644 org-ca.crt /etc/openldap/certs/

openssl x509 -in /etc/openldap/certs/ldap01.crt   -noout -subject -issuer -dates -ext subjectAltName
openssl verify -CAfile /etc/openldap/certs/org-ca.crt   /etc/openldap/certs/ldap01.crt

TLS-Pfade in cn=config eintragen

sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<'LDIF'
dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/org-ca.crt
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/ldap01.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap01.key
-
replace: olcTLSProtocolMin
olcTLSProtocolMin: 3.3
-
replace: olcSecurity
olcSecurity: simple_bind=128
LDIF

sudo systemctl restart slapd
sudo systemctl status slapd --no-pager

Hostnamenprüfung für StartTLS und LDAPS

openssl s_client -connect ldap01.example.com:636   -servername ldap01.example.com -verify_hostname ldap01.example.com   -CAfile /etc/openldap/certs/org-ca.crt -verify_return_error </dev/null

LDAPTLS_CACERT=/etc/openldap/certs/org-ca.crt ldapwhoami -x -ZZ -H ldap://ldap01.example.com   -D 'uid=alice,ou=People,dc=example,dc=com' -W

LDAPTLS_CACERT=/etc/openldap/certs/org-ca.crt ldapsearch -LLL -x -H ldaps://ldap01.example.com   -D 'uid=alice,ou=People,dc=example,dc=com' -W -b 'dc=example,dc=com' '(uid=alice)' dn cn mail

Eigenes Replikationskonto und Ablehnung unverschlüsselter Verbindungen testen

Zuerst das dedizierte Konto für die beiden Provider vorbereiten. Das folgende Passwort muss mit dem Geheimnis der Replikationsverbindung übereinstimmen. Existiert das Konto bereits, nicht erneut hinzufügen, sondern Konto und ACL prüfen.

REPL_HASH=$(slappasswd)
umask 077
cat > replicator.ldif <<EOF
dn: uid=replicator,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
uid: replicator
cn: Replication Reader
sn: Reader
userPassword: ${REPL_HASH}
EOF
unset REPL_HASH
LDAPTLS_CACERT=/etc/openldap/certs/org-ca.crt \
ldapadd -x -ZZ -H ldap://ldap01.example.com \
  -D 'cn=admin,dc=example,dc=com' -W -f replicator.ldif
rm -f replicator.ldif

# Nur eine Testzeichenfolge statt eines echten Passworts senden; Ablehnung mit confidentiality required prüfen.
ldapwhoami -x -H ldap://ldap01.example.com \
  -D 'uid=transport-probe,ou=People,dc=example,dc=com' -w not-a-real-password

ACLs mit minimalen Rechten

OpenLDAP-ACLs werden von oben nach unten ausgewertet; die zuerst passende to- und by-Regel entscheidet. Sensible Attribute wie userPassword daher zuerst behandeln und allgemeine Regeln zuletzt anordnen. Nicht auf eine allgemeine öffentliche Lesefreigabe setzen; anonymen Verbindungen nur das für Bind erforderliche auth-Recht erlauben.

sudo tee /root/openldap-acl.ldif >/dev/null <<EOF
dn: ${MDB_DN}
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.exact="uid=replicator,ou=People,dc=example,dc=com" read by * break
olcAccess: {1}to attrs=userPassword by self =xw by anonymous auth by * none
olcAccess: {2}to dn.subtree="ou=People,dc=example,dc=com" attrs=entry,children,cn,sn,uid,mail by self write by group.exact="cn=ldap-admins,ou=Groups,dc=example,dc=com" write by users read by * none
olcAccess: {3}to dn.subtree="ou=Groups,dc=example,dc=com" by group.exact="cn=ldap-admins,ou=Groups,dc=example,dc=com" write by users read by * none
olcAccess: {4}to * by users read by * none
-
add: olcLimits
olcLimits: {0}dn.exact="uid=replicator,ou=People,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
EOF

sudo chmod 0600 /root/openldap-acl.ldif
sudo ldapmodify -Q -Y EXTERNAL -H ldapi:///   -f /root/openldap-acl.ldif
sudo shred -u /root/openldap-acl.ldif

Erlaubte und verweigerte ACL-Zugriffe testen

# Anonyme Zugriffe dürfen userPassword nicht lesen können.
LDAPTLS_CACERT=/etc/openldap/certs/org-ca.crt ldapsearch -LLL -x -ZZ -H ldap://ldap01.example.com   -b 'uid=alice,ou=People,dc=example,dc=com' userPassword

# Bind mit dem eigenen Konto und Lesen gewöhnlicher Attribute prüfen.
LDAPTLS_CACERT=/etc/openldap/certs/org-ca.crt ldapsearch -LLL -x -ZZ -H ldap://ldap01.example.com   -D 'uid=alice,ou=People,dc=example,dc=com' -W   -b 'uid=alice,ou=People,dc=example,dc=com' cn mail

sudo ldapsearch -LLL -Q -Y EXTERNAL -H ldapi:///   -b "$MDB_DN" olcAccess

MDB-Indizes und Zustand

Indizes anhand tatsächlicher Suchfilter und Bind-Attribute planen. eq und sub für jedes Attribut erhöhen Schreibaufwand und Datenbankgröße. Vor Änderungen Zugriffslogs oder Anwendungsabfragen auswerten. Bei vorhandenen Daten slapindex in einem Wartungsfenster ausführen.

sudo tee /root/openldap-index.ldif >/dev/null <<EOF
dn: ${MDB_DN}
changetype: modify
replace: olcDbIndex
olcDbIndex: objectClass eq
olcDbIndex: entryUUID,entryCSN eq
olcDbIndex: uid,mail eq
olcDbIndex: cn,sn eq,sub
EOF

sudo ldapmodify -Q -Y EXTERNAL -H ldapi:///   -f /root/openldap-index.ldif
sudo shred -u /root/openldap-index.ldif

sudo ldapsearch -LLL -Q -Y EXTERNAL -H ldapi:///   -b "$MDB_DN" olcDbIndex olcDbMaxSize olcDbCheckpoint

Mit slapcat sichern und Wiederherstellung üben

Eine Sicherung benötigt sowohl cn=config als auch das Anwendungssuffix. Bei einem Einzelknoten slapd im Wartungsfenster stoppen. In einer HA-Umgebung eine Replik aus dem Loadbalancer nehmen und dort einen konsistenten LDIF-Stand erzeugen. Dateien verschlüsselt auf ein anderes System kopieren und Prüfsummen dokumentieren.

sudo bash -euo pipefail <<'BASH'
backup_dir="/var/backups/openldap/$(date +%F-%H%M%S)"
install -d -m 0700 "$backup_dir"
umask 077
systemctl stop slapd
trap 'systemctl start slapd' EXIT
slapcat -F /etc/openldap/slapd.d -n 0 > "$backup_dir/cn-config.ldif"
slapcat -F /etc/openldap/slapd.d -b 'dc=example,dc=com' > "$backup_dir/example-data.ldif"
test -s "$backup_dir/cn-config.ldif"
test -s "$backup_dir/example-data.ldif"
(cd "$backup_dir" && sha256sum ./*.ldif > SHA256SUMS && sha256sum -c SHA256SUMS)
BASH
sudo systemctl status slapd --no-pager
sudo journalctl -u slapd --since '-5 min' --no-pager

Prüfpunkte für eine Wiederherstellungsprobe

sudo slaptest -F /etc/openldap/slapd.d -u
sudo slapcat -F /etc/openldap/slapd.d -n 0 | head
sudo slapcat -F /etc/openldap/slapd.d   -b 'dc=example,dc=com' | head

LDAPTLS_CACERT=/etc/openldap/certs/org-ca.crt ldapsearch -LLL -x -ZZ -H ldap://ldap01.example.com   -D 'cn=admin,dc=example,dc=com' -W   -b 'dc=example,dc=com' '(objectClass=*)' dn | tail

• Auf einem isolierten Host in leere slapd.d- und Datenverzeichnisse zuerst die Konfiguration und danach die Daten mit slapadd einspielen.
• Eigentümer passend zum Dienstkonto des Pakets und SELinux-Kontext wiederherstellen.
• Nach slaptest LDAPI, StartTLS, LDAPS und Hostnamenprüfung testen.
• Base-DN, Anzahl der Einträge, wichtige Gruppenmitglieder und Passwort-Binds stichprobenartig prüfen.
• Erlaubte Anwendungskonto-Aktionen und die Ablehnung anonymer Zugriffe erneut testen.
• Wiederherstellungsdauer und fehlende Daten dokumentieren und RPO sowie RTO entsprechend anpassen.

syncrepl und Hochverfügbarkeit

Das Replikationskonto muss alle Quelldaten einschließlich userPassword und sämtlicher operativer Attribute lesen können, damit die Authentifizierungsdaten identisch bleiben. Die erste oben gezeigte ACL gewährt nur dem Replikations-DN vollständigen Lesezugriff; andere Verbindungen werten über by * break die folgenden Regeln weiter aus. Dieses Konto nicht für Anwendungen wiederverwenden. Liefert das Paket syncprov als dynamisches Modul, zunächst den vorgesehenen Modulpfad prüfen und das Modul laden.

Eine Multiprovider-Konfiguration mit zwei Providern bedeutet nicht, dass beliebig gleichzeitig auf beide geschrieben werden sollte. Gegen Konflikte und Split Brain muss der Loadbalancer jeweils einen aktiven Schreibpfad auswählen. Leseverteilung, Healthchecks und Rückschaltung separat planen. serverID und syncrepl-rid müssen jeweils eindeutig sein.

syncprov-Overlay und Checkpoints

sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcOverlay=syncprov,${MDB_DN}
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 1000
EOF

Beispielstruktur für syncrepl pro Provider

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldaps://ldap01.example.com
olcServerID: 2 ldaps://ldap02.example.com

dn: olcDatabase={MDB_NUMBER}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: rid=001 provider=ldaps://ldap02.example.com bindmethod=simple binddn="uid=replicator,ou=People,dc=example,dc=com" credentials=<REPLICATION_SECRET> searchbase="dc=example,dc=com" type=refreshAndPersist retry="5 5 300 +" timeout=10 tls_reqcert=demand tls_cacert=/etc/openldap/certs/org-ca.crt
-
add: olcMultiProvider
olcMultiProvider: TRUE

Replikationskonsistenz und Failover prüfen

LDAPTLS_CACERT=/etc/openldap/certs/org-ca.crt ldapsearch -LLL -x -H ldaps://ldap01.example.com   -D 'uid=replicator,ou=People,dc=example,dc=com' -W -b 'dc=example,dc=com' -s base contextCSN

LDAPTLS_CACERT=/etc/openldap/certs/org-ca.crt ldapsearch -LLL -x -H ldaps://ldap02.example.com   -D 'uid=replicator,ou=People,dc=example,dc=com' -W -b 'dc=example,dc=com' -s base contextCSN

sudo ldapsearch -LLL -Q -Y EXTERNAL -H ldapi:///   -b cn=Monitor '(objectClass=monitorOperation)' cn monitorOpInitiated monitorOpCompleted

timedatectl status
chronyc tracking

Prüfen, ob add, modify und delete desselben Testeintrags auf der Gegenseite ankommen. Anschließend einen Provider aus dem Loadbalancer nehmen und Lesen, Schreiben sowie Wiedereingliederung testen. Abweichende contextCSN allein bedeuten nicht sofort eine Störung; Logs, ausstehende Operationen, Verbindungszustand und Konvergenzzeit gemeinsam betrachten.

Betriebskontrollen

systemctl --no-pager --full status slapd
ss -lntp | grep -E ':(389|636)\b'

sudo journalctl -u slapd --since '-30 min' --no-pager
sudo ldapsearch -LLL -Q -Y EXTERNAL -H ldapi:///   -b cn=Monitor -s base '*' '+'

df -hT /var/lib/ldap /var/log
df -i /var/lib/ldap /var/log
findmnt -T /var/lib/ldap

1. systemd-Exitcode und Zeitpunkt des ersten Fehlers prüfen.
2. Sicherstellen, dass die Listener auf 389 und 636 nur an den vorgesehenen Adressen lauschen.
3. CA-Kette, SAN, Gültigkeitsdauer und Hostnamenprüfung des Clients kontrollieren.
4. Bind-DN, Base-DN, Filter, Scope und ACL-Reihenfolge mit einer minimalen Abfrage nachvollziehen.
5. MDB-Map-Größe, Dateisystembelegung, Inodes, Checkpoints und lang laufende Abfragen prüfen.
6. syncrepl-Verbindung, serverID, rid, contextCSN und Zeitsynchronisierung prüfen.
7. Prüfsummen der jüngsten slapcat-Sicherung und Ergebnisse der isolierten Wiederherstellungsprobe prüfen.

Häufige Fehler und bessere Vorgehensweisen

Weiterführende Dokumentation

• Offizielles OpenLDAP-2.6-Administrationshandbuch
• Offizielle OpenLDAP-Anleitung zur Zugriffskontrolle
• Offizielle OpenLDAP-Replikationsanleitung
• Red Hat: SSSD als LDAP-Client mit TLS
• Linux: Speicher- und Inode-Mangel diagnostizieren
• Hochverfügbarkeit mit DRBD, Pacemaker und STONITH
• Ansible-Playbooks, Vault und rollende Bereitstellung

Zusammenfassung

Ein einzelner erfolgreicher Bind schließt den OpenLDAP-Aufbau nicht ab. cn=config- und MDB-Pfade, TLS-Hostnamenprüfung, attributbezogene ACLs, abfragegerechte Indizes, gemeinsame Konfigurations- und Datensicherung sowie isolierte Wiederherstellung müssen geprüft sein. In einer HA-Umgebung schaffen eindeutige serverID und rid, Zeitsynchronisierung und ein einzelner aktiver Schreibpfad die Grundlage für einen vorhersehbaren Authentifizierungsdienst.