Podłączenie generycznego serwera LDAP do Sophos Firewall

Active Directory jest na Sophos Firewall najczęstszym serwerem uwierzytelniania, ale nie jedynym. Kto prowadzi OpenLDAP, 389 Directory Server, FreeIPA, Google Secure LDAP lub inny czysty katalog LDAP, może podłączyć Sophos Firewall dokładnie tak samo jako klienta LDAP. Typ serwera nazywa się dlatego świadomie LDAP Server, a nie Active Directory, mimo że Active Directory technicznie samo jest katalogiem LDAP.

Ten artykuł omawia celowo przypadek generyczny: usługę katalogową bez specyficznych dla AD pól, takich jak nazwy domen czy Kerberos. Dla środowisk Active Directory z LDAPS, importem grup i AD SSO pasuje zamiast tego Podłączenie Active Directory do Sophos Firewall. Dla uwierzytelniania opartego na RADIUS, na przykład przez Microsoft NPS lub bramę MFA, właściwym artykułem jest Konfiguracja serwera RADIUS w Sophos Firewall.

Kiedy pasuje generyczny serwer LDAP

Serwer LDAP w Sophos Firewall ma sens, gdy:

• Użytkownicy i grupy znajdują się w katalogu, który nie jest Active Directory, na przykład OpenLDAP, 389 Directory Server lub FreeIPA.
• Katalog działający w chmurze oferuje interfejs LDAP, na przykład Google Secure LDAP lub proxy LDAP przed Entra ID albo Okta.
• Kilka systemów uwierzytelnia się już wobec tego samego katalogu LDAP, a firewall ma korzystać z tego samego źródła.
• Nie jest potrzebny Kerberos ani NTLM, tylko wystarcza prosta autoryzacja bind.

Jeśli zamiast tego działa Windows Server z Active Directory Domain Services, wyspecjalizowany typ serwera AD jest zwykle lepszym wyborem, ponieważ czysto odwzorowuje dodatkowe pola, takie jak nazwy domen. Generyczny typ serwera LDAP działa co prawda również wobec Active Directory, ale odwzorowuje mniej automatyzmów specyficznych dla AD.

Wymagania wstępne

• Dostęp do WebAdmin Sophos Firewall.
• Osiągalność serwera LDAP z firewalla, zwykle port 389 (Plaintext/StartTLS) lub 636 (LDAPS).
• Konto bind z uprawnieniami do odczytu w odpowiednim poddrzewie, określone jako Distinguished Name (DN).
• Base DN, pod którym wyszukiwani są użytkownicy, na przykład ou=people,dc=firma,dc=local.
• Znajomość atrybutu, który służy jako nazwa logowania, często uid, sAMAccountName lub mail.
• Przy połączeniu szyfrowanym: certyfikat serwera lub łańcuch certyfikatów, jeśli firewall ma go walidować.

⚠️ Konto bind powinno mieć tylko uprawnienia do odczytu w potrzebnym poddrzewie. Nie jest ono używane do administracyjnych zmian w katalogu, tylko do uwierzytelniania zapytań użytkowników firewalla na serwerze LDAP.

Utworzenie serwera LDAP

1. Otworzyć Authentication > Servers.
2. Wybrać Add, a jako Server type wybrać LDAP server.
3. W polu Server name nadać jednoznaczną nazwę, na przykład LDAP_Firma_Intern.
4. W polu Server IP/domain wpisać adres IP lub nazwę DNS serwera LDAP.
5. W polu Version wybrać wersję LDAP obsługiwaną przez serwer, zwykle Version 3.
6. W polu Connection security wybrać między Plaintext, SSL/TLS lub STARTTLS.
7. W polu Port ustawić właściwy port, jeśli nie jest używany port domyślny.
8. Wyłączyć Anonymous login, jeśli serwer nie zezwala na anonimowe żądania bind.
9. W polu Bind DN wpisać konto techniczne jako Distinguished Name, na przykład cn=svc-sophos,ou=service,dc=firma,dc=local.
10. Wpisać odpowiednie Password.
11. W polu Base DN wpisać zakres wyszukiwania użytkowników, na przykład ou=people,dc=firma,dc=local.
12. W polu Authentication attribute wpisać atrybut, który służy jako nazwa logowania, często uid.
13. Opcjonalnie ustawić Display name attribute i Email address attribute, na przykład cn i mail.
14. Opcjonalnie ustawić Group name attribute, jeśli mają być oceniane przynależności do grup.
15. Uruchomić Test connection i sprawdzić wynik.
16. Wybrać Save.

