Konfiguracja Per-Connection AD SSO dla hostów wielu użytkowników w Sophos Firewall

Wielu użytkowników pracuje na tym samym hoście sesji pulpitu zdalnego, ale Sophos Firewall widzi dla wszystkich połączeń tylko jeden adres IP serwera. Per-Connection AD SSO rozwiązuje ten szczególny problem dla ruchu internetowego: Direct Web Proxy uwierzytelnia każde połączenie HTTP i HTTPS osobno za pomocą Kerberos lub NTLM.

Funkcja nie ogranicza się do Windows RDS: również wieloużytkownikowy serwer Linux może korzystać z tego modelu połączeń, o ile jego klienty obsługują Direct Web Proxy oraz Kerberos lub NTLM. Ten przykład przedstawia wdrożenie pilotażowe na Windows RDS; polecenia Windows i dystrybucja przez GPO nie stanowią instrukcji dla systemu Linux. Hosty spoza listy Multi-user hosts zachowują dotychczas skonfigurowane uwierzytelnianie oparte na adresie IP.

Ograniczenie jest równie ważne jak sama funkcja. Tożsamość użytkownika otrzymują wyłącznie połączenia, które przeglądarka lub aplikacja jawnie kieruje do proxy. DNS, RDP, SMB i pozostały ruch spoza proxy z tego samego adresu IP serwera pozostają nieuwierzytelnione. Jeśli również te protokoły wymagają kontroli zależnej od użytkownika, lepszym rozwiązaniem będzie SATC dla usług pulpitu zdalnego.

⚠️ Gdy adres IP zostanie dodany do Multi-user hosts, przestaje korzystać z innych metod uwierzytelniania opartych na adresie IP. Dla tego adresu nie działają wtedy STAS, Captive Portal, Clientless User ani przezroczyste AD SSO. Dlatego najpierw należy przeprowadzić test dokładnie na jednym serwerze pilotażowym i udokumentować dotychczasową ścieżkę uwierzytelniania.

Per-Connection AD SSO w dziewięciu krokach

1. Ustalić, czy przetwarzanie zależne od użytkownika ma rzeczywiście obejmować wyłącznie HTTP i HTTPS przez jawnie skonfigurowane proxy.
2. Sprawdzić Active Directory, import grup, DNS, czas i dołączenie zapory do domeny.
3. Przygotować rozwiązywalną nazwę FQDN zapory oraz pasujący HTTP-SPN dla Kerberos.
4. Najpierw ocenić zakres i wpływ na bezpieczeństwo, następnie włączyć AD SSO dla wymaganej strefy LAN w Administration > Device access i wybrać Apply. Osobno ograniczyć dostęp do Web proxy do hosta pilotażowego ukierunkowanym wyjątkiem ACL, jeśli jest wspierany; wyjątek zezwalający nie zawęża zezwolenia dla strefy. Jeśli wymagane zezwolenie jest niedopuszczalne, zatrzymać wdrożenie i uzyskać wspieraną konfigurację o ograniczonym zakresie.
5. Utworzyć dla serwera RDS obiekt hosta IP z dokładnym adresem.
6. W Authentication > Web authentication włączyć Per-Connection AD SSO dla tego hosta.
7. Skonfigurować przeglądarki i aplikacje obsługujące proxy tak, aby używały nazwy FQDN zapory i portu 3128.
8. Umieścić osobną regułę hosta z włączonym logowaniem przed konkurencyjnymi regułami użytkowników i pozostawić Match known users wyłączone.
9. Osobno sprawdzić dwie równoległe sesje RDS, różne wyniki działania Web Policy i ruch spoza proxy.

Per-Connection AD SSO, STAS czy SATC?

Wszystkie trzy metody dostarczają kontekst użytkownika, ale służą do różnych zadań.

• STAS sprawdza się na standardowych klientach Windows, gdy adres IP klienta zwykle należy do dokładnie jednego użytkownika. Zapora otrzymuje mapowanie użytkownika na adres IP na podstawie zdarzeń logowania Windows.
• Per-Connection AD SSO sprawdza się na hostach wielu użytkowników, gdy trzeba rozróżniać wyłącznie połączenia HTTP i HTTPS jawnie kierowane przez proxy. Na serwerze RDS nie jest potrzebny agent SATC, ale wszystkie aplikacje muszą niezawodnie korzystać z Direct Web Proxy.
• SATC sprawdza się na obsługiwanych systemach Windows RDS, gdy również inne typy połączeń z poszczególnych sesji użytkowników wymagają tożsamości. W tym celu na hoście sesji wymagany jest Sophos Server Protection. Aktualna instrukcja Sophos nie potwierdza możliwości nowego wdrożenia Citrix; przed zmianami w istniejących instalacjach Citrix należy skonsultować się z Sophos Support.

