LDAP: Protokoll, Datenmodell und Verzeichnisbetrieb

LDAP ist die gemeinsame Sprache, mit der Anwendungen auf Verzeichnisdienste zugreifen. Ein Client kann damit benannte Einträge suchen, Attribute lesen oder ändern und sich gegenüber dem Verzeichnis authentisieren. Das Protokoll legt Nachrichten, Operationen und Fehlercodes fest. Wie ein Server seine Daten speichert, repliziert oder gegen Ausfälle schützt, bleibt dagegen Sache der jeweiligen Implementierung. Active Directory Domain Services, OpenLDAP und 389 Directory Server sprechen daher LDAP, ohne intern dieselbe Plattform zu sein (RFC 4510, Abschnitte 1 und 2, RFC 4511, Abschnitt 3).

Diese Trennung ist im Messaging-Betrieb entscheidend. Ein Gateway kann vor der SMTP-Annahme prüfen, ob ein Empfänger existiert, Gruppen für eine Policy auflösen oder einen Administrator anmelden. Fällt diese Abfrage aus oder liefert sie veraltete Daten, ist nicht bloss «LDAP gestört»: Je nach Integration werden Nachrichten abgewiesen, Regeln falsch angewendet oder Anmeldungen blockiert. Der Administrator muss deshalb wissen, an welcher Stelle der Weg vom DNS-Namen bis zum gelesenen Attribut unterbrochen ist.

Die Erklärung folgt diesem Weg. Zuerst findet der Client einen Server und baut eine geschützte Sitzung auf. Danach authentisiert er sich, stellt eine Suche und interpretiert die Antworten. Erst wenn dieser normale Ablauf klar ist, lassen sich Schema, Active-Directory-Besonderheiten, Replikation, Skalierung und Wiederherstellung sinnvoll einordnen.

Protokollstack und Sitzungsmodell

Bevor eine Anwendung suchen kann, braucht sie ein konkretes Dienstziel. In Active-Directory-Umgebungen liefern DNS-SRV-Records mögliche Domain Controller oder Global Catalogs; andere Produkte verwenden statische FQDNs, eigene Service-Discovery oder einen Load Balancer. Diese Auswahl bestimmt nicht nur die IP-Adresse, sondern auch Standort, Serverrolle und den Namen, gegen den das Zertifikat geprüft wird. Ein Porttest gegen irgendeinen erreichbaren Server beantwortet deshalb noch nicht, ob die Anwendung ihr vorgesehenes Ziel erreicht.

Auf dem gewählten Ziel baut LDAP eine TCP-Verbindung auf. Port 389 beginnt als LDAP und kann mit der StartTLS Extended Operation zu einer geschützten Sitzung wechseln. Port 636 ist bei IANA als ldaps registriert und wird unter anderem von Active Directory für unmittelbar beginnendes TLS verwendet. In beiden Fällen muss der Client Zertifikatskette und Servernamen prüfen; «verschlüsselt» und «mit dem richtigen Server verbunden» sind zwei verschiedene Nachweise (RFC 4511, Abschnitte 4.14 und 5, IANA Service Name Registry, MS-ADTS, Using SSL/TLS).

Innerhalb dieser Verbindung überträgt LDAP keine lesbaren Befehlszeilen wie SMTP. Die Nachrichten sind als ASN.1-Strukturen beschrieben und mit Basic Encoding Rules, BER, codiert. Jede LDAPMessage trägt eine messageID, genau eine Operation und optional Controls. Über die Message-ID kann eine langlebige Verbindung mehrere laufende Operationen auseinanderhalten; deren Antworten müssen nicht in Anfragereihenfolge eintreffen. Ein erfolgreicher TCP-Handshake sagt somit nichts über BER-Decodierung, Bind oder eine vollständig abgeschlossene Suche aus (RFC 4511, Abschnitte 3.1, 4.1.1 und 5.1).

