Ten błąd hasła LDAP może wcale nie dotyczyć hasła użytkownika

Resetowanie hasła użytkownika to zły pierwszy krok, gdy dziennik mówi tylko, że bind został odrzucony. Z wtyczką katalogową w jednym logowaniu jest więcej niż jeden bind, a odmowa może należeć do konta usługi, które wykonuje wyszukiwanie. Resetowanie danych logowania użytkownika w takim przypadku nic nie zmienia. Blokuje też kogoś, kto nigdy nie był problemem.

Jedno logowanie, kilka bind

Konfiguracja z dedykowanym kontem katalogowym zwykle wykonuje cztery kroki po kolei, a każdy z nich może zakończyć logowanie.

connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groups

Wtyczka buduje połączenie uwierzytelniania użytkownika przez tego samego pomocnika, który obsługuje pierwsze połączenie, więc ten pomocnik może zawieść podczas łączenia, podczas negocjacji TLS lub podczas bind jako konto usługi. Komunikat wysokiego poziomu o haśle jest generowany później i nie niesie informacji, która tożsamość była zaangażowana. Dlatego sam tekst błędu nie może powiedzieć, czy odrzucono użytkownika, czy konto usługi.

Przeczytaj wiersze przed komunikatem i zanotuj moment, w którym nastąpiła awaria. Odmowa przy starcie, zanim pojawi się jakikolwiek użytkownik, wskazuje na skonfigurowane konto lub punkt końcowy. Odmowa, która pojawia się tylko dla jednej osoby, po udanym wyszukiwaniu, wskazuje na wpis lub stan konta tej osoby.

Powiąż błąd z tożsamością

Praktyczna zasada to zapisanie trzech rzeczy razem: kiedy zawiodło, jaka operacja trwała i jaka tożsamość została przedstawiona. Bez tej trójki dwa bardzo różne błędy wyglądają identycznie w dzienniku, który zachowuje tylko ostatnie zdanie.

Jeśli skonfigurowane konto zawodzi, sprawdź to konto i połączenie, zanim dotkniesz jakiegokolwiek rekordu użytkownika. Jeśli bind użytkownika zawodzi po udanym wyszukiwaniu, zbadaj wpis zwrócony przez wyszukiwanie, a nie ten, który zakładałeś, że zostanie zwrócony. Te dwie ścieżki dzielą komunikat i nic więcej. Zapisz, którą wykluczyłeś, bo następna osoba zapyta dokładnie o to.

Nazwa wyróżniająca to dane, nie zgadywanie

Zmiana składnika nazwy, ponieważ wygląda nieznajomo, to częsty sposób psucia działającej konfiguracji. Domyślna lokalizacja obiektów użytkowników w Active Directory to kontener o nazwie Users, a kontener nie jest tym samym typem obiektu co jednostka organizacyjna o podobnej nazwie.

Poproś administratora katalogu o rzeczywistą nazwę wyróżniającą konta albo odczytaj ją z samego obiektu. Oba poniższe mogą być poprawne we własnym katalogu, dlatego żadnego nie należy wpisywać z pamięci.

CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example

Przeniesienie lub zmiana nazwy zmienia tę wartość, podczas gdy konto i hasło pozostają ważne, więc konfiguracja, która działała w poprzednim kwartale, może zawieść w tym, bez dotykania przez kogokolwiek danych logowania. Porównaj skonfigurowany ciąg z bieżącym atrybutem katalogu po każdej reorganizacji. Zrób to także po cichej migracji, nie tylko po zgłoszonym przestoju.

Baza wyszukiwania nie jest kontem usługi

Tożsamość bind i baza wyszukiwania odpowiadają na różne pytania: jako kto uwierzytelnia się wtyczka i gdzie szuka ludzi. Udany bind, po którym nie ma pasującego użytkownika, to problem zakresu, filtra lub uprawnień do odczytu, a zastąpienie nazwy wyróżniającej konta bazą użytkowników niczego w tym nie zmienia.

Potwierdź, że usługa załadowała edytowaną konfigurację i że jej punkt końcowy, zaufanie TLS i tryb uwierzytelniania pasują do działającego testu administracyjnego. Ręczne wyszukiwanie z innego konta lub przeciw innemu kontrolerowi domeny nie jest równoważnym eksperymentem.

Sprawdź zapisany sekret i sprawdź, czy konto jest włączone, wygasłe lub zablokowane, nie drukując hasła nigdzie. Wygasanie łatwo przeoczyć, bo konto działa aż do dnia, w którym przestaje. Blokada odziedziczona po niepowiązanej usłudze jest równie cicha. Żaden z tych dwóch stanów nie tworzy komunikatu, który nazywa konto usługi.

Reguły grup przychodzą na końcu

Autoryzacja uruchamia się po udanych bind, więc sprawdzenie grupy nie może być przyczyną niepowodzenia bind, a usunięcie wymogu grupy nie może go naprawić. Jeśli logowanie dociera teraz do etapu grupy, pozostałym problemem jest członkostwo, a nie dane logowania.

Przyznanie kontu usługi szerokich uprawnień do katalogu, aby błąd zniknął, zmienia politykę dostępu całego wdrożenia. Potraktuj to jako decyzję bezpieczeństwa z własnym przeglądem, a nie jako poprawkę do komunikatu, którego jeszcze nie przypisałeś tożsamości.