Klasyczny STAS w Sophos Firewall nie potrafi rozróżniać wielu użytkowników za tym samym adresem IP serwera RDS. Per-Connection AD SSO i SATC nie są więc wygodniejszymi wariantami STAS, lecz odrębnymi modelami działania. Również SATC przypisuje tożsamość tylko procesom użytkowników; połączenia generowane przez usługi systemowe nadal wymagają osobnej reguły bez Match known users. Jeśli aplikacja nie obsługuje jawnie skonfigurowanego proxy lub protokoły inne niż WWW mają być kontrolowane według użytkownika, należy w tym miejscu przerwać i rozważyć SATC.

Przykład i wartości do zastąpienia

Procedura wykorzystuje następujący przykład:

• Host wielu użytkowników: RDS01
• Adres IP: 10.20.30.40
• FQDN zapory i adres docelowy proxy: fw01.corp.example
• Port Direct Web Proxy: 3128
• Grupy AD: RDS-Web-Standard i RDS-Web-Restricted
• po jednym koncie pilotażowym w każdej grupie, z celowo różnymi wynikami działania Web Policy

10.20.30.40 należy zastąpić stałym adresem IP serwera pilotażowego widocznym na zaporze. Za tym adresem nie mogą dodatkowo występować inne systemy korzystające z NAT. fw01.corp.example to nazwa użyta w dokumentacji, którą należy zastąpić rzeczywistą, rozwiązywalną wewnętrznie nazwą FQDN zapory. Część określająca host powinna mieć najwyżej 15 znaków i być zapisana małymi literami, aby nazwa hosta, nazwa NetBIOS, obiekt komputera w AD i SPN były ze sobą zgodne.

Port 3128 jest standardowym portem Direct Web Proxy. Jeśli w danym środowisku używany jest inny port nasłuchu, zapora, plik PAC lub GPO, przeglądarki i testy muszą korzystać z tej samej wartości. Przykładowe grupy służą wyłącznie do czytelnego przeprowadzenia testów odbiorczych; nazwy grup i Web Policies muszą odpowiadać własnej strukturze uprawnień.

Przygotowanie wymagań wstępnych

Sprawdzenie Active Directory i dołączenia do domeny

Zapora wymaga działającego serwera Active Directory, zaimportowanych grup i pomyślnego dołączenia do domeny. Artykuł Łączenie Active Directory z Sophos Firewall wyjaśnia LDAPS, bazę wyszukiwania, import grup i ogólne wymagania AD SSO.

Jeśli serwer AD nie jest jeszcze skonfigurowany, w Authentication > Servers > Add należy wybrać typ Active Directory. Wprowadzić nazwę serwera, osiągalny adres IP lub FQDN kontrolera domeny, domenę NetBIOS, domenę AD i bazę wyszukiwania właściwą dla swojego środowiska. Dla corp.example bazą wyszukiwania jest dc=corp,dc=example. Zaszyfrować połączenie za pomocą SSL/TLS na porcie 636 lub STARTTLS na porcie 389 i przygotować weryfikację certyfikatu zgodnie z podlinkowaną procedurą AD. Wprowadzić konto do odczytu/dołączania do domeny z uprawnieniami opisanymi poniżej, wykonać Test connection i zapisać przez Save. Nie zastępować używanego już serwera AD wyłącznie na potrzeby pilotażu ani nie zmieniać jego danych dostępowych bez uprzedniej weryfikacji. Jeśli domena wymusza ścisłe wiązanie kanału LDAP lub podpisywanie LDAP, przed wdrożeniem należy wyjaśnić zgodność w ramach procedury AD; pomoc Sophos dotycząca serwera AD wskazuje tu ograniczenie. Nie wyłączać wymagań ochrony obowiązujących w całej domenie w celu usunięcia błędu.

Podczas importu grup wybranie jednostki organizacyjnej (OU) automatycznie zaznacza wszystkie zawarte w niej grupy. Attach to all the Groups przypisuje wybrane wspólne polityki do każdej grupy importowanej przez kreator. Przed zakończeniem należy więc sprawdzić listę grup rozszerzoną przez wybór OU oraz zakres tych polityk; uwzględnić tylko rzeczywiście potrzebne grupy i zamierzone przypisania polityk.

Na potrzeby pilotażu w Authentication > Servers > Manage otworzyć Import przy serwerze AD, uruchomić Import group wizard przez Start i wybrać odpowiednią Base DN. Dla przykładowej domeny corp.example jest to dc=corp,dc=example; zastępuje się składniki domeny, a nie składnię LDAP. Wybrać RDS-Web-Standard i RDS-Web-Restricted, sprawdzić wspólne przypisanie polityk i podsumowanie, zakończyć kreator i zamknąć go przez Close. Następnie w Authentication > Groups sprawdzić, czy obie grupy rzeczywiście istnieją. Samo pomyślne dołączenie do domeny nie importuje grup wymaganych przez polityki.

