17 grudnia 2017

bramki antyspamowe i LDAPS

Niedawno miałem ciekawy przypadek przy konfiguracji bramki Symantec Messaging Gateway. Dla lepszej ochrony systemu pocztowego (jak dla mnie oczywiście Exchange), bramki te, podobnie jak wiele innych tego typu rozwiązań, pobierają z katalogu LDAP listę adresową organizacji. W ten sposób mogą weryfikować listę odbiorców dla poczty przychodzącej i listę nadawców dla poczty wychodzącej. W ten sposób również użytkownicy Exchange mogą łączyć się do swojej kwarantanny, znajdującej się na bramce. Konfiguracja integracji bramki antyspamowej z Active Directory jest stosunkowo prosta i polega na wskazaniu serwera, DN konta używanego do czytania danych (w przypadku AD może być również UPN tego konta), no i oczywiście hasła tego konta. Dodatkowym atrybutem połączenia jest port TCP (domyślnie 389). Kolejnym krokiem jest test połączenia.
Błąd przy zestawianiu połączenia z AD





















Przy próbie połączenia kreator pokazywał mi błąd, świadczący o nieprawidłowym koncie. Jednak próba połączenia z AD z komputera domenowego działała poprawnie. Po weryfikacji haseł, ustawień firewalla i innych kwestii sieciowych, sprawdziłem polisy GPO. Okazało się, że zarówno na kontrolerach domenowych, jak i na stacjach roboczych jest ustawione wymuszenie podpisywania pakietów LDAP (LDAP signing). Niestety funkcja ta powoduje problemy z uwierzytelnieniem z urządzeń takich jak SMG czy SonicWall.
Alternatywą było ustawienie połączenia na LDAPS. Przełączyłem port na 636 (domyślny port połączenia LDAPS) i tym razem dostałem komunikat, że nie mogę nawiązać połączenia z serwerem. O co chodzi? Człowiek przyzwyczaił się, że w środowisku domenowym wdrażany jest do wewnętrznych celów organizacji urząd certyfikacyjny (CA), a że całkiem sporo firm instaluje CA na kontrolerze domeny, a w takim wypadku dla kontrolerów domyślnie instalowane są certyfikaty, właśnie służące do szyfrowania komunikacji LDAP (czyli właśnie LDAPS). Jeżeli jednak w AD nie ma zainstalowanego urzędu certyfikacji, to takich certyfikatów niestety nie ma domyślnie zainstalowanych, więc LDAPS nie działa. Jak to zmienić? Bardzo prosto. Można oczywiście wdrożyć urząd certyfikacyjny na jednym z serwerów Windows, jednak nie zawsze jest to możliwe. Tak naprawdę, do uruchomienia LDAPS na kontrolerach domeny możemy użyć dowolnego urzędu CA, do którego mamy dostęp, żeby wygenerować potrzebne nam certyfikaty. Dobra instrukcja, jak to zrobić znajduje się na stronach wikipedii Technet. Możemy jednak postąpić jeszcze prościej - użyć certyfikatów self-signed. Tak naprawdę do uruchomienia LDAPS certyfikaty muszą spełniać 3 warunki:
  1. Certyfikat musi obsługiwać funkcję Server Authentication. Czyli innymi słowy musi zawierać Server Authentication OID: 1.3.6.1.5.5.7.3.1
  2. Atrybut Subject Name lub pierwsza nazwa w atrybucie Subject Alternative Name (SAN) musi  być zgodna z nazwą Fully Qualified Domain Name (FQDN) serwera - np. SubjectCN=server1.contoso.com
  3. W lokalnym magazynie konta komputera musi znajdować się klucz prywatny certyfikatu.
Czyli możemy z linii komend wygenerować certyfikat komendą:
certreq -New -Machine policy.inf
Wcześniej oczywiście musimy sobie przygotować plik policy.inf zawierający niezbędne informacje.
Kilka przykładów prostego i bardziej rozbudowanego pliku znalazłem na blogu Oskara Virota.
Jeżeli jednak kontrolery domeny są w wersji Windows 2012 lub nowszej możemy użyć cmdleta powershell New-SelfSignedCertificate
Tworząc certyfikat nawet przy minimalnej ilości atrybutów uzyskamy odpowiedni wynik, chociaż certyfikat będzie miał standardową długość życia certyfikatu (jeden rok):
New-SelfSignedCertificate -DnsName "server1.contoso.com" -CertStoreLocation "cert:\LocalMachine\My"
Teraz musimy wyeksportować certyfikat (najlepiej w formacie Base64) i zaimportować go ponownie, tym razem wybierając magazyn Zaufanych Głównych Urzędów Certyfikacji, na wszystkich kontrolerach domeny, z którymi chcemy, żeby komunikacja LDAPS działała (oczywiście na nich również powinniśmy wygenerować i wyeksportować kolejne certyfikaty), oraz na bramce SMG.
Po restarcie kontrolera domeny połączenie LDAPS powinno uruchomić się bez problemów.

Brak komentarzy: