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.

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 wyłącznie HTTP i HTTPS przesyłane przez jawne proxy mają być przetwarzane zależnie od użytkownika.
2. Sprawdzić Active Directory, import grup, DNS, czas i Domain Join zapory.
3. Przygotować rozwiązywalną nazwę FQDN zapory oraz odpowiedni HTTP-SPN dla Kerberos.
4. Zezwolić na AD SSO i Web proxy tylko dla wymaganej strefy źródłowej lub hosta pilotażowego.
5. Utworzyć dla serwera RDS dokładny obiekt hosta IP.
6. W sekcji Authentication > Web authentication włączyć Per-Connection AD SSO dla tego hosta.
7. Skonfigurować przeglądarki i aplikacje obsługujące proxy do korzystania z nazwy FQDN zapory i portu 3128.
8. Umieścić osobną, logowaną regułę hosta przed kolidującymi regułami użytkowników i pozostawić Match known users wyłączone.
9. Oddzielnie sprawdzić dwie równoległe sesje RDS, różne wyniki Web Policy oraz ruch spoza proxy.

Per-Connection AD SSO, STAS czy SATC?

Wszystkie trzy metody dostarczają kontekst użytkownika, lecz rozwiązują różne zadania.

• STAS jest odpowiedni dla zwykłych klientów Windows, gdy jeden adres IP klienta zazwyczaj należy do dokładnie jednego użytkownika. Zapora otrzymuje powiązanie użytkownika z adresem IP na podstawie zdarzeń logowania Windows.
• Per-Connection AD SSO jest odpowiedni dla hostów wielu użytkowników, jeśli trzeba rozróżniać tylko jawnie przekazywane przez proxy połączenia HTTP i HTTPS. Agent SATC nie jest potrzebny na serwerze RDS, ale wszystkie aplikacje muszą niezawodnie korzystać z Direct Web Proxy.
• SATC jest odpowiedni dla systemów RDS lub Citrix, jeśli tożsamości wymagają również inne typy połączeń z poszczególnych sesji użytkowników. Wymaga to Sophos Server Protection na hoście sesji.

Klasyczny STAS w Sophos Firewall nie potrafi rozróżnić 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. Jeśli aplikacja nie obsługuje jawnego proxy albo protokoły inne niż webowe mają być kontrolowane zależnie od użytkownika, należy zatrzymać wdrożenie i ocenić SATC.

Przykład i wartości do zastąpienia

W instrukcji użyto następującego przykładu:

• host wielu użytkowników: RDS01
• adres IP: 10.20.30.40
• nazwa FQDN zapory i cel 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 Web Policy

Adres 10.20.30.40 należy zastąpić stałym adresem IP serwera pilotażowego widocznym przez zaporę. Za tym adresem nie mogą przez NAT pojawiać się dodatkowe systemy. fw01.corp.example to nazwa przykładowa, którą trzeba zastąpić rzeczywistą, wewnętrznie rozwiązywalną nazwą FQDN zapory. Część hosta powinna mieć najwyżej 15 znaków i być zapisana małymi literami, aby nazwa hosta, nazwa NetBIOS, obiekt komputera AD i SPN były zgodne.

Port 3128 jest standardowym portem Direct Web Proxy. Jeśli środowisko korzysta z innego Listening Port, zapora, plik PAC lub GPO, przeglądarki i testy muszą używać tej samej wartości. Przykładowe grupy służą jedynie czytelnemu testowi akceptacyjnemu; nazwy grup i Web Policies trzeba dopasować do własnej struktury uprawnień.

Przygotowanie wymagań

Sprawdzenie Active Directory i Domain Join

Zapora wymaga działającego serwera Active Directory, zaimportowanych grup i poprawnego Domain Join. Artykuł Łączenie Active Directory z Sophos Firewall opisuje LDAPS, bazę wyszukiwania, import grup i ogólne wymagania AD SSO.

Do zwykłych zapytań LDAP wystarczy konto z uprawnieniami do odczytu. Domain Join i utworzenie SPN wymagają natomiast konta Domain Admin albo konta z prawidłowo delegowanymi uprawnieniami. Zapisane konto musi także umożliwiać późniejszy rejoin, ponieważ HA, dodatkowe serwery AD lub aktualizacje mogą ponownie go uruchomić. Nie należy w tym celu bez potrzeby stale używać nieograniczonego konta Domain Admin.