Für Änderungen gilt eine wichtige Grenze: Eine einzelne LDAP-Operation ist in ihrem Umfang atomar, mehrere Einträge bilden aber keine gemeinsame Kernprotokoll-Transaktion. RFC 5805 beschreibt eine experimentelle Transaktionserweiterung, deren Unterstützung der Client am Root DSE erkennen muss. Selbst dort bleibt zu prüfen, wie Replikate die Änderung sehen. Provisionierungsprozesse brauchen deshalb eigene Regeln für Wiederholung, Teilfehler und Abgleich statt eine stillschweigend angenommene Datenbanktransaktion (RFC 4511, Abschnitt 3, RFC 5805, Abschnitte 1 und 3).

Datenmodell: DIT, Entry, Attribut und Schema

Nach dem Sitzungsaufbau muss der Client benennen können, wo und wonach er sucht. LDAP organisiert Verzeichnisdaten dafür als Directory Information Tree, kurz DIT. Jeder Entry hat einen eindeutigen Distinguished Name und Attribute. Das Schema beschreibt, welche Attribute existieren, wie ihre Werte verglichen werden und welche Object Classes sie verlangen oder erlauben. Ohne dieses Modell bleiben Suchbasis, Filter und Resultate bloss Zeichenketten ohne verlässliche Bedeutung (RFC 4512, Abschnitte 2 und 3, RFC 4511, Abschnitt 4.1.7).

Der Distinguished Name bildet den Pfad eines Eintrags im Baum. Bei cn=Mail Gateway,ou=Services,dc=example,dc=ch bezeichnet cn=Mail Gateway den lokalen Relative Distinguished Name; die folgenden RDNs führen über den Container bis zur Namenswurzel. Da RDNs mehrwertig sein können und Zeichen wie Komma, Plus oder Backslash escaped werden, darf Software einen DN nicht durch simples Aufteilen an Kommas verarbeiten. Sie benötigt einen RFC-4514-konformen Parser (RFC 4512, Abschnitt 2.3, RFC 4514, Abschnitte 2 und 3).

dn: cn=Mail Gateway,ou=Services,dc=example,dc=ch
objectClass: top
objectClass: person
objectClass: organizationalPerson
cn: Mail Gateway
sn: Gateway
mail: mail-gateway@example.ch

Für Exporte und Importe gibt es mit LDIF eine standardisierte Textdarstellung. LDIF bildet Entries oder Änderungsdatensätze ab, ist jedoch nicht das Wireformat der laufenden LDAP-Sitzung. Zeilenfaltung, Base64-Werte und Change Records folgen eigenen Regeln. Vor allem enthält ein Export nur, was der Server und die Berechtigungen sichtbar machen; operative Attribute, ACLs oder Backendzustand können fehlen. Ein LDIF-Dump ist daher ein Datenauszug, aber nicht automatisch ein wiederherstellbares Serverbackup (RFC 2849, Abschnitte 2 und 4).

Die Bedeutung eines Attributwerts kommt erst aus dem Schema. Eine Matching Rule wie caseIgnoreMatch, integerMatch oder ein DN-Vergleich entscheidet, ob zwei Werte gleich sind und welche Filter darauf funktionieren. Auf dem Wire erscheinen Werte zunächst als Octet Strings; Syntax und Attributtyp liefern ihre Interpretation. Eigene Schemaelemente brauchen deshalb dauerhaft eindeutige OIDs, definierte Syntaxen und Matching Rules sowie einen Rollout, der Server und alle abhängigen Clients gemeinsam berücksichtigt (RFC 4512, Abschnitt 4, RFC 4517, RFC 4520).

Operationen und Zustandswechsel

Mit Transport, Namen und Schema steht das Grundgerüst; nun beginnt der eigentliche Protokolldialog. Der erste entscheidende Zustandswechsel ist gewöhnlich Bind. Er legt fest, unter welcher Identität und mit welchen daraus abgeleiteten Rechten die folgenden Operationen laufen. Ein erneuter Bind ersetzt diesen Zustand. Solange der Server einen Bind verarbeitet, darf der Client keine anderen Operationen auf derselben Verbindung starten (RFC 4511, Abschnitte 3.1 und 4.2).

