Active Directory z Sophos Firewall: konfiguracja

Active Directory jest w wielu środowiskach Sophos Firewall nadal centralnym źródłem użytkowników, grup i uwierzytelniania. Firewall używa integracji AD na przykład do reguł użytkowników, Remote Access VPN, Captive Portal, User Portal, reportingu lub scenariuszy Single Sign-On.

Ten artykuł wyjaśnia, jak dodać serwer Active Directory na Sophos Firewall, które pola są naprawdę ważne i jak później sprawdzić połączenie. Dla nowych projektów Remote Access należy dodatkowo zdecydować, czy klasyczne AD, RADIUS albo Microsoft Entra ID SSO dla Sophos Connect i VPN Portal pasuje lepiej.

Poniższe Sophos-Techvids-Video pokazuje podstawowy proces jako uzupełnienie wizualne. Film został przygotowany dla SFOS v21, logika nadal jest pomocna, ale pojedyncze ekrany w SFOS 22 mogą wyglądać nieco inaczej.

Kontekst

Sophos Firewall może korzystać z wielu źródeł uwierzytelniania. Active Directory ma sens, gdy użytkownicy i grupy są już utrzymywani lokalnie w domenie Windows, a firewall ma bezpośrednio używać tych tożsamości.

Typowe zastosowania:

• synchronizacja użytkowników i grup z lokalnego Active Directory
• reguły firewall z odniesieniem do użytkownika lub grupy
• Remote Access VPN z użytkownikami AD
• User Portal lub Captive Portal z kontami domenowymi
• reporting według użytkownika zamiast tylko adresu IP
• Active Directory SSO z NTLM lub Kerberos

Integracja AD nie oznacza jednak automatycznie, że rozwiązane są wszystkie pytania dotyczące uwierzytelniania. Trzeba rozróżnić, czy firewall tylko odpytuje użytkowników przez LDAP/LDAPS, czy importowane są grupy, czy używane jest SSO oraz czy Remote Access dodatkowo wymaga MFA. Dla podstaw MFA pasuje Aktywacja MFA dla Sophos Firewall WebAdmin, VPN Portal i Remote Access.

Ważne decyzje przed konfiguracją

Przed dodaniem serwera należy wyjaśnić te punkty:

⚠️ Połączenie między firewallem i serwerem uwierzytelniania powinno być szyfrowane. Nieszyfrowany LDAP na porcie 389 może działać w laboratoriach, ale dla środowisk produkcyjnych nie jest dobrym trwałym rozwiązaniem.

Dla integracji AD obsługiwane są także starsze wersje Windows Server, ale w aktualnych środowiskach istotne są przede wszystkim Windows Server 2016, 2019, 2022 i 2025. Od SFOS 21.5 MR1 Active Directory SSO z Windows Server 2025 jest możliwe dla NTLM i Kerberos. SFOS 22 zawiera zaktualizowane komponenty Samba dla Kerberos i NTLM oraz usuwa starsze metody szyfrowania. Właśnie po upgrade firewalla lub Domain Controller należy celowo przetestować AD SSO, import grup i Remote Access.

Ważne: ścisłe wymuszanie LDAP Channel Binding i LDAP Signing nie jest obecnie obsługiwane przez Sophos Firewall. Jeżeli Domain Controllers wymuszają bardzo twarde wymagania bezpieczeństwa LDAP, integrację AD należy przetestować w oknie serwisowym przed zmianą produkcyjną.

Dodanie serwera Active Directory

Konfiguracja odbywa się w WebAdmin Sophos Firewall:

Authentication > Servers

Tam przez Add tworzy się nowy serwer uwierzytelniania i jako Server Type wybiera Active Directory.

Pola konfiguracji Active Directory

Numeracja na zrzucie ekranu jest celowa: najważniejsze pola są wyjaśniane od góry do dołu. Zależnie od wersji SFOS kolejność może wyglądać nieco inaczej. W nowszych wersjach widać dodatkowo Validate server certificate, jeśli ma być aktywowana weryfikacja certyfikatu dla LDAPS.

