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 typowi kandydaci na ogólne połączenie LDAP, ale nie są to produkty wymienne. Atrybuty, zwracane wartości grup i wygaśnięcie konta różnią się w zależności od schematu. Dlatego też niniejszy przewodnik stanowi przykład, który można przenieść; 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 WebAdmin do Sophos Firewall;
  • Dostępność serwera LDAP z firewalla poprzez port skonfigurowany na serwerze;
  • konto 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;
  • login, nazwa wyświetlana, adres e-mail, grupa i, jeśli ma to zastosowanie, atrybuty wygaśnięcia konta;
  • Podczas sprawdzania certyfikatu rozpoznawalna nazwa serwera i odpowiedni łańcuch zaufania urzędu certyfikacji.

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 Bind nie wymaga administracyjnych uprawnień do zapisu. Ogranicz jego prawa odczytu do poddrzewa i atrybutów wymaganych przez zaporę ogniową w przypadku żądań użytkowników.

Przed przejściem na Authentication > Services należy udokumentować wybrane serwery, ich kolejność i opcje dziedziczenia dla każdej metody, której to dotyczy. Zapisz także poprzednie Default group pod Firewall authentication methods. Dzięki temu można cofnąć zmianę bez pochopnego usuwania nowych obiektów.

Rozróżnij Bind DN, Base DN i atrybuty

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

Podstawowa nazwa wyróżniająca, która jest zbyt wąska, nie pozwoli znaleźć wszystkich potrzebnych użytkowników. Niepotrzebnie szeroka baza wyszukiwania może spowolnić wyszukiwanie i zawierać niechciane elementy. Append base DN podczas wiązania dołącza podstawową nazwę wyróżniającą do niekompletnej nazwy wyróżniającej powiązania; jeśli DN jest już kompletny, opcję zwykle pozostawia się wyłączoną. Zachowanie używanego serwera LDAP ma kluczowe znaczenie.

Atrybuty również pochodzą ze schematu katalogu. uid, cn, mail i memberOf to przykłady, a nie uniwersalne specyfikacje. Sophos zaleca memberOf jako Group name attribute, ale używa GID w swoim własnym przykładzie konfiguracji ogólnej. Dlatego wartość zwracaną, mapowanie grup lokalnych i wielokrotne członkostwo należy sprawdzić z prawdziwymi użytkownikami testowymi.

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.

W przypadku Validate server certificate nazwa określona w certyfikacie serwera i możliwa do rozpoznania przez zaporę sieciową musi znajdować się w polu Server IP/domain. Sophos nazywa to CNAME w pomocy SFOS 22, podczas gdy ten sam opis pola w innym miejscu wspomina jedynie o IP serwera. Nazwa certyfikatu jest zatem bezpiecznym wyborem w przypadku kontrolowanego wdrożenia protokołu TLS. Jeżeli zapora nie może rozpoznać tej nazwy, można utworzyć wpis w obszarze 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.

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. Zasady przypisane do użytkownika mają pierwszeństwo przed zasadami grupy. Pełną logikę grup, obejmującą pilota, wyjątki dla użytkowników i Main Group, 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. Wybierz LDAP server jako Server type.
  3. Przypisz unikalny Server name, na przykład LDAP-Firma.
  4. Wpisz adres IP serwera lub nazwę domeny w polu Server IP/domain. W przypadku Validate server certificate użyj rozpoznawalnej nazwy z certyfikatu serwera.
  5. Wybierz wersję 2 lub 3 w polu Version, zgodnie z obsługą serwera. 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 i Password konta z uprawnieniami do odczytu.
  8. Włącz Append base DN tylko wtedy, gdy serwer powinien dodać podstawową nazwę wyróżniającą podczas wiązania.
  9. Jeśli połączenie jest bezpieczne, zdecyduj świadomie, 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 stosuje się do specjalnego przypadku opisanego poniżej. Wybierz wymagany Client certificate z listy.

Ustaw bazę wyszukiwania i atrybuty

  1. Wpisz punkt początkowy wyszukiwania użytkownika w polu Base DN. Get base DN może uzyskać bazę wyszukiwania oferowaną przez serwer.
  2. Ustaw atrybut z nazwą logowania na Authentication attribute, często uid lub mail.
  3. Wpisz Display name attribute i Email address attribute, zgodnie z obiektem użytkownika, na przykład cn i mail.
  4. Wpisz atrybut grupy zwrócony 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 ważności.
  6. Uruchom Test connection i zapisz za pomocą Save.

