Mehrere Domain Controller mit Sophos ZTNA einrichten

Wenn Windows-Geräte Active Directory über Sophos ZTNA erreichen müssen, bildet ein einzelner Domain Controller einen vermeidbaren Single Point of Failure. Ab Sophos Endpoint 2026.1 unterstützt ZTNA mehrere DC-Ressourcen mit Priorität und Gewichtung. So lassen sich zwei Domain Controller im Normalbetrieb verwenden und ein weiterer DC als Ausweichziel vorsehen.

Jeder Domain Controller wird dafür als eigene agentenbasierte Ressource vom Typ Domain Controller (DC) angelegt. Sophos ZTNA stellt die Verbindung bereit und beantwortet die passenden DNS-SRV-Abfragen auf dem Endpoint. Die vorhandene AD-Struktur, DNS-Auflösung und Vertrauensstellungen bleiben weiterhin Aufgabe der Active-Directory-Umgebung.

Für die allgemeine Einrichtungsreihenfolge passt zuerst Sophos ZTNA einrichten: Überblick und Reihenfolge. Planung, DNS und Erreichbarkeit des Gateways beschreibt Sophos ZTNA Gateway planen und erstellen.

DC-Ressourcen und Identity Provider unterscheiden

Mehrere DC-Ressourcen bedeuten nicht automatisch, dass der ZTNA Identity Provider Benutzer aus mehreren unabhängigen AD-Domains authentifizieren kann.

DC-Ressourcen transportieren DNS-, Kerberos-, LDAP- und weiteren benötigten AD-Verkehr durch den ZTNA-Tunnel.
Der Identity Provider authentifiziert den Benutzer für ZTNA. Beim lokalen Microsoft-AD-Identity-Provider unterstützt Sophos weiterhin eine Domain; Primary und Secondary AD Server müssen zu derselben Domain gehören.
AD DNS und Forest Trusts müssen bereits funktionieren. ZTNA erstellt keine DNS-Weiterleitungen, Vertrauensstellungen oder domänenübergreifende Benutzersynchronisierung.

Damit eignet sich die Funktion direkt für mehrere DCs derselben Domain. Bei mehreren Domains oder Forests muss zusätzlich geprüft werden, ob Identity Provider, DNS und bestehende Trusts den geplanten Zugriff tatsächlich unterstützen.

Voraussetzungen

Vor der Konfiguration sollten folgende Punkte erfüllt sein:

Sophos Central mit aktiver ZTNA-Lizenz.
Ein eingerichtetes und vom Endpoint erreichbares ZTNA Gateway.
Windows-Geräte mit ZTNA Agent und Sophos Endpoint 2026.1 oder neuer.
Synchronisierte Benutzergruppen und eine passende agentenbasierte ZTNA Policy.
Ein eindeutiger FQDN pro Domain Controller, beispielsweise dc01.example.com.
Erreichbarkeit jedes DCs vom ZTNA Gateway über die tatsächlich benötigten AD-Dienste.
Funktionierende interne DNS-Auflösung sowie vorhandene Trusts und DNS-Weiterleitungen bei mehreren Domains oder Forests.

Die Endpoint-Version steht in Sophos Central unter My Environment > Computers & Servers > <Gerät> > Summary. Unter Assigned Products und Installed component versions lässt sich prüfen, ob das Pilotgerät bereits die benötigte Version verwendet.

Jeden Domain Controller als Ressource anlegen

Für jeden DC wird eine eigene Ressource erstellt:

In Sophos Central My Products > ZTNA > Resources & Access öffnen und Add Resource wählen.
Einen eindeutigen Namen und eine kurze Beschreibung eintragen, beispielsweise dc01-example und Domain Controller Standort Zürich.
Das zuständige Gateway auswählen.
Als Access method den Wert Agent wählen.
Die passende agentenbasierte Policy zuordnen.
Als Resource type den Wert Domain Controller (DC) wählen.
Unter External FQDN den vollständigen Namen dieses DCs eintragen, beispielsweise dc01.example.com – nicht nur die Root-Domain example.com.
Internal FQDN/IP address nur eintragen, wenn das interne Ziel vom External FQDN abweicht. Ohne Wert verwendet Sophos den External FQDN.
Die automatisch eingetragenen Ports prüfen und nur um Dienste ergänzen, die diese Umgebung wirklich benötigt.
Unter Advanced Domain Controller settings die SRV-Einträge kontrollieren.
Unter Assign User Groups die Gruppen zuweisen, die AD-Dienste über diesen DC benötigen.
Speichern und den DC anschliessend mit einem Windows-Pilotgerät testen.