Przegląd pól:

Udany Test connection dowodzi tylko, że serwer, port, konto bind i baza wyszukiwania są zasadniczo osiągalne. Czy właściwi użytkownicy są znajdowani, a grupy poprawnie przyporządkowane, trzeba potem sprawdzić z prawdziwym użytkownikiem testowym.

Właściwy wybór szyfrowania

Dla środowisk produkcyjnych połączenie między firewallem a serwerem LDAP powinno być szyfrowane, albo przez LDAPS na porcie 636, albo przez STARTTLS na klasycznym porcie 389. Plaintext-LDAP wysyła hasła bind i częściowo dane użytkowników bez szyfrowania i powinien być używany tylko w ściśle zabezpieczonych, wewnętrznych scenariuszach testowych.

W polu Validate server certificate firewall sprawdza, czy certyfikat prezentowany przez serwer LDAP jest zaufany. Przy certyfikatach z podpisem własnym, jak te używane na przykład w Google Secure LDAP, certyfikat może zostać oznaczony jako niezaufany, mimo że połączenie działa. W takim przypadku trzeba świadomie zdecydować, czy sprawdzanie certyfikatu zostanie dostosowane, czy certyfikat zostanie zaimportowany do firewalla.

Przykład: Google Secure LDAP

Google Secure LDAP dobrze pokazuje, jak katalog działający w chmurze jest podłączany przez generyczny LDAP:

• Server IP/domain: ldap.google.com
• Port: 636
• Version: 3
• Connection security: SSL/TLS
• Bind DN i Password: dane dostępowe z LDAP-client-credentials wygenerowanych w Google Admin Console.
• Certyfikat: certyfikat klienta wystawiony przez Google wraz z kluczem prywatnym jest przechowywany na firewallu.
• Atrybuty: uid dla logowania, cn dla wyświetlanej nazwy, mail dla adresu e-mail, memberOf dla grup.

Ten przykład można przenieść na innych dostawców LDAP o podobnej strukturze. Decydujące jest zawsze to, który atrybut dostawca faktycznie wypełnia dla nazwy logowania, wyświetlanej nazwy, e-maila i przynależności do grupy.

Poprawne wpisanie Bind DN i Base DN

Najczęstszym źródłem błędów przy nowym serwerze LDAP jest błędnie zapisana lub błędnie zrozumiana składnia DN.

Ważne zasady:

• DN zapisuje się od części najbardziej szczegółowej do najbardziej ogólnej, na przykład cn=svc-sophos,ou=service,dc=firma,dc=local.
• Base DN dla wyszukiwania użytkowników musi być poddrzewem, w którym rzeczywiście znajdują się odpowiednie obiekty użytkowników, niekoniecznie korzeniem katalogu.
• Jeśli użytkownicy znajdują się w kilku jednostkach organizacyjnych, Base DN musi być wybrana wystarczająco wysoko w drzewie, aby objąć wszystkie istotne kontenery.
• Append base DN decyduje, czy Base DN jest dodatkowo dołączana do Bind DN. Zależy to od serwera i przy problemach powinno być celowo testowane.

Jeśli Base DN jest wybrana zbyt wąsko, firewall może zgłosić udany test połączenia, ale później nie znajduje żadnych użytkowników. Jeśli Base DN jest wybrana zbyt szeroko, wyszukiwanie może trwać niepotrzebnie długo lub obejmować niepożądane obiekty.

Przypisanie grup i atrybutów

Dla reguł firewalla, Web Policies lub uprawnień VPN według grup decydujący jest Group name attribute. Określa on, który atrybut LDAP firewall interpretuje jako przynależność do grupy.

Typowe wzorce:

