Meerdere Domain Controllers instellen met Sophos ZTNA

Wanneer Windows-apparaten Active Directory via Sophos ZTNA moeten bereiken, vormt één Domain Controller een vermijdbaar single point of failure. Vanaf Sophos Endpoint 2026.1 ondersteunt ZTNA meerdere DC-resources met prioriteit en weging. Zo kunnen twee Domain Controllers tijdens normaal gebruik worden ingezet en kan een derde DC als uitwijkdoel dienen.

Elke Domain Controller wordt hiervoor als afzonderlijke agentgebaseerde resource van het type Domain Controller (DC) aangemaakt. Sophos ZTNA verzorgt de verbinding en beantwoordt de bijbehorende DNS-SRV-query’s op het endpoint. De bestaande AD-structuur, DNS-resolutie en vertrouwensrelaties blijven de verantwoordelijkheid van de Active Directory-omgeving.

DC-resources en Identity Provider onderscheiden

Meerdere DC-resources betekenen niet automatisch dat de ZTNA Identity Provider gebruikers uit meerdere onafhankelijke AD-domeinen kan authenticeren.

DC-resources transporteren DNS-, Kerberos-, LDAP- en ander benodigd AD-verkeer door de ZTNA-tunnel.
De Identity Provider authenticeert de gebruiker voor ZTNA. Bij de lokale Microsoft AD Identity Provider ondersteunt Sophos nog steeds één domein; Primary en Secondary AD Server moeten tot hetzelfde domein behoren.
AD DNS en Forest Trusts moeten al functioneren. ZTNA maakt geen DNS-forwarding, vertrouwensrelaties of domeinoverschrijdende gebruikerssynchronisatie aan.

De functie is daarmee direct geschikt voor meerdere DC’s binnen hetzelfde domein. Bij meerdere domeinen of forests moet daarnaast worden gecontroleerd of de Identity Provider, DNS en bestaande trusts de geplande toegang daadwerkelijk ondersteunen.

Vereisten, licentie en rollen

Vóór de configuratie moeten de volgende punten zijn geregeld:

Sophos Fusion (voorheen Sophos Central) met een actieve ZTNA-licentie.
Een geconfigureerde ZTNA Gateway die vanaf het endpoint bereikbaar is.
Windows-apparaten met ZTNA Agent en Sophos Endpoint 2026.1 of nieuwer.
Gesynchroniseerde gebruikersgroepen en een passende agentgebaseerde ZTNA Policy.
Een unieke FQDN per Domain Controller, bijvoorbeeld dc01.example.com.
Bereikbaarheid van elke DC vanaf de ZTNA Gateway via de werkelijk benodigde AD-services.
Werkende interne DNS-resolutie en bestaande trusts en DNS-forwarding bij meerdere domeinen of forests.

De endpointversie staat in Sophos Fusion onder My Environment > Computers & Servers > <Apparaat> > Summary. Onder Assigned Products en Installed component versions kan worden gecontroleerd of het pilotapparaat al de vereiste versie gebruikt.

Controleer vóór de wijziging of ZTNA > Resources & Access in de tenant beschikbaar is en of het gebruikte administratoraccount daar resources mag toevoegen en bewerken. Ga bij een ontbrekende menuoptie of knop niet verder op basis van een veronderstelde rol of licentie, maar controleer de ZTNA-machtiging en de afgenomen functionaliteit in de eigen tenant of bij de verantwoordelijke Sophos-partner.

Resources toevoegen: elke Domain Controller aanmaken

Maak elke DC afzonderlijk aan als Domain Controller met agentgebaseerde toegangsmethode:

Open in Sophos Fusion My Products > ZTNA > Resources & Access en selecteer Add Resource.
Voer een unieke naam en een korte beschrijving in, bijvoorbeeld dc01-example en Domain Controller locatie Zürich.
Laat Show resource in user portal ingeschakeld overeenkomstig de gewenste gebruikerstoegang.
Selecteer de verantwoordelijke Gateway.
Selecteer voor Access method de waarde Agent en wijs de passende agentgebaseerde Policy toe.
Selecteer voor Resource type de waarde Domain Controller (DC).
Voer onder External FQDN de volledige naam van deze DC in, bijvoorbeeld dc01.example.com – niet alleen het rootdomein example.com.
Vul Internal FQDN/IP address alleen in als het interne doel afwijkt van de External FQDN. Zonder waarde gebruikt Sophos automatisch de External FQDN.
Controleer de automatisch ingevulde poorten en voeg alleen services toe die deze omgeving werkelijk nodig heeft.
Controleer onder Advanced Domain Controller settings de SRV-records.
Verplaats onder Assign User Groups alle groepen die resources achter deze DC nodig hebben van Available User Groups naar Assigned User Groups.
Selecteer Save en test de DC vervolgens met een Windows-pilotapparaat.