W sekcji Authentication > Services > Firewall authentication methods należy wybrać właściwy serwer AD i ustawić go we właściwej kolejności. Gdy serwerów jest kilka, zapora sprawdza je od góry do dołu. Opcja Test connection przy serwerze AD potwierdza tylko dane logowania i osiągalność, a nie późniejsze logowanie Kerberos lub NTLM w przeglądarce.

Sprawdzenie FQDN, DNS, SPN i czasu

Kerberos działa tylko wtedy, gdy klienci używają nazwy FQDN zapory jako celu proxy. Adres IP proxy nie wystarcza. Na pilotażowym kliencie Windows można wykonać następujące kontrole tylko do odczytu:

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

HTTP-SPN, czyli Service Principal Name, wiąże nazwę FQDN proxy z obiektem komputera zapory w AD. Polecenie setspn -Q powinno zwrócić dokładnie jedno prawidłowe powiązanie. Brak wyniku lub kilka wyników trzeba wyjaśnić przed wdrożeniem.

Odpowiedź DNS musi wskazywać właściwą zaporę. Klient, Domain Controller i zapora potrzebują także czasu zgodnego z wymaganiami Kerberos. Polecenia nie wprowadzają żadnych zmian. Nie należy korygować SPN, Domain Join ani konfiguracji czasu na podstawie przypuszczeń; najpierw trzeba potwierdzić rzeczywisty błąd.

Inwentaryzacja obsługi proxy i wyjątków

Każda przeglądarka i aplikacja, której ruch internetowy ma otrzymać użytkownika, musi korzystać z jawnego proxy i obsługiwać zintegrowane uwierzytelnianie Windows. Przed wdrożeniem należy co najmniej sprawdzić:

• 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
• cele znajdujące się w pliku PAC lub na liście obejść proxy

Ruch omijający proxy zgodnie z założeniem pozostaje bez identyfikatora użytkownika. Dla wymaganych połączeń maszynowych należy zaplanować osobną, ściśle ograniczoną regułę bez zależności od użytkownika. Szeroka reguła Any osłabiłaby działanie zabezpieczeń użytkowników i Web Policies.

Konfiguracja Per-Connection AD SSO

1. Przygotowanie FQDN zapory i AD SSO

W sekcji Administration > Admin and user settings należy wprowadzić właściwą nazwę FQDN zapory. Następnie w Authentication > Web authentication, przy If Active Directory (AD) SSO is configured, wybrać Kerberos & NTLM. NTLM jest technicznie obsługiwany jako mechanizm awaryjny, jednak w większych instalacjach Kerberos powinien działać niezawodnie, ponieważ Per-Connection AD SSO może generować bardzo wiele dodatkowych żądań uwierzytelniania.

Po inicjalizacji AD SSO w Log Viewer, w sekcji Authentication, muszą pojawić się następujące komunikaty o powodzeniu:

• Kerberos authentication initialized successfully
• NTLM authentication channel established successfully

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

2. Ścisłe zezwolenie w Device Access

W sekcji Administration > Device access należy zezwolić na AD SSO i Web proxy dla przewidzianej ścieżki źródłowej. Przy stałym adresie IP hosta pilotażowego ukierunkowana Local service ACL exception rule jest zwykle bardziej restrykcyjna niż dostęp dla całej strefy LAN. Dodatkowy wyjątek Accept nie ogranicza jednak już aktywnego zezwolenia dla strefy; w rzeczywiście ścisłym projekcie szerokie zezwolenie musi pozostać wyłączone. Pełną konfigurację opisuje Device Access i Local Service ACL.

Dostęp przez Web Proxy ma ważny skutek uboczny: dozwolony host może przez proxy docierać do usług HTTP i HTTPS zapory, nawet jeśli jego strefa nie ma dostępu w zwykłej macierzy Local Service. Z hosta pilotażowego należy więc wykonać negatywne testy WebAdmin, User Portal i innych lokalnych celów. Jeśli taka ekspozycja jest nieakceptowalna w danej sieci, projektu nie należy uruchamiać produkcyjnie.

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

3. Utworzenie hosta wielu użytkowników

Nowy obiekt hosta należy utworzyć pod następującą ścieżką:

Hosts and services > IP host > Add

Dla przykładu należy użyć tych wartości:

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

W pierwszym teście nie należy podawać całego zakresu ani podsieci. W przeciwnym razie wiele systemów może jednocześnie utracić dotychczasowe uwierzytelnianie oparte na adresie IP. Po pomyślnym osobnym teście zatwierdzone hosty można w kontrolowany sposób połączyć w grupę hostów.