• Katalogi z klasycznym schematem groupOfNames lub posixGroup często używają atrybutu takiego jak memberOf lub oceniają przynależność do grupy przez odwołania zwrotne.
• Katalogi w chmurze z proxy LDAP, na przykład Google Secure LDAP, dostarczają grupy często bezpośrednio w atrybucie memberOf przy obiekcie użytkownika.
• Jeśli schemat jest niejasny, pomocna jest przeglądarka LDAP lub narzędzie wiersza poleceń, takie jak ldapsearch, aby raz w pełni obejrzeć obiekt użytkownika, zanim firewall zostanie skonfigurowany.

Po konfiguracji należy przetestować co najmniej jednego użytkownika z każdej istotnej grupy. Pojedyncze udane logowanie nie dowodzi, że przypisanie grup działa poprawnie dla wszystkich grup.

Aktywacja serwera LDAP dla usług

Utworzony serwer LDAP sam z siebie jeszcze nikogo nie uwierzytelnia. Musi zostać dodatkowo przypisany w Authentication > Services do żądanej usługi, na przykład VPN Portal, SSL VPN, Captive Portal lub logowanie administracyjne.

Praktyczny przebieg:

1. Otworzyć Authentication > Services.
2. Wybrać dotyczącą usługę, na przykład Firewall authentication methods lub VPN.
3. Dodać nowo utworzony serwer LDAP jako źródło uwierzytelniania.
4. Sprawdzić kolejność, jeśli równolegle używanych jest kilka serwerów.
5. Sprawdzić przewidzianą usługę z użytkownikiem testowym.

Jeśli kilka serwerów uwierzytelniania jest aktywnych jednocześnie, na przykład LDAP i użytkownicy lokalni, kolejność powinna być świadomie wybrana. Firewall odpytuje serwery w wpisanej kolejności.

Testowanie i walidacja połączenia

Po zapisaniu konfiguracja powinna być testowana wieloetapowo:

1. Test connection w masce serwera: potwierdza osiągalność, konto bind i Base DN.
2. Zalogowanie użytkownika testowego do docelowej usługi: potwierdza, że uwierzytelnianie faktycznie działa.
3. Sprawdzenie przynależności do grupy: potwierdza, że Group name attribute jest poprawnie oceniany.
4. Przetestowanie błędnego użytkownika lub błędnego hasła: potwierdza, że nieudane logowania są prawidłowo odrzucane.
5. Sprawdzenie Log Viewer: pokazuje, czy żądania uwierzytelnienia docierają i są przetwarzane zgodnie z oczekiwaniami.

Użytkownik testowy, który loguje się pomyślnie, ale nie jest przypisany do oczekiwanej grupy, wskazuje zwykle na błędny Group name attribute lub nieoczekiwany schemat grup.

Typowe błędy

• Błędna składnia DN: Bind DN lub Base DN są zamienione, błędnie zapisane lub używają błędnych separatorów. Sprawdzić składnię wobec schematu katalogu.
• Base DN wybrana zbyt wąsko: test połączenia jest udany, ale rzeczywiści użytkownicy nie są znajdowani. Ustawić Base DN wyżej w drzewie katalogu.
• Błędny port lub błędne szyfrowanie: LDAPS na porcie 389 lub Plaintext na porcie 636 nie działa. Port i Connection security muszą do siebie pasować.
• Certyfikat niezaufany: przy certyfikatach z podpisem własnym firewall może uznać połączenie za niezaufane. Świadomie zaimportować certyfikat lub celowo dostosować walidację.
• Anonymous login aktywne, mimo że serwer tego odmawia: bind kończy się niepowodzeniem. Wyłączyć Anonymous login i wpisać Bind DN/Password.
• Atrybut grupy nie pasuje do schematu: logowanie działa, ale reguły grupowe nie działają. Sprawdzić atrybut wobec rzeczywistego schematu LDAP, na przykład za pomocą ldapsearch.
• Serwer LDAP nieprzypisany w Authentication > Services: serwer jest utworzony, ale nie jest używany przez żadną usługę. Uzupełnić przypisanie w Authentication > Services.
• Kilka serwerów uwierzytelniania w błędnej kolejności: inny serwer odpowiada jako pierwszy i daje nieoczekiwane zachowanie. Sprawdzić kolejność w Authentication > Services.

FAQ