Nach erfolgreichem Bind kann der Client lesen oder schreiben. Eine Suche liefert nicht eine einzige grosse Antwort, sondern null oder mehrere SearchResultEntry-Nachrichten, eventuell References und zum Abschluss genau ein SearchResultDone. Erst dieses Abschlussresultat zeigt, ob die Sequenz vollständig war. Modify, Add, Delete und ModifyDN ändern Einträge; Compare prüft einen Attributwert nach dessen Matching Rule, ohne einen normalen Suchtreffer zurückzugeben (RFC 4511, Abschnitte 4.5 bis 4.9).

Auch das Sitzungsende hat eine klare Semantik. Unbind ist eine einseitige Aufforderung zum Schliessen und besitzt keine Antwort. Abandon bittet den Server, eine bestimmte Operation abzubrechen, garantiert diesen Abbruch aber nicht. Reisst stattdessen TCP ab, verschwinden alle laufenden Operationen. Bei einer Schreiboperation kann der Client dann nicht sicher wissen, ob die Änderung vor oder nach dem Verbindungsverlust wirksam wurde; ein Retry braucht daher zuerst einen Zustandsabgleich statt blindes Wiederholen (RFC 4511, Abschnitte 4.3 und 4.11).

Controls und Extended Operations ergänzen diesen Ablauf, ohne eine neue LDAP-Version einzuführen. Jedes Control hat eine OID, eine Criticality und optional einen BER-codierten Wert. Markiert ein Client ein unbekanntes oder nicht ausführbares Control als kritisch, muss die Operation mit unavailableCriticalExtension scheitern; andernfalls darf der Server es ignorieren. Vor Paging, Sync oder einer Herstellerfunktion liest ein sauberer Client deshalb am Root DSE unter anderem supportedControl, supportedExtension, supportedFeatures, supportedLDAPVersion und supportedSASLMechanisms (RFC 4511, Abschnitt 4.1.11, RFC 4512, Abschnitt 5.1).

Bind, SASL und TLS-Vertrauensgrenzen

Der Bind entscheidet, wem der Server die nächste Suche zurechnet. Beim Simple Bind sind drei Fälle auseinanderzuhalten: Leerer DN und leeres Passwort ergeben anonymen Zugriff. Ein nicht leerer DN mit leerem Passwort ist ein unauthenticated Bind und bestätigt die genannte Identität ausdrücklich nicht, obwohl der Server success liefern kann. Erst ein nicht leerer DN mit nicht leerem Passwort bildet die normale Name/Password-Authentisierung. Clients sollten leere Passwörter daher schon vor dem Request ablehnen; Server sollten unauthenticated Binds nicht versehentlich freigeben (RFC 4513, Abschnitte 5.1.1 bis 5.1.3 und 6.3.1).

Bei dieser Passwortauthentisierung kennt der Server das präsentierte Geheimnis. Der Transport muss deshalb nicht nur verschlüsselt, sondern auch authentisiert sein. Dazu gehören eine gültige Zertifikatskette und die Prüfung, ob der konfigurierte DNS-Name im Zertifikat steht. Wer jedes Zertifikat akzeptiert oder eine IP-Adresse verwendet, kann einen verschlüsselten Kanal zum falschen Gegenüber aufbauen. Die gleiche Prüfung gilt für StartTLS und für LDAP mit sofortigem TLS (RFC 4513, Abschnitte 3.1 und 5.1.3, RFC 9525, Abschnitte 2 und 4, TLS).

SASL erlaubt statt eines blossen Passwort-Bind unterschiedliche Authentisierungsmechanismen und kann zusätzlich einen Schutz für nachfolgende LDAP-Nachrichten aushandeln. In Active Directory sind insbesondere Negotiate, Kerberos und NTLM anzutreffen. LDAP Signing schützt dort die Integrität bestimmter SASL-Sitzungen; Channel Binding verknüpft die Authentisierung mit der darunterliegenden TLS-Verbindung. TLS, Signing und Channel Binding lösen somit verwandte, aber nicht identische Probleme. Ein Test muss den wirklichen Bind-Typ des Produkts abbilden (RFC 4513, Abschnitt 5.2, Microsoft: LDAP signing, MS-ADTS, Channel Binding).