Jeżeli istnieje kilka Domain Controllers, należy świadomie zdecydować, czy firewall odpyta konkretny DC, czy stabilna wewnętrzna nazwa DNS wskazuje na odpowiednią infrastrukturę AD. Ważne jest, aby rozwiązywanie DNS, certyfikat, routing i reguły firewall pasowały do siebie.

Validate server certificate

W aktualnych wersjach SFOS można dodatkowo aktywować Validate server certificate. Jest to sensowne dla LDAPS, ponieważ firewall wtedy nie tylko łączy się szyfrowanym kanałem, lecz także sprawdza, czy ufa certyfikatowi Domain Controller.

Muszą pasować te punkty:

1. Wystawiająca CA certyfikatu Domain Controller jest znana na firewallu pod Certificates > Certificates.
2. Wartość w Server IP/domain pasuje do nazwy certyfikatu albo do Subject Alternative Name certyfikatu.
3. Jeśli używany jest CNAME, firewall może rozwiązać tę nazwę wewnętrznie.
4. Data i godzina na firewallu oraz Domain Controller są poprawne.

Jeżeli wewnętrzne rozwiązywanie DNS nie rozwiązuje poprawnie CNAME albo nazwy Domain Controller, może pomóc DNS Host Entry pod Network > DNS > DNS host entry.

NetBIOS domain i Domain name

Sophos Firewall potrzebuje zarówno informacji o NetBIOS domain, jak i Domain name. Te wartości powinny dokładnie pasować do domeny AD.

NetBIOS domain można znaleźć na przykład w Active Directory Users and Computers we właściwościach domeny.

Domain name jest nazwą DNS domeny, na przykład example.local albo ad.example.com.

Typowe błędy w tym miejscu:

• NetBIOS name i DNS domain name są mylone.
• Wpisany Domain Controller należy do innej domeny.
• Firewall nie może rozwiązać nazwy DNS Domain Controller.
• Między firewallem i Domain Controller połączenie blokuje firewall sieciowy lub Windows Firewall.

Konto serwisowe i hasło

Do dostępu do Active Directory należy używać dedykowanego konta serwisowego. Konto Domain Admin nie jest potrzebne do normalnych zapytań LDAP i niepotrzebnie zwiększa ryzyko.

Sensowne zasady:

• osobne konto dla firewalla, na przykład svc-sophos-fw-ldap
• tylko wymagane prawa odczytu
• udokumentowany owner dla zmian hasła
• długie, unikalne hasło
• brak logowania interaktywnego, jeśli zasady AD potrafią to poprawnie odwzorować
• monitoring albo przypomnienie przed wygaśnięciem hasła

Jeśli hasło konta serwisowego wygaśnie lub zostanie zmienione, firewall nie może już odpytywać użytkowników i grup. Później często wygląda to jak problem VPN, portalu albo reguły użytkownika, choć rzeczywista przyczyna leży w integracji AD.

Bezpieczeństwo połączenia i LDAPS

Dla środowisk produkcyjnych należy preferować LDAPS. Domain Controller potrzebuje do tego odpowiedniego certyfikatu, a firewall musi ufać wystawiającej CA.

Należy sprawdzić:

• Port 636 jest osiągalny z interfejsu firewalla do Domain Controller.
• Certyfikat Domain Controller jest ważny.
• Nazwa certyfikatu pasuje do używanej nazwy DNS.
• Wystawiająca CA jest znana na firewallu, jeśli wymagana jest weryfikacja.
• Czas i data na firewallu oraz Domain Controller są poprawne.

Przy tematach certyfikatów istotna jest także dystrybucja CA. Dla dystrybucji CA Sophos Firewall na klientów pasuje Dystrybucja certyfikatu CA Sophos Firewall dla HTTPS Scanning. Dla LDAPS decydująca jest natomiast przede wszystkim CA Domain Controller lub wewnętrznej PKI.

Display name attribute i Email address attribute

