Sophos Firewall: migracja eDirectory przed SFOS 23

SFOS 23.0 nie obsługuje już natywnego serwera uwierzytelniania eDirectory. Jeśli na firewallu pozostanie natywna konfiguracja serwera eDirectory, aktualizacja firmware’u do SFOS 23.0 lub nowszej wersji zakończy się niepowodzeniem. Przed aktualizacją musi zatem działać obsługiwany serwer uwierzytelniania, a konfiguracja natywnego serwera eDirectory i mechanizmu SSO eDirectory musi zostać całkowicie usunięta.

W SFOS 22.0 MR2 eDirectory nadal działa. Ten czas należy wykorzystać na kontrolowaną pracę równoległą: dodać nowe źródło, zweryfikować użytkowników i grupy przy użyciu rzeczywistych kont, etapami przełączyć usługi uwierzytelniania i usunąć eDirectory dopiero wtedy, gdy możliwość wycofania zmian nie będzie już potrzebna. Powiązane usługi Entra ID SSO należy przy tym traktować łącznie. Przegląd MR2 omawia pozostałe zmiany w tej wersji.

Skrócona procedura

Zinwentaryzować wszystkie zależności od eDirectory w serwerach, grupach, usługach, regułach, VPN i SSO.
Przygotować aktualny backup, lokalnego administratora i udokumentowany dostęp do konsoli.
W zależności od zastosowania wybrać jako system docelowy generyczny LDAP, Active Directory, RADIUS lub Microsoft Entra ID SSO.
Równolegle dodać nowy serwer uwierzytelniania i sprawdzić połączenie, użytkowników oraz grupy.
Świadomie odwzorować grupy i polityki na nowe źródło.
W Authentication > Services etapami przełączać usługi i testować je przy użyciu rzeczywistych kont; powiązane usługi Entra ID SSO traktować łącznie.
Dopiero po pełnej weryfikacji usunąć wszystkie natywne konfiguracje serwera eDirectory i SSO, ponownie wykonać backup i rozpocząć aktualizację do SFOS 23.

Celowo nie jest to migracja wykonywana jednym przełącznikiem. Firewall korzysta z serwerów uwierzytelniania osobno dla każdej usługi i w ustalonej kolejności. Ponadto uprawnienia często zależą od grup, które po migracji mogą mieć te same nazwy, ale niekoniecznie takie samo przypisanie i działanie.

Co jest obecnie zależne od eDirectory

Przed pierwszą zmianą trzeba dokładnie ustalić, gdzie eDirectory jest faktycznie używane. Inwentaryzacja powinna obejmować co najmniej następujące obszary:

W Authentication > Servers znajdują się serwery eDirectory oraz ewentualnie kilka docelowych katalogów.
W Authentication > Services dla każdej usługi określono, które serwery są odpytywane i w jakiej kolejności.
W Authentication > Groups polityki grupowe, Default Group i kolejność grup mogą określać efektywne uprawnienia użytkownika. W przypadku Active Directory dochodzą Main Group i pozostałe członkostwa.
Reguły firewalla, polityki Web i Application oraz Traffic Shaping mogą odwoływać się do użytkowników lub grup.
VPN Portal, SSL VPN, Remote Access IPsec, User Portal i Captive Portal mają własne ścieżki logowania i nadawania uprawnień.
MFA i logowanie administracyjne mogą zależeć od grup oraz kolejności uwierzytelniania.
Raporty oparte na użytkownikach i przezroczyste rozpoznawanie użytkowników nadal wymagają niezawodnego powiązania użytkownika z połączeniem.

Zrzut ekranu przedstawiający obecną kolejność serwerów, usług i grup jest często bardziej użyteczny niż sama lista nazw. Dla każdej ważnej grupy warto dodatkowo zanotować co najmniej jednego użytkownika testowego, który powinien uzyskać dostęp, oraz jednego, który powinien zostać odrzucony. Pozwala to później sprawdzić nie tylko, kto uzyskuje dostęp, lecz także kto jest prawidłowo odrzucany.

Wybór odpowiedniej metody docelowej

Nie istnieje uniwersalny zamiennik 1:1 dla każdego środowiska eDirectory. Firma może nadal korzystać z istniejącego katalogu przez LDAP, przenieść tożsamości do innego katalogu albo łączyć kilka metod uwierzytelniania zależnie od usługi.

