Przejdz do tresci
Avanet

Konfiguracja wielu kontrolerów domeny w Sophos ZTNA

Sophos Workspace Protection

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.

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, licencja i role

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

  • Sophos Fusion (dawniej 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 Fusion 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.

Przed zmianą należy sprawdzić, czy w tenancie jest dostępna sekcja ZTNA > Resources & Access i czy używane konto administratora może w niej dodawać i edytować zasoby. Jeśli brakuje pozycji menu lub przycisku, nie należy kontynuować na podstawie założonej roli lub licencji, lecz wyjaśnić uprawnienia ZTNA i wykupiony zakres we własnym tenancie albo z właściwym partnerem Sophos.

Jak dodawać zasoby: tworzenie każdego kontrolera domeny

Każdy DC należy utworzyć oddzielnie jako Domain Controller z metodą dostępu opartą na agencie:

  1. W Sophos Fusion 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. Pozostawić włączoną opcję Show resource in user portal odpowiednio do wymaganego dostępu użytkowników.
  4. Wybrać właściwą Gateway.
  5. Dla opcji Access method wybrać wartość Agent i 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 automatycznie 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 przenieść z Available User Groups do Assigned User Groups wszystkie grupy, które potrzebują zasobów za tym DC.
  12. Wybrać Save, a następnie przetestować DC za pomocą urządzenia pilotażowego z systemem Windows.

Zasoby bezagentowe i zasoby oparte na agencie wymagają różnych rekordów DNS. Dla zasobu DC opartego na agencie Sophos nie tworzy domeny aliasowej. 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. Dostęp oparty na adresie IP nie jest w ten sposób automatycznie przechwytywany.

Sprawdzanie rekordów DNS i 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.

Sophos podaje dodatkowo następujące porty dla tego typu zasobu:

  • TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
  • UDP: 88, 389, 464, 636, 4389, 63664 (w niemieckojęzycznej pomocy Sophos ten wiersz jest oznaczony jako UCP)

Ogólny formularz zasobu wymaga Specify the port type and port number (na przykład HTTPS i 443 dla aplikacji internetowej). W przypadku kontrolera domeny miarodajne są zamiast tego wymagane usługi TCP i UDP.

Nietypowych wartości UDP nie należy bez sprawdzenia traktować jako ogólnego zalecenia dla AD. Pochodzą one z aktualnej instrukcji zasobów Sophos; decydujące jest to, jakie usługi faktycznie oferuje własny DC i jakich połączeń wymaga dana funkcja AD. Zasób może zawierać łącznie do 20 wpisów portów TCP i UDP. Zakresy wpisuje się z łącznikiem, a wiele pozycji oddziela przecinkami, na przykład 49152-65535.

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

  • porty automatycznie wstępnie skonfigurowane w aktualnym interfejsie Sophos Fusion,
  • 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.

W przypadku wrażliwych na opóźnienia udziałów plikowych CIFS lub SMB Sophos zaleca lokalną bramę. Nie zmienia to wymaganej kontroli portów i funkcji, ale skraca ścieżkę danych w porównaniu z Cloud Gateway.

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 wyłączać produkcyjnych kontrolerów DC. Zamiast tego należy użyć dwóch ograniczonych czasowo reguł sieciowych dotyczących wyłącznie urządzenia pilotażowego, aby odizolować ścieżki do dc01.example.com i dc02.example.com bez wpływu na inne klienty. Wartość TTL oraz lokalne pamięci podręczne DNS i DC mogą opóźnić przełączenie, dlatego w harmonogramie testu trzeba uwzględnić skonfigurowaną wartość TTL i opóźnienie pamięci podręcznych.

Gdy oba kontrolery DC z Priority 1 są odizolowane, należy za pomocą Resolve-DnsName potwierdzić, że odpowiedź SRV zawiera dc03.example.com z Priority 2, za pomocą nltest /dsgetdc:example.com /force wykazać wybór dc03, a następnie pomyślnie wykonać rzeczywisty proces logowania lub działania aplikacji zależny od AD. Następnie należy usunąć obie reguły testowe, ponownie uwzględnić opóźnienie pamięci podręcznych i za pomocą rozwiązywania SRV, nltest oraz tego samego procesu potwierdzić, że wybór wraca do dc01 lub dc02 w grupie z Priority 1.

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

Dostęp przez FQDN nie działa, ale dostęp przez adres IP działa

ZTNA Agent przechwytuje zasoby wyłącznie na podstawie FQDN. Bezpośredni dostęp przez IP może zatem ominąć ZTNA i nie jest pomyślnym testem ZTNA. Należy ponowić dostęp przy użyciu nazwy wpisanej w External FQDN. Jeśli użytkownicy muszą uzyskiwać dostęp do zasobów wewnętrznych wyłącznie przez ZTNA, należy dodatkowo zablokować bezpośrednią ścieżkę IP odpowiednimi regułami zapory.

Grupa Entra ID po zmianie nazwy nie ma już dostępu

Jeśli wcześniej przypisana grupa Microsoft Entra ID zostanie później przemianowana, Sophos nie aktualizuje automatycznie listy grup zasobu. Należy ponownie przypisać odpowiednią grupę w Assign User Groups, zapisać i przetestować dostęp z konta członka tej grupy.

Zewnętrzna nazwa FQDN jest publicznie rozwiązywana

W przypadku zasobu opartego na agencie zewnętrzna nazwa FQDN nie może być publicznie dostępna. Jest to sytuacja odwrotna niż dla zasobu bezagentowego, którego zewnętrzna nazwa FQDN musi być publicznie dostępna. Należy więc sprawdzić razem publikację DNS i Access method; dla opisanego tu zasobu DC metodą dostępu pozostaje Agent.

Wielu użytkowników sporadycznie traci połączenie z AD

ZTNA Gateway 2.2 ma znany problem NZT-10022: serwer websocket bramy może sporadycznie odrzucać duże pakiety AD. W efekcie wielu użytkowników może pozornie losowo tracić łączność z AD, a protokoły Kerberos i RDP, udziały plikowe Windows oraz inne aplikacje korzystające z AD mogą działać wolno lub przestać działać. Ograniczonym obejściem jest ustawienie MTU 1420 bajtów na adapterze Sophos ZTNA TAP odpowiedniego endpointu; nie należy wprowadzać tej wartości prewencyjnie na wszystkich urządzeniach.

Zmianę należy najpierw wprowadzić na urządzeniu pilotażowym w sesji PowerShell uruchomionej z uprawnieniami administratora. Wcześniej trzeba zanotować alias i pierwotną wartość MTU dla IPv4 i IPv6:

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

Zastąpić <TAP-ALIAS> wyświetlonym aliasem, ustawić MTU i sprawdzić obowiązującą wartość:

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

Następnie ponownie połączyć ZTNA i kilka razy powtórzyć operację Kerberos, RDP lub udziału plikowego, która wcześniej kończyła się niepowodzeniem. Jeśli błąd pozostanie lub pojawią się inne problemy z łącznością, przywrócić zanotowane wartości; zastąpić <ORIGINAL_MTU> pierwotną wartością dla każdej rodziny adresów:

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

Jeżeli pierwsze zapytanie nie zwróci adaptera, użyć Get-NetAdapter, aby ustalić dokładny alias, i nie modyfikować innego interfejsu. Jeśli po ponownym połączeniu lub restarcie MTU wraca do poprzedniej wartości albo 1420 nie daje wyraźnej poprawy, nie należy dalej jej obniżać. Zamiast tego zebrać wersje bramy i endpointu, dane o użytkownikach i usługach, znaczniki czasu, MTU przed zmianą i po niej oraz przechwycone pakiety, a następnie eskalować przypadek z identyfikatorem NZT-10022.

Wymagania dotyczące portów używanych usług Windows firma Microsoft opisuje w dokumencie Service overview and network port requirements.

Bezpieczne wycofanie zmian i odłączenie

Nie należy usuwać zasobu DC podczas trwającego logowania ani produkcyjnego testu failover. Najpierw trzeba zanotować przypisane grupy użytkowników, porty, rekordy SRV, Priority i Weight oraz sprawdzić, czy osiągalny pozostaje co najmniej jeden przetestowany DC z tej samej grupy priorytetów albo przewidziany zapasowy DC.

Aby wycofać zmianę, należy otworzyć My Products > ZTNA > Resources & Access i wybrać resource name. Można tam edytować szczegóły zasobu lub go usunąć. Nieprawidłową zmianę portów, wartości SRV lub grup należy najpierw przywrócić do zanotowanych wartości początkowych i zapisać. Zasób można usunąć dopiero wtedy, gdy jego FQDN nie jest już potrzebny użytkownikom ani aplikacjom.

Następnie na urządzeniu pilotażowym należy ponownie sprawdzić rozwiązywanie SRV, nltest /dsgetdc:example.com /force oraz odpowiedni proces logowania lub działania aplikacji. Jeśli żaden przetestowany DC nie pozostaje osiągalny, należy zatrzymać się przed usunięciem i eskalować przypadek z zapisanymi wartościami. Zakończonego usunięcia nie można cofnąć. Jeśli zasób został już usunięty, tylko wykwalifikowany administrator może ręcznie odtworzyć go na podstawie zapisanych ustawień, ponownie przypisać grupy, a następnie powtórzyć pełną walidację. Jeśli trzeba zachować tożsamość lub stan zasobu albo zapisy są niekompletne, nie należy go odtwarzać, lecz eskalować przypadek.

Eksploatacja, przegląd i cykl życia

Priority, Weight i TTL powinny znaleźć się w dokumentacji operacyjnej środowiska AD. Przypisanie należy ponownie sprawdzać po zmianach lokalizacji DC, nazw FQDN, oferowanych usług, portów lub grup użytkowników. Ponowne przypisanie przemianowanej grupy Entra ID jest osobnym krokiem operacyjnym; automatyczna aktualizacja nie następuje.

Dla tej funkcji nie udokumentowano konkretnych instrukcji migracji, wycofania ani zakończenia cyklu życia. Po aktualizacji produktu należy najpierw sprawdzić bieżącą pomoc dotyczącą zasobów i pola widoczne w tenancie, a następnie ponownie zweryfikować zmiany na ograniczonym urządzeniu pilotażowym.

Powiązane istniejące instrukcje

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.