Für die Einführung strengerer AD-Richtlinien genügt deshalb kein Blick auf die Windows-Version. Neue AD-DS-Bereitstellungen auf Windows Server 2025 verlangen LDAP Signing standardmässig, während Upgrades bestehende Einstellungen übernehmen. Microsoft nennt die Directory-Service-Events 2886 bis 2889 für Signing sowie 3039 bis 3041 für Channel Binding. Diese Auditdaten zeigen, welche Clients, Ports und Bind-Verfahren tatsächlich betroffen wären; erst danach lässt sich die Durchsetzung auf belastbarer Datenbasis planen (Microsoft: LDAP signing, Default Security Behavior und Event Monitoring, Microsoft: LDAP session security after ADV190023).

Search: Basis, Scope, Filter und Attributprojektion

Nach sicherem Bind folgt die Operation, an der die meisten Integrationen hängen: Search. Der Request benennt eine Base DN, den Scope, die Aliasbehandlung, eigene Size- und Time-Limits, einen Filter und die gewünschten Attribute. baseObject liest nur den Basiseintrag, singleLevel dessen direkte Kinder und wholeSubtree den gesamten Unterbaum einschliesslich Basis. Der Server darf strengere Limits setzen. Null Treffer bei success sind eine gültige Antwort; noSuchObject bedeutet dagegen, dass die Suchbasis fehlt oder für diese Identität nicht sichtbar ist (RFC 4511, Abschnitte 4.5.1 und 4.5.2).

Der Filter beschreibt nicht freie SQL-Logik, sondern einen Baum in Präfixnotation. (&(objectClass=person)(mail=*@example.ch)) verbindet beispielsweise einen Equality- mit einem Substring-Ausdruck. | steht für OR, ! für NOT, =* für Presence und := für ein Extensible Match. Ob ein Vergleich Gross-/Kleinschreibung, Zahlenordnung oder DN-Semantik verwendet, entscheidet die Matching Rule des jeweiligen Attributs (RFC 4511, Abschnitt 4.5.1, RFC 4515, RFC 4517).

Damit wird das Erzeugen von Filtern zu einer Sicherheitsaufgabe. Werte aus Benutzereingaben müssen nach RFC 4515 codiert werden; insbesondere *, Klammern, Backslash, NUL und ungültige UTF-8-Oktette dürfen nicht roh in den Ausdruck gelangen. Eine Stringkonkatenation kann sonst die Filterstruktur verändern und LDAP-Injection ermöglichen. DN-Escaping nach RFC 4514 folgt anderen Regeln und ist kein Ersatz für Filter-Encoding (RFC 4515, Abschnitt 3, RFC 4514, Abschnitt 3).

Neben dem Filter bestimmt die Attributliste, wie viel der Server zurückliefert. Eine leere Liste fordert alle normalen Benutzerattribute an, 1.1 keine Attribute, * alle Benutzerattribute und + nach RFC 3673 alle operativen Attribute. ACLs können davon weiterhin Werte ausblenden. Produktive Clients sollten nur benötigte Attribute anfordern: Grosse Mehrfachwerte belasten Netzwerk, Decoder und Speicher und können eigene Serverlimits auslösen (RFC 4511, Abschnitt 4.5.1.8, RFC 3673).

Paging, Sortierung und sich ändernde Resultate

Grössere Treffermengen werden gewöhnlich mit dem Simple Paged Results Control übertragen. Der Server gibt jeder Seite ein opakes Cookie mit, das der Client zusammen mit demselben Request zurücksendet. Dieses Cookie ist kein Offset und kein dauerhafter Cursor. Ändert sich der Verzeichnisbestand während der Folge, können Einträge fehlen oder doppelt erscheinen. Paging begrenzt also die Datenmenge pro Antwort, erzeugt aber keinen konsistenten Snapshot (RFC 2696, Abschnitte 2 und 3).

