Friday, June 12th, 2009...10:39 pm

Certyfikat SSL dla połączenia LDAP

Jump to Comments

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ć.

2 Comments

  • Jesli chodzi o autoenrollment to w GPO dla DC trzeba wlaczyc autoenrollment. W “Certificate Services Client – Autoenrollment Properties” zaznacza sie “Update certificates that use certificate templates” dla obiektów komputera. Certyfikaty ktore trafiaja do DC to “Domain Controller” i “Kerberos Authentication” a w przypadku Win2k3 jest jeszcze DC Authentication.

    Pozdrawiam

  • @Pat
    Tak, masz rację i oczywiście tak to działa – cały problem polega jednak na tym że trafiają do skłądu Personal dla Local system … a ja chciałbym żeby trafiły gdzie indziej :).

Leave a Reply