Do zwykłych zapytań LDAP wystarcza konto z uprawnieniami do odczytu. Dołączenie do domeny i utworzenie SPN wymagają natomiast konta administratora domeny lub konta z prawidłowo delegowanymi uprawnieniami. Skonfigurowane konto musi również umożliwiać późniejsze ponowne dołączenie do domeny, ponieważ HA, kolejne serwery AD lub aktualizacje mogą wywołać je ponownie. Nie należy w tym celu niepotrzebnie używać na stałe konta administratora domeny z nieograniczonymi uprawnieniami.

W Authentication > Services > Firewall authentication methods wybrać przewidziany serwer AD i ustawić go we właściwej kolejności. Przy wielu serwerach zapora sprawdza je od góry do dołu. Test connection przy serwerze AD potwierdza wyłącznie dane dostępowe i osiągalność, a nie późniejsze logowanie Kerberos lub NTLM w przeglądarce.

W tym samym obszarze świadomie wybrać Default group i zapisać przez Apply. Jeśli wymagana grupa AD nie została zaimportowana, pomyślnie uwierzytelniony użytkownik może trafić do grupy domyślnej zamiast otrzymać zamierzoną politykę grupową. Użytkownicy w OU, którzy nie należą do grupy katalogowej, mogą pojawić się w Open group. Przy członkostwie w wielu grupach pierwsza pasująca grupa może określać politykę; dlatego należy sprawdzić nie tylko import, lecz także kolejność i rzeczywiste przypisanie. W pilotażu nie używać więc szeroko uprawnionej grupy domyślnej jako zastępstwa dla brakującego importu. Przy pierwszym nowym logowaniu sprawdzić rzeczywiste przypisanie grupy w Authentication > Users; obiekt użytkownika nie musi być widoczny przed tym logowaniem.

Kontrola FQDN, DNS, SPN i czasu

Kerberos działa tylko wtedy, gdy klienty używają nazwy FQDN zapory jako adresu docelowego proxy. Sam adres IP proxy nie wystarcza. Na pilotażowym kliencie Windows pomocne są następujące polecenia diagnostyczne, które tylko odczytują dane:

Resolve-DnsName fw01.corp.example
setspn -Q HTTP/fw01.corp.example
w32tm /query /status

HTTP-SPN, czyli Service Principal Name, wiąże FQDN proxy z obiektem komputera zapory w AD. setspn -Q powinno zwrócić dokładnie jedno pasujące przypisanie. Brak wyniku lub wiele wyników należy wyjaśnić przed wdrożeniem.

Sufiks DNS skonfigurowany w polu nazwy hosta nie jest automatycznie sufiksem AD: podczas dołączania do domeny zapora tworzy nazwę komputera w AD i SPN na podstawie swojej nazwy NetBIOS i domeny AD. Jeśli domena DNS i domena AD są różne, porównać FQDN zarejestrowany w obiekcie komputera w AD z planowanym adresem docelowym proxy. Przykład zakłada pasujący SPN dla fw01.corp.example; samo wpisanie tej nazwy w Admin and user settings tego nie potwierdza. Najpierw wspólnie zweryfikować DNS i SPN dla rzeczywistego adresu docelowego proxy, a dopiero potem rozprowadzić konfigurację proxy. Nie tworzyć dodatkowych SPN na podstawie przypuszczeń.

Odpowiedź DNS musi wskazywać właściwą zaporę. Klient, kontroler domeny i zapora potrzebują ponadto czasu zgodnego z wymaganiami Kerberos. Polecenia niczego nie zmieniają. Nie poprawiać SPN, dołączenia do domeny ani konfiguracji czasu na podstawie przypuszczeń, lecz najpierw potwierdzić rzeczywisty błąd.

Weryfikacja obsługi proxy i wyjątków

Każda przeglądarka i każda aplikacja, której ruch internetowy ma otrzymać tożsamość użytkownika, musi korzystać z jawnie skonfigurowanego proxy i obsługiwać Kerberos lub NTLM; w przykładzie Windows RDS odbywa się to przez zintegrowane uwierzytelnianie Windows. Przed wdrożeniem sprawdzić co najmniej:

• przeglądarki w każdej obsługiwanej sesji RDS
• aplikacje z własnym stosem HTTP
• aktualizacje Windows i oprogramowania
• usługi działające w kontekście systemowym zamiast w sesji użytkownika
• adresy docelowe znajdujące się w pliku PAC lub na liście pomijania proxy

Ruch omijający proxy zgodnie z oczekiwaniami pozostaje bez identyfikatora użytkownika. Dla wymaganych połączeń maszynowych zaplanować osobną, ściśle ograniczoną regułę bez odniesienia do użytkownika. Szeroka reguła Any osłabiłaby skuteczność zabezpieczeń wynikających z polityk użytkowników i Web Policies.

Konfiguracja Per-Connection AD SSO

1. Przygotowanie FQDN zapory i AD SSO