Dalsze używanie eDirectory przez generyczny LDAP

Jeśli samo eDirectory pozostaje w użyciu, Sophos Firewall może odpytywać je podczas logowania użytkowników za pomocą obsługiwanego typu serwera LDAP server. Ta metoda nie zmienia automatycznie drzewa katalogu, ale wymaga nowej konfiguracji LDAP z odpowiednią Base DN oraz właściwymi atrybutami logowania i grup.

Należy pamiętać o ograniczeniu: natywny mechanizm SSO eDirectory nie jest dostępny od SFOS 23. Generyczny serwer LDAP weryfikuje logowanie, ale nie zapewnia przezroczystego rozpoznawania użytkowników. Użytkownicy, którzy wcześniej byli rozpoznawani automatycznie, potrzebują więc nowej ścieżki SSO lub logowania. Pełny opis pól zawiera artykuł Podłączenie generycznego serwera LDAP do Sophos Firewall.

Active Directory

Active Directory jest odpowiednie, gdy użytkownicy znajdują się już w domenie Windows lub są do niej świadomie migrowani. Trzeba wtedy zaimportować grupy, ponownie sprawdzić Main Group i polityki oraz osobno skonfigurować wymagane przezroczyste rozpoznawanie użytkowników. Artykuł Podłączenie Active Directory do Sophos Firewall opisuje LDAPS, import grup i testy usług.

STAS przekazuje firewallowi informacje o logowaniach do domeny Windows w sposób przezroczysty, ale nie konwertuje dotychczasowej konfiguracji SSO eDirectory. Jeśli ta ścieżka tożsamości jest potrzebna, należy zaplanować ją jako osobną migrację zgodnie z artykułem STAS dla Sophos Firewall.

RADIUS

RADIUS jest odpowiedni, gdy działa już centralna usługa uwierzytelniania lub brama MFA. Serwer RADIUS musi dostarczać firewallowi informacje potrzebne dla danej usługi; model grup katalogowych nie jest przenoszony automatycznie. Metoda MFA musi być zgodna z usługą: na przykład VPN Portal nie obsługuje RADIUS MFA opartego na mechanizmie challenge. Shared Secret, atrybut grupy, limity czasu i pozostałe ograniczenia opisano w artykule Konfiguracja serwera RADIUS w Sophos Firewall.

Microsoft Entra ID SSO

Microsoft Entra ID SSO może być przydatne w udokumentowanych scenariuszach dotyczących portali, administratorów i Remote Access. Nie jest jednak uniwersalnym zamiennikiem każdego odpytania przy użyciu nazwy użytkownika i hasła ani mechanizmem przezroczystego rozpoznawania użytkowników LAN. W przypadku Remote Access powiązane usługi trzeba koordynować: VPN Portal i SSL VPN używają tego samego serwera Entra; przy pliku aprowizacyjnym dotyczy to również IPsec. Redirect URI, grupy, Conditional Access i obsługiwane usługi opisano w artykule Microsoft Entra ID SSO dla Sophos Connect i VPN Portal.

Architektura docelowa może być mieszana. Przykładowo LDAP może początkowo uwierzytelniać użytkowników z istniejącego eDirectory, a Remote Access może zostać później celowo przeniesiony do RADIUS lub Entra ID SSO. Kluczowe jest, aby każda używana usługa miała przetestowaną ścieżkę docelową, zanim eDirectory zostanie usunięte.

Zabezpieczenie środowiska przed pierwszą zmianą

Przed przełączeniem powinny być dostępne następujące elementy:

Aktualny, zaszyfrowany backup Sophos Firewall.
Lokalny administrator, którego logowanie nie zależy od eDirectory ani od nowego źródła zewnętrznego. W Authentication > Services opcja Local musi nadal być zaznaczona w Administrator authentication methods.
Udokumentowany dostęp do konsoli lub inny dostęp awaryjny do firewalla.
Zrzuty ekranu albo pisemna inwentaryzacja kolejności serwerów, usług i grup.
Co najmniej jedno konto testowe dla każdej ważnej grupy oraz konto, które nie powinno uzyskać dostępu.
Okno serwisowe, osoba odpowiedzialna za decyzję i jednoznaczne kryterium wycofania zmian.

