Konfigurera flera domänkontrollanter med Sophos ZTNA

När Windows-enheter behöver nå Active Directory via Sophos ZTNA blir en enda domänkontrollant en onödig single point of failure. Från och med Sophos Endpoint 2026.1 stöder ZTNA flera DC-resurser med prioritet och viktning. Därmed kan två domänkontrollanter användas i normal drift och ytterligare en DC fungera som reservmål.

Varje domänkontrollant skapas då som en separat agentbaserad resurs av typen Domain Controller (DC). Sophos ZTNA tillhandahåller anslutningen och besvarar motsvarande DNS-SRV-frågor på endpoint-enheten. Den befintliga AD-strukturen, DNS-upplösningen och förtroenderelationerna förblir en uppgift för Active Directory-miljön.

Skilja mellan DC-resurser och Identity Provider

Flera DC-resurser innebär inte automatiskt att ZTNA Identity Provider kan autentisera användare från flera oberoende AD-domäner.

DC-resurser transporterar DNS-, Kerberos-, LDAP- och annan nödvändig AD-trafik genom ZTNA-tunneln.
Identity Provider autentiserar användaren för ZTNA. Med en lokal Microsoft AD Identity Provider stöder Sophos fortfarande en domän. Primary och Secondary AD Server måste tillhöra samma domän.
AD DNS och Forest Trusts måste redan fungera. ZTNA skapar inte DNS-vidarebefordran, förtroenderelationer eller domänöverskridande användarsynkronisering.

Funktionen lämpar sig därför direkt för flera DC:er i samma domän. Vid flera domäner eller forests måste man dessutom kontrollera om Identity Provider, DNS och befintliga trusts faktiskt stöder den planerade åtkomsten.

Förutsättningar, licens och roller

Följande punkter ska vara uppfyllda före konfigureringen:

Sophos Fusion (tidigare Sophos Central) med en aktiv ZTNA-licens.
En konfigurerad ZTNA Gateway som kan nås från endpoint-enheten.
Windows-enheter med ZTNA Agent och Sophos Endpoint 2026.1 eller senare.
Synkroniserade användargrupper och en lämplig agentbaserad ZTNA Policy.
Ett unikt FQDN för varje domänkontrollant, till exempel dc01.example.com.
Nåbarhet till varje DC från ZTNA Gateway via de AD-tjänster som faktiskt behövs.
Fungerande intern DNS-upplösning samt befintliga trusts och DNS-vidarebefordran vid flera domäner eller forests.

Endpoint-versionen visas i Sophos Fusion under My Environment > Computers & Servers > <Enhet> > Summary. Under Assigned Products och Installed component versions går det att kontrollera om pilotenheten redan använder den version som krävs.

Kontrollera före ändringen att ZTNA > Resources & Access är tillgängligt i klientorganisationen och att administratörskontot som används får lägga till och redigera resurser där. Om menyalternativet eller knappen saknas ska du inte fortsätta utifrån en antagen roll eller licens, utan klarlägga ZTNA-behörigheten och det tecknade omfånget i den egna klientorganisationen eller med ansvarig Sophos-partner.

Så lägger du till resurser: skapa varje domänkontrollant

Skapa varje DC separat som en Domain Controller med agentbaserad åtkomstmetod:

Öppna My Products > ZTNA > Resources & Access i Sophos Fusion och välj Add Resource.
Ange ett unikt namn och en kort beskrivning, till exempel dc01-example och Domänkontrollant på Zürich-kontoret.
Låt Show resource in user portal vara aktiverat enligt önskad användaråtkomst.
Välj ansvarig Gateway.
Välj värdet Agent för Access method och tilldela lämplig agentbaserad Policy.
Välj värdet Domain Controller (DC) för Resource type.
Ange det fullständiga namnet på denna DC under External FQDN, till exempel dc01.example.com – inte bara rotdomänen example.com.
Ange Internal FQDN/IP address endast om det interna målet skiljer sig från External FQDN. Utan något värde använder Sophos automatiskt External FQDN.
Kontrollera portarna som läggs till automatiskt och komplettera endast med tjänster som miljön faktiskt behöver.
Kontrollera SRV-posterna under Advanced Domain Controller settings.
Flytta under Assign User Groups alla grupper som behöver resurser bakom denna DC från Available User Groups till Assigned User Groups.
Välj Save och testa därefter DC:n med en Windows-pilotenhet.