Agentloze resources en agentgebaseerde resources vereisen verschillende DNS-records. Sophos maakt voor een agentgebaseerde DC-resource geen aliasdomein aan. Daarom mogen voor de DC geen publieke CNAME en geen wildcard-DNS-record worden aangemaakt; ook mag de External FQDN niet publiek beschikbaar zijn. Een Gateway-CNAME dat voor de Sophos Cloud Gateway nodig is, blijft hiervan uitgezonderd. De ZTNA Agent onderschept de geconfigureerde FQDN op het endpoint. IP-gebaseerde toegang wordt daardoor niet automatisch onderschept.

DNS-records en poorten afstemmen op de omgeving

Het resourcetype Domain Controller (DC) vult automatisch een reeks poorten in. Deze lijst is een uitgangspunt, maar vervangt niet de controle van de werkelijk gebruikte AD-functies. Een eenvoudige LDAP-test vereist andere verbindingen dan een aanmelding met Kerberos, groepsbeleid, DNS, SMB of dynamische RPC.

Sophos noemt voor dit resourcetype bovendien de volgende poorten:

TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
UDP: 88, 389, 464, 636, 4389, 63664 (in de Duitstalige Sophos-help heet deze regel UCP)

Het algemene resourceformulier vraagt om Specify the port type and port number (bijvoorbeeld HTTPS en 443 voor een web-app). Voor een Domain Controller zijn in plaats daarvan de benodigde TCP- en UDP-services bepalend.

Neem de ongebruikelijke UDP-waarden niet zonder controle over als algemene AD-aanbeveling. Ze komen uit de huidige Sophos-resourcehandleiding; bepalend blijft welke services de eigen DC werkelijk aanbiedt en welke verbindingen de AD-functie nodig heeft. Een resource kan in totaal maximaal 20 TCP- en UDP-poortvermeldingen bevatten. Voer bereiken in met een koppelteken en scheid meerdere vermeldingen met komma’s, bijvoorbeeld 49152-65535.

Statische poortlijsten mogen daarom niet blind worden overgenomen. Doorslaggevend zijn:

de automatisch ingevulde poorten in de actuele Sophos Fusion-interface,
de services en poorten die onder Advanced Domain Controller settings worden gebruikt,
de Microsoft-poortvereisten voor de AD-functies die in deze omgeving worden gebruikt,
de bereikbaarheid van deze poorten vanaf de ZTNA Gateway naar de betreffende DC.

Als een vereiste poort ontbreekt in het normale poortveld van de resource, is een passend SRV-record in de geavanceerde instellingen alleen niet voldoende. De verbinding kan dan ondanks een correct DNS-antwoord mislukken.

Voor latentiegevoelige CIFS- of SMB-bestandsshares adviseert Sophos een lokale gateway. Dit verandert niets aan de vereiste poort- en functiecontrole, maar verkort het gegevenspad ten opzichte van een Cloud Gateway.

SRV-prioriteit en -weging begrijpen

Active Directory gebruikt DNS-SRV-records zodat clients een geschikte service en Domain Controller kunnen vinden. Sophos ZTNA legt deze records vast onder Advanced Domain Controller settings.

De belangrijkste velden zijn:

Services: AD-service, bijvoorbeeld LDAP of Kerberos.
Domain name: DNS-domein waarvoor het SRV-record geldt.
Protocol: TCP of UDP.
Port numbers: Poort van de betreffende service, bijvoorbeeld 389 voor LDAP of 88 voor Kerberos.
Priority: Een lager getal betekent een hogere prioriteit. DC’s met de laagste beschikbare prioriteit worden eerst gebruikt.
Weight: Verdeelt de selectie tussen DC’s met dezelfde prioriteit.
TTL: Tijd in seconden waarin een antwoord in de cache mag blijven. De standaardwaarde 86400 komt overeen met 24 uur.

De prioriteit bepaalt dus de voorkeursgroep. De weging beïnvloedt alleen de selectie binnen dezelfde groep. Ze garandeert geen exacte procentuele verdeling van het verkeer, omdat DNS-cache, clientgedrag en het aantal query’s het resultaat mede bepalen.

Voorbeeld met twee actieve DC’s en één uitwijk-DC

Voor het domein example.com moet de normale belasting over twee DC’s worden verdeeld. Een derde DC wordt alleen als uitwijkdoel gebruikt:

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

