Przejdz do tresci
Avanet

Połącz generyczny serwer LDAP z Sophos Firewall

Sophos Firewall

Sophos Firewall może uwierzytelniać użytkowników za pomocą serwera typu LDAP server na podstawie atrybutów katalogowych i członkostwa w grupach. W praktyce potrzebne są cztery kroki: przygotowanie grupy lokalnej, podłączenie serwera LDAP, wybranie go w Authentication > Services dla odpowiedniej usługi oraz sprawdzenie logowania i autoryzacji na rzeczywistych kontach testowych.

OpenLDAP, 389 Directory Server lub FreeIPA to typowe rozwiązania do integracji przez generyczny interfejs LDAP, ale nie są to produkty zamienne. Atrybuty, zwracane informacje o grupach i sposób obsługi wygasania kont różnią się w zależności od schematu. Dlatego niniejszy przewodnik przedstawia przykład, który można dostosować do własnego środowiska; wartości należy sprawdzić na rzeczywistym obiekcie użytkownika. Google Secure LDAP opisano poniżej jako odrębny wariant, udokumentowany przez firmę Sophos.

W przypadku Windows Active Directory z LDAPS, importem grup lub logowaniem jednokrotnym AD, lepiej sprawdzi się artykuł Połącz Active Directory z Sophos Firewall. RADIUS za pośrednictwem Microsoft NPS lub bramy MFA opisano w artykule Skonfiguruj serwer RADIUS w Sophos Firewall. Jeśli chcesz zastąpić natywny typ serwera eDirectory przed wersją SFOS 23, kompletny proces migracji znajdziesz w artykule Migracja eDirectory przed wersją SFOS 23.

Przygotuj wartości i procedurę wycofania zmian

Wymagane:

  • dostęp do interfejsu WebAdmin zapory Sophos Firewall;
  • dostępność serwera LDAP z zapory przez port skonfigurowany na serwerze;
  • konto do operacji bind z uprawnieniami do odczytu wymaganego obszaru katalogu;
  • Bind DN i Base DN, na przykład cn=svc-sophos,ou=service,dc=example,dc=net i ou=people,dc=example,dc=net;
  • atrybuty nazwy logowania, nazwy wyświetlanej, adresu e-mail, grupy i ewentualnie daty wygaśnięcia konta;
  • przy weryfikacji certyfikatu: nazwa serwera, którą można rozwiązać przez DNS, i odpowiedni łańcuch zaufania CA.

Typowe wartości początkowe to port 389 dla STARTTLS i 636 dla SSL/TLS. Nie są to sztywne ustawienia domyślne SFOS: katalog może używać innego portu, który musi być zgodny z Connection security i konfiguracją serwera.

⚠️ Konto do operacji bind nie wymaga administracyjnych uprawnień do zapisu. Ogranicz jego uprawnienia do odczytu do poddrzewa i atrybutów, których zapora potrzebuje do obsługi zapytań o użytkowników.

Przed zmianą ustawień w Authentication > Services udokumentuj wybrane serwery, ich kolejność i opcje dziedziczenia dla każdej metody, której dotyczy zmiana. W sekcji Firewall authentication methods zapisz dodatkowo dotychczasową wartość Default group. Dzięki temu można cofnąć zmianę bez pochopnego usuwania nowych obiektów. Podczas wprowadzania zmian zachowaj dostęp przez wcześniej przetestowane lokalne konto administratora, umożliwiające przywrócenie konfiguracji.

Rozróżnij Bind DN, Base DN i atrybuty

DN prowadzi od konkretnego obiektu do korzenia katalogu. cn=svc-sophos,ou=service,dc=example,dc=net oznacza w przykładzie konto do operacji bind. Z kolei Base DN określa punkt początkowy wyszukiwania użytkowników, np. ou=people,dc=example,dc=net.

Zbyt wąska baza wyszukiwania Base DN nie pozwoli znaleźć wszystkich potrzebnych użytkowników. Niepotrzebnie szeroka baza wyszukiwania może spowolnić wyszukiwanie i objąć niepożądane obiekty. Append base DN dołącza Base DN do niepełnej nazwy Bind DN podczas operacji bind; jeśli DN jest już kompletny, opcję zwykle pozostawia się wyłączoną. Decydujące jest zachowanie używanego serwera LDAP.