Active Directory macht diese Unterscheidung im Alltag sichtbar: Die LDAP Policy MaxPageSize begrenzt ungepagte Resultate standardmässig auf 1000 Objekte. Ein Import, der genau 1000 Einträge erhält, hat seine Vollständigkeit daher nicht bewiesen. Der Client muss Seiten und Cookies korrekt abarbeiten und einen Abbruch erkennen. Weitere Policies begrenzen Query-Dauer, Receive Buffer und gleichzeitig gehaltene Result Sets. Für den Betrieb sind deshalb Page Size, Seitenzahl, letzter Cookiefortschritt, Timeout und Wiederanlauf zu protokollieren (MS-ADTS, LDAP Policies, Microsoft: Paging Search Results).

Active Directory als LDAP-Serverprofil

Die bisherigen Regeln gelten für LDAP allgemein. Active Directory Domain Services ist eine konkrete Serverimplementierung mit zusätzlichen Rollen und Konventionen. Seine Daten sind auf Naming Contexts verteilt; ein Domain Controller hält mindestens Schema, Configuration und den eigenen Domain-Naming-Context. Der Root DSE besitzt den leeren DN und nennt unter anderem defaultNamingContext, configurationNamingContext, schemaNamingContext, alle namingContexts, den Servernamen und unterstützte Mechanismen. Nach TCP und TLS ist dieser Eintrag der erste Test, der tatsächlich etwas über den erreichten Verzeichnisdienst aussagt (RFC 4512, Abschnitt 5.1, Microsoft RootDSE, MS-ADTS, rootDSE Attributes).

Die Wahl zwischen Domain Controller und Global Catalog verändert das Suchergebnis. Ein DC bedient LDAP auf 389 beziehungsweise 636 und kennt den vollständigen Domain-Naming-Context seiner Domain. Der Global Catalog verwendet zusätzlich 3268 oder 3269 und hält eine partielle Replik aus allen Domains der Gesamtstruktur. Er kann forestweit Objekte finden, liefert für entfernte Domains aber nur Attribute des Partial Attribute Set. Ein erfolgreicher Treffer beweist daher noch nicht, dass das für die Anwendung benötigte Attribut vorhanden ist (MS-ADTS, Ports, Microsoft: Searching the Global Catalog, Microsoft: Attributes included in the Global Catalog).

Auch Filter können AD-spezifisch werden. Die Matching Rule 1.2.840.113556.1.4.1941, LDAP_MATCHING_RULE_TRANSITIVE_EVAL, folgt beispielsweise verlinkten Attributen und kann verschachtelte Gruppen auswerten. Ihre Unterstützung steht nicht einfach in supportedControl. Zudem enthält memberOf nicht die Primary Group. Eine Autorisierungsentscheidung aus Gruppenmitgliedschaften muss deshalb Gruppenverschachtelung, Primary Group, Gruppenscope, ACL-Sicht und Replikationsstand ausdrücklich berücksichtigen (MS-ADTS, LDAP Matching Rules, Microsoft: Primary group membership).

Welcher Server diese Abfragen beantwortet, entscheidet bei Windows-Clients der DC Locator zusammen mit DNS-SRV-Records. Standort- und rollenbezogene Records liefern Kandidaten mit Priorität und Gewicht. Eine statisch eingetragene IP umgeht diese Auswahl und erschwert die Zertifikatsprüfung. Ein einfacher TCP-Load-Balancer verteilt zwar Verbindungen, kennt aber ohne zusätzliche Logik weder schreibbare DCs noch Global Catalogs, Naming Contexts oder den Stand der Replikation (Microsoft: DC Locator, Microsoft: Verify LDAP SRV records).

Schliesslich darf LDAP-Erreichbarkeit nicht mit gesunder Replikation verwechselt werden. AD repliziert Verzeichnisänderungen über das Directory Replication Service Remote Protocol; OpenLDAPs syncrepl verwendet dagegen LDAP Content Synchronization mit Provider, Consumer und Cookies. Eine Testsuche kann zeigen, dass ein bestimmter Server antwortet. Ob alle Server dieselben Änderungen besitzen und nach einem Ausfall wieder aufholen, muss mit den Werkzeugen der jeweiligen Plattform geprüft werden (MS-DRSR, Relationship to Other Protocols, RFC 4533, OpenLDAP Administrator’s Guide: Replication).