Door dezelfde Priority behoren dc01 en dc02 tot de voorkeursgroep. De weging stuurt hun geschatte selectie in een verhouding van 60 tot 40. dc03 met Priority 2 wordt pas meegenomen wanneer geen DC met Priority 1 beschikbaar is.

Alle drie de resources hebben passende SRV-records nodig voor hetzelfde domein en de werkelijk benodigde services. De hogere numerieke waarde 2 en daarmee de lagere selectieprioriteit maken dc03 echter niet automatisch tot een volledige vervanging: replicatie, DNS, de Global Catalog-rol en bereikbare AD-services moeten eveneens aansluiten op de beoogde failover.

Werking op een Windows-apparaat testen

Controleer eerst het SRV-antwoord voor het gewenste domein:

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

Het antwoord moet de geconfigureerde Domain Controllers met Priority en Weight bevatten. Forceer vervolgens een nieuwe DC-zoekopdracht:

nltest /dsgetdc:example.com /force

nltest toont de geselecteerde bereikbare DC, maar niet noodzakelijk alle beschikbare doelen. De verbinding met afzonderlijke services kan daarom aanvullend worden getest:

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

Poort 389 test in dit voorbeeld LDAP via TCP. Voor Kerberos, DNS, SMB of RPC moeten tests volgen die passen bij het werkelijke gebruiksscenario. Een volledige acceptatietest omvat bovendien een echte Windows-aanmelding of toegang tot de toepassing die AD via ZTNA nodig heeft.

Voor een packet capture op het endpoint toont dit Wireshark-filter uitsluitend DNS-SRV-query’s:

dns.qry.type == 33

Een failovertest hoort op een pilotapparaat en in een onderhoudsvenster. Schakel geen productie-DC’s uit. Gebruik in plaats daarvan twee tijdelijke netwerkregels die alleen voor het pilotapparaat gelden om de paden naar dc01.example.com en dc02.example.com te isoleren zonder andere clients te beïnvloeden. TTL en lokale DNS- en DC-caches kunnen de failover vertragen; houd daarom in de testplanning rekening met de geconfigureerde TTL en cachevertraging.

Gebruik terwijl beide DC’s met Priority 1 zijn geïsoleerd Resolve-DnsName om te bevestigen dat het SRV-antwoord dc03.example.com met Priority 2 bevat, gebruik nltest /dsgetdc:example.com /force om aan te tonen dat dc03 wordt geselecteerd en voltooi de echte AD-afhankelijke aanmelding of toepassingsworkflow met succes. Verwijder vervolgens beide testregels, houd opnieuw rekening met de cachevertraging en bevestig met SRV-resolutie, nltest en dezelfde workflow dat de selectie terugkeert naar dc01 of dc02 in de Priority 1-groep.

Wanneer geen Domain Controller bereikbaar is

Controleer bij een storing in deze volgorde:

Is elke DC aangemaakt als resource met Access method: Agent en Resource type: Domain Controller (DC)?
Gebruikt External FQDN de concrete DC-naam en niet alleen het AD-domein?
Kloppen domein, service, protocol, poort, Priority en Weight van de SRV-records?
Zijn alle daar gebruikte poorten ook opgenomen in het normale poortveld van de resource?
Kan de ZTNA Gateway elke DC via deze poorten bereiken?
Zijn pilotgebruikers, groepen en Policy correct toegewezen?
Draait op het Windows-apparaat Sophos Endpoint 2026.1 of nieuwer?
Tonen Resolve-DnsName, nltest en dns.qry.type == 33 dezelfde DC’s als Sophos Fusion?

Toegang via FQDN mislukt, maar via het IP-adres werkt deze

De ZTNA Agent onderschept resources alleen op FQDN-basis. Rechtstreekse IP-toegang kan ZTNA daarom omzeilen en is geen geslaagde ZTNA-test. Herhaal de toegang met de naam die onder External FQDN is ingevoerd. Als gebruikers interne resources uitsluitend via ZTNA mogen bereiken, blokkeer dan ook het rechtstreekse IP-pad met passende firewallregels.

Een hernoemde Entra ID-groep heeft geen toegang meer

Als een al toegewezen Microsoft Entra ID-groep later wordt hernoemd, werkt Sophos de groepslijst van de resource niet automatisch bij. Wijs de betrokken groep opnieuw toe onder Assign User Groups, sla op en test de toegang met een lid van die groep.

De externe FQDN is publiek oplosbaar

Bij een agentgebaseerde resource mag de externe FQDN niet publiek beschikbaar zijn. Dit is het tegenovergestelde van een agentloze resource, waarvan de externe FQDN publiek beschikbaar moet zijn. Controleer daarom DNS-publicatie en Access method samen; voor de hier beschreven DC-resource blijft de toegangsmethode Agent.