W Administration > Admin and user settings wprowadzić przewidzianą nazwę FQDN zapory i zapisać przez Apply. Następnie w Authentication > Web authentication, przy If Active Directory (AD) SSO is configured, wybrać opcję Kerberos & NTLM i również zapisać przez Apply. NTLM jest technicznie obsługiwany jako mechanizm rezerwowy; Kerberos jest szybszy i bezpieczniejszy i powinien niezawodnie działać w pilotażu. Ponieważ każde połączenie proxy może wywołać uwierzytelnianie, przed większym wdrożeniem należy także obserwować błędy logowania, czasy odpowiedzi oraz obciążenie zapory i AD przy reprezentatywnym ruchu. Nie wyprowadzać z tego stałego mnożnika obciążenia ani gwarantowanej liczby obsługiwanych użytkowników.

Jeśli urządzenia końcowe nie są odpowiednio skonfigurowane dla Kerberos lub przeglądarka nie obsługuje uwierzytelniania Kerberos, automatycznie używany jest NTLMv2 jako mechanizm rezerwowy. W przeciwieństwie do Kerberos NTLMv2 nie wymaga nazwy FQDN jako adresu docelowego proxy. Ten mechanizm zgodności nie gwarantuje jednak pomyślnego logowania: opisane poniżej kanały uwierzytelniania muszą być zainicjalizowane, a rzeczywistą ścieżkę logowania należy sprawdzić za pomocą kont pilotażowych.

W Log Viewer, w Authentication, po inicjalizacji AD SSO muszą pojawić się następujące komunikaty powodzenia:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

Zapora udostępnia te metody dopiero wtedy, gdy działają oba kanały. Cannot initialize Kerberos authentication lub Cannot establish NTLM authentication channel oznaczają konieczność zatrzymania wdrożenia, a nie zachętę do restartowania usługi w ciemno.

2. Ścisłe ograniczenie Device Access

Sophos wymaga włączenia AD SSO dla wymaganej strefy LAN w Administration > Device access i zatwierdzenia przez Apply jako warunku działania Kerberos/NTLM. Najpierw ocenić zakres zezwolenia dla strefy i wpływ na bezpieczeństwo; nie otwierać całej strefy LAN bez tej oceny. Wyłączenie AD SSO we wszystkich strefach uniemożliwia działanie Kerberos/NTLM. Wyjątek ACL dla AD SSO ograniczony do jednego hosta nie zastępuje tego warunku. Dodanie wyjątku zezwalającego nie zawęża istniejącego zezwolenia dla strefy. Jeśli wymagane zezwolenie jest niedopuszczalne, zatrzymać wdrożenie i uzyskać od właściciela ACL lub Sophos Support wspieraną konfigurację o ograniczonym zakresie dla zainstalowanej kompilacji. Osobno ograniczyć dostęp źródłowy do Web proxy do hosta pilotażowego za pomocą ukierunkowanej Local service ACL exception rule, jeśli jest wspierana. Wyjątek zezwalający nie zawęża aktywnego zezwolenia na Web proxy dla całej strefy; szerokie zezwolenie proxy nie może pozostać aktywne, jeśli dostęp ma być rzeczywiście ograniczony do hosta. Nie włączać innych zbędnych stref ani usług. Pełną konfigurację wyjaśnia artykuł Device Access i Local Service ACL.

Dostęp do Web Proxy ma istotny skutek uboczny: host, któremu przyznano dostęp, może przez proxy uzyskać dostęp do usług HTTP i HTTPS zapory, nawet jeśli ich strefa nie jest dopuszczona w standardowej macierzy usług lokalnych. Dlatego z hosta pilotażowego należy przeprowadzić testy negatywne dostępu do WebAdmin, User Portal i innych lokalnych adresów docelowych. Jeśli taka ekspozycja jest niedopuszczalna we własnej sieci, nie aktywować tego projektu produkcyjnie.

W Web > General settings sprawdzić rzeczywisty Web proxy listening port i dozwolone porty docelowe. Domyślny 3128 zmieniać tylko wtedy, gdy można spójnie dostosować plik PAC, GPO i wszystkie zarządzane aplikacje.

3. Utworzenie hosta wielu użytkowników

Utworzyć nowy obiekt hosta w następującej lokalizacji:

Hosts and services > IP host > Add

W przykładzie używane są następujące wartości:

1. Name: RDS01
2. IP version: IPv4
3. Type: IP
4. IP address: 10.20.30.40

Zapisać przez Save i sprawdzić, czy obiekt zawiera dokładny adres IP hosta pilotażowego, zanim zostanie wybrany na liście hostów wielu użytkowników.

Na potrzeby pierwszego testu nie wprowadzać całego zakresu ani podsieci. W przeciwnym razie wiele systemów może jednocześnie utracić dotychczasowe uwierzytelnianie oparte na adresie IP. Kilka hostów dopuszczonych później można po pomyślnym odbiorze każdego z nich w kontrolowany sposób połączyć w grupę hostów.

