Przejdz do tresci
Avanet

Konfiguracja wielu kontrolerów domeny w Sophos ZTNA

Zero Trust Network Access

Jeśli urządzenia z systemem Windows muszą łączyć się z Active Directory przez Sophos ZTNA, pojedynczy kontroler domeny stanowi możliwy do uniknięcia pojedynczy punkt awarii. Od wersji Sophos Endpoint 2026.1 ZTNA obsługuje wiele zasobów DC z priorytetem i wagą. Dzięki temu można korzystać z dwóch kontrolerów domeny w normalnej pracy i przewidzieć kolejny DC jako cel zapasowy.

Każdy kontroler domeny jest w tym celu tworzony jako oddzielny zasób oparty na agencie typu Domain Controller (DC). Sophos ZTNA zapewnia połączenie i odpowiada na odpowiednie zapytania DNS-SRV na urządzeniu końcowym. Istniejąca struktura AD, rozwiązywanie nazw DNS i relacje zaufania nadal pozostają zadaniem środowiska Active Directory.

Ogólną kolejność konfiguracji przedstawia najpierw artykuł Konfiguracja Sophos ZTNA: przegląd i kolejność. Planowanie, DNS i osiągalność bramy opisano w Planowanie i tworzenie Sophos ZTNA Gateway.

Rozróżnienie zasobów DC i Identity Provider

Wiele zasobów DC nie oznacza automatycznie, że ZTNA Identity Provider może uwierzytelniać użytkowników z kilku niezależnych domen AD.

  • Zasoby DC transportują przez tunel ZTNA ruch DNS, Kerberos, LDAP i inny wymagany ruch AD.
  • Identity Provider uwierzytelnia użytkownika na potrzeby ZTNA. W przypadku lokalnego Microsoft AD Identity Provider Sophos nadal obsługuje jedną domenę; Primary i Secondary AD Server muszą należeć do tej samej domeny.
  • AD DNS i Forest Trusts muszą już działać. ZTNA nie tworzy przekazywania DNS, relacji zaufania ani synchronizacji użytkowników między domenami.

Funkcja nadaje się więc bezpośrednio do obsługi wielu kontrolerów DC w tej samej domenie. W przypadku wielu domen lub lasów należy dodatkowo sprawdzić, czy Identity Provider, DNS i istniejące relacje zaufania rzeczywiście obsługują planowany dostęp.

Wymagania

Przed rozpoczęciem konfiguracji należy spełnić następujące warunki:

  • Sophos Central z aktywną licencją ZTNA.
  • Skonfigurowana ZTNA Gateway dostępna z urządzenia końcowego.
  • Urządzenia z systemem Windows z ZTNA Agent i Sophos Endpoint 2026.1 lub nowszym.
  • Zsynchronizowane grupy użytkowników i odpowiednia ZTNA Policy oparta na agencie.
  • Unikalna nazwa FQDN dla każdego kontrolera domeny, na przykład dc01.example.com.
  • Osiągalność każdego DC z ZTNA Gateway przez rzeczywiście wymagane usługi AD.
  • Działające wewnętrzne rozwiązywanie nazw DNS oraz istniejące relacje zaufania i przekazywanie DNS w przypadku wielu domen lub lasów.

Wersję Endpoint można znaleźć w Sophos Central w sekcji My Environment > Computers & Servers > <Urządzenie> > Summary. W obszarach Assigned Products i Installed component versions można sprawdzić, czy urządzenie pilotażowe korzysta już z wymaganej wersji.

Tworzenie każdego kontrolera domeny jako zasobu