Meerdere gebruikers verliezen sporadisch de AD-verbinding

ZTNA Gateway 2.2 heeft het bekende probleem NZT-10022: de websocketserver van de gateway kan grote AD-pakketten sporadisch verwerpen. Daardoor kunnen meerdere gebruikers schijnbaar willekeurig de AD-verbinding verliezen, of kunnen Kerberos, RDP, Windows-bestandsshares en andere AD-afhankelijke toepassingen traag reageren of mislukken. De beperkte workaround is een MTU van 1420 bytes op de Sophos ZTNA TAP-adapter van het betrokken endpoint; stel deze waarde niet preventief in op alle apparaten.

Voer de wijziging eerst uit op een pilotapparaat vanuit PowerShell met administratorrechten. Noteer vooraf de alias en de oorspronkelijke MTU voor IPv4 en IPv6:

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

Vervang <TAP-ALIAS> door de weergegeven alias, stel de MTU in en controleer de effectieve waarde:

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

Maak daarna opnieuw verbinding met ZTNA en herhaal de Kerberos-, RDP- of bestandssharehandeling die eerder mislukte enkele keren. Herstel de genoteerde waarden als de storing blijft bestaan of andere verbindingsproblemen optreden; vervang <ORIGINAL_MTU> door de oorspronkelijke waarde van elke adresfamilie:

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

Als de eerste query geen adapter oplevert, gebruikt u Get-NetAdapter om de exacte alias vast te stellen en wijzigt u geen andere interface. Als de MTU na opnieuw verbinden of herstarten terugspringt, of 1420 niet duidelijk helpt, verlaagt u deze niet verder. Verzamel in plaats daarvan de gateway- en endpointversies, betrokken gebruikers en services, tijdstempels, de MTU voor en na de wijziging en een pakketopname, en escaleer de case met NZT-10022.

Microsoft beschrijft de poortvereisten van de gebruikte Windows-services onder Service overview and network port requirements.

Veilig terugdraaien en buiten gebruik stellen

Verwijder een DC-resource niet tijdens een lopende aanmelding of een productieve failovertest. Noteer eerst de toegewezen gebruikersgroepen, poorten, SRV-records, Priority en Weight en controleer of ten minste één geteste DC uit dezelfde prioriteitsgroep of de beoogde uitwijk-DC bereikbaar blijft.

Open om een wijziging terug te draaien My Products > ZTNA > Resources & Access en selecteer de resource name. Daar kunt u de resourcedetails bewerken of de resource verwijderen. Zet een onjuiste wijziging aan poorten, SRV-waarden of groepen eerst terug naar de genoteerde beginwaarden en sla deze op. Verwijder een resource pas als gebruikers en toepassingen de FQDN niet meer nodig hebben.

Controleer daarna op het pilotapparaat opnieuw de SRV-resolutie, nltest /dsgetdc:example.com /force en het betrokken aanmeldings- of toepassingsproces. Stop vóór verwijdering en escaleer met de opgeslagen waarden als geen geteste DC bereikbaar blijft. Een voltooide verwijdering kan niet ongedaan worden gemaakt. Als de resource al is verwijderd, mag alleen een gekwalificeerde beheerder deze handmatig opnieuw maken aan de hand van de genoteerde instellingen, de groepen opnieuw toewijzen en daarna de volledige validatie herhalen. Maak de resource niet opnieuw als de identiteit of status ervan behouden moet blijven of als de gegevens onvolledig zijn; escaleer dan de case.

Beheer, review en lifecycle

Priority, Weight en TTL horen in de operationele documentatie van de AD-omgeving. Controleer de toewijzing opnieuw na wijzigingen aan DC-locaties, FQDN’s, aangeboden services, poorten of gebruikersgroepen. Het opnieuw toewijzen van een hernoemde Entra ID-groep is een afzonderlijke beheerhandeling; er vindt geen automatische update plaats.

Voor deze functie is geen specifieke instructie voor migratie, uitfasering of end-of-life gedocumenteerd. Controleer na productupdates eerst de actuele resourcehelp en de in de tenant zichtbare velden, en valideer wijzigingen vervolgens opnieuw op een beperkt pilotapparaat.

Gerelateerde bestaande handleidingen

Voor de algemene installatievolgorde is eerst Sophos ZTNA instellen: overzicht en volgorde van toepassing. De planning, DNS en bereikbaarheid van de gateway staan beschreven in Sophos ZTNA Gateway plannen en aanmaken.