Agentlösa resurser och agentbaserade resurser kräver olika DNS-poster. Sophos skapar ingen aliasdomän för en agentbaserad DC-resurs. Därför får varken en publik CNAME eller en DNS-post med jokertecken skapas för DC:n. External FQDN får inte heller vara publikt tillgängligt. En Gateway-CNAME som krävs för Sophos Cloud Gateway påverkas inte av detta. ZTNA Agent fångar upp det konfigurerade FQDN-namnet på endpoint-enheten. IP-baserad åtkomst fångas därför inte upp automatiskt.

Kontrollera DNS-poster och portar utifrån miljön

Resurstypen Domain Controller (DC) lägger automatiskt till ett antal portar. Listan är en utgångspunkt, men ersätter inte kontrollen av vilka AD-funktioner som faktiskt används. Ett enkelt LDAP-test behöver andra anslutningar än inloggning med Kerberos, grupprinciper, DNS, SMB eller dynamisk RPC.

Sophos anger dessutom följande portar för den här resurstypen:

TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
UDP: 88, 389, 464, 636, 4389, 63664 (i den tyskspråkiga Sophos-hjälpen är raden märkt UCP)

I det allmänna resursformuläret ska du Specify the port type and port number (till exempel HTTPS och 443 för en webbapp). För en domänkontrollant är det i stället de nödvändiga TCP- och UDP-tjänsterna som gäller.

Använd inte de ovanliga UDP-värdena utan kontroll som en allmän AD-rekommendation. De kommer från den aktuella Sophos-resursguiden. Avgörande är vilka tjänster den egna DC:n faktiskt erbjuder och vilka anslutningar AD-funktionen behöver. En resurs kan innehålla sammanlagt upp till 20 TCP- och UDP-portposter. Ange intervall med bindestreck och avgränsa flera poster med kommatecken, till exempel 49152-65535.

Statiska portlistor ska därför inte övertas utan kontroll. Avgörande är:

portarna som fylls i automatiskt i det aktuella Sophos Fusion-gränssnittet,
tjänsterna och portarna som används under Advanced Domain Controller settings,
Microsofts portkrav för de AD-funktioner som används i den aktuella miljön,
att dessa portar är nåbara från ZTNA Gateway till respektive DC.

Om en port som behövs saknas i resursens vanliga portfält räcker inte en motsvarande SRV-post i de avancerade inställningarna. Anslutningen kan då misslyckas trots ett korrekt DNS-svar.

För latenskänsliga CIFS- eller SMB-fildelningar rekommenderar Sophos en lokal gateway. Det ändrar inte den port- och funktionskontroll som krävs, men kortar datavägen jämfört med en Cloud Gateway.

Förstå SRV-prioritet och viktning

Active Directory använder DNS-SRV-poster för att klienter ska hitta en lämplig tjänst och domänkontrollant. Sophos ZTNA avbildar dessa poster under Advanced Domain Controller settings.

De viktigaste fälten är:

Services: AD-tjänst, till exempel LDAP eller Kerberos.
Domain name: DNS-domänen som SRV-posten gäller för.
Protocol: TCP eller UDP.
Port numbers: Port för respektive tjänst, till exempel 389 för LDAP eller 88 för Kerberos.
Priority: Ett lägre tal innebär högre prioritet. DC:er med lägst tillgänglig prioritet används först.
Weight: Fördelar valet mellan DC:er med samma prioritet.
TTL: Tiden i sekunder som ett svar får cachelagras. Standardvärdet 86400 motsvarar 24 timmar.

Prioriteten bestämmer alltså den föredragna gruppen. Viktningen påverkar endast valet inom samma grupp. Den garanterar inte en exakt procentuell trafikfördelning eftersom DNS-cache, klientbeteende och antalet frågor också påverkar resultatet.

Exempel med två aktiva och en reserv-DC

För domänen example.com ska den normala belastningen fördelas mellan två DC:er. En tredje DC används endast som reservmål:

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

Eftersom dc01 och dc02 har samma Priority tillhör de den föredragna gruppen. Viktningen styr deras ungefärliga fördelning i förhållandet 60 till 40. dc03 med Priority 2 tas först med när ingen DC med Priority 1 är tillgänglig.