4. Włączenie Per-Connection AD SSO

Należy przejść do następującej sekcji:

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 obszarze Multi-user hosts dodać obiekt RDS01.
3. Zapisać przyciskiem Apply.

Od tej chwili STAS, Captive Portal, Clientless User i przezroczyste AD SSO nie są dostępne dla adresu 10.20.30.40. Dlatego zmianę należy wykonać w oknie serwisowym, a istniejącej sesji RDS nie wolno traktować jako jedynego testu.

5. Dystrybucja Direct Web Proxy

Proxy przeglądarki lub systemu należy ustawić przez GPO, plik PAC albo zarządzaną aplikację na następującą wartość:

fw01.corp.example:3128

Kerberos wymaga dokładnie tej nazwy FQDN, która odpowiada SPN. Adres IP jako cel proxy, nierozwiązywalna nazwa skrócona lub inny alias często powodują przejście na NTLM albo monit o dane logowania. Wpisy obejścia należy celowo ograniczać i dokumentować, ponieważ każde ominięte połączenie nie otrzyma tożsamości Per-Connection.

Ogólną konfigurację listenera, pliku PAC, reguły i wycofania opisano w artykule Konfiguracja Direct Web Proxy z plikiem PAC. Ten artykuł dodaje wyłącznie uwierzytelnianie wielu użytkowników.

6. Umieszczenie osobnej reguły zapory

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

Bezpieczne ramy konfiguracji:

• Source zones: rzeczywista strefa RDS, na przykład LAN
• Source networks and devices: tylko RDS01
• Destination zones: WAN
• Destination networks: tylko potrzebne cele albo świadomie Any
• Services: osobna usługa TCP dla 3128 lub faktycznie skonfigurowanego proxy-Listening Port; Any tylko świadomie
• Log firewall traffic: włączone
• Match known users: wyłączone
• Web filtering > Web policy: wybrana przygotowana Policy zależna od użytkownika lub grupy

Web Policies potrafią 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 przez Match known users w tej regule hosta. Po wybraniu lub zmianie Web Policy trzeba ponownie sprawdzić przełącznik, ponieważ zależność od użytkownika może go znów włączyć.

Dla DNS, aktualizacji i innych wymaganych połączeń spoza proxy należy utworzyć osobną regułę maszynową. Nie wolno dodawać ogólnej reguły WAN-do-LAN; przykład połączenia przychodzącego pokazywany przez Sophos nie jest potrzebny do zwykłego dostępu webowego z RDS i bez osobnego celu publikacji niepotrzebnie zwiększałby powierzchnię ataku. Strukturę, kolejność i logowanie opisuje artykuł Prawidłowe tworzenie reguł zapory.

Test z dwoma użytkownikami RDS

Jedno udane wywołanie w przeglądarce dowodzi jedynie, że działa jakiś ruch proxy. Właściwy test akceptacyjny wymaga dwóch równoległych sesji.

1. Przypisać dwa pilotażowe konta 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 wywołać jeden dozwolony oraz jeden celowo inaczej oceniany adres HTTP lub HTTPS.
5. W sekcji Current activities > Live users sprawdzić obu użytkowników z Client Type Multi-host client.
6. W sekcji Log viewer > Authentication sprawdzić użytkownika i Log Comp dla Kerberos lub NTLM.
7. Porównać w logach webowych i zapory użytkownika, Policy, Rule ID, akcję i czas.
8. Uruchomić potrzebny test spoza proxy i potwierdzić, że ruch ten nie otrzymuje 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 osiągalna jest usługa niedozwolona przez projekt bezpieczeństwa, należy zatrzymać wdrożenie i kontynuować dopiero po zastosowaniu potwierdzonego dodatkowego zabezpieczenia.

Kolejne hosty RDS można dodać dopiero wtedy, gdy obaj użytkownicy są jednocześnie prawidłowo rozróżniani, występują zamierzone wyniki Web Policy, a ścieżka spoza proxy jest zrozumiała. W ogólnym teście reguł pomaga instrukcja Kontrolowane testowanie reguł Sophos Firewall.

Rozwiązywanie problemów

Proxy jest nieosiągalne

Należy sprawdzić rozwiązywanie FQDN, port, wynik PAC/GPO, strefę źródłową oraz zezwolenia Web proxy i AD SSO. Udany test serwera AD nie potwierdza dostępu do proxy. Przy trasach SD-WAN port proxy lub Any musi pasować do kryterium usługi; zapora sama nawiązuje zewnętrzne połączenie proxy, dlatego nie wszystkie cechy klienta działają tak samo jak w zwykłym ruchu routowanym.

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

