ADSync Ports

Der ADSync-Service spricht sowohl mit dem Microsoft Provisioning Service in der Cloud als auch mit dem lokalen Active Directory. Damit ADSync auch PasswordHashSync und Groups Writeback V2 u.a. nutzen kann, hat das Dienstkonto durchaus privilegierte Rechte, so dass Sie das System mit ADSync als "Tier-0"-System ansehen sollten. Wenn Sie dann noch mehrere AD-Forests ansprechen, die vielleicht nicht mal mit einem Trust verbunden sind, dann sollten wir schon genau wissen, welche Ports von ADSync genutzt werden.

Szenarien

Das ist insbesondere interessant, wenn ihr ADSync nicht nur einen Forest ausliest, in dem er selbst installiert ist, sondern weitere Forests bedienen muss:

Die Herausforderung ist hier oft eine beschränkte Konnektivität. Stellen Sie sich vor, dass sie schon lange ihre Domain1 mit ihrem ADSync und ihrem Tenant verbunden haben und nun kauft ihre Firma eine andere Firma, die einen eigenen Forest betreibt. Die "Cross-Forest"-Migration von Benutzer, Gruppen, Computern und Servern dauert in der Regel länger aber eine Zusammenarbeit mit Exchange Online, SharePoint und insbesondere Teams passiert meist sehr früh.

Ihr ADSync muss also die Domain Controller des anderen Forest erreichen und dazu müssen Sie eine IP-Verbindung, z.B. über VPN, schalten und hoffen, dass es keine überlappenden Subnetze gibt. Das kann sogar dazu führen, dass sie den ADSync in ein eigenes VLAN mit einem eindeutigen IP-Subnetz einsperren.

Solange Sie aber nichts über den Sicherheitsstandard des anderen Netzwerks kennen, sollten Sie ihren ADSync Server keinesfalls "erreichbar" machen, denn ADSync ist klassisch ein "Tier-0"-System und sollte den gleichen Schutzlevel haben, wie ein Domain Controller. Denken Sie nur daran, dass ADSync z.B. Kennworte als Teil von Password Hash Sync (PHS) auslesen kann oder auch Kennworte schreiben kann.

Wenn Sie statt ADSync auf AzureAD Cloud Sync setzen, dann sprechen alle lokal installierten Agenten mit der Cloud und es ist keine Querverbindung zwischen Forests erforderlich.

Domainmitglied

Schon für die Verbindung zu einem anderen Forest sollte ich genau wissen, was ADSync hier benötigt. Bei einer klassischen ADSync-Installation ist der Server Mitglied einer Domain. Das ist im Prinzip auch ratsam, weil das System damit durch das Active Directory einfacher verwaltet werden kann, z.B. Windows Updates, Gruppenrichtlinien, zentrale Benutzerdatenbank statt lokale Benutzer. Aber natürlich können Sie ADSync auch auf einem Standalone-System installieren. Allerdings nicht mit der Express-Installation.

Sie müssen in dem Fall eine "Custom Installation" durchführen. Die Installation ohne Domainmitgliedschaft hat aber auch den Vorteil, das der Server nicht automatisch das LAN als "Domain-Netzwerk" einstuft, sondern sie dieses auf "Public" stellen können und damit der Server sehr gut abgeschottet ist. Zudem können Sie nun über lokale Benutzer auch dem Administrator aus dem anderen Forest oder einem Dienstleister einen Zugriff erlauben, ohne dass er gleich über eine Domain-Mitgliedschaft zu viele Berechtigungen bekommt

Für die weitere Analyse habe ich ADSync auf einem "Standalone-Server" installiert, weil ich dann per Wireshark sehr einfach die Verbindungsversuche erfassen kann und keine Domain-Kommunikation sich einmischt.

Verbindungen

Ein Computer, auf dem ADSync betrieben wird, kommuniziert mit den unterschiedlichsten Dienste:

  • Lokales AD als Domain-Mitglied
    Wenn der ADSync-Computer seinerseits Mitglied einer Domain ist, dann gelten die bekannten Voraussetzungen. Windows muss nicht nur per DNS (Port 53) den Server erreichen und finden, sondern auch Kerberos (Port 88) und LDAP (Port 389, Port 3268) nutzen und per SMB (Port 445) auf SYSVOL und NETLOGON zugreifen können, um z.B. Gruppenrichtlinien zu laden. Auch RPC (135 RPC) und weitere High-Ports sind erforderlich. Siehe auch "Service overview and network port requirements for Windows" https://learn.microsoft.com/en-US/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements
  • Microsoft 365 Provisioning Service
    Die Verbindung zum Microsoft 365 Provisioning Service ist schnell beschrieben: ADSync nutzt HTTPS über Port 443 und die Verbindung kann auch über einen Proxy geleitet werden. Die meisten Firewalls kennen die IP-Adressen oder DNS-Namen der Gegenstellen, so dass Sie auch hier genau steuern können, wohin ADSync kommunizieren kann.
  • AD-Forest
    Zur Kommunikation mit dem Active Directory ist primäre der LDAP-Port 389 erforderlich. Allerdings muss ADSync per DNS den Service auflösen und sich per Kerberos anmelden können. Daher ist Port 88 ebenfalls erforderlich. Der DNS Port 53 ist nicht zwingend, solange ADSync irgendwie den Server auflösen kann.

