Przejdz do tresci
Avanet

Podłączenie generycznego serwera LDAP do Sophos Firewall

Sophos Firewall

Typ serwera LDAP server umożliwia Sophos Firewall uwierzytelnianie użytkowników z OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP i innych katalogów LDAP. Pełna procedura składa się z czterech części: utworzenia grupy lokalnej, bezpiecznego podłączenia serwera LDAP, aktywowania go w Authentication > Services oraz sprawdzenia logowania i przypisania do grupy przy użyciu rzeczywistego użytkownika.

W przypadku Windows Active Directory z LDAPS, importem grup lub AD SSO bardziej odpowiedni jest artykuł Podłączenie Active Directory do Sophos Firewall. Uwierzytelnianie RADIUS przez Microsoft NPS lub bramę MFA opisano w artykule Konfiguracja serwera RADIUS w Sophos Firewall.

Pełny proces zastępowania natywnego typu serwera eDirectory przed SFOS 23 — obejmujący inwentaryzację, wybór systemu docelowego, pracę równoległą i możliwość wycofania zmian — opisano w artykule Migracja eDirectory przed SFOS 23.

Wymagania

  • dostęp WebAdmin do Sophos Firewall
  • osiągalność serwera LDAP z firewalla, zwykle przez port 389 dla STARTTLS lub 636 dla SSL/TLS
  • konto bind z prawami odczytu do wymaganego zakresu 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
  • faktycznie używane atrybuty użytkownika, takie jak uid, cn, mail i atrybut grupy
  • właściwy łańcuch zaufania CA i działające rozwiązywanie nazw DNS przy włączonej weryfikacji certyfikatu

⚠️ Konto bind powinno mieć wyłącznie prawa odczytu do wymaganego poddrzewa. Nie służy do wykonywania zmian administracyjnych w katalogu, lecz jedynie do uwierzytelniania zapytań użytkowników firewalla wobec serwera LDAP.

Dodawanie serwera LDAP

Przygotowanie lokalnej grupy LDAP

  1. Otworzyć Authentication > Groups i wybrać Add.
  2. Utworzyć grupę o jednoznacznej nazwie, na przykład Użytkownicy-LDAP.
  3. Ustawić dostęp, limity czasu i inne zasady grupy odpowiednio do późniejszego zastosowania, a następnie zapisać.

Ta grupa zostanie później użyta jako Default group. Nie blokuje dostępu automatycznie: o uprawnieniach decydują zasady przypisane do grupy i reguły danego serwisu.

Ogólną logikę grup z restrykcyjną Default Group, wyjątkami użytkowników, pilotażem i wycofaniem opisuje artykuł Bezpieczne zarządzanie grupami użytkowników Sophos Firewall; przypisanie właściwe dla LDAP wynika następnie z atrybutu grupy i schematu katalogu.

Konfiguracja połączenia i bind

  1. Otworzyć Authentication > Servers i wybrać Add.
  2. Jako Server type wybrać LDAP server.
  3. Nadać jednoznaczną wartość Server name, na przykład LDAP-Firma.
  4. W polu Server IP/domain wpisać nazwę DNS serwera LDAP. Przy aktywnej weryfikacji certyfikatu musi ona odpowiadać nazwie w certyfikacie serwera.
  5. Użyć Version 3, chyba że katalog wymaga innej wersji. Google Secure LDAP obsługuje wyłącznie wersję 3.
  6. W środowisku produkcyjnym wybrać SSL/TLS lub STARTTLS oraz odpowiedni port.
  7. Wyłączyć Anonymous login i wpisać Bind DN oraz Password konta z prawami odczytu.
  8. Włączyć Append base DN tylko wtedy, gdy serwer LDAP oczekuje dołączenia Base DN podczas bind.
  9. Włączyć Validate server certificate, gdy nazwa, DNS i zaufanie CA są poprawnie skonfigurowane. Client certificate jest potrzebny tylko wtedy, gdy usługa LDAP wymaga wzajemnego uwierzytelniania certyfikatami.

Wprowadzanie bazy wyszukiwania i atrybutów

  1. W polu Base DN wpisać punkt początkowy wyszukiwania użytkowników, na przykład ou=people,dc=example,dc=net. Funkcja Get base DN może pobrać bazę wyszukiwania udostępnianą przez serwer.
  2. Jako Authentication attribute ustawić atrybut logowania, zwykle uid lub mail.
  3. Wpisać Display name attribute i Email address attribute zgodnie z obiektem użytkownika, na przykład cn i mail.
  4. W polu Group name attribute wpisać atrybut, z którego firewall otrzymuje informacje o grupach użytkownika. Sophos zaleca memberOf, ale poprawna wartość zależy od schematu katalogu.
  5. Jeśli katalog udostępnia datę wygaśnięcia konta, wpisać odpowiedni Expiry date attribute.
  6. Uruchomić Test connection i zapisać przyciskiem Save.

