Gdzie MSAD LDAP przechowuje dane uwierzytelniające używane do uwierzytelnienia użytkowników?


1

Mogę przeglądać szczegóły użytkownika istniejącego katalogu LDAP za pomocą nazwy wyróżniającej powiązania i hasła powiązania. Nie mogę znaleźć żadnego wpisu przechowującego hasło użytkownika. Czy to możliwe, że atrybuty hasła są ukryte na koncie powiązania, którego użyłem do połączenia z MSAD LDAP? Jeśli nie, to czy LDAP przechowuje hasła oddzielnie w innym miejscu?

Planuję skonfigurować moją aplikację do uwierzytelniania użytkowników na podstawie tego LDAP.


Całkowicie zależy od serwera LDAP. AD robi jedną rzecz OpenLDAP robi coś innego.
Zoredache

Cześć @Zoredache - zaktualizowałem pytanie. Pracuję z MSAD. Pomyślałem, że być może wszyscy dostawcy usług katalogowych LDAP zastosowali wspólny schemat przechowywania / zarządzania poświadczeniami kont użytkowników.
Kent Pawar

Odpowiedzi:


1

Planuję skonfigurować moją aplikację do uwierzytelniania użytkowników na podstawie tego LDAP.

Prawidłowym sposobem uwierzytelnienia konta ldap jest po prostu próba powiązania z serwerem ldap z danymi uwierzytelniającymi. W przypadku niektórych serwerów musisz podać pełną nazwę wyróżniającą na podstawie logowania. Musisz więc założyć konto, aby wyszukać nazwę wyróżniającą, biorąc pod uwagę inny identyfikator.

Gdzie są przechowywane poświadczenia.

Większość serwerów przechowuje skrót w atrybucie o nazwie „hasło”. Ale ACL są ustawione na ten atrybut, więc nikt nie może go odczytać. Microsoft po prostu nie zezwala na odczytywanie skrótu hasła za pośrednictwem LDAP jako funkcji bezpieczeństwa. Można go ustawić tylko przez połączenie LDAPS, czyli LDAP w SSL. Konfigurowanie systemu Windows do obsługi LDAPS wymaga utworzenia urzędu certyfikacji lub zakupu certyfikatów.


Dziękuję za wyjaśnienie! Tak, właśnie dla tego skonfigurowałem konto powiązania, więc aplikacja używa go do powiązania z serwerem LDAP i sprawdzenia poprawności poświadczeń.
Kent Pawar

1

Ogólnie rzecz biorąc, chociaż atrybuty mogą wyglądać jak atrybuty w dowolnym systemie LDAP, atrybut hasła jest prawie zawsze specjalnym przypadkiem. Być może jest to ograniczone przez serwer LDAP jako szczególny przypadek. Być może ACL go chronią. Być może jest w stanie pisać, ale nie można go odczytać.

Często istnieje kilka atrybutów hasła (AD ma unicodePassword i userPassword) i zależy to od tego, które z nich należy zastosować. Novell / NetIQ eDirectory ma hasło użytkownika, które zależy od konfiguracji, co do wartości pod nim (pary kluczy RSA, nspmPassword lub proste hasło, które jest bardziej nieparzyste niż zwykły atrybut, ponieważ jest przechowywane w częściach w wielu atrybutach)

Niektóre serwery LDAP umożliwiają powiązanie z wartością skrótu, która odpowiada zapisanej wartości skrótu, a wartość skrótu może być możliwa do odzyskania, ale nieodwracalna.

Ale kluczem jest to, że nie powinno to mieć znaczenia. Ponieważ każdy serwer LDAP jest inny, musisz zastosować standardowe podejście do haseł LDAP, aby spróbować powiązać się z użytkownikiem przy użyciu podanej nazwy wyróżniającej i hasła. A jeśli nie podają nazwy wyróżniającej, wyszukaj uid = nazwa użytkownika lub cn = nazwa użytkownika lub jakikolwiek twój atrybut nazewnictwa, aby znaleźć pełną nazwę wyróżniającą.

Wreszcie należy pamiętać, że standard LDAP mówi, że połączenie z pustym hasłem zakończy się powodzeniem, ale jako połączenie anonimowe. Musisz więc upewnić się, że hasła, na które zezwalasz, nie są puste, w przeciwnym razie otrzymasz udane powiązanie i możliwe, że ktoś nieświadomie wpuści.


+1. Dziękuję @geoffc. To jest bardzo pouczające.
Kent Pawar
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.