Hoppa till innehållet
Avanet

Konfigurera flera domänkontrollanter med Sophos ZTNA

Zero Trust Network Access

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.

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.

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

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

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

Skapa varje domänkontrollant som en resurs

En separat resurs skapas för varje DC:

  1. Öppna My Products > ZTNA > Resources & Access i Sophos Central och välj Add Resource.
  2. Ange ett unikt namn och en kort beskrivning, till exempel dc01-example och Domänkontrollant på Zürich-kontoret.
  3. Välj ansvarig Gateway.
  4. Välj värdet Agent för Access method.
  5. Tilldela lämplig agentbaserad Policy.
  6. Välj värdet Domain Controller (DC) för Resource type.
  7. Ange det fullständiga namnet på denna DC under External FQDN, till exempel dc01.example.com – inte bara rotdomänen example.com.
  8. 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 External FQDN.
  9. Kontrollera portarna som läggs till automatiskt och komplettera endast med tjänster som miljön faktiskt behöver.
  10. Kontrollera SRV-posterna under Advanced Domain Controller settings.
  11. Tilldela under Assign User Groups de grupper som behöver AD-tjänster via denna DC.
  12. Spara och testa därefter DC:n med en Windows-pilotenhet.

Sophos skapar inget Resource Alias 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. Direkt åtkomst via IP-adressen fångas därför inte upp automatiskt.

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

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

  • portarna som fylls i automatiskt i det aktuella Sophos Central-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ö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 en produktions-DC för testet, utan bryt den primära vägen kontrollerat och endast för testet. Kontrollera därefter nltest, SRV-upplösningen och den berörda applikationen igen. Efter ändringar av Priority eller Weight kan TTL och lokala DNS-cacheminnen fördröja resultatet.

När ingen domänkontrollant kan nås

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

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

För ZTNA Gateway 2.2 anger Sophos dessutom NZT-10022 i den aktuella Known Issues List: stora AD-paket kan sporadiskt kasseras. Möjliga symptom är opålitliga Kerberos-, RDP- eller fildelningsanslutningar. Som lösning anger Sophos en MTU på 1420 byte för Sophos ZTNA TAP-adaptern. Ändringen gäller endast det här specifika felet och ska inte införas förebyggande på alla enheter.

Den officiella fältbeskrivningen och det aktuella gränssnittet finns hos Sophos under Add resources. Microsoft beskriver portkraven för Windows-tjänsterna som används under Service overview and network port requirements.