Według Sophos Test connection sprawdza połączenie i poświadczenia wiązania. Test nie dowodzi, że podstawowa nazwa wyróżniająca obejmuje wszystkich użytkowników ani że autoryzacja grupowa lub usługowa obowiązuje prawidłowo. Wymagany jest do tego rzeczywiste logowanie.

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. Wybierz przygotowaną grupę LDAP-Benutzer jako Default group i kliknij Apply.
  4. Wybierz serwer osobno dla wszystkich aktualnie 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. Jeśli istnieje wiele serwerów, zapora będzie wysyłać zapytania do nich w pokazanej kolejności. Metoda Administratora nie ma zastosowania w przypadku Super Administratora. W przypadku L2TP i PPTP Sophos dokumentuje wyłącznie PAP dla LDAP; tej kombinacji nie należy ponownie wprowadzać bez wcześniejszej oceny ze względu na PAP i przestarzałe metody VPN.

Skonfiguruj Google Secure LDAP

Przed konfiguracją zapory sieciowej klient LDAP jest tworzony w konsoli administracyjnej Google w sekcji Apps > LDAP. Jego Access permissions są ograniczone, pobierane są certyfikat i odpowiadający mu klucz prywatny i generowane są osobne dane dostępowe. Hasło nie jest już widoczne po zamknięciu okna dialogowego.

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 ustawionego Access permissions.

Przed zaimportowaniem certyfikatu pod Administration > Time sprawdź, czy zapora sieciowa pobiera poprawny czas poprzez NTP. Zdaniem Sophos, źle ustawiony ręcznie zegar może spowodować niepowodzenie importu certyfikatów. Następnie wybierz format CER (.cer) w obszarze Certificates > Certificates > Add 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 nadal działa. Ta informacja dotyczy certyfikatu klienta, a nie sprawdzanie certyfikatu 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

Do utworzenia grupy Google LDAP wymagany jest mail. Oficjalne instrukcje Google nie określają jawnie ustawienia Validate server certificate na liście wartości. Bez testu laboratoryjnego SFOS-22 nie należy ustalać ani stałego włączenia, ani wyłączenia; o wyborze opcji decyduje ogólna procedura TLS i Twój własny łańcuch zaufania.

Sprawdź logowanie i przypisanie do grupy

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

  1. Test connection musi potwierdzić połączenie i dane uwierzytelniające Bind.
  2. W Authentication > Services sprawdź listę serwerów, kolejność i dziedziczenie każdej użytej 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 sieciowa 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ź pozytywny test dla każdej odpowiedniej grupy katalogów. Dodatkowo sprawdź na koncie użytkownika bez odpowiedniego przypisania do grupy lokalnej, czy ma zastosowanie oczekiwany Default group.
  6. Sprawdź nie tylko logowanie, lecz także zamierzoną zasadę lub regułę testową. Następnie użyj nieprawidłowego hasła jako testu negatywnego.
  7. Do logowania użytkownika, autoryzacji i rejestrowania zdarzeń sprawdź access_server.log; w przypadku problemów z portalem VPN dodatkowo vpnportal.log.
  8. Jeśli używany jest atrybut wygaśnięcia, dołącz konto testowe ze znanym statusem wygaśnięcia.

Jeśli wartości schematu są niejasne, administrator może odczytać obiekt użytkownika 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 ścieżka diagnostyczna nie jest poleceniem SFOS i nie należy do powłoki Advanced Shell. W przykładzie założono LDAPS i zaufanie do urzędu certyfikacji serwera w systemie, z którego uruchamiane jest polecenie; STARTTLS wymaga odpowiednio dostosowanego wywołania. -W interaktywnie pyta o hasło powiązania. 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ć.

Izoluj błędy według 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, rozpoznawanie nazw DNS i czas systemowy zapory, ważność i łańcuch urzędów certyfikacji. Nie dezaktywuj 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 grupy lokalnej i Default group. memberOf jest zaleceniem, ale nie gwarantowanym mapowaniem dla każdego schematu.
  • Serwer został utworzony, ale nie jest używany: Sprawdź wybór, kolejność i dziedziczenie usługi, której dotyczy problem, pod Authentication > Services.
  • Google Secure LDAP nie nawiązuje powiązania: Sprawdź osobno wersję 3, port 636, wyłączone Anonymous login, wyłączone Append base DN, stan usługi klienta, dane uwierzytelniające i certyfikat klienta Google.
  • Wyszukiwanie jest powolne lub zwraca niechciane konta: Ogranicz podstawową nazwę wyróżniającą do wymaganego poddrzewa.
  • Logowanie działa, oczekiwana polityka nie: Sprawdź osobno nadpisanie ustawień użytkownika, zasady grupy, mapowanie grup oraz właściwą regułę zapory lub VPN. Pełny model diagnostyczny pokazuje Systematyczne rozwiązywanie błędów uwierzytelniania.

Bezpiecznie wycofaj zmiany

W przypadku nieudanego wdrożenia najpierw przywróć wcześniej udokumentowany wybór serwera, kolejność i dziedziczenie dla każdej metody, której dotyczy problem. W ramach Firewall authentication methods przywracany jest również poprzedni 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.