🌳LDAP-Grundlagen

Ein LDAP-Verzeichnis ist ein Baum. Jeder Knoten ist ein Eintrag mit einem eindeutigen Namen, dem Distinguished Name (DN), und einer Menge von Attributen. Welche Attribute ein Eintrag haben muss oder darf, bestimmen seine Objektklassen.

🗂️Der Verzeichnisbaum (DIT)

Beispieldaten dc=example,dc=org. Wähle einen Eintrag: rechts siehst du DN, Objektklassen und jedes Attribut mit seiner Rolle im Schema.

Directory Information Tree

Klick auf › klappt auf, Klick auf den Namen zeigt den Eintrag.

Distinguished Name – vom Blatt zur Wurzel

,,,

Grün = RDN (Name unter dem Elternteil), blau = Vorfahren. Zusammen ergeben sie den DN. Klick auf einen Vorfahren springt dorthin.

top abstractperson structuralorganizationalPerson structuralinetOrgPerson strukturell (unterste)posixAccount auxiliary

Attribut	Wert(e)	Rolle
objectClass	top person organizationalPerson inetOrgPerson posixAccount	MUST · top
uidRDN	anna.schmidt	MUST · posixAccount
cn	Anna Schmidt	MUST · person
sn	Schmidt	MUST · person
givenName	Anna	MAY · inetOrgPerson
ou	Vertrieb	MAY · organizationalPerson
mail	anna.schmidt@example.org	MAY · inetOrgPerson
title	Vertriebsleiterin	MAY · organizationalPerson
telephoneNumber	+49 30 23125 101	MAY · person
employeeNumber	1001	MAY · inetOrgPersonSINGLE-VALUE
userPassword	{SSHA}aQRixUDxLtbZ/TGd+murQf+Om0xKqqeV	MAY · person
uidNumber	10001	MUST · posixAccountSINGLE-VALUE
gidNumber	10000	MUST · posixAccountSINGLE-VALUE
homeDirectory	/home/anna.schmidt	MUST · posixAccountSINGLE-VALUE
loginShell	/bin/bash	MAY · posixAccountSINGLE-VALUE

Operationsattribute zeigen (die liefert der Server nur auf Anfrage, z. B. ldapsearch … "+")

📚 Quellen: RFC 4512 – LDAP: Directory Information Models · RFC 4519 – LDAP: Schema for User Applications · RFC 2798 – Definition of the inetOrgPerson Object Class · RFC 2307 – An Approach for Using LDAP as a Network Information Service

✂️DN-Zerleger

Ein DN wird von links (Eintrag) nach rechts (Wurzel) gelesen. Jeder durch Komma getrennte Teil ist ein RDN aus Attributtyp = Wert. Sonderzeichen im Wert werden escaped.

DN eingeben

streng nach RFC 4514 (keine Leerzeichen um Trenner)

cn=Schulz\,␣Frank,ou=people,dc=example,dc=org

AttributtypWertEscape \,Hex-Escape \2C#BER-WertRDN-Trenner ,mehrwertiger RDN +ignoriertes Leerzeichen

Ebene	RDN (roh)	Typ	Wert (entschlüsselt)
Eintrag (RDN)	cn=Schulz\, Frank	cn	„Schulz, Frank“
Vorfahre 1	ou=people	ou	„people“
Vorfahre 2	dc=example	dc	„example“
Wurzel	dc=org	dc	„org“

Normalform zum Vergleichen (Kleinschreibung, Leerzeichen zusammengefasst): cn=schulz\, frank,ou=people,dc=example,dc=org

🧯 Wert escapen (RFC 4514 §2.4)

Mit Backslash geschützt werden , + " \ < > ;, ein Leerzeichen oder # am Anfang, ein Leerzeichen am Ende und NUL. Statt \, ist auch die Hex-Form \2C erlaubt – OpenLDAP gibt Kommas so aus.

Rohwert

Als RDN

cn=\ Müller\, Anna #1\

Merke: Ein DN ist eine Zeichenkette mit Grammatik – beim Zusammenbauen aus Benutzereingaben (Skripte, Web-Apps) immer escapen, sonst entstehen falsche Einträge oder Injection-Lücken. Für Filter gelten andere Regeln (siehe Filter-Labor).

📚 Quellen: RFC 4514 – LDAP: String Representation of Distinguished Names

🧱Einträge, Attribute, Objektklassen

Eintrag  uid=anna.schmidt,ou=people,dc=example,dc=org
│
├─ objectClass: top                  ← ABSTRACT (Wurzel)
├─ objectClass: person               ← STRUCTURAL
├─ objectClass: organizationalPerson ← STRUCTURAL
├─ objectClass: inetOrgPerson        ← STRUCTURAL (unterste)
├─ objectClass: posixAccount         ← AUXILIARY
│
├─ uid:  anna.schmidt                ← RDN-Attribut
├─ cn:   Anna Schmidt                ← MUST (person)
├─ sn:   Schmidt                     ← MUST (person)
├─ mail: anna.schmidt@example.org    ← MAY (inetOrgPerson)
└─ uidNumber: 10001                  ← MUST (posixAccount)

Attribut = Typ + ein oder mehrere Werte. Der Typ legt Syntax (z. B. Directory String, Integer) und Vergleichsregeln fest. Namen sind nicht case-sensitiv: cn und commonName sind derselbe Typ.

Objektklassen gibt es in drei Arten: ABSTRACT (nur zum Erben, z. B. top), STRUCTURAL (genau eine Kette pro Eintrag – sie sagt, was der Eintrag ist) und AUXILIARY (Zusatzattribute, beliebig viele, z. B. posixAccount).

Operationsattribute wie createTimestamp oder entryUUID pflegt der Server selbst. Sie kommen nur, wenn man sie ausdrücklich anfordert (Attributliste+).

✅ Namenskonvention

Personen liegen meist unter ou=people mit uid als RDN – der ändert sich seltener als ein Name. Ein RDN mit cn wie „Schulz, Frank“ braucht Escaping und ändert sich bei Heirat.

📚 Quellen: RFC 4512 – LDAP: Directory Information Models · RFC 4519 – LDAP: Schema for User Applications