Für eine agentenbasierte DC-Ressource erzeugt Sophos keinen Resource Alias. Für den DC dürfen deshalb weder ein öffentlicher CNAME noch ein Wildcard-DNS-Eintrag angelegt werden; auch der External FQDN darf nicht öffentlich verfügbar sein. Ein für das Sophos Cloud Gateway benötigter Gateway-CNAME bleibt davon unberührt. Der ZTNA Agent fängt den konfigurierten FQDN auf dem Endpoint ab. Ein Zugriff direkt über die IP-Adresse wird dadurch nicht automatisch erfasst.

Ports passend zur Umgebung prüfen

Der Ressourcentyp Domain Controller (DC) trägt eine Reihe von Ports automatisch ein. Diese Liste ist ein Ausgangspunkt, aber kein Ersatz für die Prüfung der tatsächlich verwendeten AD-Funktionen. Ein einfacher LDAP-Test braucht andere Verbindungen als eine Anmeldung mit Kerberos, Gruppenrichtlinien, DNS, SMB oder dynamisches RPC.

Statische Portlisten sollten deshalb nicht blind übernommen werden. Entscheidend sind:

die automatisch vorbelegten Ports in der aktuellen Sophos-Central-Oberfläche,
die unter Advanced Domain Controller settings verwendeten Dienste und Ports,
die Microsoft-Portanforderungen für die in dieser Umgebung genutzten AD-Funktionen,
die Erreichbarkeit dieser Ports vom ZTNA Gateway zum jeweiligen DC.

Fehlt ein benötigter Port im normalen Portfeld der Ressource, reicht ein passender SRV-Eintrag in den erweiterten Einstellungen allein nicht aus. Die Verbindung kann dann trotz korrekter DNS-Antwort scheitern.

SRV-Priorität und Gewichtung verstehen

Active Directory verwendet DNS-SRV-Einträge, damit Clients einen passenden Dienst und Domain Controller finden. Sophos ZTNA bildet diese Einträge unter Advanced Domain Controller settings ab.

Die wichtigsten Felder sind:

Services: AD-Dienst, beispielsweise LDAP oder Kerberos.
Domain name: DNS-Domain, für die der SRV-Eintrag gilt.
Protocol: TCP oder UDP.
Port numbers: Port des jeweiligen Dienstes, beispielsweise 389 für LDAP oder 88 für Kerberos.
Priority: Kleinere Zahl bedeutet höhere Priorität. DCs mit der niedrigsten verfügbaren Priorität werden zuerst verwendet.
Weight: Verteilt die Auswahl zwischen DCs mit derselben Priorität.
TTL: Zeit in Sekunden, während der eine Antwort zwischengespeichert werden darf. Der Standardwert 86400 entspricht 24 Stunden.

Die Priorität bestimmt damit die bevorzugte Gruppe. Die Gewichtung beeinflusst nur die Auswahl innerhalb derselben Gruppe. Sie garantiert keine exakte prozentuale Verkehrsverteilung, weil DNS-Cache, Clientverhalten und die Anzahl der Anfragen das Ergebnis mitbestimmen.

Beispiel mit zwei aktiven und einem Ausweich-DC

Für die Domain example.com soll die normale Last auf zwei DCs verteilt werden. Ein dritter DC wird nur als Ausweichziel verwendet:

dc01.example.com: Priority 1, Weight 60
dc02.example.com: Priority 1, Weight 40
dc03.example.com: Priority 2