Atrybuty również pochodzą ze schematu katalogu. uid, cn, mail i memberOf to przykłady, a nie uniwersalne wymagania. Sophos zaleca memberOf jako Group name attribute, ale używa GID we własnym ogólnym przykładzie konfiguracji. Dlatego wartość zwracaną, przypisanie do grup lokalnych i członkostwo w wielu grupach należy sprawdzić z użyciem rzeczywistych użytkowników testowych.

Wybierz szyfrowanie i certyfikaty

Plaintext wysyła poświadczenia użytkownika w formie niezaszyfrowanej i nie jest to dobra konfiguracja produkcyjna. SSL/TLS szyfruje połączenie od początku; STARTTLS przełącza początkowo nieszyfrowane połączenie LDAP na TLS.

Przy włączonej opcji Validate server certificate w polu Server IP/domain musi znajdować się nazwa wskazana w certyfikacie serwera, którą zapora może rozwiązać przez DNS. Sophos określa ją jako CNAME w pomocy SFOS 22, podczas gdy opis tego samego pola w innym miejscu wspomina jedynie o adresie IP serwera. Nazwa z certyfikatu jest zatem bezpiecznym wyborem w przypadku kontrolowanego wdrożenia TLS. Jeżeli zapora nie może rozwiązać tej nazwy, można utworzyć wpis w Network > DNS > DNS host entry. TTL, wyszukiwanie wsteczne i test resolvera opisano w artykule Skonfiguruj wpisy hosta DNS w Sophos Firewall.

Validate server certificate sprawdza certyfikat zdalnego serwera LDAP. Opcjonalny Client certificate określa certyfikat, którego zapora używa do ustanowienia bezpiecznego połączenia z usługą LDAP; Google Secure LDAP wyraźnie wymaga certyfikatu wygenerowanego przez Google. W przypadku błędów TLS napraw najpierw nazwę, DNS, czas, ważność i łańcuch zaufania, zamiast w pierwszym kroku wyłączać sprawdzanie certyfikatu serwera.

Skonfiguruj grupę i serwer LDAP

Przygotuj grupę lokalną

  1. Otwórz Authentication > Groups i wybierz Add.
  2. Wprowadź unikalny Group name, na przykład LDAP-Benutzer.
  3. Wybierz Group type odpowiedni dla planowanej metody logowania. Normal wymaga zalogowania użytkownika; Clientless kontroluje dostęp na podstawie adresu IP.
  4. Ustaw wymagane zasady dotyczące użytkowników, dostępu zdalnego i logowania, a następnie zapisz za pomocą Save.

W polach Surfing quota i Access time świadomie wybierz wymagane limity. Sophos używa w przykładzie szkoleniowym Unlimited internet access i Allowed all the time; są to przykładowe zasady, a nie warunek korzystania z LDAP. W przypadku ograniczonego dostępu pilotażowego lepiej ustawić rzeczywiście wymagany czas korzystania i dozwolony przedział czasowy. W pozostałych polach pozostaw ustawienia domyślne tylko wtedy, gdy odpowiadają one Twojej polityce dostępu.

Grupa będzie później używana jako Default group. Sama nie zezwala na ruch ani go nie blokuje; decydują o tym jej zasady oraz reguły danej usługi. W przypadku zasad użytkowników i sieci VPN dostępu zdalnego innych niż SSL VPN ustawienia specyficzne dla użytkownika mają pierwszeństwo przed zasadami grup. Ta reguła pierwszeństwa nie dotyczy dostępu zdalnego przez SSL VPN: użytkownik może uzyskiwać dostęp do zasobów objętych wszystkimi zasadami pełnego i dzielonego tunelowania, które dotyczą jego lub jego grup. Bardziej restrykcyjna zasada użytkownika nie znosi więc automatycznie szerszych uprawnień grupowych SSL VPN. Nie oznacza to ogólnej gwarancji, że każdy schemat LDAP odwzorowuje członkostwo w wielu grupach w taki sam sposób; przypisanie do grup i faktycznie dostępne zasoby należy sprawdzić podczas wdrożenia pilotażowego. Pełną logikę grup, obejmującą wdrożenie pilotażowe, wyjątki dla poszczególnych użytkowników i grupę główną, opisano w artykule Bezpieczne zarządzanie grupami użytkowników Sophos Firewall.