4. Włączenie Per-Connection AD SSO

Przejść do tego obszaru:

Authentication > Web authentication > Authentication settings for direct web proxy

Następnie:

1. Włączyć Use per-connection AD SSO authentication for multi-user hosts.
2. W Multi-user hosts dodać obiekt RDS01 przez Add new item.
3. Zapisać przez Apply.

Od tego momentu STAS, Captive Portal, Clientless User i przezroczyste AD SSO nie są już dostępne dla 10.20.30.40. Dlatego zmianę należy przeprowadzić w oknie serwisowym i nie traktować istniejącej sesji RDS jako jedynego testu.

Opcjonalne mapowanie API na potrzeby automatyzacji

Administratorzy, którzy chcą zautomatyzować ten krok wykonywany w GUI, znajdą w dokumentacji referencyjnej API dla SFOS 22.0 i 23.0 encję DirectWebProxyAuthentication. Odpowiada ona przełącznikowi i liście hostów wielu użytkowników w następujący sposób; to mapowanie nie jest kompletnym żądaniem gotowym do wykonania.

• DirectWebProxyAuthentication > PerConnectionAuth odpowiada przełącznikowi włączania i wyłączania Per-Connection AD SSO. Parametr jest udokumentowany jako nieobowiązkowy SCALAR i dopuszcza wyłącznie Enable lub Disable. Zapis z ukośnikiem w przykładzie z dokumentacji referencyjnej oznacza alternatywy, a nie trzecią dopuszczalną wartość.
• DirectWebProxyAuthentication > MultiUserHosts > Host opisuje listę nazw hostów wielu użytkowników, czyli w tym przykładzie nazwę wcześniej utworzonego obiektu hosta RDS01, a nie jego adres IP. Host jest nieobowiązkowy i udokumentowany jako ARRAY o typie danych STRING. Dozwolone jest podanie wielu wartości, a zgodnie z dokumentacją referencyjną duplikaty są ignorowane. Dokumentacja podaje maksymalnie 1500 znaków, ale nie wyjaśnia, czy limit dotyczy każdej wartości, czy całej listy.

Kolumny wartości domyślnych są puste: nie wynika z tego ani udokumentowana wartość domyślna, ani informacja o skutkach pominięcia pól. Sekcja opisująca operację nie wyjaśnia również, czy przesłana lista uzupełnia istniejące wpisy, czy je zastępuje, ani jak usuwa się wpisy. Dlatego nie należy traktować ani pominięcia listy, ani przesłania pustej listy jako bezpiecznego sposobu wycofania zmian; przed automatyzacją trzeba ustalić konkretne zachowanie aktualizacji i usuwania dla używanej kompilacji.

Tabela statusów zawiera 200 i 500. Te wpisy API nie dowodzą statusu HTTP ani poprawnego przetwarzania użytkowników i polityk. Pola komunikatów odwołują się do JavaScript; dostępna sekcja opisująca operację nie zawiera dosłownej treści komunikatów odpowiedzi.

Również w przypadku późniejszej autoryzowanej zmiany przez API obowiązują powyższe wymagania wstępne i pilotaż ograniczony do jednego hosta. Przed zmianą należy bezpiecznie zachować rzeczywiste ustawienia i zapewnić niezależny dostęp do zarządzania. Po zmianie ponownie odczytać stan przełącznika i pełną listę hostów wielu użytkowników dokładnie z tej zapory, na której wprowadzono zmianę, i porównać je z zamierzonym stanem; następnie przeprowadzić opisane poniżej testy pozytywne i negatywne dotyczące proxy, użytkowników, polityk, ruchu spoza proxy i usług lokalnych. Odpowiedź potwierdzająca przyjęcie konfiguracji nie zastępuje tych testów odbiorczych. Aby wycofać zmianę, przywrócić zachowany stan sprzed zmiany, nie wyprowadzając z tego nieudokumentowanej składni usuwania przez API.

5. Dystrybucja Direct Web Proxy

Ustawić proxy przeglądarki lub systemu za pomocą GPO, pliku PAC lub zarządzanej aplikacji na następującą wartość:

fw01.corp.example:3128

Dla Kerberos trzeba użyć dokładnie tej nazwy FQDN, która odpowiada SPN. Adres IP jako adres docelowy proxy, nierozwiązywalna nazwa skrócona lub inny alias często prowadzą do przełączenia na NTLM lub monitu o logowanie. Wpisy pomijania proxy należy świadomie ograniczać i dokumentować, ponieważ każde połączenie omijające proxy nie otrzymuje tożsamości Per-Connection.

Ogólna konfiguracja nasłuchu, PAC, reguł i wycofania zmian jest opisana w artykule Konfiguracja Direct Web Proxy z plikiem PAC. Ten artykuł uzupełnia tę konfigurację wyłącznie o uwierzytelnianie wielu użytkowników.

6. Umieszczenie osobnej reguły zapory

