LDAP na porcie 389 nadal jest obecny w wielu małych i średnich środowiskach. Szpitale powiatowe, urzędy, firmy z jednym administratorem IT – wszędzie tam wdrożenie pełnego Microsoft PKI bywa odkładane na później. Efekt? Firewall komunikuje się z Active Directory jawnym protokołem, a dane uwierzytelniające i zapytania katalogowe mogą być podatne na podsłuch.
Nie musi to jednak oznaczać budowania rozbudowanej infrastruktury AD CS, kupowania dodatkowych licencji ani uruchamiania kolejnej roli serwerowej. Można przygotować lokalny Root CA i certyfikat serwerowy LDAPS z poziomu PowerShell, zaufać temu urzędowi na FortiGate i skonfigurować bezpieczne połączenie na porcie 636.
Najważniejsze zastrzeżenie: zielony status Successful w FortiGate nie jest jeszcze dowodem pełnego bezpieczeństwa. Szyfrowanie TLS to dopiero połowa zadania. Trzeba także wymusić weryfikację tożsamości serwera.
Spis treści:
Dlaczego LDAP na porcie 389 to problem
Klasyczny LDAP działa standardowo na porcie 389 i bez dodatkowej ochrony przesyła komunikację w sposób podatny na podsłuch. Gdy FortiGate korzysta z Active Directory na potrzeby uwierzytelniania VPN, polityk opartych o grupy lub innych mechanizmów kontroli dostępu, integracja z katalogiem nie powinna pozostawać w postaci jawnego połączenia.
W praktyce przeszkodą często nie jest brak świadomości ryzyka, lecz skala zadania. Pełnoprawny urząd certyfikacji Microsoft AD CS oznacza dodatkową rolę, projektowanie cyklu życia certyfikatów oraz późniejsze utrzymanie. Dla niewielkiego środowiska może to być nieproporcjonalne do potrzeby zabezpieczenia jednego połączenia FortiGate-Active Directory.
LDAPS rozwiązuje ten problem, ponieważ używa TLS i domyślnie działa na porcie 636. Aby połączenie było faktycznie odporne na podszycie się pod serwer, FortiGate musi jednak nie tylko zestawić TLS, ale też rozpoznać i zweryfikować certyfikat kontrolera domeny.
Co jest potrzebne do bezpiecznego LDAPS
Pełna walidacja opiera się na dwóch elementach:
- certyfikacie serwerowym na kontrolerze domeny, używanym przez usługę LDAPS;
- certyfikacie Root CA, który podpisał certyfikat serwera i zostanie zaimportowany do FortiGate jako zaufany urząd certyfikacji.
Klucz prywatny Root CA powinien pozostać w bezpiecznym magazynie certyfikatów na kontrolerze domeny. Do FortiGate eksportowany jest wyłącznie publiczny certyfikat urzędu w pliku .cer. To właśnie on pozwala firewallowi potwierdzić, że certyfikat przedstawiony przez kontroler domeny został podpisany przez zaufane źródło.
Generowanie Root CA i certyfikatu LDAPS w PowerShell
Pierwszy krok wykonaj bezpośrednio na kontrolerze domeny. Uruchom PowerShell z uprawnieniami administratora, a następnie wygeneruj lokalny Root CA, dodaj go do magazynu zaufanych urzędów systemu Windows, utwórz podpisany nim certyfikat serwerowy i wyeksportuj certyfikat CA na pulpit.
$fqdn=([System.Net.Dns]::GetHostEntry("localhost").HostName); $domain=$env:USERDNSDOMAIN; $root=New-SelfSignedCertificate -Subject "CN=Lokalny Root CA dla LDAPS" -CertStoreLocation cert:\LocalMachine\My -KeyAlgorithm RSA -KeyLength 4096 -HashAlgorithm SHA256 -KeyUsage CertSign,CRLSign -Type Custom -TextExtension @("2.5.29.19={text}ca=true") -FriendlyName "AD-RootCA" -NotAfter (Get-Date).AddYears(10); $s=New-Object System.Security.Cryptography.X509Certificates.X509Store("Root","LocalMachine"); $s.Open("ReadWrite"); $s.Add($root); $s.Close(); New-SelfSignedCertificate -DnsName $fqdn,$env:COMPUTERNAME,$domain -CertStoreLocation cert:\LocalMachine\My -KeyAlgorithm RSA -KeyLength 4096 -HashAlgorithm SHA256 -NotAfter (Get-Date).AddYears(5) -FriendlyName "LDAPS-ServerCert" -Type SSLServerAuthentication -Signer $root; Export-Certificate -Cert $root -FilePath "$HOME\Desktop\ad_root_ca.cer"
Polecenie automatycznie odczytuje pełną nazwę serwera oraz nazwę domeny. Root CA otrzymuje klucz RSA 4096 bitów, SHA-256 i 10-letnią ważność. Certyfikat serwerowy LDAPS jest ważny przez 5 lat i zawiera nazwy DNS wykryte dla kontrolera domeny.
Efektem pracy powinien być plik ad_root_ca.cer na pulpicie. To ten plik trzeba przenieść do FortiGate. Nie eksportuj ani nie przenoś klucza prywatnego urzędu certyfikacji.
Import Root CA do FortiGate i porządek w nazwach
Zaloguj się do interfejsu FortiGate i przejdź do System → Certificates. Jeżeli tej pozycji nie ma w menu, sprawdź w Feature Visibility, czy zarządzanie certyfikatami jest włączone.
Następnie wybierz:
- Create/Import,
- CA Certificate,
- import z File,
- plik
ad_root_ca.cer.
FortiGate może automatycznie nazwać zaimportowany certyfikat na przykład CA_Cert_1. Taka nazwa działa, ale szybko tworzy bałagan w środowisku z większą liczbą certyfikatów. Warto od razu zmienić ją na czytelną, na przykład AD-RootCA-MojaDomena.
config vpn certificate ca
rename CA_Cert_1 to "AD-RootCA-MojaDomena"
end
Składnia może różnić się zależnie od wersji FortiOS. Po odświeżeniu listy certyfikatów należy potwierdzić, że Root CA jest widoczny pod nową nazwą.
Konfiguracja serwera LDAPS w FortiOS
Konfigurację serwera LDAP najwygodniej wykonać w CLI. Poniższy przykład tworzy połączenie LDAPS, korzysta z dedykowanego konta serwisowego i wymusza sprawdzanie tożsamości serwera.
config user ldap
edit AD_LDAP_Secure
set server serwer.moja.domena
set cnid sAMAccountName
set dn dc=moja,dc=domena
set type regular
set username ldap-reader@moja.domena
set password haslo-ldap-reader
set secure ldaps
set server-identity-check enable
set ca-cert AD-RootCA-MojaDomena
next
end
Przed zapisaniem konfiguracji zamień wartości przykładowe na dane własnego środowiska. Szczególnej uwagi wymagają pola server, dn, username i ca-cert.
Adres serwera musi być zgodny z certyfikatem
W parametrze set server podaj pełną nazwę FQDN kontrolera domeny, identyczną z nazwą używaną w certyfikacie serwerowym, na przykład dc01.moja.domena. Nie używaj samego adresu IP.
Przy włączonej weryfikacji certyfikatu FortiGate porównuje nazwę serwera z wpisami CN lub SAN w certyfikacie. Jeżeli firewall łączy się pod adresem IP albo inną nazwą niż ta uwzględniona w certyfikacie, walidacja nie powiedzie się.
Użyj sAMAccountName zamiast CN
Parametr cnid definiuje atrybut używany jako identyfikator użytkownika. Dla typowego środowiska Active Directory rozsądnym wyborem jest:
set cnid sAMAccountName
Wartość CN często zawiera pełne imię i nazwisko. Pozostawienie jej jako identyfikatora mogłoby wymagać od użytkowników wpisywania długich nazw ze spacjami i znakami diakrytycznymi. sAMAccountName pozwala logować się klasycznym, krótkim loginem.
Ustaw poprawny Base DN
Parametr set dn określa punkt startowy przeszukiwania Active Directory. Dla domeny moja.domena będzie to:
set dn dc=moja,dc=domena
To istotne, ponieważ FortiGate używa tej ścieżki do wyszukiwania użytkowników i grup w katalogu.
Wybierz bind type regular i konto serwisowe
Domyślna konfiguracja Active Directory nie zezwala na anonimowe przeszukiwanie katalogu. Dlatego zamiast prostego trybu połączenia należy użyć:
set type regular
FortiGate zaloguje się wtedy do katalogu przy użyciu wskazanego konta serwisowego. Najlepiej przygotować osobne konto, przeznaczone wyłącznie do tego celu i posiadające ograniczone uprawnienia potrzebne do przeszukiwania katalogu.
W polach username oraz password wpisz dane tego konta. W przykładzie użyto formatu ldap-reader@moja.domena.
LDAPS, DNS i pełna walidacja certyfikatu
Bezpieczne połączenie wymaga trzech powiązanych ustawień:
set secure ldaps– przełącza połączenie na LDAPS, domyślnie port 636;set server-identity-check enable– wymusza sprawdzenie tożsamości serwera;set ca-cert AD-RootCA-MojaDomena– wskazuje zaufany Root CA zaimportowany do FortiGate.
FortiGate musi też umieć poprawnie rozwiązać FQDN kontrolera domeny przez DNS. To nie jest detal techniczny, ale warunek poprawnej walidacji. Firewall musi odnaleźć serwer pod nazwą zgodną z certyfikatem, a następnie sprawdzić, czy certyfikat został podpisany przez wskazany urząd certyfikacji.
Pułapka: Successful nie zawsze znaczy bezpiecznie
To najważniejszy punkt całego wdrożenia. Po aktywacji LDAPS test połączenia może zwrócić status Successful, nawet jeśli weryfikacja certyfikatu serwera nie została skonfigurowana.
Taki wynik potwierdza jedynie, że handshake TLS został wykonany i transmisja jest szyfrowana. Nie oznacza automatycznie, że FortiGate zweryfikował, z kim zestawił połączenie.
Gdy opcja server-identity-check jest wyłączona, urządzenie może zaakceptować dowolny przedstawiony certyfikat. To otwiera drogę do ataku typu man-in-the-middle: ruch jest zaszyfrowany, ale może być szyfrowany do niewłaściwego serwera.
Szyfrowanie bez weryfikacji tożsamości serwera nie daje pełnej ochrony. Dopiero zaufany Root CA, zgodny FQDN i aktywny Server Identity Check budują właściwy łańcuch zaufania.
W GUI należy włączyć Server Identity Check i wybrać właściwy certyfikat CA. W CLI odpowiadają za to polecenia:
set server-identity-check enable
set ca-cert AD-RootCA-MojaDomena
Dopiero wtedy FortiGate sprawdzi podpis certyfikatu i zgodność nazwy FQDN kontrolera domeny.
Test diagnostyczny połączenia LDAP
Po zapisaniu konfiguracji sprawdź, czy FortiGate potrafi wyszukać użytkownika i poprawnie uwierzytelnić połączenie z katalogiem.
diagnose test authserver ldap AD_LDAP_Secure nazwa_uzytkownika hasło_uzytkownika
Jeżeli profil LDAP otrzymał inną nazwę niż AD_LDAP_Secure, użyj własnej wartości. Podstaw także dane istniejącego konta, które powinno zostać odnalezione w Active Directory.
Udany test warto interpretować razem z konfiguracją, a nie w oderwaniu od niej. Zweryfikuj, czy profil rzeczywiście ma włączone server-identity-check, wskazany właściwy ca-cert, poprawny FQDN oraz działający DNS.
Lista kontrolna bezpiecznego LDAPS na FortiGate
Przed uznaniem wdrożenia za zakończone przejdź przez krótką listę:
- kontroler domeny ma certyfikat serwerowy przeznaczony do uwierzytelniania SSL;
- certyfikat serwerowy zawiera prawidłowy FQDN kontrolera domeny;
- Root CA został zaimportowany do FortiGate jako certyfikat CA;
- nazwa Root CA w
set ca-certjest zgodna z nazwą w FortiGate; - parametr
set serverwykorzystuje FQDN, a nie adres IP; - FortiGate poprawnie rozwiązuje FQDN przez DNS;
- połączenie używa
set secure ldaps; - włączono
set server-identity-check enable; - do przeszukiwania katalogu używane jest dedykowane konto serwisowe;
- test diagnostyczny LDAP kończy się powodzeniem.
Mała zmiana, realna poprawa bezpieczeństwa
Przejście z LDAP na porcie 389 do LDAPS na porcie 636 eliminuje przesyłanie danych uwierzytelniających przez nieszyfrowane połączenie. W małych organizacjach nie musi oznaczać rozbudowanego projektu PKI. Lokalny Root CA, certyfikat serwerowy i kilka komend FortiOS wystarczą, aby zbudować bezpieczne połączenie FortiGate z Active Directory.
Nie pomijaj jednak weryfikacji tożsamości serwera. To właśnie ona rozróżnia połączenie „zaszyfrowane” od połączenia, które rzeczywiście sprawdza, czy komunikuje się z właściwym kontrolerem domeny.
FAQ
Czy LDAPS używa portu 636?
Tak. LDAPS standardowo działa na porcie 636 i zabezpiecza komunikację LDAP przy użyciu TLS.
Czy do wdrożenia LDAPS na FortiGate potrzebny jest Microsoft AD CS?
Nie. W tym scenariuszu można utworzyć lokalny Root CA i podpisany nim certyfikat serwerowy bezpośrednio w PowerShell na kontrolerze domeny.
Dlaczego w konfiguracji LDAP należy użyć FQDN zamiast adresu IP?
FortiGate porównuje nazwę serwera z wpisami CN lub SAN w certyfikacie. Adres IP zwykle nie odpowiada nazwie zapisanej w certyfikacie, przez co weryfikacja tożsamości może się nie powieść.
Czy status Successful w teście FortiGate potwierdza pełne bezpieczeństwo?
Nie. Taki status może jedynie potwierdzać powodzenie handshake TLS i szyfrowanie ruchu. Pełna ochrona wymaga także aktywnego Server Identity Check oraz wskazania zaufanego certyfikatu CA.
Jakiego atrybutu użyć jako identyfikatora użytkownika LDAP?
W typowych środowiskach Active Directory warto użyć sAMAccountName. Dzięki temu użytkownicy mogą logować się krótkim loginem zamiast pełnym imieniem i nazwiskiem zapisanym w CN.