Skonfiguruj połączenie i operację bind

  1. Otwórz Authentication > Servers i wybierz Add.
  2. W polu Server type wybierz LDAP server.
  3. Nadaj unikalny Server name, na przykład LDAP-Firma.
  4. Wpisz adres IP serwera lub nazwę domeny w polu Server IP/domain. Przy włączonej opcji Validate server certificate użyj nazwy z certyfikatu serwera, którą można rozwiązać przez DNS.
  5. W polu Version wybierz obsługiwaną przez serwer wersję 2 lub 3. Google Secure LDAP wymaga wersji 3.
  6. Ustaw razem Connection security i Port. W środowisku produkcyjnym użyj SSL/TLS lub STARTTLS.
  7. Wyłącz Anonymous login i wprowadź Bind DN oraz Password konta z uprawnieniami do odczytu.
  8. Włącz Append base DN tylko wtedy, gdy zapora ma dołączać Base DN do niepełnej nazwy Bind DN podczas operacji bind.
  9. Przy szyfrowanym połączeniu świadomie zdecyduj, czy opcja Validate server certificate ma być włączona. W przypadku zwykłych serwerów LDAP bezpiecznym wyborem produkcyjnym jest weryfikacja certyfikatu po prawidłowym skonfigurowaniu nazwy, DNS i zaufania. Google Secure LDAP stanowi szczególny przypadek opisany poniżej. Wybierz wymagany Client certificate z listy.

Ustaw bazę wyszukiwania i atrybuty

  1. Wpisz punkt początkowy wyszukiwania użytkowników w polu Base DN. Get base DN może pobrać bazę wyszukiwania oferowaną przez serwer.
  2. W polu Authentication attribute ustaw atrybut zawierający nazwę logowania, często uid lub mail.
  3. Wypełnij pola Display name attribute i Email address attribute zgodnie z obiektem użytkownika, na przykład wartościami cn i mail.
  4. Wpisz atrybut grupy zwracany dla obiektu użytkownika w polu Group name attribute. Sophos zaleca memberOf, ale atrybut ten musi odpowiadać schematowi i formatowi zwracanych danych.
  5. Wprowadź Expiry date attribute pasujący do schematu. Jeśli takiego atrybutu nie ma, przed wdrożeniem sprawdź, czy formularz przyjmuje wartość pustą i jak obsługiwane są konta bez daty wygaśnięcia.
  6. Uruchom Test connection i zapisz za pomocą Save.

Display name attribute i Email address attribute są opcjonalnymi polami w przypadku generycznego serwera LDAP. Nazwa wyświetlana ułatwia rozpoznanie lokalnego obiektu użytkownika; atrybut adresu e-mail dostarcza powiązany adres. Natomiast do tworzenia grup Google LDAP atrybut adresu e-mail jest wymagany. Expiry date attribute określa wygaśnięcie konta, a nie czas trwania sesji VPN. Sophos podaje w ogólnym przykładzie szkoleniowym Date, a w przypadku Google expiry; właściwa nazwa atrybutu zależy od danego schematu.

Według Sophos Test connection sprawdza połączenie i poświadczenia operacji bind. Test nie dowodzi, że Base DN obejmuje wszystkich użytkowników ani że przypisanie do grupy lub uprawnienia do usługi działają prawidłowo. Wymagane jest do tego rzeczywiste logowanie.

