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 Aufgaben der Active-Directory-Umgebung.

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, Lizenz und Rollen

Vor der Konfiguration müssen folgende Voraussetzungen erfüllt sein:

Sophos Fusion (ehemals 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-Richtlinie.
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 Fusion 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.

Vor der Änderung kontrollieren, dass ZTNA > Ressourcen und Zugriff im Tenant verfügbar ist und das verwendete Administratorkonto dort Ressourcen hinzufügen und bearbeiten darf. Fehlt der Menüpunkt oder die Schaltfläche, nicht mit einer vermuteten Rolle oder Lizenz weiterarbeiten, sondern die ZTNA-Berechtigung und den gebuchten Umfang im eigenen Tenant beziehungsweise mit dem zuständigen Sophos-Partner klären.

Wie Sie Ressourcen hinzufügen: jeden Domain Controller anlegen

Jeder DC wird einzeln als Domänen-Controller mit agentenbasierter Zugriffsmethode angelegt:

In Sophos Fusion Meine Produkte > ZTNA > Ressourcen und Zugriff öffnen und Ressource hinzuzufügen wählen.
Einen eindeutigen Namen und eine kurze Beschreibung eintragen, beispielsweise dc01-example und Domain Controller Standort Zürich.
Ressource im Benutzerportal anzeigen entsprechend dem gewünschten Benutzerzugriff aktiviert lassen.
Das zuständige Gateway auswählen.
Als Zugriffsmethode den Wert Agent wählen und die passende agentenbasierte Richtlinie zuordnen.
Als Ressourcentyp den Wert Domänen-Controller (DC) wählen.
Unter Externer FQDN den vollständigen Namen dieses DCs eintragen, beispielsweise dc01.example.com – nicht nur die Root-Domain example.com.
Interner FQDN/IP-Adresse nur eintragen, wenn das interne Ziel vom externen FQDN abweicht. Ohne Wert übernimmt Sophos automatisch den externen FQDN.
Die automatisch eingetragenen Ports prüfen und nur um Dienste ergänzen, die diese Umgebung wirklich benötigt.
Unter Erweiterte Domänencontroller-Einstellungen die SRV-Einträge kontrollieren.
Unter Benutzergruppen zuweisen alle Gruppen von Verfügbare Benutzergruppen nach Zugewiesene Benutzergruppen verschieben, die Ressourcen hinter diesem DC benötigen.
Speichern wählen und den DC anschliessend mit einem Windows-Pilotgerät testen.

Agentenlose Ressourcen und Agentenbasierte Ressourcen benötigen unterschiedliche DNS-Einträge. Für eine agentenbasierte DC-Ressource erzeugt Sophos keine Alias-Domäne. Für den DC dürfen deshalb weder ein öffentlicher CNAME noch ein Wildcard-DNS-Eintrag angelegt werden; auch der Externe 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. IP-basierter Zugriff wird dadurch nicht automatisch erfasst.

DNS-Einträge und 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.

Sophos nennt für diesen Ressourcentyp zusätzlich folgende Ports:

TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
UDP: 88, 389, 464, 636, 4389, 63664 (in der deutschsprachigen Sophos-Hilfe ist die Zeile mit UCP beschriftet)

Die allgemeine Ressourcenmaske fordert: Geben Sie Porttyp und Portnummer an (zum Beispiel für eine Web-App HTTPS und 443). Für einen Domain Controller sind stattdessen die benötigten TCP- und UDP-Dienste massgeblich.

Die ungewöhnlichen UDP-Werte nicht ungeprüft als allgemeine AD-Empfehlung übernehmen. Sie stammen aus der aktuellen Sophos-Ressourcenanleitung; massgeblich bleibt, welche Dienste der eigene DC tatsächlich anbietet und welche Verbindungen die eigene AD-Funktion benötigt. Eine Ressource kann insgesamt bis zu 20 TCP- und UDP-Portangaben enthalten; Bereiche werden mit Bindestrich und mehrere Angaben kommagetrennt erfasst, beispielsweise 49152-65535.

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

die automatisch vorbelegten Ports in der aktuellen Sophos-Central-Oberfläche,
die unter Erweiterte Domänencontroller-Einstellungen 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.

Für latenzempfindliche CIFS- oder SMB-Dateifreigaben empfiehlt Sophos ein lokales Gateway. Das ändert nichts an der erforderlichen Port- und Funktionsprüfung, verkürzt aber den Datenpfad gegenüber einem Cloud Gateway.

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 Erweiterte Domänencontroller-Einstellungen ab.

Die wichtigsten Felder sind:

Dienste: AD-Dienst, beispielsweise LDAP oder Kerberos.
Domänenname: DNS-Domain, für die der SRV-Eintrag gilt.
Protocol: TCP oder UDP.
Portnummern: Port des jeweiligen Dienstes, beispielsweise 389 für LDAP oder 88 für Kerberos.
Priorität: Kleinere Zahl bedeutet höhere Priorität. DCs mit der niedrigsten verfügbaren Priorität werden zuerst verwendet.
Gewichtung: 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.

Anwendungsbeispiel 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: Priorität 1, Gewichtung 60
dc02.example.com: Priorität 1, Gewichtung 40
dc03.example.com: Priorität 2

dc01 und dc02 gehören durch die gleiche Priorität zur bevorzugten Gruppe. Die Gewichtung steuert ihre ungefähre Auswahl im Verhältnis 60 zu 40. dc03 mit Priorität 2 wird erst berücksichtigt, wenn kein DC mit Priorität 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 Priorität und Gewichtung 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 keine produktiven DCs abschalten. Stattdessen mit zwei zeitlich begrenzten, auf das Pilotgerät beschränkten Netzwerkregeln die Pfade zu dc01.example.com und dc02.example.com isolieren, ohne andere Clients zu beeinflussen. TTL und lokale DNS- sowie DC-Caches können die Umschaltung verzögern; deshalb die konfigurierte TTL und die Cache-Verzögerung im Testzeitplan berücksichtigen.

Während beide DCs mit Priorität 1 isoliert sind, mit Resolve-DnsName bestätigen, dass die SRV-Antwort dc03.example.com mit Priorität 2 enthält, mit nltest /dsgetdc:example.com /force die Auswahl von dc03 nachweisen und den echten AD-abhängigen Anmelde- oder Anwendungsablauf erfolgreich ausführen. Danach beide Testregeln entfernen, die Cache-Verzögerung erneut berücksichtigen und mit SRV-Auflösung, nltest und demselben Ablauf bestätigen, dass wieder dc01 oder dc02 aus der Prioritätsgruppe 1 ausgewählt wird.

Wenn kein Domain Controller erreichbar ist

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

Ist jeder DC als Ressource mit Zugriffsmethode: Agent und Ressourcentyp: Domänen-Controller (DC) angelegt?
Verwendet Externer FQDN den konkreten DC-Namen und nicht nur die AD-Domain?
Stimmen Domain, Dienst, Protokoll, Port, Priorität und Gewichtung 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 Richtlinie 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 Fusion?

Zugriff per FQDN scheitert, per IP-Adresse funktioniert er

Der ZTNA Agent fängt Ressourcen nur auf FQDN-Basis ab. Ein direkter IP-Zugriff kann deshalb an ZTNA vorbeigehen und ist kein erfolgreicher ZTNA-Test. Den Zugriff mit dem unter Externer FQDN eingetragenen Namen wiederholen. Wenn Benutzer interne Ressourcen zwingend über ZTNA erreichen sollen, muss der direkte IP-Pfad zusätzlich mit passenden Firewallregeln verhindert werden.

Eine umbenannte Entra-ID-Gruppe hat keinen Zugriff mehr

Wird eine bereits zugewiesene Microsoft-Entra-ID-Gruppe später umbenannt, aktualisiert Sophos die Gruppenliste der Ressource nicht automatisch. Die betroffene Gruppe unter Benutzergruppen zuweisen erneut zuweisen, speichern und den Zugriff mit einem Mitglied dieser Gruppe testen.

Der externe FQDN ist öffentlich auflösbar

Bei einer agentenbasierten Ressource darf der externe FQDN nicht öffentlich verfügbar sein. Das ist der umgekehrte Fall zu einer agentenlosen Ressource, deren externer FQDN öffentlich verfügbar sein muss. DNS-Veröffentlichung und Zugriffsmethode deshalb gemeinsam prüfen; für die hier beschriebene DC-Ressource bleibt die Zugriffsmethode Agent.

Mehrere Benutzer verlieren sporadisch die AD-Verbindung

ZTNA Gateway 2.2 hat den bekannten Fehler NZT-10022: Der Gateway-Websocket-Server kann grosse AD-Pakete sporadisch verwerfen. Dadurch verlieren mehrere Benutzer scheinbar zufällig die AD-Verbindung, oder Kerberos, RDP, Windows-Dateifreigaben und andere AD-gestützte Anwendungen reagieren langsam oder schlagen fehl. Der begrenzte Workaround ist eine MTU von 1420 Byte am Sophos-ZTNA-TAP-Adapter des betroffenen Endpoints; diesen Wert nicht vorsorglich auf allen Geräten setzen.

Die Änderung zuerst auf einem Pilotgerät und in einer PowerShell mit Administratorrechten durchführen. Vorher Alias und ursprüngliche MTU für IPv4 und IPv6 notieren:

Get-NetIPInterface | Where-Object InterfaceAlias -Like '*Sophos*ZTNA*TAP*' | Format-Table InterfaceAlias, AddressFamily, NlMtuBytes

<TAP-ALIAS> durch den angezeigten Alias ersetzen, die MTU setzen und den wirksamen Wert kontrollieren:

Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -NlMtuBytes 1420
Get-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' | Format-Table InterfaceAlias, AddressFamily, NlMtuBytes

Danach die ZTNA-Verbindung neu aufbauen und genau den zuvor fehlerhaften Kerberos-, RDP- oder Dateifreigabe-Vorgang mehrfach wiederholen. Bleibt der Fehler bestehen oder treten andere Verbindungsprobleme auf, mit den zuvor notierten Werten zurückgehen; <ORIGINAL_MTU> dabei je Adressfamilie durch deren ursprünglichen Wert ersetzen:

Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -AddressFamily IPv4 -NlMtuBytes <ORIGINAL_MTU>
Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -AddressFamily IPv6 -NlMtuBytes <ORIGINAL_MTU>

Liefert die erste Abfrage keinen Adapter, mit Get-NetAdapter den exakten Alias ermitteln und nicht irgendeine andere Schnittstelle ändern. Springt die MTU nach Neuverbindung oder Neustart zurück oder hilft 1420 nicht eindeutig, den Wert nicht weiter absenken. Stattdessen Gateway- und Endpoint-Version, betroffene Benutzer und Dienste, Zeitstempel, die MTU vor und nach der Änderung sowie eine Paketaufzeichnung sammeln und den Fall mit NZT-10022 eskalieren.

Die Portanforderungen der verwendeten Windows-Dienste beschreibt Microsoft unter Service overview and network port requirements.

Sicherer Rückweg und Offboarding

Eine DC-Ressource nicht während einer laufenden Anmeldung oder eines produktiven Failover-Tests entfernen. Zuerst festhalten, welche Benutzergruppen, Ports, SRV-Einträge, Priorität und Gewichtung zugewiesen sind, und prüfen, ob noch mindestens ein getesteter DC derselben Prioritätsgruppe beziehungsweise der vorgesehene Ausweich-DC erreichbar bleibt.

Zum Zurücknehmen einer Änderung Meine Produkte > ZTNA > Ressourcen und Zugriff öffnen und den Namen der Ressource wählen. Dort lassen sich die Ressourcendetails bearbeiten oder die Ressource entfernen. Eine fehlerhafte Änderung an Ports, SRV-Werten oder Gruppen zunächst auf die notierten Ausgangswerte zurücksetzen und speichern. Eine Ressource erst entfernen, wenn ihr FQDN nicht mehr von Benutzern oder Anwendungen benötigt wird.

Danach auf dem Pilotgerät die SRV-Auflösung, nltest /dsgetdc:example.com /force und den betroffenen Anmelde- oder Anwendungsablauf erneut prüfen. Bleibt kein getesteter DC erreichbar, vor dem Entfernen stoppen und mit den gesicherten Werten eskalieren. Eine abgeschlossene Entfernung lässt sich nicht rückgängig machen. Wurde die Ressource bereits entfernt, darf ein qualifizierter Administrator sie nur anhand der gesicherten Einstellungen manuell neu erstellen, die Gruppen erneut zuweisen und anschliessend die vollständige Validierung wiederholen. Wenn Identität oder Zustand der Ressource erhalten bleiben müssen oder die Aufzeichnungen unvollständig sind, nicht neu erstellen, sondern den Fall eskalieren.

Betrieb, Review und Lifecycle

Priorität, Gewichtung und TTL gehören in die Betriebsdokumentation der AD-Umgebung. Die Zuordnung nach Änderungen an DC-Standorten, FQDNs, angebotenen Diensten, Ports oder Benutzergruppen erneut prüfen. Bei einer umbenannten Entra-ID-Gruppe ist die erneute Zuweisung ein eigener Betriebsschritt; eine automatische Aktualisierung findet nicht statt.

Für diese Funktion ist keine konkrete Migrations-, Ablösungs- oder End-of-Life-Anweisung dokumentiert. Bei Produktupdates zuerst die aktuelle Ressourcenhilfe und die im Tenant sichtbaren Felder prüfen und Änderungen wieder auf einem begrenzten Pilotgerät validieren.