ldap.domain.tld Alle Dienste in Ihrer Zone fragen diesen Server ab, daher ist eine flexible Struktur sinnvoll und vereinfacht die Verwaltung maximal.
Wir trennen alle Dienste voneinander, diese können so alle auf derselben Maschine laufen, aber auch im Netzwerk verteilt werden. Spätere Lastverteilung ist so ohne Konfigurationsänderungen machbar.
Krei.se bietet einen rudimentären LDAP-Server für alle Subdomains. Hier die Anleitung wie man diesen exakt 1:1 selbst aufsetzt.
Vorteile eines LDAP-Servers:
Aufbau des Tutorials:
📝 Was nicht zwingend notwendig, aber gut zu wissen ist markiert der Notizblock.
Die Einrichtung ist Linux-agnostisch und funktioniert und Debian wie unter Arch, allerdings liegen die Einstellungen bei Debian in /etc/ldap, Arch /etc/openldap
🐧 Debian:
root@server:~# apt install slapd schema2ldif
root@server:/etc/ldap#🏹 Arch:
pacman -S openldap && yay -S schema2ldif
root@server:/etc/openldap#Hier wird i.d.R. ein 👑 Administrator-Passwort festgelegt, unbedingt sicher wählen und notieren. Mehr dazu in 4.
LDAP braucht für das Wissen welche Eigenschaften ein Objekt besitzen muss sogenannte Schema. Diese legen z.B. fest, dass alle Objekte des Typs Benutzer einen Eintrag für seinen Namen haben müssen.
Dieses Schema erlaubt das Anlegen verschachtelter Gruppen was ein sehr wichtiges Grundprinzip der Krei.se-Systemarchitektur abbildet.
ou=Gruppen keine GID
├── ou=Mitarbeiter GID 2000
│ ├── ou=Manager GID 2100
│ │ ├── cn=Inhaber GID 2110
│ │ ├── cn=Partner GID 2120
│ │ └── cn=Geschäftsführer GID 2150
│ ├── ou=Kundendienst GID 2500
│ │ ├── cn=HomeOffice GID 2550 <-- Beispielnutzer cn=maxmueller als member
│ │ └── cn=Kundendienstleitung GID 2560
│ └── cn=Aussendienst GID 2900
├── cn=Lieferanten GID 5000
└── cn=Gäste GID 9000Mit verschachtelten Gruppen können Sie einen Benutzer in HomeOffice eintragen - er erhält so als sekundäre Gruppen HomeOffice, Kundendienst und Mitarbeiter.
Die Benutzer selbst können Sie in LDAP in Ordner und Unterordner sortieren wie sie wollen, eindeutig muss nur die User-ID (uid maxmueller) sein. Mit der Gruppenstruktur muss diese Benutzer-Ordnung nicht übereinstimmen, Sie dient allein der besseren Lesbarkeit des Domänen-Baums.
ou=Benutzer keine GID - rein optische Sortierung
├── ou=Mitarbeiter keine GID - rein optische Sortierung
│ ├── cn=maxmueller prim. GID 2000
│ ├── cn=lieschenmueller prim. GID 2000
│ ├── cn=...
└── ou=Gäste keine GID - rein optische Sortierung
└── cn=guest prim. GID 9000Benutzer sind alle Identitäten, die sich gegen Ihren LDAP-Server authentifizieren müssen um Dienste zu nutzen. Es macht Sinn auch Dienste die keinen Login benötigen gegen einen Gast-Account zu authentifizieren, denn so filtern Sie alle Bots heraus die Anfragen stellen ohne von einer Ihrer Internetseiten o.ä. zu kommen.
📝 Die primäre Gruppen-ID eines Benutzers setzen wir immer als die GID der obersten Ebene seiner Zuordnung im Gruppen-Baum. maxmueller ist in unseren Beispielen in ou=Gruppen,ou=Kundendienst,cn=HomeOffice als member eingetragen und daher primär Mitarbeiter mit GID 2000.
Schema herunterladen und in ldif umwandeln:
root@server:/etc/ldap/schema# wget https://github.com/jtyr/rfc2307bis/raw/master/rfc2307bis.schema
root@server:/etc/ldap/schema# schema2ldif rfc2307bis.schema > rfc2307bis.ldifDas Schema ersetzt das NIS-Schema mit dem keine verschachtelten Gruppen möglich sind. Das alte NIS-Schema müssen wir daher vor dem Einspielen des neuen Schemas löschen.
(Das manuelle erstellen der delete.ldif können Sie auch überspringen und hier direkt herunterladen: https://github.com/krei-se/OLC-rfc2307bis/raw/main/delete_nis_attributes_and_objects.ldif)
root@server:/etc/ldap/schema# wget https://raw.githubusercontent.com/krei-se/OLC-rfc2307bis/refs/heads/main/delete_nis_attributes_and_objects.ldifStellen Sie für ein manuelles Erstellen zunächst sicher, dass OpenLDAP bereits läuft.
Ziehen Sie das alte Schema als LDIF aus Ihrer cn=config:
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn={2}nis,cn=schema,cn=config > delete_nis_attributes_and_objects.ldif.ldifDiese LDIF-Datei passen Sie nun mit delete-Direktiven an:
dn: cn={2}nis,cn=schema,cn=config
changetype: modify
delete: olcObjectClasses
olcObjectClasses: ...
-
delete: olcObjectAttributes
olcObjectAttributes: ...Stellen Sie sicher, dass keine leerzeilen etc. enthalten sind.
Jetzt können Sie bei laufendem Server das alte Schema löschen und das rfc2307bis.ldif einspielen:
root@server:/etc/ldap/schema# ldapmodify -Y EXTERNAL -H ldapi:/// -f delete_nis_attributes_and_objects.ldif
root@server:/etc/ldap/schema# ldapadd -Y EXTERNAL -H ldapi:/// -f rfc2307bis.ldifcn={2}nis,cn=schema,cn=config ist jetzt leer und rfc2307bis werden Sie unter cn={4},cn=schema,cn=config finden. Wenn Sie das nicht wollen können Sie den Server anhalten und die Dateien in etc/ldap/slap.d/cn=config einfach umbenennen. Generell wird abgeraten diese Dateien zu modifizierien, aber ich habe das schon zig mal so gemacht und garantiere, dass das klappt. Denn mehr als diese Dateien hat LDAP nicht als Datenbank für cn=config.
root@server:/etc/ldap/schema# systemctl stop slapd
root@server:/etc/ldap/schema# rm /etc/ldap/slapd.d/cn\=config/cn\=schema/cn\={2}nis.ldif
root@server:/etc/ldap/schema# mv /etc/ldap/slapd.d/cn\=config/cn\=schema/cn\={4}rfc2307bis.ldif /etc/ldap/slapd.d/cn\=config/cn\=schema/cn=\{2}rfc2307bis.ldif
root@server:/etc/ldap/schema# systemctl start slapdDas wars schon.
Damit wir für jeden Benutzer festlegen können unter welchen Adressen er Mails empfangen und versenden darf spielen wir noch das Postfix-Schema ein:
/etc/ldap/schema# wget https://raw.githubusercontent.com/credativ/postfix-ldap-schema/master/postfix.schema
/etc/ldap/schema# schema2ldif postfix.schema > postfix.ldif
/etc/ldap/schema# ldapadd -Y EXTERNAL -H ldapi:/// -f postfix.ldif👷👷👷 --- ab hier wird noch gebaut --- 👷👷👷
Für Dovecot brauchen wir noch Einstellungen für die maximale Postfach-Größe, etc. - hier gibt es einiges an Schemas zur Auswahl, da ich derzeit nur MailQuota nutze und evtl. noch Änderungen durchführe habe ich es mal anderen gleichgetan und ein eigenes für Dovecot erstellt:
/etc/ldap/schema# wget https://krei.se/schemas/dovecot.schema👷👷👷 --- bis hier wird noch gebaut --- 👷👷👷
Ist schon in rfc2307bis mit drin.
Das wars schon. Mail-Versand ist nicht Thema dieses Artikels.
OpenLDAP läuft mit Zertifikaten von letsencrypt sofort, da Sie auf den Domänencontroller aber nicht per Browser o.ä. zugreifen sondern immer mit Diensten oder eigenen Verwaltungstools lohnt sich die Nutzung eines eigenen CAs und von ED25519-Kurven. Das ist nicht Thema des Artikels, wir setzen das Vorliegen von Schlüsseln hier voraus. Wie Sie Schlüssel von letsencrypt automatisch verteilen können Sie hier nachlesen.
In /etc/ldap werden auch für den Client-Zugriff Konfigurationen in der Datei ldap.conf gespeichert und manchmal liegt dort noch die Datei slapd.conf rum. Die letztere brauchen Sie nicht. slapd, der Dienst für OpenLDAP speichert alle Einstelungen in der cn=config Datenbank. Wichtig ist erstmal nur zu wissen, dass beim Start des Dienstes festgelegt wird auf welchen URLs/Ports er läuft. ldap:/// ist unverschlüsselt, ldapi:/// erlaubt Zugriff von der lokalen Konsole aus und ldaps:/// ist SSL-verschlüsselt.
Unter Arch liegt diese Einstellung etwas versteckt.
/etc/systemd/system/multi-user.target.wants/slapd.service verrät uns, dass standardmäßig ldap:/// und ldapi:/// aktiv ist.
Zudem wird /etc/conf.d/slapd eingebunden. Stellen Sie daher sicher, dass Sie URLs/Ports so einstellen und ggf. deaktivieren, dass später nur noch Zugriff per SSL ldaps:/// und lokal mit ldapi:/// sowie ldap://localhost/ möglich ist.
In Debian ist der Start von OpenLDAP in /etc/inid.d/slapd geregelt und diese bindet nur /etc/default/slapd ein.
Stellen Sie in beiden Fällen sicher, dass bereits vor dem Installieren der SSL-Schlüssel ldaps:/// aktiviert ist. Wir nutzen kein StartTLS, OpenLDAP läuft mit ldaps:/// auf Port 636 und erwartet zwingend zu Verbindungsaufbau SSL.
Sie erstellen nun eine LDIF-Datei enablessl.ldif in der der Pfad zu den Schlüsseln steckt:
dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca.domain.tld.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap.domain.tld.key
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap.domain.tld.crt📝 Den olcTLSCACertificateFile Eintrag benötigen Sie nur, wenn Sie eine 🏰 eigene CA verwenden, die noch nicht systemweit hinterlegt ist. Wie das geht können Sie hier nachlesen. Ansonsten genügen die beiden letzten Zeilen. Das - trennt übrigens im LDIF, dass Sie mehrere Einträge unter demselben changetype machen wollen.
OpenLDAP wird die Einträge nur annehmen, wenn die Zugriffsrechte exakt passen was ohne hilfreiche Fehlermeldung sehr frustrierend enden kann, denn auch das chown muss exakt stimmen. Prüfen Sie genau unter welchem Benutzer OpenLDAP läuft, in Arch ist das ldap/ldap, Debian nutzt openldap/openldap. Dienste die den Server-Schlüssel lesen müssen können Sie daher:
usermod -a -G ssl-cert openldap) und dieser Gruppe 750 Rechte in /etc/ssl/private einräumen ODERSollte so aussehen:
root@server:/etc/ssl# groupadd ssl-cert
root@server:/etc/ssl# usermod -a -G ssl-cert openldap
root@server:/etc/ssl# ls -l
drwxr-xr-x 2 root root 16384 Jul 14 11:25 certs
-rw-r--r-- 1 root root 12411 Jun 6 21:55 openssl.cnf
drwx------ 2 root root 4096 Jul 14 11:02 private
root@server:/etc/ssl# chown root:ssl-cert private
root@server:/etc/ssl# chmod 750 private
root@server:/etc/ssl# ls -l
total 36
drwxr-xr-x 2 root root 16384 Jul 14 11:25 certs
-rw-r--r-- 1 root root 12411 Jun 6 21:55 openssl.cnf
drwxr-x--- 2 root ssl-cert 4096 Jul 14 11:02 privateDas Server-Zertifikat benötigt ZWINGEND chmod 644, der Schlüssel MUSS chmod 640 haben. Andernfalls wird OpenLDAP die Einträge nicht übernehmen!
📝 Letsencrypt gewährt Zugriffe auf Schlüssel standardmäßig nur für root und erstellt neue Schlüssel auch nur für root, daher macht Sinn diese als renewal-hook zu verteilen und per chown lesbar zu machen (Siehe Blog-Eintrag für letsencrypt)
Ob LDAP den Pfad und Schlüssel lesen kann können Sie bereits vor Einspielen und Neustart des Servers prüfen:
sudo -u openldap file /etc/ssl/private/ldap.domain.tld.key
/etc/ssl/private/ldap.domain.tld.key: ASCII text
sudo -u openldap file /etc/ssl/certs/ldap.domain.tld.crt
/etc/ssl/private/ldap.domain.tld.key: ASCII textDies prüft zwar nicht, ob die chown Rechte exakt passen ist aber hilfreich um den gesamten Pfad zu prüfen.
Alles doppelt und dreifach geprüft - auch das Zertifikat und nicht nur den Schlüssel? Dann spielen Sie nach aktivieren von ldaps:/// und Neustart des Dienstes das LDIF ein:
ldapadd -Y EXTERNAL -H ldapi:/// -f enablessl.ldifWenn hier keine Fehlermeldung kommt sollte der Zugriff der ldaps:/// nun funktionieren und Sie haben sich mit diesem langweiligen Blog-Post stundenlange Fehlersuche und spätere Restrukturierungen erspart.
Am nervigsten für Neulinge ist zu verstehen, wozu man cn=admin, olcRootDN oder olcRootPW braucht und was die Einträge bewirken wenn der olcRootDN als User existiert. Debian hat z.B. cn=admin,dc=domain,dc=tld User und einen cn=admin,cn=config User, legt aber diesen Nutzer nicht in der dc=domain,dc=tld Datenbank an.
Spätestens ab mehreren Datenbanken macht es Sinn zentral das RootPW über einen Verwalter-DN nur in dessen BaseDN Datenbank zu setzen und diesen als olcRootDN in den einzelnen Datenbanken zu hinterlegen. Dann kann man immernoch für cn=config als Fallback einen oldRootDN mit Passwort setzen der nicht in einer dieser Datenbanken als Verwalter auftaucht und nur für Admin-Aufgaben Datenbank-übergreifend gebraucht wird. Das ist dann cn=admin,cn=config und hat sein Passwort nur als olcRootPW hinterlegt.
Sie wollen es sicherlich zwar möglichst einfach, aber das Minimum kann unterschiedlich sein.
Wichtig ist zu verstehen, dass wir für die Datenbank, also sowohl cn=config als auch jede vom Server bereitgestellte BaseDN (das können mehrere sein) unterschiedliche Root-User festlegen können.
Denn das erlaubt OpenLDAP zwar beim Verwalten, startet dann aber erstmal nicht mehr :D
olcRootDN legt für die Datenbanken fest welcher User die maximalen Zugriffsrechte hat. Das KANN ein Eintrag in einer BaseDN sein, cn=Manager,dc=domain,dc=tld ist völlig legitim. MUSS es aber nicht.
olcRootPW ist ein Fallback für das Root-Passwort. Sie können diesen Eintrag setzen, er ist z.B. auch noch valide falls Ihre Benutzerdatenbank gerade mal nicht will. Sie müssen aber hier nichts setzen (Danger-Zone) und können das SSHA-Passwort eines gültigen DN in Ihrer Benutzerdatenbank nutzen. Die ganz Mutigen machen das auch für cn=config, denn wenn für den RootDN von cn=config kein passwort gefunden wird und auch kein olcRootPW sind Sie zumindest remote erstmal aus der Server-Konfiguration ausgesperrt.
Die ersten beiden Beispiele betrachten nur cn=config:
Beispiel: olcRootDN ist cn=admin,cn=config und hat ein olcRootPW. Es ist nur dieser Login gültig, da cn=config nirgendwo sonst Benutzerpasswörter speichert.
cn=config:
olcDatabase={0}config,cn=config
olcRootDN: cn=admin,cn=config
olcRootPW: supersecurepassword
dc=example,dc=com:
...Beispiel 2: olcRootDN ist cn=admin,dc=domain,dc=tld und hat kein olcRootPW. Es muss die Datenbank für dc=domain,dc=tld aktiv sein und dort unbedingt ein cn=admin Eintrag existieren.
cn=config:
olcDatabase={0}config,cn=config
olcRootDN: cn=admin,dc=domain,dc=tld
(olcRootPW: darf man nicht setzen, Fehler denn olcRootDN muss unter dem selben cn=config suffix sein)
dc=domain,dc=tld:
cn=admin:
userPassword: somewhatsecurepasswordBeispiel 3: sowohl userPassword als auch olcRootPW vergeben (geht eigentlich nur in dc=domain,dc=tld)
Das gilt nur für Datenbanken mit Usern. Hier ist möglich im User-Eintrag sowohl das userPassword zu vergeben als auch diesen User noch mit olcRootPW zu versehen - jetzt kann man sich mit beiden anmelden. Das ist eigentlich nur hilfreich wenn es unbedingt ein root aus der Userdatenbank sein muss und diese u.U. auch mal ausfällt:
cn=config:
olcDatabase={0}config,cn=config: (hier unwichtig)
olcRootDN: cn=admin,dc=domain,dc=tld
olcDatabase={1}mdb,cn=config: (das ist die basedn datenbank)
olcRootDN: cn=admin,dc=domain,dc=tld
olcRootPW: alsosomehwatsecurepassword < +
dc=domain,dc=tld: \ beides valide
cn=admin: / Logins
userPassword: somewhatsecurepassword < +olcDatabase={-1}frontend,cn=config
olcDatabase={0}config,cn=config
olcDatabase={1}mdb,cn=config
dc=domain,dc=tld - hier macht ein olcRootDN aus der Benutzerdatenbank ohne olcRootPW Sinn, denn notfalls kommen Sie immer über cn=config wieder an diese Einstellung ran. z.B. olcRootDN:cn=Verwalter,dc=domain,dc=tld OHNE olcRootPW, aber in dc=domain,dc=tld MIT SSHA-UserpasswortSie können mehrere BaseDNs von OpenLDAP servieren lassen indem Sie eine neue olcDatabase=mdb erstellen. Wichtig: Muss ein anderes olcDbDirectory besitzen, z.B. /var/lib/ldap/domain.tld.
So aufgeteilt können Sie mit cn=admin,cn=config auch remote neue Domains hinzufügen aber müssen für die jeweiligen Admins nur den für eine Domain notwendigen cn=Verwalter aushändigen.
📝 In einer neuen Datenbank setzen Sie den BaseDN in der Root DSE mittels "New Context Entry"
📝 Mit mehreren Datenbanken erhalten alle Clienten über Zugriff auf namingContexts Wissen über alle anderen BaseDNs. Wer das nicht will kann in olcDatabase{-1}frontend folgende olcAccess-Regeln einfügen um nur selektiv namingContexts anzuzeigen:
{1}to dn.exact="" attrs=namingContexts val/distinguishedNameMatch="dc=example,dc=com" by dn.subtree="dc=example,dc=com" read
{2}to dn.exact="" attrs=namingContexts val/distinguishedNameMatch="dc=example,dc=net" by dn.subtree="dc=example,dc=net" read Das fängt Anfragen zur RootDSE ab (dn.exact="") für das Attribut namingContexts mit dem bestimmten Wert für die Domain und zeigt es nur für Logins unter dieser Domain/BaseDN an.
Wer hier schon überlegt oh mann mehrere Datenbanken, Rechte, geht das nicht einfacher?
NEIN! Ok nun es geht schon, aber am besten mit o=Organisation statt dc
o=SuperCorp
dc=supercorp,dc=com
...
dc=supercorp,dc=net
...
ou=users
cn=maxmegamanHier können Sie also Domains und Nutzer unterschiedlich gruppieren, natürlich super sauber und kann immer wachsen.
d.h. ob ein Nutzer bei Ihnen jetzt in der Zweigstelle arbeitet @megacorp.de oder in die Zentral wechselt @supercorp.de ist völlig egal, er bleibt immer cn=maxmegaman,cn=users,o=SuperCorp
Aber Debian lässt bei der Installation leider nur zu dc=supercorp,dc=com zu erstellen. Das umgeht man mit:
add_o_basedn.ldif:
dn: o=SuperCorp
objectClass: top
objectClass: organization
o: SuperCorpmit ldapadd einspielen.
Den können Sie jetzt in cn=config als basedn konfigurieren:
olcDatabase={1}mdb,cn=config:
olcSuffix: o=SuperCorpslappasswd generiert SSHA-Passwörter, das brauchen Sie im LDIF.
Folgendes LDIF nutzen:
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=admin,cn=config
-
replace: olcRootPW
olcRootPW: {SSHA}xxxxxxxxxxxxxxxxxxxxxEinspielen mit:
ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ldap/allowcnadmincnconfig.ldifJetzt können Sie auch mit Apache Directory Studio, etc. eine Verbindung zu cn=config nutzen. Den BaseDN dort ignorieren / nicht fetchen und explizit cn=config angeben.
Mit Debian Trixie ist das endlich mitkompiliert, man kann also einfach das modul laden:
addargon2.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: argon2Passwörter dafür erstellt man mit:
slappasswd -o module-load=argon2 -h '{ARGON2}'hier gibt es noch als Optionen:
Stellen Sie sich vor Sie kommen heim oder in IRGENDEIN HAUS das sie noch nicht kennen und hängen Ihre Jacke an die Garderobe. Keinen Wimpernschlag später ist die Jacke weg. Wohin? Da müssen Sie erst fragen! Wen? Tja das steht nicht an der Garderobe, da müssen Sie erstmal rumgucken. Und wenn Sie endlich den Verantwortlichen gefunden haben (wenn Sie Glück haben ist der noch nicht entlassen) dann sagt der mit voller Überzeugung: Na die Jacke hängt jetzt im Kleiderschrank, da wo sie hingehört. Ausserdem ist die Jacke gewaschen und magentafarben getönt, das ist Firmenvorschrift und läuft ganz automatisch - toll oder?
Da werden Sie irgendwann wahnsinnig. Wenn da eine Garderobe ist (Zweig existiert) an die ich meine Jacke hängen kann (Schema lässt das zu) und ich kein Access Denied sehe (ich habe das Recht dort eine Jacke hinzuhängen) DANN LASS DIE JACKE UNVERÄNDERT DA HÄNGEN. Welche Werte mein Eintrag hat (Farbe der Jacke) ist völlig irrelevant und diese Werte auch noch zu ändern (umfärben weil Vorschrift) ist Rezept für frustrierte Mitarbeiter.
LDAP ist ein Verzeichnisdienst und ermöglicht Authentifizierung. Die biegen wir später noch um, dann fragt LDAP zum Authentifizieren bei Kerberos nach. Denn das ist Aufgabe von Kerberos!
Mehr macht LDAP nicht. Daten und Logik sind 2 verschiedene Dinge, ein memberOf Overlay würde jetzt ohnehin keine verschachtelten Gruppen beachten, Sie also nicht zu Parent-Gruppen hinzufügen.
Beispiel:
Gruppe 4000 Kundendienst
+ Gruppe 4010 Callcenter
+ Gruppe 4020 SchlichtungWenn Sie jetzt in Gruppe Callcenter drin sind erhalten Sie unter Linux mit groups und rfc2307bis bereits beide GIDs 4010 und 4000 was auch Sinn macht - LDAP gibt memberOf aber nur für 4010.
Da hakt es also schon, aber das zugrundeliegende Problem ist einer Datenbank (nichts anderes ist LDAP) noch Logik mitzugeben die dann magisch agiert. Schon hier weiss man als Admin nicht ob man jemanden aus einer Gruppe entfernt indem man dieses memberOf Attribut entfernt oder member in der Gruppe - denn das sind beides einfach Einträge.
Refint dient dazu neben der Struktur die das Schema vorgibt die Werte von Attributen zu kontrollieren - auch das KANN man zwar in einer Datenbank machen, aber es vermischt wieder die Zuständigkeiten.
Was auf keinen Fall in einer Datenbank etwas verloren hat ist jegliche LOGIK anzuwenden - das ist Sache Ihrer Software die LDAP als Datenquelle nutzt.
Wenn ich als Programmierer also sehen kann dieser LDAP-Server nutzt das Schema xy dann weiss ich wo welche Daten liegen - aber man wird maximal kirre wenn die Datenbank dann automatisch anfängt Einträge zu ändern, anzulegen oder mich zu korrigieren.
Deshalb bauen wir weder Logik noch Constraints in LDAP ein.
Das Thema olcAccess behandeln wir ausführlicher in OpenLDAP-olcAccess