Tylko dla automatyzacji przez API przy przejściu z SFOS 22 na SFOS 23: W dokumentacji API LDAP zmieniają się udokumentowane wiersze w sekcji Status Message Information: dla Add LDAP server z 200/500/502/503 na 200/400/401/403/409/500, a dla Edit LDAP server z 200/500/503 na 200/400/401/403/404/500. 409 występuje tylko dla Add, a 404 tylko dla Edit. Symbole prezentacji również zmieniają się z Message.LDAP* na Message.CP*. Te wiersze i symbole dokumentacji nie gwarantują faktycznie przesyłanych kodów ani komunikatów i nie ustanawiają stałego mapowania z 502/503 na 409/404. Przy automatyzacji przez API należy sprawdzić dokumentację używanej wersji i zweryfikować rzeczywiste odpowiedzi docelowej zapory przed przyjęciem mapowania. Jest to osobna kontrola API; nadal wymagane są kontrola Test connection w GUI i rzeczywiste logowanie.

Przed każdym zautomatyzowanym dodaniem lub edycją serwera LDAP: Dokumentacja API dla SFOS 22 i 23 zawiera sprzeczne informacje dotyczące IntegrationType: przykład podaje LooseIntegration/TightIntegration i oznacza atrybuty DisplayNameAttribute, EmailAddressAttribute, GroupNameAttribute i ExpiryDateAttribute komentarzem Only For Tight Integration; tabela parametrów opisuje oba tryby, ale dopuszcza wyłącznie wartość 1. Nie należy na tej podstawie wyciągać wniosków o obsłudze któregokolwiek trybu, znaczeniu 1 ani dopuszczalności pomijania atrybutów warunkowych. Przykład nie stanowi gotowej do wysłania treści żądania; również podane w nim wartości tekstowe przełączników i zabezpieczeń połączenia nie odpowiadają kodowaniu wartości w tabelach. Przed wprowadzeniem zmiany sprawdź schemat lub dokumentację API wersji docelowej oraz skontroluj rzeczywistą konfigurację docelową i powiązaną odpowiedź API w trybie tylko do odczytu. Jeśli mapowanie pozostaje niejasne, nie uruchamiaj opartej na nim automatyzacji, lecz skorzystaj ze sprawdzonej procedury w GUI lub wyjaśnij wymagania API z pomocą techniczną Sophos. Opisane powyżej kroki w GUI pozostają odrębne od tej kontroli; nadal wymagane są Test connection oraz rzeczywiste testy tożsamości, grup, wygaśnięcia konta, jeśli ma zastosowanie, i każdej używanej usługi.

Włącz LDAP dla wymaganych usług

  1. Otwórz Authentication > Services.
  2. W obszarze Firewall authentication methods przenieś serwer LDAP do Selected authentication servers. Jeśli ma odpowiadać jako pierwszy, umieść go na pierwszym miejscu.
  3. Jako Default group wybierz przygotowaną grupę LDAP-Benutzer i kliknij Apply.
  4. Wybierz serwer osobno dla wszystkich faktycznie używanych metod: User portal authentication methods, VPN portal authentication methods, VPN (IPsec/dial-in/L2TP/PPTP) authentication methods, Administrator authentication methods i SSL VPN authentication methods.
  5. Opcji dziedziczenia takich jak Set authentication methods same as firewall, Same as firewall lub Same as VPN używaj tylko wtedy, gdy chcesz zastosować dziedziczoną listę serwerów.

Dla każdej metody uwierzytelniania można wybrać maksymalnie 20 serwerów. W przypadku wielu serwerów zapora odpytuje je w wyświetlanej kolejności. Metoda uwierzytelniania administratorów nie ma zastosowania do superadministratora. W przypadku L2TP i PPTP Sophos dokumentuje wyłącznie PAP dla LDAP; ze względu na ten protokół i przestarzałe metody VPN nie należy wdrażać tej kombinacji bez wcześniejszej oceny.

Dodatkowo w przypadku logowania administratorów: Użytkownik uwierzytelniany zewnętrznie przez LDAP jest przy pierwszym logowaniu początkowo tworzony jako użytkownik standardowy, nawet jeśli w katalogu ma rolę administratora. Najpierw zaloguj się przewidzianym do tego kontem do udostępnionej usługi, takiej jak portal użytkownika lub portal VPN. Następnie, korzystając z istniejącego lokalnego konta administratora, przejdź do Authentication > Users, edytuj utworzonego użytkownika, ustaw User type na Administrator, wybierz Profile ograniczony do wymaganych uprawnień i zapisz za pomocą Save. Samo wybranie serwera w Administrator authentication methods nie wystarczy. Następnie sprawdź na tym koncie logowanie do WebAdmin oraz dozwolone i niedozwolone czynności administracyjne; nadal zachowaj dostęp przez przetestowane lokalne konto umożliwiające przywrócenie konfiguracji.