Dla każdego DC tworzy się oddzielny zasób:

  1. W Sophos Central otworzyć My Products > ZTNA > Resources & Access i wybrać Add Resource.
  2. Wprowadzić unikalną nazwę i krótki opis, na przykład dc01-example i Kontroler domeny, lokalizacja Zurych.
  3. Wybrać właściwą Gateway.
  4. Dla opcji Access method wybrać wartość Agent.
  5. Przypisać odpowiednią Policy opartą na agencie.
  6. Dla opcji Resource type wybrać wartość Domain Controller (DC).
  7. W polu External FQDN wprowadzić pełną nazwę tego DC, na przykład dc01.example.com – nie tylko domenę główną example.com.
  8. Pole Internal FQDN/IP address wypełnić tylko wtedy, gdy cel wewnętrzny różni się od External FQDN. Bez podanej wartości Sophos używa External FQDN.
  9. Sprawdzić automatycznie wprowadzone porty i dodać tylko usługi rzeczywiście potrzebne w tym środowisku.
  10. W obszarze Advanced Domain Controller settings sprawdzić rekordy SRV.
  11. W obszarze Assign User Groups przypisać grupy, które potrzebują usług AD przez ten DC.
  12. Zapisać konfigurację, a następnie przetestować DC za pomocą urządzenia pilotażowego z systemem Windows.

Dla zasobu DC opartego na agencie Sophos nie tworzy Resource Alias. Dlatego dla DC nie wolno tworzyć publicznego rekordu CNAME ani rekordu DNS z symbolem wieloznacznym; również External FQDN nie może być publicznie dostępny. Nie dotyczy to rekordu CNAME bramy wymaganego dla Sophos Cloud Gateway. ZTNA Agent przechwytuje skonfigurowaną nazwę FQDN na urządzeniu końcowym. Bezpośredni dostęp przez adres IP nie jest w ten sposób automatycznie przechwytywany.

Sprawdzanie portów odpowiednio do środowiska

Typ zasobu Domain Controller (DC) automatycznie wprowadza zestaw portów. Ta lista stanowi punkt wyjścia, ale nie zastępuje sprawdzenia faktycznie używanych funkcji AD. Inne połączenia są potrzebne do prostego testu LDAP, a inne do logowania Kerberos, zasad grupy, DNS, SMB czy dynamicznych portów RPC.

Nie należy więc bezkrytycznie kopiować statycznych list portów. Decydujące znaczenie mają:

  • porty automatycznie wstępnie skonfigurowane w aktualnym interfejsie Sophos Central,
  • usługi i porty używane w obszarze Advanced Domain Controller settings,
  • wymagania firmy Microsoft dotyczące portów dla funkcji AD używanych w tym środowisku,
  • osiągalność tych portów z ZTNA Gateway do danego DC.

Jeśli wymaganego portu brakuje w zwykłym polu portu zasobu, sam odpowiedni rekord SRV w ustawieniach zaawansowanych nie wystarczy. Połączenie może się wtedy nie powieść mimo prawidłowej odpowiedzi DNS.

Zrozumienie priorytetu i wagi SRV

Active Directory używa rekordów DNS-SRV, aby klienci mogli znaleźć odpowiednią usługę i kontroler domeny. Sophos ZTNA odwzorowuje te rekordy w obszarze Advanced Domain Controller settings.

Najważniejsze pola to:

  • Services: Usługa AD, na przykład LDAP lub Kerberos.
  • Domain name: Domena DNS, której dotyczy rekord SRV.
  • Protocol: TCP lub UDP.
  • Port numbers: Port danej usługi, na przykład 389 dla LDAP lub 88 dla Kerberos.
  • Priority: Mniejsza liczba oznacza wyższy priorytet. W pierwszej kolejności używane są kontrolery DC o najniższym dostępnym priorytecie.
  • Weight: Rozdziela wybór między kontrolery DC o tym samym priorytecie.
  • TTL: Czas w sekundach, przez który odpowiedź może być przechowywana w pamięci podręcznej. Wartość domyślna 86400 odpowiada 24 godzinom.

Priorytet określa zatem preferowaną grupę. Waga wpływa tylko na wybór w obrębie tej samej grupy. Nie gwarantuje dokładnego procentowego rozkładu ruchu, ponieważ na wynik wpływają również pamięć podręczna DNS, zachowanie klienta i liczba zapytań.

Przykład z dwoma aktywnymi i jednym zapasowym DC

Dla domeny example.com normalne obciążenie ma być rozłożone na dwa kontrolery DC. Trzeci DC jest używany tylko jako cel zapasowy:

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