Dostęp WebAdmin należy przełączyć na końcu. Wcześniej trzeba sprawdzić, czy opcja Local nadal jest zaznaczona i czy lokalne logowanie działa w prywatnym oknie przeglądarki. Pozostaje dzięki temu niezależna ścieżka dostępu na wypadek, gdyby nowe zewnętrzne uwierzytelnianie lub rozpoznawanie grup nie działało zgodnie z oczekiwaniami.

Równoległa konfiguracja serwera docelowego

Nowy serwer należy najpierw dodać jako dodatkowy. Podczas początkowej konfiguracji serwera dotychczasowy wybór eDirectory pozostaje bez zmian; dopiero na potrzeby testu pilotażowego zmienia się jedną, łatwą do kontrolowania metodę uwierzytelniania.

Przykład: podłączenie eDirectory jako generycznego serwera LDAP

W Authentication > Servers > Add przykładowa konfiguracja pilotażowa może wyglądać następująco:

Server type: LDAP server
Server name: EDIR-LDAP-PILOT
Server IP/domain: edir01.example.net
Version: 3
Connection security: SSL/TLS
Port: 636
Bind DN: cn=sfos-bind,ou=service,o=Example
Base DN: ou=users,o=Example
Authentication attribute: na przykład uid, po sprawdzeniu obiektu użytkownika
Group name attribute: na przykład groupMembership, po sprawdzeniu obiektu użytkownika
Validate server certificate: włączone po skonfigurowaniu zaufania firewalla do wystawiającego urzędu certyfikacji

edir01.example.net, Bind DN i Base DN są wartościami przykładowymi i trzeba je dostosować do własnego drzewa katalogu. Przy aktywnej weryfikacji certyfikatu skonfigurowana nazwa FQDN musi odpowiadać certyfikatowi serwera i być rozwiązywalna przez firewall. Konto bind potrzebuje wyłącznie uprawnień odczytu do wymaganego obszaru katalogu.

Właściwe atrybuty logowania i grup zależą od rzeczywistego obiektu użytkownika. W środowisku eDirectory na przykład cn lub uid mogą mieć znaczenie przy logowaniu, a groupMembership w przypadku grup. Są to wartości wymagające weryfikacji, a nie ustawienia uniwersalne.

Obiekt użytkownika można sprawdzić w trybie tylko do odczytu z systemu administracyjnego Linux:

LDAPTLS_CACERT='/secure/path/edir-ca.pem' \
ldapsearch -LLL -x \
  -H 'ldaps://edir01.example.net:636' \
  -D 'cn=sfos-bind,ou=service,o=Example' -W \
  -b 'ou=users,o=Example' -s sub \
  '(|(cn=max.muster)(uid=max.muster))' \
  dn objectClass cn uid mail groupMembership

Tego polecenia nie należy wykonywać w Advanced Shell na Sophos Firewall. Opcja -W interaktywnie pyta o hasło konta bind, dzięki czemu nie jest ono zapisywane w historii powłoki. Ścieżkę w LDAPTLS_CACERT, nazwę FQDN, DN-y, filtr i żądane atrybuty trzeba dostosować do własnego środowiska. Jeśli lokalny klient OpenLDAP ufa już urzędowi certyfikacji za pośrednictwem swojego magazynu zaufania lub pliku ldap.conf, można pominąć LDAPTLS_CACERT. W przeciwnym razie zmienna musi wskazywać czytelny pakiet certyfikatów CA w formacie PEM.

Przykładowy wynik może wyglądać następująco:

dn: cn=Max Muster,ou=users,o=Example
cn: Max Muster
uid: max.muster
mail: max.muster@example.net
groupMembership: cn=VPN-Mitarbeitende,ou=groups,o=Example

Jest to przykład odczytu, a nie gwarantowany schemat eDirectory. Jeśli brakuje groupMembership albo katalog zwraca inne wartości, trzeba ustalić rzeczywisty atrybut i odpowiednio dostosować konfigurację firewalla. Następnie należy osobno sprawdzić Test connection, rzeczywiste logowanie użytkownika i wynikową grupę.

Ponowne odwzorowanie grup i polityk