Skonfiguruj Google Secure LDAP

Przed konfiguracją zapory utwórz klienta LDAP w konsoli administracyjnej Google w sekcji Apps > LDAP. Ogranicz jego Access permissions, pobierz certyfikat wraz z kluczem prywatnym i wygeneruj osobne dane uwierzytelniające. Hasło nie jest już widoczne po zamknięciu okna dialogowego. Jeśli nazwa użytkownika lub hasło są nieprawidłowe albo nie są już dostępne, wygeneruj nowe dane uwierzytelniające w konsoli administracyjnej Google, a następnie zaktualizuj Bind DN i Password w konfiguracji serwera LDAP zapory.

Google może zmieniać interfejs i kroki w konsoli administracyjnej. Przed rozpoczęciem konfiguracji sprawdź więc aktualną dokumentację Google dotyczącą tworzenia klientów LDAP, pobierania certyfikatu i generowania danych uwierzytelniających. Dostępność usługi w używanej edycji Google opisano w dokumentacji Google Secure LDAP; uprawnienia dostępu muszą odpowiadać przewidzianemu zakresowi użytkowników i grup.

Procedurę udokumentowaną przez Sophos w konsoli administracyjnej Google można wykonać następująco:

  1. W sekcji Apps > LDAP rozpocznij od ADD CLIENT, wprowadź nazwę klienta LDAP i Description, a następnie wybierz CONTINUE. Unikalna nazwa, taka jak Sophos-Firewall-Pilot, ułatwia późniejszą identyfikację.
  2. Ogranicz Access permissions do wymaganego zakresu użytkowników i grup, a następnie potwierdź za pomocą ADD LDAP CLIENT.
  3. Wybierz Download certificate. Archiwum ZIP zawiera plik certyfikatu .cer i klucz prywatny .key. Wypakuj oba pliki do chronionego folderu roboczego i zanotuj ich lokalizację na potrzeby późniejszego importu. Klucza prywatnego nie wolno umieszczać w zgłoszeniach ani w niezabezpieczonych zasobach udostępnionych.
  4. Przejdź dalej za pomocą CONTINUE TO CLIENT DETAILS, otwórz kartę Authentication i wybierz GENERATE NEW CREDENTIALS. Bezpiecznie zapisz Username i Password przed wybraniem CLOSE; te wartości będą później używane jako Bind DN i Password, a nie dane dostępowe administratora Google.

Dane uwierzytelniające Google nie zastępują certyfikatu klienta. W tym wariancie Sophos Firewall wymaga zarówno certyfikatu z kluczem prywatnym, jak i wygenerowanych poświadczeń operacji bind.

Następnie włącz klienta w sekcji Service status za pomocą ON for everyone i zapisz za pomocą SAVE. Ten status usługi aktywuje klienta, ale nie zastępuje wcześniej ustawionych Access permissions.

Przed zaimportowaniem certyfikatu sprawdź w Administration > Time, czy zapora pobiera poprawny czas przez NTP. Według Sophos nieprawidłowo ustawiony ręcznie zegar może spowodować niepowodzenie importu certyfikatów. Następnie w Certificates > Certificates > Add wybierz format CER (.cer) i zaimportuj zarówno Certificate, jak i Private key z pakietu pobranego z Google. Certyfikat może być oznaczony jako niezaufany, ponieważ Google podpisuje go samodzielnie; Sophos potwierdza, że Google LDAP mimo to działa. Ta informacja dotyczy certyfikatu klienta, a nie sprawdzania certyfikatu serwera LDAP.