Atrybut wyświetlania określa, jak użytkownicy są prezentowani w Sophos Firewall. Typowe wartości to:

• sAMAccountName
• userPrincipalName
• displayName
• name

sAMAccountName jest w klasycznych środowiskach AD często odporny i krótki. userPrincipalName jest bliższy nowoczesnym nazwom logowania i tożsamościom chmurowym. displayName jest dobrze czytelny dla ludzi, ale nie zawsze wystarczająco jednoznaczny dla eksploatacji i troubleshooting.

Atrybuty można sprawdzić w Active Directory Users and Computers, jeśli aktywne są Advanced Features.

Atrybut e-mail to najczęściej mail. Jest istotny głównie wtedy, gdy firewall ma przypisywać użytkownikom informacje związane z e-mailem.

Baza wyszukiwania i grupy

Baza wyszukiwania określa, którą część Active Directory przeszukuje firewall. Dla całej domeny przykładem byłoby:

DC=example,DC=local

Dla pojedynczej OU ścieżka może wyglądać na przykład tak:

OU=Users,OU=Company,DC=example,DC=local

Distinguished Name OU można znaleźć w Active Directory Users and Computers w atrybutach OU.

Zbyt szeroka baza wyszukiwania często działa, ale czyni konfigurację mniej przejrzystą. Dla środowisk produkcyjnych lepiej stosować:

• dedykowaną OU albo jasną bazę wyszukiwania dla istotnych użytkowników
• osobne grupy AD dla VPN, portali lub reguł firewall
• brak przypadkowego ponownego użycia dużych grup działowych
• test importu grup po zmianach
• regularne usuwanie starych lub pustych grup

Zbyt szerokie importy grup mogą długoterminowo obciążać także wewnętrzne zarządzanie użytkownikami firewalla. Jeśli powstaje bardzo wielu starych użytkowników lub grup, a pobieranie z portalu VPN później nieoczekiwanie zawodzi, pomaga sprawdzenie limitu User ID na Sophos Firewall.

Ważne przy Remote Access: Sophos zmienił w SFOS 21.5 MR1, że L2TP i PPTP nie są już automatycznie aktywowane przy imporcie grup z Active Directory i Microsoft Entra ID. Zmniejsza to niezamierzoną powierzchnię ataku, ale po upgrade należy to sprawdzić, jeśli stare procesy Remote Access polegały na takim zachowaniu.

Import grup i rozumienie użytkowników

Po dodaniu serwera AD grupy AD nie są automatycznie w pełni dostępne na firewallu. Grupy importuje się przez asystenta importu:

Authentication > Servers > Import

Przebieg:

1. Wybrać serwer AD i uruchomić Import.
2. Wybrać Base DN dla wyszukiwania grup.
3. Wybrać wymagane grupy AD.
4. Sprawdzić wspólne Group Policies.
5. Skontrolować wybór i zakończyć import.
6. Pod Authentication > Groups sprawdzić, czy grupy są poprawnie dostępne.

Użytkownicy pojawiają się pod Authentication > Users dopiero wtedy, gdy zalogują się do usługi, na przykład User Portal, VPN Portal, Captive Portal lub przez Remote Access VPN. Przy każdym logowaniu firewall ponownie sprawdza, które importowane grupy pasują do użytkownika, i aktualizuje przypisanie.

Jeżeli użytkownik nie zostanie znaleziony w żadnej importowanej grupie AD, trafia do Default Group. Tę Default Group widać pod Authentication > Services przy Firewall Authentication Methods. Standardowo jest to często Open group.

W środowiskach HA grupy AD importuje się na urządzeniu Primary. Dotyczy to również czyszczenia starych użytkowników AD przez Purge AD users.

Main Group, kolejność grup i grupy zagnieżdżone

Użytkownik AD może należeć do wielu grup. Sophos Firewall rozróżnia przy tym:

To ważne, ponieważ nie wszystkie funkcje oceniają wiele grup. Niektóre funkcje używają tylko Main Group. Jeżeli użytkownik należy do kilku grup AD, może przez to zadziałać inna policy niż oczekiwano.