Udane logowanie nie wystarczy, jeśli użytkownik trafi później do niewłaściwej grupy. Załóżmy, że dotychczasowa grupa VPN-Mitarbeitende może korzystać z SSL VPN i uzyskuje dostęp do aplikacji wewnętrznych przez regułę opartą na użytkownikach. Po migracji trzeba odpowiedzieć co najmniej na następujące pytania:

Czy użytkownik testowy jest widoczny w Authentication > Users z oczekiwaną efektywną grupą? W Active Directory Main Group i pozostałe członkostwa sprawdza się osobno.
Czy nowa grupa znajduje się w Authentication > Groups i ma właściwą pozycję?
Czy konfiguracja SSL VPN lub IPsec odwołuje się do nowej efektywnej grupy?
Czy użytkownik nadal pasuje do przewidzianej reguły firewalla, a nie do bardziej ogólnej reguły?
Czy nadal obowiązuje wymagana polityka MFA?

Takie same widoczne nazwy grup z dwóch źródeł nie gwarantują ani tego samego członkostwa, ani takiego samego efektywnego priorytetu grupy. W Active Directory kolejność grup i Main Group mogą wpływać na VPN, MFA oraz inne polityki. Podstawy opisano w artykule Aktywacja MFA w Sophos Firewall.

Przełączanie po jednej usłudze

W Authentication > Services serwery uwierzytelniania wybiera się osobno dla każdej usługi. Dlatego nie należy przełączać wszystkiego jednocześnie. Powiązane usługi Entra ID SSO planuje się jednak i zatwierdza jako wspólną ścieżkę.

Najpierw wybrać łatwą do kontrolowania usługę i użytkownika pilotażowego.
Wybrać nowy serwer dla tej usługi i świadomie określić jego pozycję w kolejności serwerów.
Zastosować zmianę oraz przetestować jedno prawidłowe i jedno celowo nieprawidłowe logowanie.
Sprawdzić użytkownika, grupę, wpis w logu i faktycznie zastosowaną politykę.
Dopiero wtedy przełączyć kolejną usługę.

Należy zacząć od świadomie wybranej, łatwej do kontrolowania usługi pilotażowej. Następnie przełącza się faktycznie używane obszary, takie jak Firewall authentication methods, User portal authentication methods, VPN portal authentication methods, SSL VPN authentication methods i Remote Access IPsec. W przypadku Entra ID SSO opisane powyżej powiązane usługi Remote Access przełącza się w sposób skoordynowany. Ze względu na ryzyko blokady Administrator authentication methods przełącza się na końcu. Przegląd portali Sophos Firewall wyjaśnia, które portale działają niezależnie i muszą być osiągalne.

Jeśli ta sama nazwa użytkownika istnieje na starym i nowym serwerze, kolejność serwerów może ukrywać błędne mapowanie grup. Na potrzeby kontrolowanego testu można tymczasowo wybrać tylko nowy serwer w wybranej usłudze pilotażowej. Rzeczywiste logowanie i Authentication > Users pokażą wtedy, czy nowe źródło dostarcza użytkownika z oczekiwaną grupą.

Weryfikacja przy użyciu rzeczywistych połączeń

Test connection potwierdza osiągalność serwera i poprawność danych logowania. Weryfikacja kończy się jednak dopiero wtedy, gdy działa rzeczywista usługa i powiązane z nią uprawnienie.

Dla każdej istotnej grupy weryfikacja powinna potwierdzić co najmniej następujące elementy:

Uprawniony użytkownik może zalogować się do przewidzianego portalu lub usługi VPN.
Nieuprawniony użytkownik zostaje odrzucony albo otrzymuje wyłącznie przewidzianą ograniczoną politykę.
W Authentication > Users użytkownik i grupa są prawidłowe.
Log Viewer pokazuje zrozumiałe zdarzenie uwierzytelniania.
Polityki firewalla, Web i VPN odpowiadają oczekiwanej regule.
Cele wewnętrzne są osiągalne przez przewidzianą ścieżkę ruchu.
MFA i role administracyjne działają zgodnie z planem.

Za pomocą Firewall Rule Testing i Log Viewer można sprawdzić, który Rule ID ma zastosowanie do użytkownika i jego ruchu. Przezroczyste rozpoznawanie użytkowników lub SSO testuje się osobno; udane logowanie LDAP nie potwierdza działania tej ścieżki.