Podczas importu nadaj certyfikatowi unikalną nazwę. Za pomocą Choose File wybierz wypakowany plik .cer dla Certificate i odpowiadający mu plik .key dla Private key, w obu przypadkach zatwierdź za pomocą Open, a na koniec wybierz Save. Dopiero po zapisaniu można wybrać ten certyfikat w polu Client certificate w konfiguracji serwera LDAP.

Do serwera LDAP mają zastosowanie następujące wartości:

  • Server IP/domain: ldap.google.com
  • Version: 3
  • Connection security: SSL/TLS
  • Port: 636
  • Anonymous login: wyłączone
  • Bind DN i Password: wygenerowane dane uwierzytelniające Google LDAP
  • Append base DN: wyłączone
  • Client certificate: zaimportowany certyfikat Google
  • Base DN: wprowadź lub pobierz za pomocą Get base DN
  • Authentication attribute: UID
  • Display name attribute: CN
  • Email address attribute: mail
  • Group name attribute: memberOf
  • Expiry date attribute: expiry

mail jest wymagany do tworzenia grup Google LDAP. Instrukcja Sophos dotycząca Google Secure LDAP nie określa jawnie ustawienia Validate server certificate na liście wartości. Nie można z tego wywnioskować wymogu ani włączenia, ani wyłączenia tej opcji; decyzję należy podjąć zgodnie z ogólną procedurą TLS i własnym łańcuchem zaufania. Oznaczenie certyfikatu klienta Google jako niezaufanego nie jest powodem do wyłączenia sprawdzania certyfikatu zdalnego serwera.

Sprawdź połączenie z Google za pomocą Test connection i zapisz serwer za pomocą Save. Następnie, zgodnie z opisem powyżej, przygotuj lokalną grupę LDAP i wybierz serwer Google w Authentication > Services dla wymaganych usług. Również w przypadku Google samo utworzenie obiektu serwera nie umożliwia jeszcze korzystania z żadnej usługi; późniejsze logowanie pilotażowe sprawdza tożsamość, grupę i uprawnienia.

Sprawdź logowanie i przypisanie do grupy

Test odbiorczy obejmuje połączenie, tożsamość i autoryzację:

  1. Test connection musi potwierdzić połączenie i poświadczenia operacji bind.
  2. W Authentication > Services sprawdź listę serwerów, kolejność i dziedziczenie każdej używanej metody. Default group należy do Firewall authentication methods.
  3. Zaloguj się do wybranej usługi jako użytkownik pilotażowy. Przy pierwszym logowaniu zapora tworzy lokalnie użytkownika uwierzytelnionego zewnętrznie.
  4. W obszarze Authentication > Users sprawdź, czy użytkownik i grupa są wyświetlane zgodnie z oczekiwaniami.
  5. Przeprowadź test pozytywny dla każdej istotnej grupy katalogowej. Dodatkowo sprawdź na koncie użytkownika bez odpowiedniego przypisania do grupy lokalnej, czy stosowana jest oczekiwana Default group.
  6. Sprawdź nie tylko logowanie, lecz także zamierzoną zasadę lub regułę testową. W przypadku SSL VPN przetestuj dostęp do dozwolonych i zablokowanych zasobów z uwzględnieniem obowiązujących zasad użytkowników i grup; nie wyciągaj wniosków o faktycznych uprawnieniach wyłącznie na podstawie restrykcyjnej zasady użytkownika. Następnie użyj nieprawidłowego hasła jako testu negatywnego.
  7. Aby sprawdzić logowanie użytkownika, autoryzację i rozliczanie użycia, przejrzyj access_server.log; w przypadku problemów z portalem VPN dodatkowo vpnportal.log.
  8. Jeśli używany jest atrybut wygaśnięcia, uwzględnij konto testowe o znanym stanie wygaśnięcia.

Jeśli wartości schematu są niejasne, administrator może odpytać obiekt użytkownika w trybie tylko do odczytu z systemu administracyjnego z Linuksem lub bezpośrednio z serwera LDAP:

ldapsearch -LLL -x -H ldaps://ldap.example.net:636 \
  -D 'cn=svc-sophos,ou=service,dc=example,dc=net' -W \
  -b 'ou=people,dc=example,dc=net' \
  '(uid=max.muster)' '*' '+'