Integrations- und Betriebsmodelle

Für den Betrieb ist nun weniger wichtig, dass ein Produkt «LDAP unterstützt», sondern wie es LDAP verwendet. Bei einem Laufzeit-Lookup wartet eine Nachricht oder Sitzung direkt auf Search und Serverantwort. Beim Credential Check sucht ein technisches Konto zuerst den Benutzer-DN und führt danach einen zweiten Bind mit dem eingegebenen Passwort aus. Ein Import oder Cache liest dagegen viele Einträge und arbeitet bis zum nächsten Lauf mit einer lokalen Kopie. Diese Muster haben unterschiedliche Folgen für Latenz, Passwortverarbeitung, Failover und Datenalter; die Produktdokumentation muss das konkrete Verhalten benennen (RFC 4511, Abschnitte 4.2 und 4.5, RFC 2696).

Unabhängig vom Muster braucht der Client getrennte Connect-, Bind-, Operation- und Idle-Timeouts. Ein Connection Pool spart TCP-, TLS- und Bind-Aufbau, trägt aber den Authentisierungszustand der Verbindung mit. Tote Sessions müssen erkannt werden, und eine Verbindung darf nicht versehentlich zwischen Benutzern oder Mandanten wechseln. Failover braucht eine nachvollziehbare Zielreihenfolge, begrenzte Wiederholungen und einen Weg zurück zum bevorzugten Ziel. Andernfalls vervielfachen parallele Retries gerade während eines Verzeichnisausfalls die Last (RFC 4511, Abschnitte 3.1, 4.2 und 5.3).

Auf Serverseite bestimmen Base DN, Scope, Filter und Attributliste die Arbeit. Eine selektive Gleichheitsbedingung auf einem indexierten Attribut ist etwas anderes als ein führender Substring oder ein grosser OR-Ausdruck. LDAP veröffentlicht keinen Ausführungsplan und schreibt keine Indextechnik vor. Der Administrator muss daher die echten Produktfilter mit Resultatmenge, p95-/p99-Latenz und Servermetriken korrelieren. Eine schnelle Suche nach einem einzelnen Testkonto belegt nicht, dass eine Empfängerprüfung unter Spitzenlast skaliert (OpenLDAP Administrator’s Guide: Performance Tuning, MS-ADTS: LDAP Policies).

Monitoring sollte den Ablauf in dieselben Stufen zerlegen wie die Fehlersuche: DNS-Auswahl, TCP- und TLS-Aufbau, Bind, Search-Latenz, Result Code, Trefferzahl und Paging-Fortschritt. Hinzu kommen Poolbelegung, Retryrate und der Stand von Import oder Sync. Ein einziger synthetischer Bind kann die Erreichbarkeit bestätigen, erkennt aber weder fehlende Attribute noch einen unvollständigen Import oder einen zurückliegenden Replikationspartner.

Für Backup und Recovery reicht der sichtbare Verzeichnisinhalt ebenfalls nicht. Zu sichern sind Schema, ACLs, Backend- und Serverkonfiguration, Schlüssel und Zertifikate, Replikationsidentitäten sowie das Verfahren, mit dem ein wiederhergestellter Knoten wieder in die Topologie aufgenommen wird. Active Directory verwendet dafür System State und eigene Forest-Recovery-Schritte; OpenLDAP hängt von seinem Backend ab. Das Handbuch unterscheidet etwa eine LMDB-Sicherung von slapcat und weist auf semantisch inkonsistente LDIF-Zustände bei mehrteiligen Änderungen hin. LDAP selbst definiert keinen Backupmechanismus (Microsoft: Back up the System State data, OpenLDAP Administrator’s Guide: Directory Backups).