Kolejność grup zmienia się tutaj:

Authentication > Groups > Reorder

Zagnieżdżone grupy AD nie są obsługiwane. Jeśli Firewall Policy ma obowiązywać dla podgrupy, ta podgrupa musi być sama zaimportowana. Nie wystarczy importować tylko nadrzędnej grupy AD.

Podstawowa grupa AD użytkownika również nie jest przejmowana jak normalne członkostwo grupy. Dotyczy to szczególnie standardowej grupy AD Domain Users. Dla Firewall Policies należy dlatego używać jawnych grup bezpieczeństwa i dodawać użytkowników bezpośrednio do tych grup.

Które funkcje obsługują wiele grup

Dla eksploatacji ta tabela jest szczególnie ważna:

Przykład praktyczny: użytkownik należy do VPN-Users i Firewall-Admins. Dla SSL VPN wieloczłonkostwo może działać. Dla IPsec Remote Access albo przypisania grup MFA może jednak liczyć się tylko Main Group. Dlatego przy Remote Access i dostępach administracyjnych należy świadomie testować, która grupa jest ustawiona w obiekcie użytkownika jako Group.

Wiele serwerów Active Directory

Można skonfigurować wiele serwerów AD. Firewall waliduje wtedy użytkowników w kolejności skonfigurowanej w WebAdmin. Nie jest to zastępstwo dla dobrze zaplanowanego projektu AD.

Rekomendacje:

• Świadomie ustawić kolejność serwerów pod Authentication > Services.
• Dla każdego serwera jednoznacznie udokumentować bazę wyszukiwania i domenę.
• Nie używać sprzecznych grup o tej samej nazwie w różnych źródłach.
• Przy wielu UPN lub wielu domenach dokładnie zaplanować osobną konfigurację DNS i AD.
• Failover testować nie tylko przez Test connection, lecz prawdziwym loginem użytkownika.
• Przy awarii serwera AD komunikat dla użytkownika może wyglądać jak błędne hasło.

Jeżeli wiele UPN należy do tej samej infrastruktury domenowej, wpisy DNS i konfiguracja serwera AD muszą pasować do danej domeny. Ważne jest, aby baza wyszukiwania, Domain Name i rozwiązywanie serwera należały do siebie.

Test połączenia

Po zapisaniu należy bezpośrednio przetestować połączenie. Test sprawdza, czy firewall osiąga serwer i czy wprowadzone dane zasadniczo pasują.

Pomyślny test nie oznacza automatycznie, że reguły użytkowników, SSO lub VPN już działają. Następnie należy sprawdzić co najmniej:

1. Użytkownicy lub grupy AD są poprawnie znajdowani.
2. Użytkownik testowy może zalogować się w przewidzianym miejscu.
3. Członkostwo grup pasuje do wymaganych uprawnień firewall lub VPN.
4. Log Viewer pokazuje zrozumiałe zdarzenia uwierzytelniania.
5. Remote Access VPN, User Portal lub Captive Portal działają z normalnym użytkownikiem testowym.
6. MFA jest wymagane, jeśli jest zaplanowane dla danego zastosowania.
7. Serwer AD jest wpisany pod Authentication > Services w wymaganym miejscu Firewall Authentication Methods.

Dla Remote Access z Sophos Connect następnym pasującym krokiem jest Konfiguracja Sophos Connect Client na Sophos Firewall.

Walidacja według zastosowania

Po integracji AD nie należy dokumentować tylko pojedynczego testu połączenia. Różne funkcje używają integracji AD w różny sposób. Dlatego dla każdego planowanego zastosowania należy przeprowadzić osobny test.

Takie rozdzielenie oszczędza czas w eksploatacji. Pomyślny test LDAP dowodzi tylko, że serwer, port, konto bind i baza wyszukiwania są zasadniczo osiągalne. Nie dowodzi, że grupy VPN są poprawnie przypisane, że MFA działa albo że ruch użytkownika w regułach firewall jest oceniany z tożsamością.

