Acea eroare de parolă LDAP poate să nu fie deloc parola utilizatorului

Resetarea parolei unui utilizator este primul pas greșit când jurnalul spune doar că un bind a fost refuzat. Cu un plugin de director există mai mult de un bind într-o singură autentificare, iar refuzul poate aparține contului de serviciu care efectuează căutarea. Resetarea acreditărilor utilizatorului în acest caz nu schimbă nimic. De asemenea, blochează pe cineva care nu a fost niciodată problema.

O autentificare, mai multe bind-uri

O configurație cu un cont de director dedicat efectuează de obicei patru pași în ordine, iar oricare dintre ei poate încheia autentificarea.

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

Pluginul își construiește conexiunea de autentificare a utilizatorului prin același ajutor care gestionează prima conexiune, așa că acel ajutor poate eșua la conectare, la negocierea TLS sau la bind ca cont de serviciu. Mesajul de nivel înalt despre o parolă este generat mai târziu și nu poartă informația despre ce identitate a fost implicată. De aceea textul erorii singur nu poate spune dacă a fost refuzat utilizatorul sau contul de serviciu.

Citiți liniile dinaintea mesajului și notați momentul în care s-a produs eșecul. Un refuz la pornire, înainte să apară vreun utilizator, indică contul configurat sau punctul final. Un refuz care apare doar pentru o persoană, după o căutare reușită, indică intrarea sau starea contului acelei persoane.

Asociați eroarea cu o identitate

Regula practică este să înregistrați trei lucruri împreună: când a eșuat, ce operațiune rula și ce identitate a fost prezentată. Fără acel triplu, două defecțiuni foarte diferite arată identic într-un jurnal care păstrează doar ultima propoziție.

Dacă contul configurat eșuează, inspectați acel cont și conexiunea înainte de a atinge orice înregistrare de utilizator. Dacă bind-ul utilizatorului eșuează după o căutare reușită, examinați intrarea returnată de căutare, nu pe cea pe care presupuneați că o va returna. Cele două căi împărtășesc un mesaj și nimic altceva. Notați pe care l-ați exclus, pentru că următoarea persoană va întreba exact asta.

Numele distinctiv este o informație, nu o presupunere

Schimbarea unei componente a numelui pentru că pare neobișnuită este o modalitate obișnuită de a strica o configurație funcțională. Locația implicită a obiectelor de utilizator în Active Directory este un container numit Users, iar un container nu este același tip de obiect ca o unitate organizațională cu nume similar.

Cereți administratorului directorului numele distinctiv real al contului sau citiți-l din obiectul însuși. Ambele variante de mai jos pot fi corecte în propriul director, motiv pentru care niciuna nu ar trebui tastată din memorie.

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

O mutare sau o redenumire schimbă acea valoare în timp ce contul și parola rămân valide, așa că o configurație care funcționa trimestrul trecut poate eșua acesta fără ca cineva să atingă o acreditare. Comparați șirul configurat cu atributul actual al directorului după orice reorganizare. Faceți-o și după o migrare silențioasă, nu doar după o întrerupere raportată.

Baza de căutare nu este un cont de serviciu

Identitatea bind și baza de căutare răspund la întrebări diferite: ca cine se autentifică pluginul și unde caută oameni. Un bind reușit urmat de niciun utilizator potrivit este o problemă de domeniu, filtru sau permisiune de citire, iar înlocuirea numelui distinctiv al contului cu baza utilizatorilor nu schimbă nimic în privința asta.

Confirmați că serviciul a încărcat configurația pe care ați editat-o și că punctul final, încrederea TLS și modul de autentificare corespund unui test administrativ funcțional. O căutare manuală cu alt cont, sau împotriva altui controler de domeniu, nu este un experiment echivalent.

Verificați secretul stocat și verificați dacă contul este activat, expirat sau blocat, fără a tipări parola nicăieri. Expirarea este ușor de ratat pentru că contul continuă să funcționeze până în ziua în care nu mai funcționează. O blocare moștenită de la un serviciu nelegat este la fel de silențioasă. Niciuna dintre cele două condiții nu produce un mesaj care să numească contul de serviciu.

Regulile de grup vin la final

Autorizarea rulează după ce bind-urile reușesc, deci o verificare de grup nu poate fi cauza unui eșec de bind, iar eliminarea cerinței de grup nu îl poate repara. Dacă autentificarea ajunge acum la etapa de grup, problema rămasă este apartenența, nu acreditările.

Acordarea de drepturi largi de director contului de serviciu pentru ca eroarea să dispară schimbă politica de acces a întregii implementări. Tratați asta ca pe o decizie de securitate cu propria revizuire, nu ca pe o corectură pentru un mesaj pe care nu l-ați atribuit încă unei identități.