Alla tre resurser behöver passande SRV-poster för samma domän och de tjänster som faktiskt behövs. Det högre talet 2 och därmed den lägre urvalsprioriteten gör dock inte automatiskt dc03 till en fullständig ersättare. Replikering, DNS, Global Catalog-rollen och nåbara AD-tjänster måste också passa för planerad failover.

Testa funktionen på en Windows-enhet

Kontrollera först SRV-svaret för den aktuella domänen:

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

Svaret ska innehålla de konfigurerade domänkontrollanterna med Priority och Weight. Tvinga därefter fram en ny DC-sökning:

nltest /dsgetdc:example.com /force

nltest visar vald nåbar DC, men inte nödvändigtvis alla tillgängliga mål. Därför kan anslutningen till enskilda tjänster också testas:

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

Port 389 testar i detta exempel LDAP via TCP. För Kerberos, DNS, SMB eller RPC måste tester som passar det verkliga användningsfallet genomföras. Ett fullständigt acceptanstest omfattar dessutom en verklig Windows-inloggning eller åtkomst till applikationen som behöver AD via ZTNA.

Vid en paketinsamling på endpoint-enheten visar detta Wireshark-filter endast DNS-SRV-frågor:

dns.qry.type == 33

Ett failover-test hör hemma på en pilotenhet och i ett underhållsfönster. Stäng inte av produktions-DC:er. Använd i stället två tidsbegränsade nätverksregler som endast gäller pilotenheten för att isolera vägarna till dc01.example.com och dc02.example.com utan att påverka andra klienter. TTL och lokala DNS- och DC-cacheminnen kan fördröja failover. Ta därför hänsyn till konfigurerad TTL och cachefördröjning i testplanen.

När båda DC:erna med Priority 1 är isolerade använder du Resolve-DnsName för att bekräfta att SRV-svaret innehåller dc03.example.com med Priority 2, nltest /dsgetdc:example.com /force för att visa att dc03 väljs och genomför sedan det verkliga AD-beroende inloggnings- eller applikationsflödet. Ta därefter bort båda testreglerna, ta åter hänsyn till cachefördröjningen och bekräfta med SRV-upplösning, nltest och samma flöde att valet återgår till dc01 eller dc02 i gruppen med Priority 1.

När ingen domänkontrollant kan nås

Kontrollera följande i denna ordning vid en störning:

Är varje DC skapad som en resurs med Access method: Agent och Resource type: Domain Controller (DC)?
Använder External FQDN det konkreta DC-namnet och inte bara AD-domänen?
Stämmer domän, tjänst, protokoll, port, Priority och Weight för SRV-posterna?
Finns alla portar som används där också i resursens vanliga portfält?
Kan ZTNA Gateway nå varje DC via dessa portar?
Är pilotanvändare, grupper och Policy korrekt tilldelade?
Kör Windows-enheten Sophos Endpoint 2026.1 eller senare?
Visar Resolve-DnsName, nltest och dns.qry.type == 33 samma DC:er som Sophos Fusion?

Åtkomst via FQDN misslyckas, men åtkomst via IP-adress fungerar

ZTNA Agent fångar endast upp resurser baserat på FQDN. Direkt IP-åtkomst kan därför gå förbi ZTNA och är inte ett lyckat ZTNA-test. Upprepa åtkomsten med namnet som anges under External FQDN. Om användare måste nå interna resurser uteslutande via ZTNA ska den direkta IP-vägen också blockeras med lämpliga brandväggsregler.

En namnändrad Entra ID-grupp har inte längre åtkomst

Om en redan tilldelad Microsoft Entra ID-grupp senare byter namn uppdaterar Sophos inte automatiskt resursens grupplista. Tilldela den berörda gruppen igen under Assign User Groups, spara och testa åtkomsten med en medlem i gruppen.

Externt FQDN kan lösas upp publikt

För en agentbaserad resurs får det externa FQDN-namnet inte vara publikt tillgängligt. Det är motsatsen till en agentlös resurs, vars externa FQDN måste vara publikt tillgängligt. Kontrollera därför DNS-publicering och Access method tillsammans. För den DC-resurs som beskrivs här förblir åtkomstmetoden Agent.