W Rules and policies > Firewall rules utworzyć osobną, jasno nazwaną regułę ruchu wychodzącego dla RDS01. Musi znajdować się przed regułami, które obejmują ten sam host z włączonym Match known users.

Dla tego przykładu IPv4 wybrać IPv4 > Add firewall rule > New firewall rule. Jako Rule name ustawić na przykład RDS01_DirectProxy_Outbound, a jako Action — Accept. Nazwa jest dowolna; powinna wskazywać host i przeznaczenie. Pozycję przed konkurencyjnymi regułami użytkowników sprawdzić na podstawie pełnej listy reguł, a nie tylko nazwy.

Bezpieczny zakres konfiguracji:

• Source zones: rzeczywista strefa RDS, na przykład LAN
• Source networks and devices: tylko RDS01
• Destination zones: WAN
• Destination networks: tylko wymagane adresy docelowe lub świadomie Any
• Services: HTTP, HTTPS i własna usługa TCP dla 3128 albo rzeczywiście skonfigurowanego portu nasłuchu proxy; Any tylko świadomie. Wybranie wyłącznie portu nasłuchu nie stanowi pełnego wyboru usług dla Direct Proxy.
• Log firewall traffic: włączone
• Match known users: wyłączone
• Web filtering > Web policy: wybrać przygotowaną politykę zależną od użytkownika lub grupy

Web Policies mogą rozróżniać użytkowników i grupy w ruchu proxy, ale działają dopiero po przypisaniu do reguły zapory. To rozróżnienie należy skonfigurować w Web Policy, a nie w Match known users tej reguły hosta. Po wybraniu lub zmianie Web Policy ponownie sprawdzić przełącznik, ponieważ zależność od użytkownika może go ponownie włączyć.

Zapisać przez Save, ponownie otworzyć regułę i sprawdzić Match known users, logowanie, Web Policy i pozycję. Reguła hosta zezwala na przewidzianą ścieżkę ruchu; Web Policy decyduje w jej obrębie o użytkownikach i grupach. Prawidłowo rozpoznana tożsamość nie oznacza więc automatycznie właściwych uprawnień.

Ogólna instrukcja AD SSO opisuje również reguły użytkowników z włączonym Match known users. Nie jest to model reguł dla wpisanego tutaj adresu IP hosta wielu użytkowników: szczegółowa instrukcja Per-Connection wyraźnie wymaga osobnej reguły z wyłączonym przełącznikiem. Nie należy też przenosić dopasowania usług z przezroczystej reguły HTTP/HTTPS: port nasłuchu proxy opisuje ścieżkę klient–proxy, natomiast osobne połączenie proxy–adres docelowy korzysta z usług docelowych, takich jak HTTP lub HTTPS. W pilotażu potwierdzić rzeczywiste Rule ID i właściwy port na podstawie logów. Klient IPv6 łączący się z adresem docelowym IPv4 może wymagać dwóch reguł; ten przykład IPv4 nie stanowi pełnej instrukcji dla środowiska dual-stack.

Dla DNS, aktualizacji i innych niezbędnych połączeń spoza proxy utworzyć osobną regułę maszynową. Nie dodawać ogólnej reguły WAN–LAN; pokazany przez Sophos przykład ruchu przychodzącego nie jest potrzebny do standardowego dostępu RDS do WWW i bez odrębnego celu publikacji stanowiłby niepotrzebną powierzchnię ataku. Konfigurację, kolejność i logowanie wyjaśnia artykuł Prawidłowe tworzenie reguł zapory.

Jeśli niezależnie od proxy istnieje uzasadniony dostęp przychodzący do hosta wielu użytkowników, także w jego osobnej regule Match known users musi być wyłączone. Ściśle określić strefę źródłową i dozwolone hosty źródłowe, strefę docelową i RDS01 oraz rzeczywiście wymagane usługi, włączyć logowanie i sprawdzić pozycję przed konkurencyjnymi regułami użytkowników. Nie jest to zachęta do publicznego udostępniania RDP; dla standardowego dostępu do WWW nie tworzy się nowej reguły ruchu przychodzącego.

Testy odbiorcze z dwoma użytkownikami RDS

Pojedyncze pomyślne otwarcie strony w przeglądarce dowodzi tylko, że działa jakiś ruch proxy. Właściwy odbiór wymaga dwóch równoległych sesji.

