LDAP ACLs

UCS - Univention Corporate Server
#1

Hallo,

eine allgemeine Verständnisfrage: Warum ist ein ldapsearch bei einer LDAP-Datenbank mit vielen ACLs so viel langsamer als bei einer mit weniger ACLs?

Gut, die Antwort liegt quasi auf der Hand, ich möchte daher meine Frage leicht modifizieren:
Warum ist ein ldapsearch, also ein Lesezugriff, bei einer LDAP-Datenbank mit vielen ACLs, die eigentlich nur den Schreibzugriff regeln, so viel langsamer als bei einer mit weniger ACLs?

Ich habe hier zum Testen 3 UCS-Server zur Verfügung: 1x Master, 1x Backup, 1x Slave. Die ACLs wurden von mir nicht angefasst und müssten daher UCS-Default sein.
Folgenden Befehl habe ich testweise jeweils lokal als unpreviligierter Benutzer ausgeführt: “time ldapsearch -xLLL > /dev/null”
Ergebnis: Bei Master und Backup sind es jeweils fast 9 Sekunden, beim Slave nur ein Bruchteil einer Sekunde. Der Faktor liegt zwischen 10 und 100. Und dass es an den ACLs liegt, habe ich spaßeshalber mal getestet, indem ich diese auf dem Master deutlich gekürzt habe. (Die Hardware ist jeweils identisch)

Was mich daran aber wundert ist, dass die vielen ACLs quasi nur den Schreibzugriff regeln. Lesen darf eh jeder.
Warum sind nun Lesezugriffe langsamer? Was technisch vielleicht gut begründbar ist, ergibt für mich logisch irgendwie keinen Sinn.

Kann man die ACLs nicht irgendwie so optimieren, dass slapd bei Lesezugriffen sofort sieht, dass dies eh jeder darf und diese somit nicht “aufgehalten” werden?

(Oder ist es gar ein Fehler in unserer Konfiguration, dass sich das so auswirkt und Lesezugriffe gar nicht für Jedermann erlaubt sein sollten?)

Der Grund weshalb ich frage: Gerade auf dem Master muss das LDAP beschrieben werden können, weshalb dort die ACLs notwendig sind. Gerade dort läuft aber auch der Univention Directory Manager. Eine unglückliche Kombination. Gibt es eine einfache Möglichkeit, z.B. zusätzlich ein Slave-LDAP auf dem Master zu starten, um Zugriffe zu beschleunigen?
Ein Univention Directory Manager, der für jeden “Klick” 10 bis 20 Sekunden benötigt (es sind ja meist gleich mehrere LDAP-Anfragen dank der vielen Abstraktionsschichten im python-Backend) ist jedenfalls nicht schön, aber ab einer bestimmten Größe wohl üblich.

Des weiteren führt dies dazu, bestimmte, von vielen LDAP-Anfragen abhängige Dienste, auf jeden Fall nicht auf einen UCS Master oder Backup zu installieren.

Gruß
Michael Heide

#2

Hallo,

auch auf einem DC-Master System sind nicht alle Attribute der LDAP-Objekte für jeden Benutzer lesbar (z.B. Passwörter, Kerberos Optionen etc). Desweiteren ist es in vielen Szenarien nicht gewünscht dem Administrator Account Schreibrechte auf das komplette LDAP zu gewähren.

Würde als eine der ersten ACLs eine Regel definiert die z.B. dem Administrator das Lesen aller Objekte und Attribute erlaubt, würden die ACLs ab diesem Punkt nicht weiter durchlaufen. Dies hätte zur Folge das der Administrator über keine Schreibberechtigungen mehr verfügt.
Grundsätzlich besteht allerdings die Möglichkeit eine globale Schreibberechtigung für den Administrator zu definieren wenn dies gewünscht ist.

Wenn Sie als root auf der Kommandozeile viele LDAP-Operationen durchführen, lohnt es sich, die ldapi-Schnittstelle zu verwenden. Allen Operationen die den slapd über diese Schnittstelle erreichen, werden Schreibberechtigungen auf das komplette LDAP eingeräumt. Es existiert auch ein Eintrag in unserem Bugtracking-Sytsem der beschreibt dass das UDM-CLI dies Schnittstelle verwenden können soll:
forge.univention.org/bugzilla/s … gi?id=4233

Mit freundlichen Grüßen
Janis Meybohm

#3

Hallo,

das erklärt ein wenig, weshalb DC-Master so viel langsamer sind als Slaves. Sieht ein LDAP-Server aber wirklich nicht, ob eine Anfrage lesend oder schreibend ist? Wie ist das im LDAP-Protokoll vorgesehen? Muss OpenLDAP wirklich die kompletten ACLs abarbeiten, auch wenn die Anfrage eh nur lesend ist?

Ich meine, besser wäre es ja erstmal vorher festzustellen, ob der Zugriff lesend oder schreibend ist. Dementsprechend könnte man den Großteil der ACLs ja weglassen. Als Beispiel mal logisch betrachtet, ohne die Möglichkeiten der Implementation zu berücksichtigen, könnte man bei Lesezugriffen ja grundsätzlich die Konfiguration eines UCS Slaves verwenden und nur bei Schreibzugriffen alle ACLs eines Master auswerten.

Ist das nur in OpenLDAP so in meinen Augen grundlegend falsch implementiert oder sieht das das Protokoll in sich so vor?

Für größere Installationen mit komplexen ACLs bleibt ja dann quasi nur übrig, für Änderungen einen Master slapd mit Schreib-ACLs aufzusetzen und für Lesezugriffe einen daraufhin synchronisierten slapd mit einfacheren ACLs zu verwenden. Der Faktor >10 zwischen DC-Master und DC-Slave ist schon enorm.

Gruß
Michael Heide

#4

Hallo,

im Grunde sollte es möglich sein uid=Administrator in einer der ersten ACLs schreibenden Zugriff auf das komplette LDAP zu gewähren:

access to *
    by dn="uid=Administrator,cn=users,<LDAP-Basis> write
    by * none break

Dies hätte zur folge das Zugriffe durch den Administrator die ACLs nur bis zu dieser ACL durchlaufen werden.
Da eine solche Konfiguration bei vielen Kunden nicht gewünscht ist (beispielsweise aufgrund einer selektiven Replikation) ist diese ALC nicht standardmäßig definiert.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon