LDAP in der easydb kann benutzt werden, um Teile des Benutzermanagements über ein LDAP-Verzeichnis abzuwickeln. Dabei kennt die easydb zwei Arten des LDAP-Zugriffs:
Beim Vollzugriff wird der LDAP Server genutzt, um den Benutzer zu authentifizieren und ihn einer oder mehreren easydb-Gruppen zuzuordnen. Hierbei erfolgt das Benutzermanagement nur über die easydb-Gruppen, nicht über einzelne Benutzer.
Bei dieser Betriebsart werden die Benutzer einzeln in der easydb angelegt, nur die Authentifizierung erfolgt über LDAP. Hier muss LOGIN_EASYDB_LDAPAUTH_COLUMN gesetzt werden, LOGIN_METHODS bleibt weiterhin easydb.
Die LDAP-Authentifizierung wird mittels einer erweiterten Form von URLs im Stil von RFC 2255 angegeben. Ein weitgehend ähnliches Format wird auch von apache verwendet . Abweichend von RFC 2255 können die erweiterten Attribute (ab bindname im Beispiel) aus Kompatibilitätsgründen (vor 4.0.140 der einzige Weg) auch durch Fragezeichen statt Kommata getrennt werden. Durch die Konformität müssen jetzt allerdings Kommata in den Werten (z.B. der DN bei bindname) URL-kodiert werden.
Alle Parameter die innerhalb von [ und ] stehen sind optional.
<n> Konfigurations-Identifier
Es können mehrere LDAP-Konfigurationen angegeben werden, um verschiedene Suchparameter zu ermöglichen oder um die Ausfallsicherheit zu erhöhen.
In den folgenden Fällen wird der nächste Server angefragt:
Wenn hingegen der bind fehlschlägt werden die weiteren Server nicht kontaktiert.
<proto> Protokoll über das der Ldap-Server kontaktiert werden soll.
Mögliche Werte sind ‘ldap’, ‘ldapi’, ‘ldaps’.
<host> Ldap-Server
Bei ldapi sollte hier nichts, oder der Pfad zum Socket-Verzeichnis des LDAP-Servers angegeben werden. Bei ldap und ldaps ist dies die Adresse des Servers (via IP oder via DNS).
<port> Serverport
Als Standard wird, wie vom Standard vorgegeben, 389 verwendet.
<basedn> Basisverzeichnis der Suche
Dies gibt das Verzeichnis an, unterhalb dessen im LDAP-Baum gesucht wird.
<matchAttr> Suchattribut
Gibt an, nach welchem Attribut gesucht werden soll. Standardmässig wird ‘uid’ verwendet. Wenn das Attribut leer gelassen wird, wird kein Filter erzeugt. In diesem Fall muss ein expliziter Filter konfiguriert sein!
<scope> Suchraum
Mögliche Werte sind ‘base’, ‘one’, ‘sub’. ‘sub’ ist Standard.
<filter> Suchfilter
Zusätzlich zu der Bedingung, die durch das ‘matchAttr’ generiert wird, können noch weitere Bedingungen generiert werden. Ein häufiges Beispiel etwa wäre
objectClass=posixAccount
oder ein wenig komplexer:
|(objectClass=sambaSamAccount)(objectClass=posixAccount)
Die Variable ‘user’ ist für Ersetzungen verfügbar. Dies kann zum Beispiel genutzt werden um Authentifizierung etwa entweder über den Usernamen oder über die Mailadresse zu ermöglichen.
|(uid=%(user:ldap)s)(mail=%(user:ldap)s)
Das Anhängen von ‘:ldap’ an den Variablennamen sorgt dafür dass der Name so escaped wird, dass er den Suchausdruck nicht verändern kann. So wird etwa der username ‘*’ zu ‘\52’ escaped und findet damit nicht mehr alle dn’s.
<bindname> und <cred> Authorisierungsdaten für die Suche
Wenn in ihrem Verzeichnis keine anonymen Suchen erlaubt sind, können sie diese Parameter angeben. Dadurch wird die Suche nach dem User-Account mit diesen Daten durchgeführt. Selbstverständlich wird nachfolgend noch ein bind mit dem gefundenen User und dessen Passwort durchgeführt.
Wenn diese Attribute nicht definiert sind wird für die Suche ein anonymer bind vorgenommen.
Die Werte dieser Felder müssen URL-kodiert sein, aus , wird also %2C, aus = wird %3D.
Das sieht beispielsweise so aus:
LDAP_USER_URL_1=ldap://ldap-server/dc=pfgroup,dc=de?uid?sub?objectClass=posixAccount?bindname=cn%3Dsearch%2Cdc%3Dpfgroup%2Cdc%3Dde,cred=test
<e-user-record> Authentifizierung für Abfrage des Nutzerdatensatzes (ab Version 4.0.140)
Standardmäßig user, dabei keine zusätzliche Authentifizierung durchgeführt. Mit machine wird vor dem Holen des Datensatzes der mit den bindname und cred beschriebene Nutzer authentifiziert.
Diese Variable beinflusst wie der Username zur Darstellung formatiert wird.
Als Variablen stehen alle LDAP-Attribute des gefundenen Users bereit. Formatstrings sind in einem eigenen Kapitel beschrieben.
LDAP_DISPLAYNAME_FORMAT=Ldap User: %(displayname:html)s (%(dn:html)s)
Alle LDAP-Attribute müssen klein geschrieben werden!
Es ist wichtig mittels :html escaping anzuschalten wenn das Attribut HTML enthalten und vom user geändert werden kann.
Oftmals sind im LDAP-Verzeichnis unerwünschte Zeichen enthalten. So enthält der Displayname oftmals unnötige Kommata. Mit dem folgenden Beispiel können diese entfernt werden.
LDAP_DISPLAYNAME_REGEX=/([^,]*),*(.*)/
LDAP_DISPLAYNAME_REPLACE=$1 $2
Diese Variablen bestimmen, wie sich die Systemkennung des Users zusammensetzt. Dies ist etwa für Erteilung von Rechten/Gruppenmitgliedschaften wichtig.
Die einzelnen Variablen verhalten sich äquivalent wie die LDAP_DISPLAYNAME_* Variablen.
LDAP_USER_ID_FORMAT=ldap_%(uid)s
Diese Variable ist wie LDAP_USER_URL_<n> aufgebaut. Folgende Unterschiede existieren:
Es wird immer das Gruppenmapping mit <n> genutzt, dass zu dem <n> aus LDAP_USER_URL_<n> passt.
LDAP_GROUPS_URL_1=ldap://ldap-server/ou=Groups,dc=pfgroup,dc=de??sub?(&(|(memberUid=%(uid:ldap)s)(gidNumber=%(gidnumber:ldap)s))(objectClass=groupOfNames))
In diesem Beispiel wird nach allen Gruppen gesucht, die den Nutzer entweder über memberuid referenzieren, oder die vom User über gidNumber referenziert werden. Die Bedingung ‘(objectClass=groupOfNames)’ ist hier wichtig, da sonst andere User mit der gleichen primären Gruppe gefunden werden könnten!
(Ab Version 4.0.140) Enthält der Nutzer-Datensatz mehr als einen Wert für ein Attribut, so wird für jede mögliche Kombination ein Filter erstellt und die Ergebnisse ODER-verknüpft.
Falls LDAP nur als Quelle für Gruppen genutzt wird, also nicht für die Authentifikation (z.B. mit Kerberos), dann ist nur <n>=1 verwendbar, also nur LDAP_GROUPS_URL_1.
Hieraus wird der Gruppenname, der in der easydb verwendet wird, generiert. Verhält sich wie die entsprechende Konfiguration von LDAP_DISPLAYNAME_*
LDAP_GROUP_NAME_FORMAT=ldap_group_%(cn)s
Nachdem easydb die Gruppen gelesen hat, erfolgt pro Gruppe noch eine Umsetzung in easydb-Gruppen. Dafür wird auf der Gruppen-Tabelle ein Select ausgeführt, der als WHERE-Clause LDAP_WHERE_GROUP_SQL erhält. Darin wird %g durch die jeweilige Gruppe ersetzt.
Normalerweise wird dafür eine zusätzliche Spalte (ldap_gruppe) in der Gruppentabelle genutzt.
LDAP_WHERE_GROUP_SQL=ldap_gruppe = %g
Sollten die Gruppennamen in der easydb und im LDAP identisch sein, kann natürlich auch die Spalte name verwendet werden.
Beim Mapping von mehreren LDAP-Gruppen auf eine easydb-Gruppe kann folgende Konfiguration verwendet werden (in der Spalte ldap_gruppe steht beispielsweise Gruppe Eins, Gruppe Zwei):
LDAP_WHERE_GROUP_SQL= %g = ANY(regexp_split_to_array(ldap_gruppe, ','))
Neben dem Gruppennamen könnte in der Spalte ldap_gruppe auch ein regulärer Ausdruck stehen, der auf mehrere Gruppen im LDAP zutrifft (z.B. ^.*admin$). Dann muss die Variable entsprechend angepasst werden, für MySQL beispielsweise:
LDAP_WHERE_GROUP_SQL=ldap_gruppe REGEXP %g
Es können bei dem Matching mehr als eine easydb-Gruppe gefunden werden. Dem Benutzer werden dann alle gefundenen Gruppen zugeordnet. Seit Version 4.0.259.