Ein Restoretest ist erst abgeschlossen, wenn ein Client den wiederhergestellten Dienst über den vorgesehenen DNS-Namen findet, TLS und Bind erfolgreich sind, Root DSE und Schema stimmen, reale Suchen vollständige Attribute liefern und die Replikation kontrolliert wieder anläuft. Damit führt Recovery zurück zum Beginn des Artikels: Der ganze Pfad zählt, nicht bloss eine gestartete Datenbank.

Diagnosewerkzeuge

Die Diagnose folgt demselben Pfad wie eine produktive Abfrage. Sie beginnt im Netz der betroffenen Anwendung und verwendet deren DNS-Namen, Truststore, Bind-Verfahren, Base DN, Filter und Attributliste. Ein Test vom Admin-Laptop kann sonst erfolgreich sein, während das Gateway weiterhin einen anderen DC, eine andere CA oder einen anderen Scope verwendet. Die Beispiele nutzen reservierte Namen und lesen nur Metadaten; Bind-Passwörter gehören weder in die Shell-History noch in Prozessargumente. ldapsearch -W fragt sie interaktiv ab.

Dienstziele über DNS ermitteln

Resolve-DnsName _ldap._tcp.dc._msdcs.example.ch -Type SRV -DnsOnly
Resolve-DnsName _ldap._tcp.gc._msdcs.example.ch -Type SRV -DnsOnly

dig +noall +answer SRV _ldap._tcp.dc._msdcs.example.ch
dig +noall +answer SRV _ldap._tcp.gc._msdcs.example.ch

Resolve-DnsName und dig zeigen Targets, Ports, Prioritäten und Gewichte. Danach sind A-/AAAA-Auflösung, Standortbezug und Erreichbarkeit jedes tatsächlich wählbaren Targets zu prüfen. Ein einzelner erreichbarer DC behebt einen fehlerhaften SRV-Satz nicht (Microsoft: DC Locator).

TCP und implizites TLS auf Port 636 prüfen

Test-NetConnection dc1.example.ch -Port 636 -InformationLevel Detailed
$tcp = [Net.Sockets.TcpClient]::new(“dc1.example.ch”, 636)
$tls = [Net.Security.SslStream]::new($tcp.GetStream(), $false)
$tls.AuthenticateAsClient(“dc1.example.ch”)
$tls.SslProtocol
$tls.RemoteCertificate.Subject
$tls.RemoteCertificate.GetExpirationDateString()
$tls.Dispose(); $tcp.Dispose()

openssl s_client \
  -connect dc1.example.ch:636 \
  -servername dc1.example.ch \
  -verify_hostname dc1.example.ch \
  -verify_return_error -brief

Test-NetConnection belegt zunächst nur den TCP-Connect. Das anschliessende .NET SslStream beziehungsweise openssl s_client prüft TLS mit dem konfigurierten DNS-Namen. s_client -showcerts zeigt lediglich die vom Server gesendeten Zertifikate und ist für sich kein erfolgreicher Chain- oder Hostname-Nachweis. StartTLS auf 389 kann unter Unix mit openssl s_client -starttls ldap separat geprüft werden (OpenSSL s_client, RFC 4511, Abschnitt 4.14).

Root DSE und Fähigkeiten lesen

Get-ADRootDSE -Server dc1.example.ch -Properties @(
  "defaultNamingContext"
  "namingContexts"
  "supportedLDAPVersion"
  "supportedControl"
  "supportedSASLMechanisms"
)

ldapsearch -LLL -x -ZZ -H ldap://dc1.example.ch \
  -s base -b "" \
  defaultNamingContext namingContexts supportedLDAPVersion \
  supportedControl supportedSASLMechanisms

Get-ADRootDSE verwendet hier das ActiveDirectory-Modul und standardmässig die angemeldete Windows-Identität. ldapsearch erzwingt mit -ZZ erfolgreiches StartTLS und liest anonym nur die vom Server freigegebenen Root-DSE-Attribute. Ein fehlendes OID belegt, dass genau dieses Ziel die Funktion nicht veröffentlicht; es sagt nichts über andere Clusterknoten aus.

Reale Suche mit Scope, Filter und Paging nachstellen