All diese Ports zeigen aber auch auf, dass de Betrieb in einer klassischen DMZ nicht sinnvoll ist. der Server müsste dazu ohne Domainmitgliedschaft betrieben werden und dennoch per RPC auf interne Server zugreifen. Dann ist es wohl immer einfacher, dass der ADSync-Server die gleichen Klassifizierung wie ein Domain Controller (Tier-0) bekommt, da er ja z.B. Kennworte zurückschreiben kann oder das DirSync-Recht hat. Die einzelne ausgehende Verbindung per HTTPS zu einem bekannten Endpunkt in der Microsoft Cloud ist hier wohl am einfachsten zu kontrollieren.

Verbindungstest beim Setup

Technisch können Sie mit TELNET, Test-NETTCPConnection u.a. Tools schaue, ob die Verbindungen schon alle eingerichtet sind. Wenn wir aber mal ehrlich sind, dann starten wir doch alle einfach das Installationsprogramm und warten die ersten Fehler ab. Die ersten Schritte des Setups funktionieren fast immer, denn zuerst wird SQL installiert und eine Datenbank vorbereitet, dann die Dienste hinterlegt und erst bei der Konfiguration fällt dann vielleicht auf, dass eine Domain nicht auflösbar oder noch nicht erreichbar ist. Wohl dem, der dann weiß, wo ADSync bzw. das Setup seine Informationen ablegt.

Am interessantesten sind aber die Protokolldateien im ProgramData:

Interessant sind hier die Dateien mit dem Namen "ADConnectivityTool-<yyyymmdd-hhMMss>". Hier das Beispiel eines Inhalts:

