AD LDS, Set-ADUser und Firewall

Ich nutzen den AD LDS / ADAM - der kleine LDAP-Server gerne für generische Verzeichnisdienste, z.B. Rufnummernrouting mit SIP-SBCs (Audiocodes LDAP-Routing V2) oder LDAP-Adressbücher für ERP/CRM-Lösungen oder Callcenter bereit zu stellen. Die Verwaltung der Einträge kann per LDAP, ADAMSync oder die AD-PowerShell (*-ADUser) erfolgen. Diese Seite beschreibt die Tücken von Deep-Inspection Firewalls.

Umgebung

Bei einem Kunden sind die AD-LDS-Server weltweit an jedem Standort verteilt, an dem auch ein SBC platziert war. So konnten Anrufe über einen lokalen SIP-Trunk durch den SBC direkt gegen den lokalen LDAP-Service abgefragt und anhand der Antwort entweder zu Teams, zu einem anderen SBC oder zur noch vorhandenen TK-Technik oder CallCenter geroutet werden. Die komplette Verwaltung der Einträge im AD LDS ist natürlich das zentrale Provisioning erforderlich. Es wurde absichtlich auf eine Replikation durch AD LDS verzichtet, um möglichst autarke Systeme zu betreiben und das Risiko durch lokale Administratoren etc. zu minimieren.

Das Provisioning erfolgt durch eine zentrale Instanz, die aus einer Datenbank sich die Einträge extrahiert und nicht nur in die AD LDS-Server geschrieben hat. Das Provisioning hat auch die relevanten Felder im Anmelde-Forest, in Teams und anderen Systemen geschrieben.

AD LDS und Port 9389

Irgendwann wurde aber ein AD LDS-Server in einer Niederlassung aufgebaut, bei dem alle Versuche die Werte mit "Set-ADUser" zu schreiben, fehlgeschlagen sind. Die lapidare Fehlermeldung lautet:

Set-ADUser : The operation returned because the timeout limit was exceeded.

Weitere Hinweise gab es nicht. Die üblichen Tests haben auch keine Fehler gezeigt:

  • AD LDS Dienst gestartet. OK
  • AD-LDS Server per DNS auflösbar und Antwort Korrekt: OK
  • "Test-NetConnection -Server <server> -port 389"  erfolgreich.
  • Verbindung mit LDP.EXE und Anmeldung: OK

Damit waren eigentlich alle Voraussetzungen erfüllt. Aber ein NETSTAT bzw. ein "Get-NetTCPConnection -RemoteAddress <server" lieferte keine aktiven Verbindungen auf 389/636  sondern eine Verbindung zu 9389. Eine schnelle Suche im Internet liefert dann auch schnell die Antwort:


Quelle: https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements#active-directory-local-security-authority

Die Active Directory PowerShell nutzt gar nicht Port 389, 636 oder 3268 sondern verbindet sich zum Active Directory Web Service (ADWS).

Die Dienste sind natürlich auf dem Server auch gestartet und lokal funktioniert auch alles. Daher lag der Verdacht nahe, dass auf dem Weg zwischen der Provisining-Plattform und dem AD LDS-Server etwas stört.

Ich habe sogar den Server mit "-Server LDAP://servername:398" angegeben. Dennoch hat *-ADUser immer wieder nur den Port 9389 verwendet. Anscheinend werden diese Werte dann als Daten durch den Webservice-Tunnel an den entfernten Server gegeben, der diese dann lokal umsetzt.

Wireshark Verbindung

Wenn man nicht weiß, wie viele Router, Firewalls, Proxy-Server, WAN-Optimierer u.a. zwischen zwei Systemen stehen und der Zugriff auf diese Systeme nicht vorliegt, dann bleibt nur der Mitschnitt mit WireShark und Co auf beiden Endpunkten. Es bietet sich hier an, z.B. auf den fraglichen Port oder zumindest auf die IP-Adressen der beiden Server zu filtern, damit die Mitschnitte einfach vergleichbar sind.

Auf dem Provisioning-System sieht die Verbindung durchwachsen aus. Der Fachmann erkennt den Drei-Wege Handshake (TCP SYN ACK RES) und dann sendet der Client noch was und die Gegenstelle antwortet noch aber die Pakete sind sehr klein. Nach 120 Sekunden legt dann der Client wieder auf.