1. Przypisać dwa konta pilotażowe AD do różnych grup Web Policy.
2. Otworzyć dwie nowe sesje RDS na RDS01.
3. W obu sesjach sprawdzić efektywną konfigurację proxy.
4. W każdej sesji wykonać jedno dozwolone żądanie HTTP lub HTTPS oraz jedno żądanie celowo oceniane inaczej.
5. W Current activities > Live users sprawdzić obu użytkowników z Client Type Multi-host client.
6. W Log viewer > Authentication sprawdzić użytkowników i Log Comp dla Kerberos lub NTLM.
7. W logach WWW i zapory porównać użytkownika, politykę, Rule ID, działanie i czas.
8. Wykonać niezbędny test ruchu spoza proxy i potwierdzić, że nie otrzymuje on błędnie tożsamości użytkownika.
9. Z hosta pilotażowego ustalić, które lokalne usługi HTTP i HTTPS zapory są dostępne przez proxy. Jeśli dostępna jest usługa niedopuszczalna w przyjętym projekcie zabezpieczeń, zatrzymać wdrożenie i wznowić je dopiero po potwierdzeniu dodatkowego środka ochronnego.

Miarodajne porównanie wykorzystuje w obu sesjach ten sam zatwierdzony cel testowy: konto w RDS-Web-Standard może go otworzyć, a konto w RDS-Web-Restricted zostaje zablokowane przez przygotowaną Web Policy. Zapisać datę, godzinę, użytkownika, źródłowy adres IP, Rule ID, politykę i wynik. Następnie otworzyć cel kontrolny, z którego mogą korzystać obie grupy. Pozwala to odróżnić zamierzone ograniczenie grupy od ogólnej awarii proxy lub DNS. Cele testowe pochodzą z własnej zatwierdzonej listy testowej; nie blokować produkcyjnej strony biznesowej wyłącznie na potrzeby odbioru.

Kolejne hosty RDS dodawać dopiero wtedy, gdy obaj użytkownicy są jednocześnie prawidłowo rozróżniani, uzyskiwane są zamierzone wyniki Web Policy i znany jest sposób działania ścieżki spoza proxy. W ogólnych testach odbiorczych reguł pomaga artykuł Kontrolowane testowanie reguł Sophos Firewall.

Rozwiązywanie problemów

Proxy jest nieosiągalne

Sprawdzić rozwiązywanie FQDN, port, wynik konfiguracji PAC/GPO, strefę źródłową oraz zezwolenia Web proxy i AD SSO. Pomyślny test serwera AD nie potwierdza dostępu do proxy. Przy trasach SD-WAN port proxy lub Any musi pasować do dopasowania usług; zapora sama tworzy zewnętrzne połączenie proxy, dlatego nie obowiązują wszystkie cechy klienta tak jak w zwykłym ruchu routowanym.

Przeglądarka prosi o dane logowania lub używa NTLM

Sprawdzić adres docelowy proxy, DNS, HTTP-SPN, strefę przeglądarki i zintegrowane uwierzytelnianie. Kerberos wymaga pasującej nazwy FQDN, a nie adresu IP zapory. Przełączenie na NTLM jest objawem, który należy najpierw wyjaśnić, a nie powodem do zapobiegawczego wdrożenia wyłącznie NTLM.

Obie sesje są widoczne jako ten sam użytkownik

Sprawdzić, czy obie przeglądarki rzeczywiście korzystają z jawnie skonfigurowanego proxy i czy aplikacja nie tworzy połączeń poza daną sesją użytkownika. Również pośredniczące proxy lub NAT może zmienić oczekiwany model połączeń. W Live Users musi pojawić się typ Multi-host client; zwykłe mapowanie oparte na adresie IP oznacza dla tego hosta niewłaściwą ścieżkę.

Użytkownik jest widoczny, ale Web Policy nie działa

Łącznie sprawdzić grupę AD, Main Group, kolejność Web Policies, regułę zapory i wpis w logu. Match known users musi pozostać wyłączone w specjalnej regule hosta. Widoczne uwierzytelnienie nie dowodzi jeszcze, że żądanie korzysta z oczekiwanej Web Policy lub Firewall Rule ID.

Jeśli użytkownik pilotażowy znajduje się w Default group zamiast w oczekiwanej zaimportowanej grupie AD, najpierw sprawdzić Authentication > Groups, bazę wyszukiwania i import grup. Nie przypisywać szerszej polityki grupy domyślnej w celu zamaskowania błędu. Po kontrolowanej korekcie sprawdzić przy nowym logowaniu, czy przypisanie i oba testy polityk dają właściwe wyniki.

Ruch inny niż WWW nie pokazuje użytkownika

Jest to oczekiwane zachowanie. Per-Connection AD SSO identyfikuje wyłącznie HTTP i HTTPS przez Direct Web Proxy. Dla wymaganego ruchu maszynowego stosuje się regułę bez odniesienia do użytkownika. Jeśli RDP, SMB, ruch bazodanowy lub inny ruch spoza proxy trzeba rozróżniać według sesji, należy przejść na SATC.

Po aktualizacji lub przełączeniu awaryjnym HA SSO przestaje działać