Należy sprawdzić cel proxy, DNS, HTTP-SPN, strefę przeglądarki i zintegrowane uwierzytelnianie. Kerberos wymaga właściwej nazwy FQDN, a nie adresu IP zapory. Przejście na NTLM jest objawem, który najpierw trzeba wyjaśnić, a nie powodem do zapobiegawczego wdrożenia wyłącznie NTLM.

Obie sesje są widoczne jako ten sam użytkownik

Należy sprawdzić, czy obie przeglądarki rzeczywiście używają jawnego proxy i czy aplikacja nie tworzy połączeń poza daną sesją użytkownika. Proxy nadrzędne lub NAT również mogą zmienić oczekiwany model połączeń. W Live Users musi pojawić się typ Multi-host client; zwykłe powiązanie oparte na adresie IP jest dla tego hosta nieprawidłową ścieżką.

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

Należy łącznie sprawdzić grupę AD, Main Group, kolejność Web Policy, 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.

Ruch inny niż webowy nie pokazuje użytkownika

Jest to zachowanie oczekiwane. Per-Connection AD SSO identyfikuje tylko HTTP i HTTPS przesyłane przez Direct Web Proxy. Dla niezbędnego ruchu maszynowego obowiązuje reguła bez zależności od użytkownika. Jeśli RDP, SMB, ruch bazodanowy lub inny ruch spoza proxy trzeba rozróżniać według sesji, należy przejść na SATC.

SSO przestało działać po aktualizacji lub przełączeniu HA

AD SSO może wymagać ponownego Domain Join po aktualizacji, przy użyciu wielu serwerów AD albo w HA. Delegowane konto join musi więc pozostać ważne. Po kontrolowanym przełączeniu należy przeprowadzić test z nowym połączeniem proxy i oboma kontami pilotażowymi; nie należy 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ł przechowuje wyłącznie logi ruchu, który sam obsłużył. Dla danego zdarzenia trzeba więc sprawdzić węzeł aktywny lub przetwarzający w tym czasie.

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 ewentualnym KVNO. access_server.log pomaga analizować uwierzytelnianie i autoryzację, a awarrenhttp.log Web Proxy. Plik awarrenhttp_access.log powstaje tylko po czasowym włączeniu debugowania i nie należy do zwykłych pierwszych kroków. Przed restartem usług lub rozszerzeniem debugowania trzeba najpierw zabezpieczyć przedział czasu, użytkownika, cel, regułę i dostępne logi.

Wycofanie zmian

Poprawny powrót przywraca nie tylko proxy, ale również poprzedni model uwierzytelniania.

1. Udokumentować bieżącą 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 powiązanie STAS, Clientless lub Captive Portal tylko wtedy, gdy było wcześniej udokumentowane i właściwe dla tego adresu IP.
5. Po sprawdzeniu innych zależności usunąć pilotażowy wyjątek ACL oraz tymczasowe zezwolenia strefowe AD SSO i Web Proxy albo dokładnie przywrócić ich wcześniejszy stan.
6. Wyłączyć lub usunąć specjalne reguły hosta i reguły maszynowe, gdy ścieżka zastępcza zostanie potwierdzona.
7. Ponownie przetestować nowe sesje przeglądarki i RDS, a w HA obie role operacyjne.

Lista kontrolna

• Per-Connection AD SSO jest przeznaczone wyłącznie dla jawnego ruchu HTTP/HTTPS przez proxy.
• Host pilotażowy ma stały, jednoznaczny adres IP bez innych systemów za nim.
• Sprawdzono AD, grupy, Domain Join, FQDN, DNS, SPN i czas.
• AD SSO i Web Proxy są dozwolone tylko dla wymaganej ścieżki źródłowej.
• 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 zaplanowano jako ruch maszynowy albo projekt zmieniono na SATC.
• Pozytywnie i negatywnie przetestowano dwóch równoległych użytkowników, różne Policies i dostęp administracyjny.
• Dla przełączenia HA i aktualizacji istnieje udokumentowana procedura rejoin i ponownego testu.
• Udokumentowano wycofanie listy hostów wielu użytkowników, dystrybucji proxy, Device Access, reguł i poprzedniego uwierzytelniania.

Często zadawane pytania