Flera användare förlorar sporadiskt AD-anslutningen

ZTNA Gateway 2.2 har det kända problemet NZT-10022: gatewayens websocket-server kan sporadiskt kassera stora AD-paket. Flera användare kan då till synes slumpmässigt förlora AD-anslutningen, eller så kan Kerberos, RDP, Windows-fildelningar och andra AD-baserade applikationer bli långsamma eller sluta fungera. Den begränsade lösningen är en MTU på 1420 byte för Sophos ZTNA TAP-adaptern på den berörda endpointen. Ställ inte in värdet förebyggande på alla enheter.

Gör först ändringen på en pilotenhet i en PowerShell-session med administratörsbehörighet. Anteckna dessförinnan aliaset och det ursprungliga MTU-värdet för IPv4 och IPv6:

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

Ersätt <TAP-ALIAS> med aliaset som visas, ställ in MTU och kontrollera det aktiva värdet:

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

Anslut sedan ZTNA på nytt och upprepa den Kerberos-, RDP- eller fildelningsåtgärd som tidigare misslyckades flera gånger. Återställ de antecknade värdena om felet kvarstår eller om andra anslutningsproblem uppstår. Ersätt <ORIGINAL_MTU> med det ursprungliga värdet för respektive adressfamilj:

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

Om den första frågan inte returnerar någon adapter använder du Get-NetAdapter för att identifiera det exakta aliaset och ändrar inte ett annat gränssnitt. Om MTU återställs efter återanslutning eller omstart, eller om 1420 inte ger en tydlig förbättring, ska du inte fortsätta att sänka värdet. Samla i stället in gateway- och endpointversioner, berörda användare och tjänster, tidsstämplar, MTU före och efter ändringen samt en paketfångst, och eskalera ärendet med NZT-10022.

Microsoft beskriver portkraven för Windows-tjänsterna som används under Service overview and network port requirements.

Säker återställning och avveckling

Ta inte bort en DC-resurs under en pågående inloggning eller ett failover-test i produktion. Anteckna först tilldelade användargrupper, portar, SRV-poster, Priority och Weight och kontrollera att minst en testad DC i samma prioritetsgrupp eller avsedd reserv-DC fortfarande kan nås.

För att återställa en ändring öppnar du My Products > ZTNA > Resources & Access och väljer resource name. Där kan du redigera resursinformationen eller ta bort resursen. Återställ först en felaktig ändring av portar, SRV-värden eller grupper till de antecknade ursprungsvärdena och spara. Ta endast bort en resurs när dess FQDN inte längre behövs av användare eller applikationer.

Kontrollera därefter SRV-upplösningen, nltest /dsgetdc:example.com /force och det berörda inloggnings- eller applikationsflödet igen på pilotenheten. Om ingen testad DC fortfarande kan nås ska du stoppa före borttagningen och eskalera med de sparade värdena. En slutförd borttagning kan inte ångras. Om resursen redan har tagits bort får endast en kvalificerad administratör återskapa den manuellt utifrån de dokumenterade inställningarna, tilldela grupperna på nytt och därefter upprepa hela valideringen. Om resursens identitet eller tillstånd måste bevaras, eller om dokumentationen är ofullständig, ska du inte återskapa den utan eskalera ärendet.

Drift, granskning och livscykel

Priority, Weight och TTL hör hemma i AD-miljöns driftdokumentation. Kontrollera tilldelningen igen efter ändringar av DC-platser, FQDN, erbjudna tjänster, portar eller användargrupper. Att tilldela en namnändrad Entra ID-grupp på nytt är ett separat driftsteg. Ingen automatisk uppdatering sker.

Ingen specifik anvisning för migrering, avveckling eller slutet av livscykeln är dokumenterad för den här funktionen. Efter produktuppdateringar ska du först kontrollera den aktuella resurshjälpen och fälten som visas i klientorganisationen och sedan validera ändringarna igen på en begränsad pilotenhet.

Relaterade befintliga guider

Den övergripande konfigurationsordningen beskrivs i Konfigurera Sophos ZTNA: översikt och ordning. Planering, DNS och gatewayens nåbarhet beskrivs i Planera och skapa en Sophos ZTNA Gateway.