AD SSO może wymagać ponownego dołączenia do domeny po aktualizacji, przy korzystaniu z wielu serwerów AD lub w HA. Dlatego delegowane konto dołączania do domeny musi pozostać ważne. Po kontrolowanym przełączeniu awaryjnym przeprowadzić test z nowym połączeniem proxy i oboma kontami pilotażowymi; nie zakładać, że istniejące połączenia proxy lub bilety Kerberos będą kontynuowane bez przerwy. W każdym trybie HA każdy węzeł zapisuje wyłącznie logi ruchu, który sam przetwarzał. Dla danego zdarzenia należy więc sprawdzić węzeł aktywny lub przetwarzający ruch w tym czasie.

Przy aktualizacji z SFOS 21.5 lub starszego bezpośrednio do SFOS 22.0 GA Build 411 dodatkowo może mieć zastosowanie znany problem NC-176853: AD SSO z NTLM i Kerberos może przestać działać bezpośrednio po aktualizacji, przez co polityki oparte na tożsamości nie zostaną dopasowane. Sophos wskazuje SFOS 22.0 MR1 Build 490 jako wersję zawierającą poprawkę. Wewnętrzna procedura dotycząca KBA-000048429 opisuje diagnostykę i obejście problemu. Known Issues List nie wymienia Per-Connection AD SSO osobno; informacja ta jest więc istotna tylko wtedy, gdy podstawowa ścieżka AD SSO przestaje działać po dokładnie tej aktualizacji. Zachować numer kompilacji firmware, czas i logi, sprawdzić KBA dla objętej problemem kompilacji i nie obchodzić problemu szerokimi regułami ani zmianą uwierzytelniania.

Odczyt odpowiednich logów

W Advanced Shell istotne są następujące pliki:

cd /log
tail -n 200 nasm.log
tail -n 200 access_server.log
tail -n 200 awarrenhttp.log

nasm.log pokazuje problemy z NTLM, Kerberos i ewentualnie KVNO. access_server.log pomaga w analizie uwierzytelniania i autoryzacji, a awarrenhttp.log — Web Proxy. awarrenhttp_access.log powstaje wyłącznie przy tymczasowo włączonym debugowaniu i nie należy do standardowego pierwszego kroku. Przed restartami usług lub rozszerzeniem debugowania najpierw zachować przedział czasowy, użytkownika, adres docelowy, regułę i istniejące logi.

Wycofanie zmian

Prawidłowe wycofanie zmian przywraca nie tylko proxy, lecz także wcześniejszy model uwierzytelniania.

1. Udokumentować aktualną listę hostów wielu użytkowników, wyjątki Device Access, reguły, Web Policy i dystrybucję proxy.
2. Usunąć RDS01 z Multi-user hosts i zapisać przez Apply.
3. W kontrolowany sposób wycofać GPO proxy, plik PAC lub konfigurację aplikacji.
4. Przywrócić wcześniejsze mapowanie STAS, Clientless lub Captive Portal tylko wtedy, gdy było wcześniej udokumentowane i odpowiednie dla tego adresu IP.
5. Po sprawdzeniu innych zależności usunąć pilotażowy wyjątek ACL lub tymczasowe zezwolenia strefowe AD SSO i Web Proxy albo przywrócić je dokładnie do poprzedniego stanu.
6. Wyłączyć lub usunąć specjalne reguły hosta i reguły maszynowe, gdy tylko zostanie potwierdzona ścieżka zastępcza.
7. Ponownie przeprowadzić testy z nowymi sesjami przeglądarki i RDS, a w przypadku HA — w obu rolach operacyjnych.

Lista kontrolna

• Per-Connection AD SSO jest przeznaczone wyłącznie dla ruchu HTTP/HTTPS jawnie kierowanego przez proxy.
• Host pilotażowy ma stały, jednoznaczny adres IP bez innych systemów za nim.
• AD, grupy, dołączenie do domeny, FQDN, DNS, SPN i czas zostały sprawdzone.
• Warunek strefowy AD SSO i wpływ na bezpieczeństwo sprawdzone; wymagana strefa LAN włączona i ustawienia zatwierdzone przez Apply, dostęp do Web proxy osobno ograniczony do hosta pilotażowego bez szerokiego zezwolenia proxy. Jeśli zezwolenie dla strefy jest niedopuszczalne, zatrzymać wdrożenie i uzyskać wspieraną konfigurację o ograniczonym zakresie.
• Przeglądarki i aplikacje używają fw01.corp.example:3128 lub własnych wartości zastępczych.
• Specjalna reguła hosta ma włączone logowanie i wyłączone Match known users.
• Ruch spoza proxy został zaplanowany jako ruch maszynowy albo projekt zmieniono na SATC.
• Przeprowadzono testy pozytywne i negatywne dwóch równoległych użytkowników, różnych polityk i dostępu do zarządzania.
• Dla przełączenia awaryjnego HA i aktualizacji istnieje udokumentowana procedura ponownego dołączenia do domeny i ponownych testów.
• Udokumentowano wycofanie zmian listy hostów wielu użytkowników, dystrybucji proxy, Device Access, reguł i wcześniejszego uwierzytelniania.

Najczęściej zadawane pytania