Ze względu na tę samą wartość Priority kontrolery dc01 i dc02 należą do grupy preferowanej. Waga steruje ich przybliżonym wyborem w proporcji 60 do 40. Kontroler dc03 z Priority 2 jest brany pod uwagę dopiero wtedy, gdy żaden DC z Priority 1 nie jest dostępny.

Wszystkie trzy zasoby wymagają odpowiednich rekordów SRV dla tej samej domeny i faktycznie potrzebnych usług. Wyższa wartość liczbowa 2, a tym samym niższy priorytet wyboru, nie czyni jednak dc03 automatycznie pełnym zamiennikiem: replikacja, DNS, rola Global Catalog i osiągalne usługi AD również muszą odpowiadać planowanemu scenariuszowi failover.

Testowanie działania na urządzeniu z systemem Windows

Najpierw sprawdzić odpowiedź SRV dla wybranej domeny:

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

Odpowiedź powinna zawierać skonfigurowane kontrolery domeny wraz z wartościami Priority i Weight. Następnie wymusić nowe wyszukiwanie DC:

nltest /dsgetdc:example.com /force

nltest pokazuje wybrany osiągalny DC, ale niekoniecznie wszystkie dostępne cele. Dlatego można dodatkowo sprawdzić połączenie z poszczególnymi usługami:

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

Port 389 w tym przykładzie służy do testowania LDAP przez TCP. Dla Kerberos, DNS, SMB lub RPC należy wykonać testy odpowiadające rzeczywistemu scenariuszowi użycia. Pełny test akceptacyjny obejmuje również rzeczywiste logowanie do systemu Windows lub dostęp do aplikacji, która wymaga AD przez ZTNA.

W przypadku przechwytywania pakietów na urządzeniu końcowym poniższy filtr Wireshark wyświetla wyłącznie zapytania DNS-SRV:

dns.qry.type == 33

Test failover należy przeprowadzać na urządzeniu pilotażowym i w oknie serwisowym. Nie należy w tym celu wyłączać produkcyjnego DC, lecz w kontrolowany sposób przerwać ścieżkę podstawową tylko na czas testu. Następnie ponownie sprawdzić nltest, rozwiązywanie SRV i daną aplikację. Po zmianie Priority lub Weight wartości TTL i lokalne pamięci podręczne DNS mogą opóźnić wynik.

Gdy żaden kontroler domeny nie jest osiągalny

W przypadku awarii sprawdzić w następującej kolejności:

  1. Czy każdy DC został utworzony jako zasób z ustawieniami Access method: Agent i Resource type: Domain Controller (DC)?
  2. Czy External FQDN zawiera konkretną nazwę DC, a nie tylko domenę AD?
  3. Czy domena, usługa, protokół, port, Priority i Weight rekordów SRV są poprawne?
  4. Czy wszystkie używane tam porty znajdują się również w zwykłym polu portu zasobu?
  5. Czy ZTNA Gateway może połączyć się z każdym DC przez te porty?
  6. Czy użytkownicy pilotażowi, grupy i Policy są prawidłowo przypisani?
  7. Czy na urządzeniu z systemem Windows działa Sophos Endpoint 2026.1 lub nowszy?
  8. Czy Resolve-DnsName, nltest i dns.qry.type == 33 pokazują te same kontrolery DC co Sophos Central?

W przypadku ZTNA Gateway 2.2 Sophos wymienia ponadto NZT-10022 w aktualnym dokumencie Known Issues List: duże pakiety AD mogą być sporadycznie odrzucane. Możliwe objawy to zawodne połączenia Kerberos, RDP lub z udziałami plikowymi. Jako obejście Sophos podaje wartość MTU 1420 bajtów dla adaptera Sophos ZTNA TAP. Zmiana ta dotyczy tylko tego konkretnego problemu i nie powinna być prewencyjnie wprowadzana na wszystkich urządzeniach.

Oficjalny opis pól i aktualny interfejs są dostępne w dokumentacji Sophos Add resources. Wymagania dotyczące portów używanych usług Windows firma Microsoft opisuje w dokumencie Service overview and network port requirements.