$params = @{
  Server         = "dc1.example.ch"
  SearchBase     = "OU=People,DC=example,DC=ch"
  SearchScope    = "Subtree"
  LDAPFilter     = "(&(objectClass=user)(mail=admin@example.ch))"
  Properties     = @("mail", "proxyAddresses", "memberOf")
  ResultPageSize = 500
}
Get-ADUser @params

ldapsearch -LLL -x -ZZ -H ldap://dc1.example.ch \
  -D "CN=svc-lookup,OU=Services,DC=example,DC=ch" -W \
  -b "OU=People,DC=example,DC=ch" -s sub \
  -E pr=500/noprompt \
  "(&(objectClass=user)(mail=admin@example.ch))" \
  mail proxyAddresses memberOf

Get-ADUser akzeptiert mit -LDAPFilter die RFC-nahe Filtersyntax und führt Paging über -ResultPageSize aus. ldapsearch verwendet -E pr=500/noprompt für das Paged Results Control und -W für eine interaktive Passwortabfrage. Der Test muss ausser dem Treffer auch Abschluss-Resultat, Seitenzahl, zurückgegebene Attribute und Laufzeit dokumentieren.

Fehler einer Grenze zuordnen

Numerische Result Codes gehören zum LDAP-Protokoll; diagnosticMessage und zusätzliche AD-Subcodes sind dagegen implementationsspezifischer Kontext. Automatisierung sollte deshalb zuerst den Result Code auswerten und den Text ergänzend protokollieren. Für busy und unavailable braucht jeder Client ein begrenztes Retrybudget mit Backoff. Unbegrenzte Wiederholungen machen aus einem einzelnen Verzeichnisproblem eine Lastspitze in allen abhängigen Systemen (RFC 4511, Abschnitt 4.1.9 und Anhang A).

Technische Geschichte

LDAP entstand nicht als unabhängige Verzeichnisdatenbank. X.500 hatte Ende der 1980er-Jahre ein umfassendes Verzeichnismodell und das Directory Access Protocol definiert. RFC 1487 beschrieb 1993 einen leichteren Zugang zu diesem Modell; RFC 1777 folgte 1995 als LDAP Version 2. Das «Lightweight» bezog sich auf den gegenüber DAP vereinfachten Protokollzugang, nicht auf kleine Verzeichnisse oder geringe betriebliche Bedeutung. Die frühe Entwicklung ist eng mit Tim Howes und der University of Michigan verbunden (RFC 1487, RFC 1777).

LDAPv3 wurde 1997 mit RFC 2251 und Begleitdokumenten veröffentlicht. Erweiterbare Operationen, Controls, SASL, Internationalisierung und das überarbeitete Datenmodell machten daraus die Grundlage heutiger Implementierungen. Die LDAPbis-Arbeit ordnete diesen Stand 2006 neu: RFC 4510 dient als Roadmap, RFC 4511 beschreibt das Protokoll, RFC 4512 das Informationsmodell und RFC 4513 die Sicherheit; RFC 4514 bis 4519 ergänzen Darstellungen, URLs, Syntaxen und Schema (RFC 2251, RFC 4510, Abschnitt 3).

Parallel dazu entwickelten sich sehr unterschiedliche Server. OpenLDAP ging 1998 aus der University-of-Michigan-Implementierung hervor und führte slapd, Bibliotheken und Werkzeuge als Open-Source-Projekt weiter. Active Directory brachte mit Windows 2000 ein LDAPv3-Profil mit eigenem Schema, Naming Contexts, Controls, Matching Rules und separatem Replikationsprotokoll in die breite Unternehmensnutzung (OpenLDAP Release Road Map, OpenLDAP Administrator’s Guide – Preface, MS-ADTS).

Diese Geschichte erklärt die wichtigste Betriebsregel: LDAP vereinheitlicht den Zugriff, nicht die interne Architektur. Wer einen Client von OpenLDAP zu AD DS oder zwischen zwei Appliances verschiebt, muss deshalb mehr prüfen als Host, Port und Bind-DN. Schema, Controls, Limits, Gruppenauflösung, Replikation und Recovery bleiben Produkteigenschaften.