W2K.PL

Dzisiaj dla odmiany będzie trochę technicznie … 

Zastosowanie SSL do ochrony danych na warstwie połączenia LDAP zalecałbym wszystkim, którzy w swoim środowisku posiadają aplikacje korzystające do uwierzytelnienia właśnie z LDAP (nazywa się to LDAP simple bind). LDAP to protokół dostępu do danych a nie protokół uwierzytelnienia (jak chociażby Kerberos). Dlatego też, protokół ten nie posiada mechanizmów zabezpieczających dane sesji uwierzytelnienia. Jednakże z powodu prostego mechanizmu skorzystania z niego często jest jako protokół uwierzytelnienia nadużywany. Tłumacząc problem o  którym staram się powiedzieć na ludzki – hasła w przypadku nawiązywania połączenia LDAP są przesyłane w sieci czystym tekstem.

Tylko to powinno wystarczyć jako powód do wdrożenia SSL dla LDAP w takim wypadku (osobna sprawa to jak przekonać programistów do korzystania z takowego).

Wracając do tematu. Jak wspomniałem Active Directory umożliwia zabezpieczenie połączenia LDAP przy pomocy SSL, wymaga to jedynie wystawienia odpowiedniego certyfikatu spełniającego określone warunki – w szczególności posiadający indentyfikator Server Authentication (1.3.6.1.5.5.7.3.1) w ramach listy zastosowań.

W środowisku, w którym działa odpowiedni urząd CA zintegrowany z katalogiem AD (czyli Windows Server w skrócie) kontrolery domeny mogą odpowiednie certyfikaty pobrać automatycznie korzystając z mechanizmy auto enrolment. Możliwe jest również samodzilne przygotowanie takiego certyfikatu i instalacja go w systemie zgodnie z KB321051 W obu przypadkach certyfikat instalowany jest w składzie certyfikatów lokalnego systemu.

Skład certyfikatów lokalnego systemu ma to do siebie, że może w nim być więcej niż jeden certyfikat spełniający odpowiednie wymagania – w końcu nie jedna usługa może w systemie taki certyfikat zainstalować. W takim przypadku niestety administrator usługi katalogowej nie ma zbytniej kontroli nad tym, który z tych certyfikatów zostanie wybrany przez usługą przy połączeniu LDAP. I tutaj może pojawić sie problem – w końcu może się to wiązać z dystrybucją odpowiednich certyfikatów Root CA itp. W skrajnym przypadku może powodować problemy z dostępem do LDAP\SSL.

Poczynając od Windows 2008 mamy jednak możliwość dokładniejszego określenia, który certyfikat będzie używany przez usługę LDAP. Jeżeli umieścimy odpowiedni certyfikat nie w składzie lokalnego systemu, a w składzie certyfikatów usługi NTDSA – NTDSA\Personal – kontrolera domeny, to właśnie ten certyfikat zostanie użyty do zabezpieczenia transmisji danych LDAP.

W przypadku braku takowego w ramach składu NTDSA\Personal usługa poszuka odpowiedniego certyfikatu jak to drzewiej bywało w składzie lokalnego systemu.

Pieknie … jedyny szkopuł jaki narazie znalazałem w całym rozwiązaniu to fakt, że nie udało mi się wymyśleć jak wykorzystać mechanizmy auto enrollment do umieszczenia odpowiedniego certyfikatu bezpośrednio w składzie NTDSA\Personal. Ale że usługa CA systemu Windows i powiązane z nią mechanizmy nie są moim codziennym zajęciem to może czegoś nie wiem. Gdyby ktoś wiedział … komentarze są po to by się tą wiedzą podzielić.