Dla reguł opartych na użytkownikach należy zawsze wywołać prawdziwy test ruchu i sprawdzić w Log Viewer, czy nazwa użytkownika, grupa, Firewall Rule ID i akcja odpowiadają oczekiwaniom. Jeżeli widoczny jest tylko adres IP, przyczyna często leży w SSO, STAS, Captive Portal albo w kolejności reguł firewall. Dla środowisk STAS pasuje jako kolejny artykuł Konfiguracja STAS na Sophos Firewall.

Uwzględnienie Active Directory SSO

Active Directory SSO jest osobnym obszarem operacyjnym. Sama konfiguracja serwera AD jest podstawą, ale SSO wymaga dodatkowo pasujących warunków po stronie klienta, przeglądarki, DNS, Kerberos lub NTLM.

Dla Web Authentication Sophos Firewall obsługuje klasyczne AD SSO z Kerberos i NTLM. Kerberos jest czystszy i szybszy, ale ma większe wymagania wobec FQDN, DNS, SPN i zaufania przeglądarki. NTLM jest bardziej tolerancyjny i w starych środowiskach może być praktycznym fallbackiem, ale nie powinien po cichu stać się jedyną działającą metodą.

Przebieg AD SSO to więc więcej niż samo Test connection na serwerze AD:

