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.

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.

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

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

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 Central 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.

Elke Domain Controller als resource aanmaken

Voor elke DC wordt een afzonderlijke resource aangemaakt:

Open in Sophos Central 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.
Selecteer de verantwoordelijke Gateway.
Selecteer voor Access method de waarde Agent.
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 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.
Wijs onder Assign User Groups de groepen toe die AD-services via deze DC nodig hebben.
Sla de configuratie op en test de DC vervolgens met een Windows-pilotapparaat.

Sophos maakt geen Resource Alias aan voor een agentgebaseerde DC-resource. 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. Rechtstreekse toegang via het IP-adres wordt daardoor niet automatisch onderschept.

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.

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

de automatisch ingevulde poorten in de actuele Sophos Central-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.

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 daarvoor geen productieve DC uit, maar onderbreek het primaire pad gecontroleerd en uitsluitend voor de test. Controleer daarna opnieuw nltest, de SRV-resolutie en de betrokken toepassing. Bij wijzigingen aan Priority of Weight kunnen TTL en lokale DNS-caches het resultaat vertragen.

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 Central?

Voor ZTNA Gateway 2.2 vermeldt Sophos in de actuele Known Issues List bovendien NZT-10022: grote AD-pakketten kunnen sporadisch worden verworpen. Mogelijke symptomen zijn onbetrouwbare Kerberos-, RDP- of bestandsdelingsverbindingen. Als workaround noemt Sophos een MTU van 1420 bytes voor de Sophos ZTNA TAP-adapter. Deze wijziging hoort alleen bij dit specifieke foutbeeld en mag niet preventief op alle apparaten worden toegepast.

De officiële veldbeschrijving en de actuele interface staan bij Sophos onder Add resources. Microsoft beschrijft de poortvereisten van de gebruikte Windows-services onder Service overview and network port requirements.