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:
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.
- Dienstübersicht und Netzwerkportanforderungen für Windows
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements - Konfigurieren Sie die Active Directory-Webdienste (ADWS) so,
dass diese auf allen Servern automatisch starten
https://learn.microsoft.com/de-de/services-hub/unified/health/remediation-steps-ad/configure-the-active-directory-web-services-adws-to-start-automatically-on-all-servers
ADWS und TLS
Ich habe einige Zeit gesucht aber bis heute noch keine abschließende Antwort zum Einsatz von TLS gefunden. Wenn ich ADWS starte und der Server hat kein Zertifikat, dann finde ich folgende Meldung im Eventlog:
Log Name: Active Directory Web Services Source: ADWS Date: 03.06.2024 15:34:11 Event ID: 1400 Task Category: ADWS Certificate Events Level: Information Keywords: Classic User: N/A Computer: dc01.msxfaq.net Description: Active Directory Web Services could not find a server certificate with the specified certificate name. A certificate is required to use SSL/TLS connections. To use SSL/TLS connections, verify that a valid server authentication certificate from a trusted Certificate Authority (CA) is installed on the machine. Certificate name: dc01.msxfaq.net Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="ADWS" /> <EventID Qualifiers="16384">1400</EventID> <Version>0</Version> <Level>4</Level> <Task>5</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2024-06-03T13:34:11.6589249Z" /> <EventRecordID>3032</EventRecordID> <Correlation /> <Execution ProcessID="0" ThreadID="0" /> <Channel>Active Directory Web Services</Channel> <Computer>dc01.msxfaq.net</Computer> <Security /> </System> <EventData> <Data>dc01.msxfaq.net</Data> </EventData> </Event>
Ich habe dann ein Self Signed Zertifikat wie folgt generiert:
New-SelfSignedCertificate -Subject "dc01.msxfaq.net"
Danach ist auch die Meldung verschwunden. Ich habe dann geschaut, welche Ports der ADWS-Dienst genutzt hat. Über den bekannten Port "9389" habe ich den Prozess gesucht und dann darauf abgefragt:
$adwspid= (Get-NetTCPConnection -LocalPort 9389).owningprocess[0] Get-NetTCPConnection -OwningProcess $adwspid
Allerdings habe keinen weiteren Port gefunden, der nun TLS angeboten hätte.
In den verschiedenen Übersichten mit "Used Ports" würde für ADWS aber auch kein weiterer Port angezeigt.
- Dienstübersicht und
Netzwerkportanforderungen für Windows
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements
Auch mit WireShark konnte ich keine TLS-Verbindung sehen aber alle Abrufe waren nicht im Klartext lesbar.
- Third Party Application Fails Using LDAP
over SSL
https://learn.microsoft.com/de-de/archive/blogs/askds/third-party-application-fails-using-ldap-over-ssl - PKI Active directory web service adws
logs eventid 1402 after changing dc
certificate from domain controller template
to kerberos authentication template/
https://777notes.wordpress.com/2019/12/19/pki-active-directory-web-service-adws-logs-event-id-1402-after-changing-dc-certificate-from-domain-controller-template-to-kerberos-authentication-template/
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
- AD LDS / ADAM - der kleine LDAP-Server
- AD-PowerShell
- Audiocodes LDAP-Routing V2
- Audiocodes LDAP-Routing
- WireShark
- TCP SYN ACK RES
- PowerShell und LDAP/GC
- Active Directory Web Services Event 1202
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/active-directory-web-services-event-1202/ba-p/1514401 - The Riverbed Field Guide for the AD
Admin
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/the-riverbed-field-guide-for-the-ad-admin/ba-p/258868 - Optimization Techniques and Design
Fundamentals
https://support.riverbed.com/bin/support/static/fbunsuuo632vi3jrspe0evbko9/html/u2pi6l52l4drmhq3uhck9tu7hm/sh_9.2_dg_html/index.html#page/sh_9.2_dg/designfund.html