Według Sophos funkcja Test connection sprawdza połączenie i dane dostępowe. Dopiero rzeczywiste logowanie pokazuje, czy Base DN obejmuje wszystkich potrzebnych użytkowników i czy grupy są przypisywane poprawnie.

Wybór właściwego szyfrowania

LDAP w postaci jawnej przesyła dane logowania bez szyfrowania i nadaje się co najwyżej do odizolowanego testu. W środowisku produkcyjnym połączenie należy zabezpieczyć protokołem SSL/TLS, zwykle na porcie 636, lub STARTTLS, zwykle na porcie 389.

Należy rozróżnić dwie role certyfikatów:

  • Validate server certificate weryfikuje tożsamość zdalnego serwera LDAP. Server IP/domain musi odpowiadać prawidłowej nazwie DNS w certyfikacie, czyli Common Name lub Subject Alternative Name. Jeśli firewall nie potrafi rozwiązać tej nazwy, należy dodać odpowiedni wpis DNS w Network > DNS > DNS host entry. Konfiguracja i testowanie DNS Host Entries na Sophos Firewall opisuje TTL, reverse lookup i test resolvera. Zaufana musi być również wystawiająca CA.
  • Client certificate identyfikuje firewall wobec usługi LDAP wymagającej wzajemnego uwierzytelniania certyfikatami. Ten certyfikat nie zastępuje weryfikacji certyfikatu serwera.

W przypadku błędu TLS najpierw należy poprawić nazwę serwera, rozwiązywanie DNS, ważność i łańcuch CA. Wyłączenie weryfikacji certyfikatu serwera nie powinno być standardowym rozwiązaniem.

Poprawne wprowadzanie Bind DN i Base DN

Najczęstszą przyczyną błędów przy nowym serwerze LDAP jest niepoprawnie zapisana lub źle zrozumiana składnia DN.

  • DN prowadzi od konkretnego obiektu do korzenia katalogu, na przykład cn=svc-sophos,ou=service,dc=example,dc=net.
  • Base DN zaczyna się w miejscu, od którego ma ruszyć wyszukiwanie użytkowników. Jeśli użytkownicy znajdują się w kilku jednostkach organizacyjnych, musi być ustawiona odpowiednio wysoko w drzewie, aby objąć ich wszystkich.
  • Zbyt wąska Base DN nie zwraca pasujących użytkowników mimo osiągalności serwera. Niepotrzebnie szeroka baza wyszukiwania może spowalniać wyszukiwanie i obejmować niepożądane obiekty.
  • Append base DN dołącza Base DN do niepełnego Bind DN podczas bind. Przy pełnym DN opcja zwykle pozostaje wyłączona; decydujące jest zachowanie serwera LDAP.

Aktywowanie grup i usług

Group name attribute nie jest uniwersalnym ustawieniem dla każdej struktury grup LDAP. Podczas logowania firewall odczytuje skonfigurowany atrybut z obiektu użytkownika i wykorzystuje zwrócone informacje o grupie do przypisania. Sophos zaleca memberOf, a Google Secure LDAP używa tej wartości. OpenLDAP, 389-ds lub FreeIPA mogą jednak wymagać innej wartości w zależności od schematu, overlay i obiektu użytkownika.

Nie należy wyprowadzać atrybutu użytkownika wyłącznie z typu grupy groupOfNames lub posixGroup. Decydujące jest to, co rzeczywiście zwraca obiekt użytkownika i czy odpowiadająca mu grupa jest poprawnie odwzorowana na firewallu. Jeśli firewall nie znajdzie pasującego przypisania do grupy, użytkownik trafia do skonfigurowanej Default group.

Następnie aktywować serwer:

  1. Otworzyć Authentication > Services.
  2. W sekcji Firewall authentication methods wybrać serwer LDAP i przenieść go na żądaną pozycję na liście Selected authentication servers. Firewall odpytuje wiele serwerów w tej kolejności.
  3. Jako Default group wybrać wcześniej utworzoną grupę Użytkownicy-LDAP i kliknąć Apply.
  4. Jeśli użytkownicy mają logować się do User Portal, VPN Portal, przez SSL VPN, do innej usługi VPN lub jako administratorzy, serwer LDAP należy wybrać również w odpowiedniej metodzie uwierzytelniania.