dc01 und dc02 gehören durch die gleiche Priority zur bevorzugten Gruppe. Die Gewichtung steuert ihre ungefähre Auswahl im Verhältnis 60 zu 40. dc03 mit Priority 2 wird erst berücksichtigt, wenn kein DC mit Priority 1 verfügbar ist.

Alle drei Ressourcen brauchen passende SRV-Einträge für dieselbe Domain und die tatsächlich benötigten Dienste. Der höhere Zahlenwert 2 und damit die niedrigere Auswahlpriorität machen dc03 jedoch nicht automatisch zu einem vollständigen Ersatz: Replikation, DNS, Global-Catalog-Rolle und erreichbare AD-Dienste müssen ebenfalls zum vorgesehenen Failover passen.

Funktion auf einem Windows-Gerät prüfen

Zuerst die SRV-Antwort für die gewünschte Domain kontrollieren:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.example.com

Die Antwort sollte die konfigurierten Domain Controller mit Priority und Weight enthalten. Anschliessend eine neue DC-Suche erzwingen:

nltest /dsgetdc:example.com /force

nltest zeigt den ausgewählten erreichbaren DC, aber nicht zwingend alle verfügbaren Ziele. Die Verbindung zu einzelnen Diensten lässt sich deshalb zusätzlich prüfen:

Test-NetConnection dc01.example.com -Port 389
Test-NetConnection dc02.example.com -Port 389
Test-NetConnection dc03.example.com -Port 389

Port 389 prüft in diesem Beispiel LDAP über TCP. Für Kerberos, DNS, SMB oder RPC müssen die zum realen Anwendungsfall passenden Tests folgen. Eine vollständige Abnahme umfasst ausserdem eine echte Windows-Anmeldung oder den Zugriff auf die Anwendung, die AD über ZTNA benötigt.

Für eine Paketaufzeichnung auf dem Endpoint zeigt dieser Wireshark-Filter ausschliesslich DNS-SRV-Abfragen:

dns.qry.type == 33

Ein Failover-Test gehört auf ein Pilotgerät und in ein Wartungsfenster. Dafür nicht einen produktiven DC abschalten, sondern den primären Pfad kontrolliert nur für den Test unterbrechen. Danach nltest, die SRV-Auflösung und die betroffene Anwendung erneut prüfen. Bei Änderungen an Priority oder Weight können TTL und lokale DNS-Caches das Ergebnis verzögern.

Wenn kein Domain Controller erreichbar ist

Bei einer Störung in dieser Reihenfolge prüfen:

Ist jeder DC als Ressource mit Access method: Agent und Resource type: Domain Controller (DC) angelegt?
Verwendet External FQDN den konkreten DC-Namen und nicht nur die AD-Domain?
Stimmen Domain, Dienst, Protokoll, Port, Priority und Weight der SRV-Einträge?
Sind alle dort verwendeten Ports auch im normalen Portfeld der Ressource enthalten?
Kann das ZTNA Gateway jeden DC über diese Ports erreichen?
Sind Pilotbenutzer, Gruppen und Policy richtig zugewiesen?
Läuft auf dem Windows-Gerät Sophos Endpoint 2026.1 oder neuer?
Zeigen Resolve-DnsName, nltest und dns.qry.type == 33 dieselben DCs wie Sophos Central?

Bei ZTNA Gateway 2.2 führt Sophos in der aktuellen Known Issues List zudem NZT-10022: Grosse AD-Pakete können sporadisch verworfen werden. Mögliche Symptome sind unzuverlässige Kerberos-, RDP- oder Dateifreigabe-Verbindungen. Als Workaround nennt Sophos eine MTU von 1420 Byte für den Sophos-ZTNA-TAP-Adapter. Diese Änderung gehört nur zu diesem konkreten Fehlerbild und sollte nicht vorsorglich auf allen Geräten gesetzt werden.

Die offizielle Feldbeschreibung und jeweils aktuelle Oberfläche stehen bei Sophos unter Add resources. Die Portanforderungen der verwendeten Windows-Dienste beschreibt Microsoft unter Service overview and network port requirements.