Zur Verwaltung von Verzeichnis-Diensten gibt es verschiedene Protokoll-Welten; eine davon ist LDAP, andere sind Street Talk, NDS oder X.400. Diese Protokoll- und Dienst-Systeme sind teilweise mit einander verwandt.
MS-Windows verwendet LDAP in seinem ADS (Active Directory Service).
LDAP ist nicht leicht zu analysieren, weil viele (vermutlich: die meisten) Analyzer nicht alle LDAP-Parameter anzeigen, die vom LDAP-Server an den LDAP-Client versendet werden.
Dies liegt darin begründet, dass die LDAP-Antworten des Servers oft zu groß sind, um in nur ein Daten-Paket zu passen; folglich wird der Inhalt über mehrere Pakete verteilt.
Dies macht LAN-Analyzern jedoch massive Probleme: Sie zeigen nur den Inhalt des ersten LDAP-Antwort-Pakets an, nicht aber den Inhalt der folgenden Pakete, da der Bezugspunkt fehlt (das erste Byte des ersten Pakets).
Ausnahme hier ist die LAN-Analyse-Software TraceMagic, die erst alle Pakete der LDAP-Server-Antwort einsammelt und zusammen legt, um sodann den gesamtem Inhalt zu dekodieren. Außerdem verfügt TraceMagic über Auto-Filter, die selbsttätig wichtige Informationen aus dem LDAP-Übertragungen sichtbar machen und ggf tabellarisch zugänglich machen.
LDAP ist eng verzahnt mit folgenden Protokollen bzw. Protokoll-Architekturen:
DHCP teilt dem LAN-Client mit, unter welchem DNS-Domain-Namen die Netzwerk-Anmeldung (NetLogon) erfolgen soll, welche IP-Adresse der/die DNS-Server hat/haben, über die wiederum die Namen und IP-Adressen der LDAP- und Kerberos-Server abfragbar sind.
Mit einer sog. DNS-Service-Anfrage kann der DNS-Client die Namen und IP-Adressen von LDAP-Servern und Kerberos-Servern abfragen. Die Syntax kann so aussehen:
Es kommt regelmäßig zu Syntax-Fehlern bei diesen Anfragen, da die Service-Anfrage nur den Service-Typ, die Location sowie den DNS-Domain-Suffix enthalten darf, aber keinen Host-Namen bzw. Server-Namen. Da aber der DNS-Treiber des Clients nicht immer sicher unterscheiden kann, was Host-Name und was DNS-Domain-Suffix ist, werden Anfragen gestellt, die einen Server-Namen beinhalten und die daher vom DNS-Server mit Error-Code beantwortet werden. In der Regel fragt der Client im Abstand von Millisekunden beide Varianten ab und folglich auch die richtige; gelegentlich jedoch ist zu beobachten, dass Clients nur die falsche Syntax verwenden und somit keine Auflösung der LDAP-Service-Anfrage erhalten - was dazu führt, dass sie mangels IP-Adresse keinen LDAP-Server ansprechen können.
Eng verzahnt hiermit sind UNC-Zugriffs-Fehler, falls die Namensdienste nicht korrekt auflösen.
Einerseits setzen korrekte IP-Parameter in der Client-Konfiguration korrektes Arbeiten mit LDAP voraus.
Andererseits enthalten LDAP-Angaben des LDAP-Servers eine große Zahl an DNS-Namen und UNC-Pfaden/Namen, die sämtlich wirkungslos bleiben, wenn die Namensdienste nicht korrekt arbeiten. In diesem Zusammenhang tritt letztlich neben DNS auch WINS auf den Plan: Wenn der LDAP-Client versucht, DNS-Namen und UNC-Pfade (auf Resourcen) aufzulösen, und wenn DNS die Auflösung des Namens zur IP-Adresse nicht liefert, wird der Client auf WINS-Anfragen und ggf sogar NetBIOS-Broadcasts ausweichen. Sollte der Client über einen NetWare-Client-Treiber verfügen, wird er sogar über SLP und NDS fragen, bis hin zur Bindery-Abfrage.
Die LDAP-Parameter, die der LDAP-Server an den LDAP-Client zurück gibt, enthalten ggf. UNC-Pfade, die von SMB verwendet werden zur Ansprache der entsprechenden Netzwerkk-Resourcen; weiterhin enthalten die LDAP-Parameter Verzeichnis-Pfade auf Servern, in denen z.B. die Logon-Scripte liegen, Gruppen-Richtlinien (GPT.INI = Group Policy Template .INI) und weiteres mehr.
LDAP-Dialoge lösen folglich beim Client Server-Zugriffe via SMB aus.
Falls die Namens- und Adress-Auflösung via DNS im Gefolge von LDAP-Aktivitäten fehlschlagen, wird der Client auf WINS ausweichen (sofern WINS auf dem Client aktiviert ist).
Wenn es erst einmal so weit gekommen ist, muss damit gerechnet werden, dass über Namensdienst-Timeouts immer mehr Wartezeiten auftreten.
In einem Fall (2005) wurde beobachtet, dass Clients wie folgt vorgingen:
Client fragt Server nach seiner Identität, Server antwortet u.a. mit Gruppen-Mitgliedschaft.
Client fragt Gruppen-Attribute ab, Server antwortet, u.a. mit den Namen aller Gruppen-Mitglieder.
Client fragt weiter; Server rückt die kompletten !! Computer-Konten aller Gruppen-Mitglieder heraus.
Da alle Clients so konfiguriert waren, dass sie einander nicht "sehen" sollten und unter einander auch keinen Kontakt haben sollten, stellte diese LDAP-Variante praktisch einen Super-GAU in Sachen Sicherheit dar. Laut Microsoft hätte dies nicht sein dürfen. Das Verhalten wurde dann mit Hilfe von Microsoft/Deutschland abgestellt.