Wycofanie zmian podczas fazy pilotażowej

Dopóki firewall działa w wersji SFOS 22.0 MR2, a eDirectory nie zostało usunięte, stara konfiguracja pozostaje dostępna jako kontrolowana możliwość wycofania zmian. Jeśli test pilotażowy się nie powiedzie, trzeba przywrócić wszystkie wartości zmienione na jego potrzeby: wybór i kolejność serwerów w Authentication > Services, Default Group i kolejność grup, a także objętych zmianą członków VPN oraz odwołania MFA i polityk. Następnie należy ponownie sprawdzić logowanie, grupę i politykę.

Backup chroni konfigurację firewalla, ale nie jest automatyczną migracją tożsamości. Backup i import konfiguracji nie konwertują ani nie migrują zawartej w nich konfiguracji eDirectory. Po aktualizacji taki backup nie stanowi więc działającej możliwości powrotu do eDirectory.

Usunięcie eDirectory i dopuszczenie aktualizacji do SFOS 23

eDirectory należy usunąć dopiero po upływie zdefiniowanego wcześniej okresu obserwacji. W tym czasie każda ścieżka logowania używana produkcyjnie, każda ważna grupa, używane połączenia VPN i procedury administracyjne muszą co najmniej raz zadziałać bezbłędnie z nowym źródłem w realistycznych warunkach; niewyjaśnione błędy uwierzytelniania, grup lub polityk uniemożliwiają zatwierdzenie usunięcia.

Na zakończenie:

Sprawdzić, czy eDirectory nie jest już wybrane w żadnej metodzie uwierzytelniania.
Ponownie porównać zależności grup, VPN, polityk, MFA, administratorów i SSO z inwentaryzacją.
Usunąć z firewalla wszystkie konfiguracje natywnego serwera eDirectory i mechanizmu SSO eDirectory. Nowo utworzony generyczny LDAP server, który odpytuje ten sam katalog, pozostaje skonfigurowany.
W Authentication > Servers, Authentication > Services i inwentaryzacji sprawdzić, czy nie pozostała żadna natywna konfiguracja eDirectory ani zależność od niej.
Utworzyć nowy zaszyfrowany backup oczyszczonej konfiguracji.
Sprawdzić ogólny przewodnik Aktualizacja firmware’u Sophos Firewall: przygotowanie i najlepsze praktyki oraz aktualne informacje dotyczące wydań, aktualizacji i Known Issues dla SFOS 23. Dopiero wtedy rozpocząć aktualizację.

Błąd aktualizacji występujący przy natywnej konfiguracji serwera eDirectory oraz konieczność jej usunięcia przed SFOS 23 zostały potwierdzone przez Sophos. Przed aktualizacją produkcyjną należy dodatkowo sprawdzić ostateczne informacje dotyczące wydań, aktualizacji i Known Issues dla SFOS 23 pod kątem dalszych szczegółów.

Typowe problemy

Test connection kończy się powodzeniem, ale użytkownik trafia do niewłaściwej grupy: sprawdzić Base DN, atrybut logowania i grupy w rzeczywistym obiekcie użytkownika oraz kolejność grup.
Test pilotażowy wydaje się działać, ale może nadal korzystać z eDirectory: w kontrolowanej usłudze pilotażowej tymczasowo wybrać tylko nowy serwer, a następnie sprawdzić użytkownika, grupę i politykę.
User Portal działa, ale VPN nie: osobno sprawdzić metodę uwierzytelniania i grupę uprawnień dla każdego portalu i każdej usługi VPN.
Logowanie LDAP działa, ale przezroczyste rozpoznawanie nie: natywny mechanizm SSO eDirectory nie jest dostępny od SFOS 23. Generyczny LDAP weryfikuje logowanie, ale nie zapewnia przezroczystego rozpoznawania użytkowników.
Po migracji grup ma zastosowanie inna reguła firewalla: porównać efektywną grupę, kolejność grup i bezpośrednie odwołania do użytkowników lub grup w politykach. W Active Directory sprawdzić również Main Group i pozostałe członkostwa.
Backup jest planowany jako późniejsza możliwość powrotu do eDirectory: w SFOS 23 zawarta w nim konfiguracja eDirectory nie zostanie zmigrowana; możliwość wycofania zmian musi działać przed aktualizacją.