1. Pod Administration > Admin and user settings ustawić hostname albo FQDN. Dla Kerberos powinien to być FQDN, zapisany małymi literami, z częścią hosta maksymalnie 15 znaków, aby NetBIOS name, obiekt komputera AD i SPN nie rozjechały się.
2. Pod Administration > Admin and user settings ustawić Redirection Location tak, aby klienci mogli rozwiązać nazwę i ufać celowi. W transparentnych scenariuszach Kerberos ta nazwa musi pasować do SPN. Na kliencie Windows setspn -Q HTTP/* pomaga sprawdzić istniejące HTTP SPN.
3. Zapisać serwer AD pod Authentication > Servers i uruchomić Test connection. Ten test sprawdza łączność i dane logowania, ale nie dowodzi jeszcze, że AD SSO działa.
4. Pod Authentication > Services ustawić serwer AD na właściwej pozycji w Firewall authentication methods. AD SSO używa serwerów w tej kolejności i przechodzi do następnego dopiero wtedy, gdy poprzedni jest nieosiągalny.
5. Pod Administration > Device access aktywować AD SSO dla wymaganych stref. Zwykle jest to LAN albo jasno zdefiniowana wewnętrzna sieć klientów, a nie wszystkie strefy.
6. Pod Authentication > Web authentication przy If Active Directory (AD) SSO is configured wybrać Kerberos & NTLM albo świadomie NTLM only.
7. W odpowiednich regułach firewall sprawdzić, czy Match known users oraz dla nieznanych żądań web Use web authentication for unknown users pasują do planowanego przebiegu. Oddzielna, jasno nazwana reguła dla HTTP i HTTPS często jest łatwiejsza w eksploatacji.

Jeżeli Use web authentication for unknown users ma uwierzytelniać ruch HTTPS w trybie transparentnym, firewall może odszyfrować połączenie na potrzeby procesu uwierzytelniania. Musi to pasować do projektu TLS Inspection i certyfikatów; w przeciwnym razie AD SSO szybko wygląda jak problem przeglądarki, certyfikatu albo webfiltera.

Do walidacji decydujący jest Log Viewer. Pod Log viewer > Authentication przy starcie połączenia AD SSO powinny pojawić się komunikaty takie jak Kerberos authentication initialized successfully i NTLM authentication channel established successfully. Problematyczne są komunikaty Cannot initialize Kerberos authentication albo Cannot establish NTLM authentication channel. Kolumna Log Comp pokazuje dodatkowo, czy klient używa Kerberos, czy NTLM.

Ważna jest kwestia konta. Do zwykłych zapytań LDAP często wystarcza Domain User z prawami odczytu. Przy AD SSO firewall musi jednak dołączyć do domeny i utworzyć obiekt komputera albo SPN. Potrzebne jest więc konto Domain Admin albo konto z poprawnie delegowanymi prawami domain join. W środowiskach HA, przy wielu serwerach AD albo po upgrade firewall może musieć ponownie dołączyć do domeny. Dlatego nie należy wykonać joinu jednorazowo kontem Domain Admin, a potem przełączyć się na słabsze konto, jeżeli to konto nie może później wykonać rejoin.

Od SFOS 21.5 MR1 Windows Server 2025 jest obsługiwany przy Active Directory SSO z NTLM i Kerberos. SFOS 22 przynosi również zaktualizowane komponenty Samba i usuwa starsze metody szyfrowania. Dla administratorów oznacza to:

• Po upgrade Domain Controller celowo testować AD SSO.
• Po upgrade SFOS sprawdzić uwierzytelnianie i przypisanie użytkowników.
• Dokumentować zależności Kerberos/NTLM w starych środowiskach.
• Nie planować przestarzałego szyfrowania jako trwałego rozwiązania.
• Sprawdzić DNS request routes dla domen AD, jeżeli firewall nie znajduje rekordów usług AD przez normalny resolver.
• Nie mylić SSO z Entra ID SSO dla Sophos Connect.

Jeżeli planowane jest Entra ID SSO dla VPN lub VPN Portal, należy użyć osobnego artykułu Konfiguracja Microsoft Entra ID SSO dla Sophos Connect i VPN Portal. To inny model uwierzytelniania niż klasyczna lokalna integracja AD.

Troubleshooting

Test połączenia zawodzi

Najpierw sprawdzić osiągalność, port, routing i DNS. Następnie skontrolować bezpieczeństwo połączenia, certyfikat, konto serwisowe i hasło.

Praktyczne kontrole:

• Czy firewall może osiągnąć Domain Controller po IP?
• Czy nazwa DNS jest poprawnie rozwiązywana?
• Czy port 389 lub 636 jest osiągalny?
• Czy SSL/TLS naprawdę pasuje do portu i certyfikatu?
• Czy konto serwisowe jest aktywne i niezablokowane?
• Czy po stronie Windows istnieją reguły firewall albo wymagania LDAP Signing?

Użytkownik nie jest znajdowany

Wtedy często błędna albo zbyt wąska jest baza wyszukiwania. Sprawdzić distinguishedName OU i upewnić się, że użytkownik naprawdę znajduje się wewnątrz bazy wyszukiwania. Również pisownia, umlauty, znaki specjalne i wybrany atrybut wyświetlania mogą utrudniać wyszukiwanie.

Grupa jest importowana, ale dostęp nie działa

Wtedy należy sprawdzić łańcuch uprawnień: grupa AD, importowana grupa firewall, przypisana reguła VPN/portal/firewall, MFA i pozycja reguły. Przy Remote Access dodatkowo właściwa konfiguracja VPN musi być powiązana z grupą.

Jeżeli użytkownik należy do wielu grup AD, dodatkowo sprawdzić Main Group pod Authentication > Users. Szczególnie MFA, Remote access IPsec VPN, WAF, Hotspots i wiele ustawień związanych z użytkownikiem uwzględniają tylko Main Group.

Nowa grupa AD nie pojawia się automatycznie

Nowo utworzone grupy AD nie są automatycznie synchronizowane do firewalla. Grupę trzeba ponownie zaimportować przez asystenta importu albo ręcznie utworzyć jako pasującą grupę. Następnie użytkownik testowy powinien zalogować się ponownie, aby firewall ponownie ocenił członkostwa grup.

Użytkownik został usunięty w AD, ale nadal jest widoczny na firewallu

Użytkownicy AD, którzy już się zalogowali, mogą pozostać widoczni na firewallu. Jeśli użytkownicy zostali usunięci w AD, należy najpierw usunąć ich w AD, a potem na firewallu użyć Purge AD users. W środowiskach HA robi się to na urządzeniu Primary.

Logowanie działa, ale reguła użytkownika nie trafia

Wtedy najczęściej problemem nie jest samo LDAP, lecz przypisanie użytkownika, SSO, pozycja reguły albo logging. W Log Viewer powinno być widoczne, czy ruch jest oceniany z tożsamością użytkownika, czy tylko z adresem IP. Do analizy reguł pasuje Testowanie reguły firewall za pomocą Log Viewer, Policy Test i Packet Capture.

AD SSO przechodzi na Captive Portal albo NTLM

Jeżeli AD SSO nie działa transparentnie, zwykle biorą w tym udział Redirection URL, SPN, rozwiązywanie DNS albo zaufanie przeglądarki. Dla Kerberos nazwa, na którą firewall przekierowuje, musi należeć do pasującego HTTP SPN i być rozwiązywalna przez klienta. Dla NTLM przeglądarka musi traktować nazwę docelową jako zaufaną, inaczej poprosi o dane logowania albo przejdzie do Captive Portal.

W praktyce najpierw sprawdza się Administration > Admin and user settings, rozwiązywanie DNS nazwy przekierowania, setspn -Q HTTP/* na kliencie Windows oraz Log viewer > Authentication. Jeżeli zamiast Kerberos pojawia się tylko NTLM, często wskazuje to na problem SPN albo zaufania przeglądarki, a niekoniecznie na uszkodzone połączenie z serwerem AD.

Po upgrade pojedyncze loginy już nie działają

Po upgrade SFOS lub Domain Controller należy szczególnie zwrócić uwagę na SSO, Kerberos/NTLM, stare metody szyfrowania, certyfikaty i import grup. Jeżeli dotknięci są tylko określeni użytkownicy, dodatkowo sprawdzić znaki specjalne, spacje, UPN, członkostwa grup i status hasła.

Przy logach uwierzytelniania i usług pomaga Sophos Firewall Troubleshooting: Services i Logs.

Połączenie nie działa przy aktywnej weryfikacji certyfikatu

Jeżeli Validate server certificate jest aktywne, certyfikat, CNAME, rozwiązywanie DNS i zaufanie CA muszą do siebie pasować. Częste przyczyny to certyfikat z inną nazwą, brak wewnętrznej CA na firewallu albo CNAME, którego firewall nie może rozwiązać.

Lista kontrolna operacyjna

Przed konfiguracją:

• Domain Controller, port i nazwa DNS są ustalone.
• LDAPS i łańcuch certyfikatów są sprawdzone.
• Dedykowane konto serwisowe jest utworzone.
• Baza wyszukiwania i istotne grupy są zdefiniowane.
• Projekt MFA i Remote Access jest wyjaśniony.

Po konfiguracji:

• Test połączenia zakończony pomyślnie.
• Serwer AD wpisany jako primary albo pasująca Authentication Method.
• Użytkownik testowy i grupa testowa sprawdzeni.
• Grupy AD zaimportowane przez asystenta importu.
• Main Group użytkownika testowego skontrolowana.
• Remote Access, portal albo reguła użytkownika przetestowane normalnym użytkownikiem.
• Log Viewer pokazuje oczekiwane zdarzenia uwierzytelniania.
• Przy AD SSO sprawdzone są komunikaty Kerberos/NTLM w Authentication log.
• Wygaśnięcie hasła konta serwisowego udokumentowane.
• Test upgrade dla AD SSO, importu grup i procesów VPN zaplanowany.

W eksploatacji:

• Usuwać niepotrzebne grupy.
• Nowe grupy AD aktywnie importować, nie czekać na automatyczną synchronizację.
• Regularnie sprawdzać konto serwisowe.
• Odnawiać certyfikaty LDAPS przed wygaśnięciem.
• Kontrolować kolejność grup po zmianach AD.
• Używać Named Admins i MFA dla dostępów administracyjnych.
• Błędów uwierzytelniania nie traktować tylko jako problemu użytkownika, lecz sprawdzać również AD, sieć, certyfikaty i reguły firewall.

FAQ