Auf der Server-Seite zeigt sich nur bei den ersten drei Paketen wieder ein Drei-Wege Handshake (TCP SYN ACK RES). Wer aber genau hinschaut, sieht zwar die gleichen IP-Adressen und auch die gleichen TCP-Ports aber auch erste Unterschiede, z.B. WIN=8192 vs. WIN=14600. Auch die Sequence Number (Raw) sind unterschiedlich. Das können nicht die gleichen Pakete sein.

Die Pakete 57 und 58 des Clients erscheinen aber überhaupt nicht beim Server und die Antworten, welche der Client erhalten hat, hat der Server nie gesendet. Der Server beendet seinerseits die Verbindung nach ca. 30 Sekunden wegen Inaktivität. Auch diese Meldung kommt beim Client nicht an. Stattdessen liefert dort irgendein andere System Quittungen und nach 120 Sekunde ein RESET

Hier ist also definitiv etwas mehr oder weniger "Intelligentes System" involviert, welches auf dem Übertragungsweg die Paket verändert, filtert, umschreibt oder optimiert.

TCP-Options

Zu dem Zeitpunkt wusste ich noch nicht, was es war und wo das fragliche System stand. Anhand der IP-Adresse ist es nicht zu ermitteln, da es transparent arbeitet. Aber ich aber auf einem Server die MAC-Adressen mir angeschaut, welche ja den nächsten Hop im Netzwerk liefert. Hier war es laut Wireshark der Hersteller "Palo Alto".

Interessant war auch beim ersten SYN-Paket die Analyse der Options. Der Provisioning-Service sendet die klassischen Optionen

Auf der anderen Seite kommen die Optionen in einer anderen Reihenfolge und um weitere Felder angereichert an.

Hier sind auch erstmals zwei Optionen mit dem Namen "Riverbed Probe" zu sehen. Diese passen auch zu der Anzeige von "S+*" im Trace beim AD LDS-Server.

Hier scheint also ein Riverbed-System oder ähnliche Lösung, die die gleiche TCP-Option nutzt, im Einsatz zu sein.

Lernkurve

Als Windows Admin ist man schnell dabei den Fehler erst mal in seiner Umgebung zu suchen. Es kann ja schon viel die Funktion stören, sei es fehlende oder gestoppte Dienste, falsche Zertifikate, blockierte Ports oder Softwarebugs. Aber je größer eine Firma ist, desto eher ist ein guter Draht zu den Netzwerkern und insbesondere Firewall-Administratoren wichtig, denn die Zeiten von flachen ungefilterten Netzwerken ist definitiv vorbei. Wenn ein Server A nicht mit dem Server B sprechen muss, dann sollte man dies auch nicht erlauben, damit ein "Schnupfen" eines Systems nicht weitere System infiziert. Wir kennen das von Exchange-Servern, die eigentlich nur mit dem AD-Sprechen müssen aber für die meisten Netzwerkteilnehmer nur über ganz wenige Ports (HTTPS/443,SMTP/25,SMTP/465, SMTP/587, POPIMAP/110,143,993,955) erreichbar sein müssen. Ideale Voraussetzungen mit Firewalls und AccessListen.

Wenn aber nicht nur mit AccessListen, d.h. Allow/Block-Regeln für IP-Adressen und Ports gearbeitet wird, sondern leistungsfähige "Next Generation Firewalls" und "WAN-Optimierer" zum Einsatz kommen, dann wird auch die Fehlersuche komplexer.

Interessant ist hier, dass z.B. der Port 9389 sogar erreichbar war. Es musste also entweder schon eine Freischaltung gegeben haben oder die Filterregeln zwischen den Standorten sind per Default noch etwas freizügig aber dann grätscht die Applikation Level Firewall dazwischen. Das wird sicher protokolliert aber dürfte keinen Alarm antriggern. Damit liegt es wieder am Betreiber der Dienste letztlich nachzuweisen, dass jemand anderes die Funktion stört.

Allerdings müssen Sie auch wissen, welche Ports und Protokolle ihre Server und Dienste nutzen. Ich bin mir ziemlich sicher, dass nur weniger Administratoren wissen, das die AD-PowerShell gar nicht über Port 389 arbeitet. Nur gut, dass es auch noch den direkten Zugriff mit PowerShell und LDAP/GC gibt.

Weitere Links