Ta opcjonalna metoda diagnostyczna nie jest poleceniem SFOS i nie należy jej uruchamiać w Advanced Shell. Przykład zakłada użycie LDAPS i zaufanie do CA serwera w systemie, z którego uruchamiane jest polecenie; STARTTLS wymaga odpowiednio dostosowanego wywołania. -W interaktywnie pyta o hasło do operacji bind. Dostosuj filtr (uid=max.muster) do skonfigurowanego Authentication attribute. '*' i '+' mogą zwracać wiele zwykłych i operacyjnych atrybutów z danymi osobowymi. Przed dołączeniem wyniku do zgłoszenia lub jego udostępnieniem należy go zanonimizować.

Diagnozuj błędy na podstawie objawów

  • Brak połączenia: Sprawdź routing, DNS, port i Connection security. Następnie sprawdź Bind DN, hasło i Anonymous login.
  • Błąd TLS lub certyfikatu: Sprawdź nazwę z certyfikatu serwera, rozwiązywanie nazw DNS, czas systemowy zapory, ważność certyfikatu i łańcuch CA. Nie wyłączaj sprawdzania certyfikatu jako pierwszego kroku.
  • Test connection działa, ale użytkownik nie został znaleziony: Porównaj Base DN, Authentication attribute i wprowadzoną nazwę logowania.
  • Logowanie działa, grupa jest błędna: Sprawdź Group name attribute i jego rzeczywistą wartość zwracaną, mapowanie grup lokalnych i Default group. memberOf jest zaleceniem, ale nie gwarantuje poprawnego mapowania dla każdego schematu.
  • Serwer został utworzony, ale nie jest używany: Sprawdź wybór, kolejność i dziedziczenie serwerów dla usługi, której dotyczy problem, w Authentication > Services.
  • Google Secure LDAP nie wykonuje operacji bind: Sprawdź osobno wersję 3, port 636, wyłączone Anonymous login, wyłączone Append base DN, status usługi klienta, dane uwierzytelniające i certyfikat klienta Google.
  • Wyszukiwanie jest powolne lub zwraca niepożądane konta: Ogranicz Base DN do wymaganego poddrzewa.
  • Logowanie działa, oczekiwana zasada nie: Sprawdź osobno ustawienia specyficzne dla użytkownika, zasadę grupy, mapowanie grup oraz właściwą regułę zapory lub VPN. W przypadku SSL VPN uwzględnij wszystkie obowiązujące zasady użytkowników i grup oraz faktycznie dozwolone zasoby; sama restrykcyjna zasada użytkownika nie wystarczy. Pełny model diagnostyczny przedstawiono w artykule Systematyczne rozwiązywanie błędów uwierzytelniania.
  • Logowanie do portalu działa, logowanie do WebAdmin nie: W Authentication > Users sprawdź ręcznie przypisaną rolę administratora i Profile. Następnie sprawdź wybór serwera w Administrator authentication methods i obowiązujące reguły dostępu do urządzenia. Nie rezygnuj z lokalnego dostępu umożliwiającego przywrócenie konfiguracji, dopóki nowa metoda nie zostanie sprawdzona.

Bezpiecznie wycofaj zmiany

W przypadku nieudanego wdrożenia najpierw przywróć wcześniej udokumentowany wybór serwerów, ich kolejność i dziedziczenie dla każdej metody objętej zmianą. W Firewall authentication methods przywróć dodatkowo wcześniejszą wartość Default group. Przeprowadź test pozytywny i negatywny, korzystając z poprzedniej metody uwierzytelniania, i sprawdź odpowiednie logi.

Usuń nowy serwer i grupę LDAP tylko wtedy, gdy nie są już używane w żadnej usłudze lub zasadzie. Nie czyść automatycznie utworzonych użytkowników LDAP za pomocą Purge AD users: pomoc SFOS 22 dokumentuje tę funkcję tylko dla Active Directory. Jeśli tacy użytkownicy muszą zostać usunięci, uzgodnij wcześniej z pomocą techniczną Sophos procedurę obsługiwaną w danej konfiguracji.