[25.03.2022 19:12:38] [INFO   ] Starting NetworkConnectivityDiagnosisTools
[25.03.2022 19:12:38] [INFO   ] Verifying that 'UCLABOR.DE' exists
[25.03.2022 19:12:38] [SUCCESS] UCLABOR.DE exists
[25.03.2022 19:12:38] [INFO   ] Verifying if the provided credentials are correct
[25.03.2022 19:12:38] [INFO   ] Attempting to obtain a domainFQDN
[25.03.2022 19:12:38] [INFO   ] Attempting to retrieve DomainFQDN object...
[25.03.2022 19:12:38] [SUCCESS] The provided credentials were correct
[25.03.2022 19:12:38] [INFO   ] Attempting to obtain Domain Controllers associated with UCLABOR.DE
[25.03.2022 19:12:38] [INFO   ] Obtaining ForestFQDN
[25.03.2022 19:12:38] [INFO   ] Attempting to retrieve ForestFQDN...
[25.03.2022 19:12:38] [SUCCESS] ForestFQDN Name is: UCLABOR.DE
[25.03.2022 19:12:38] [INFO   ] Attempting to retrieve domain: UCLABOR.DE
[25.03.2022 19:12:39] [SUCCESS] The following DCs where found:
[25.03.2022 19:12:39] [SUCCESS] - DC01.UCLABOR.DE
[25.03.2022 19:12:39] [INFO   ] Validating DNS connectivity.
[25.03.2022 19:12:40] [SUCCESS] Successfully resolved _ldap._tcp.UCLABOR.DE.
[25.03.2022 19:12:40] [SUCCESS] Successfully resolved DC01.UCLABOR.DE.
[25.03.2022 19:12:40] [INFO   ] Determining if provided Forest and its associated DCs are reachable.
[25.03.2022 19:12:43] [SUCCESS] UCLABOR.DE is reachable.
[25.03.2022 19:12:46] [SUCCESS] DC01.UCLABOR.DE is reachable.
[25.03.2022 19:12:46] [INFO   ] Validating network connectivity.
[25.03.2022 19:12:52] [SUCCESS] TCP connection to DC01.UCLABOR.DE on port 53 succeeded.
[25.03.2022 19:12:52] [INFO   ] Debug entry for DC01.UCLABOR.DE [fe80::a115:42:b57f:8a8e%4]:53.
[25.03.2022 19:12:52] [INFO   ] Remote endpoint: DC01.UCLABOR.DE
[25.03.2022 19:12:52] [INFO   ] Remote port: 53
[25.03.2022 19:12:52] [INFO   ] Interface Alias: Ethernet 3
[25.03.2022 19:12:52] [INFO   ] Source Interface Address: fe80::a115:42:b57f:8a8e%4
[25.03.2022 19:12:52] [INFO   ] Ping Succeeded: False
[25.03.2022 19:12:52] [INFO   ] Ping Reply Time (RTT) Status: 
[25.03.2022 19:12:52] [INFO   ] Ping Reply Time (RTT) RoundTripTime: 
[25.03.2022 19:12:52] [INFO   ] TCPTestSucceeded: True
[25.03.2022 19:12:52] [SUCCESS] TCP connection to DC01.UCLABOR.DE on port 88 succeeded.
[25.03.2022 19:12:52] [INFO   ] Debug entry for DC01.UCLABOR.DE [fe80::a115:42:b57f:8a8e%4]:88.
[25.03.2022 19:12:52] [INFO   ] Remote endpoint: DC01.UCLABOR.DE
[25.03.2022 19:12:52] [INFO   ] Remote port: 88
[25.03.2022 19:12:52] [INFO   ] Interface Alias: Ethernet 3
[25.03.2022 19:12:52] [INFO   ] Source Interface Address: fe80::a115:42:b57f:8a8e%4
[25.03.2022 19:12:52] [INFO   ] Ping Succeeded: False
[25.03.2022 19:12:52] [INFO   ] Ping Reply Time (RTT) Status: 
[25.03.2022 19:12:52] [INFO   ] Ping Reply Time (RTT) RoundTripTime: 
[25.03.2022 19:12:52] [INFO   ] TCPTestSucceeded: True
[25.03.2022 19:12:52] [SUCCESS] TCP connection to DC01.UCLABOR.DE on port 389 succeeded.
[25.03.2022 19:12:52] [INFO   ] Debug entry for DC01.UCLABOR.DE [fe80::a115:42:b57f:8a8e%4]:389.
[25.03.2022 19:12:52] [INFO   ] Remote endpoint: DC01.UCLABOR.DE
[25.03.2022 19:12:52] [INFO   ] Remote port: 389
[25.03.2022 19:12:52] [INFO   ] Interface Alias: Ethernet 3
[25.03.2022 19:12:52] [INFO   ] Source Interface Address: fe80::a115:42:b57f:8a8e%4
[25.03.2022 19:12:52] [INFO   ] Ping Succeeded: False
[25.03.2022 19:12:52] [INFO   ] Ping Reply Time (RTT) Status: 
[25.03.2022 19:12:52] [INFO   ] Ping Reply Time (RTT) RoundTripTime: 
[25.03.2022 19:12:52] [INFO   ] TCPTestSucceeded: True

Wenn die Einrichtung ein Fehler hinsichtlich Verbindungen erscheint, dann sollten Sie hier direkt sehen, welche Systeme nicht auflösbar oder erreichbar waren.

Start-ConnectivityValidation

Die Verbindungsprüfung können Sie aber auch manuell ausführen. Schon nach der Installation von ADSync wurde das PowerShell-Modul "ADConnectivityTool" mit installiert, welches sie mit "ImportModule" einfach einbinden können:

Import-Module C:\Program Files\Microsoft Azure Active Directory Connect\Tools\ADConnectivityTool.psm1

 

 

 

Um z.B. die Verbindung zu einem Forest zu prüfen, können Sie folgende Befehle nutzen:

# Zielforest per DNS auflösen und per ICMP-Ping auf Erreichbarkeit prüfen
Confirm-TargetsAreReachable -Forest "uclabor.de" 

# Check des Forest Functional Levels
Confirm-FunctionalLevel `
   -Forest "uclabor.de" `
   -RunWithCurrentlyLoggedInUserCredentials `
   -Verbose 

Confirm-DnsConnectivity -Forest "uclabor.de"

# Kontrolle der Erreichbarkeit von 53(DNS), 88(KDC) und 389(LDAP)
Confirm-NetworkConnectivity `
   -DCs "DC01.uclabor.de","DC02.uclabor.de"

Viel Hexerei steckt natürlich nicht hinter den Commandlets. Aber sie können schnell helfen, wenn z.B. ihre Netzwerker die Firewall umbauen und danach einige Dinge nicht mehr wie erwartet funktionieren.

Wer mag, kann natürlich die ganzen Checks auch als eigene PowerShell-Skripte umsetzen und in das eigene Monitoring einbinden. So könnten Sie ihr Monitoring entsprechend erweitern.

Weitere Links