Konfiguracja Google Secure LDAP

Przed konfiguracją firewalla należy utworzyć klienta LDAP w konsoli administracyjnej Google. Ustala się tam jego prawa dostępu, pobiera certyfikat z kluczem prywatnym i generuje osobne dane dostępowe. Hasło nie jest ponownie wyświetlane po zamknięciu okna dialogowego Google.

Certyfikat klienta Google wraz z kluczem prywatnym importuje się w Certificates > Certificates > Add. Sophos Firewall może wyświetlać go jako niezaufany, ponieważ jest samopodpisany przez Google, ale certyfikat działa mimo to na potrzeby uwierzytelniania klienta. Ten komunikat nie dotyczy weryfikacji certyfikatu serwera.

Dla serwera LDAP obowiązują 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 dostępowe Google LDAP
  • Append base DN: wyłączone
  • Client certificate: zaimportowany certyfikat Google
  • Base DN: wpisać lub pobrać przez 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. Po zapisaniu obowiązują te same kroki co w przypadku katalogu lokalnego: ustawić lokalną grupę LDAP, aktywować serwer w Authentication > Services i przetestować rzeczywiste logowanie wraz z przypisaniem do grupy.

Sprawdzanie połączenia i przypisania do grup

Wiarygodny test odbiorczy obejmuje kilka poziomów:

  1. Test connection potwierdza połączenie i dane dostępowe bind.
  2. Użytkownik loguje się do przewidzianej usługi, na przykład VPN Portal lub Captive Portal.
  3. W Authentication > Users należy sprawdzić, czy użytkownik i grupa są wyświetlani zgodnie z oczekiwaniami.
  4. Jeśli używanych jest kilka grup LDAP, należy przetestować co najmniej jednego użytkownika z każdej odpowiedniej grupy. Zasada lub reguła testowa potwierdza, że działa zarówno logowanie, jak i uprawnienie danej grupy.
  5. Niepoprawne hasło jest odrzucane, a Log viewer pokazuje zrozumiały błąd uwierzytelniania.

Jeśli schemat jest niejasny, administrator może sprawdzić obiekt użytkownika w trybie tylko do odczytu z systemu administracyjnego Linux lub 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)' '*' '+'

Opcja -W interaktywnie pyta o hasło bind, dzięki czemu nie trafia ono do historii powłoki. '*' pokazuje zwykłe atrybuty, a '+' atrybuty operacyjne; przy innym atrybucie logowania należy odpowiednio zmienić filtr wyszukiwania. Tego polecenia nie należy uruchamiać w Advanced Shell Sophos Firewall. Ważne jest, czy obiekt użytkownika rzeczywiście zwraca oczekiwane atrybuty i wartości grup. Dane wyjściowe mogą zawierać dane osobowe z katalogu i przed dołączeniem do zgłoszenia lub udostępnieniem muszą zostać zanonimizowane.

Typowe błędy

  • Brak połączenia: Sprawdzić routing, DNS, port i Connection security. Następnie skontrolować Bind DN, hasło i Anonymous login.
  • Błąd TLS lub certyfikatu: Sprawdzić nazwy DNS w certyfikacie serwera, rozwiązywanie DNS, ważność i łańcuch CA. Nie wyłączać weryfikacji certyfikatu serwera jako pierwszego działania.
  • Test connection działa, ale użytkownik nie jest znajdowany: Base DN jest często zbyt wąska albo Authentication attribute nie odpowiada nazwie logowania.
  • Logowanie działa, ale użytkownik trafia do Default group: Sprawdzić Group name attribute w rzeczywistym obiekcie użytkownika, lokalne odwzorowanie grup i ich kolejność. memberOf jest częstym przykładem, ale nie jest gwarantowany dla każdego schematu.
  • Google Secure LDAP nie wykonuje bind: Sprawdzić wersję 3, port 636, wyłączone Anonymous login, wyłączone Append base DN, dane dostępowe i certyfikat klienta Google.
  • Serwer jest skonfigurowany, ale nie jest używany: Sprawdzić przypisanie, kolejność i Default group w Authentication > Services.
  • Wyszukiwanie jest wolne lub zwraca niepożądane konta: Zawęzić Base DN do wymaganego poddrzewa.
  • Inny serwer uwierzytelniania odpowiada jako pierwszy: Poprawić kolejność wybranych serwerów dla danej usługi.