Ta napaka gesla LDAP morda sploh ni uporabnikovo geslo

Ponastavljanje uporabnikovega gesla je napačna prva poteza, ko dnevnik pravi le, da je bil bind zavrnjen. Pri vtičniku za imenik je v eni prijavi več kot en bind in zavrnitev lahko pripada storitvenemu računu, ki izvaja iskanje. Ponastavljanje uporabnikovih poverilnic v tem primeru ne spremeni ničesar. Zaklene tudi nekoga, ki nikoli ni bil težava.

Ena prijava, več bind

Konfiguracija z namenskim računom imenika običajno izvede štiri korake po vrsti in kateri koli od njih lahko konča prijavo.

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

Vtičnik zgradi povezavo za preverjanje uporabnika prek istega pomočnika, ki obravnava prvo povezavo, zato lahko ta pomočnik odpove med povezovanjem, med pogajanji o TLS ali med bind kot storitveni račun. Sporočilo na visoki ravni o geslu se ustvari pozneje in ne nosi podatka, katera identiteta je bila vpletena. Zato samo besedilo napake ne more povedati, ali je bil zavrnjen uporabnik ali storitveni račun.

Preberite vrstice pred sporočilom in zabeležite trenutek, ko je prišlo do napake. Zavrnitev ob zagonu, preden pride kateri koli uporabnik, kaže na konfigurirani račun ali končno točko. Zavrnitev, ki se pojavi le za eno osebo, po uspešnem iskanju, kaže na vnos ali stanje računa te osebe.

Povežite napako z identiteto

Praktično pravilo je, da skupaj zabeležite tri stvari: kdaj je spodletelo, katera operacija je potekala in katera identiteta je bila predstavljena. Brez te trojice sta dve zelo različni napaki v dnevniku, ki hrani le zadnji stavek, videti enaki.

Če konfigurirani račun spodleti, preglejte ta račun in povezavo, preden se dotaknete katerega koli uporabniškega zapisa. Če uporabnikov bind spodleti po uspešnem iskanju, preglejte vnos, ki ga je vrnilo iskanje, ne tistega, za katerega ste domnevali, da ga bo vrnilo. Poti si delita sporočilo in nič drugega. Zapišite, katero ste izključili, ker bo naslednja oseba vprašala prav to.

Razločevalno ime je podatek, ne ugibanje

Spreminjanje sestavnega dela imena, ker se zdi neznan, je pogost način, kako pokvariti delujočo konfiguracijo. Privzeta lokacija uporabniških objektov v Active Directory je vsebnik z imenom Users, in vsebnik ni ista vrsta objekta kot organizacijska enota s podobnim imenom.

Prosite skrbnika imenika za dejansko razločevalno ime računa ali ga preberite iz samega objekta. Oba spodnja sta lahko v svojem imeniku pravilna, zato nobenega ne bi smeli vtipkati po spominu.

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

Premik ali preimenovanje spremeni to vrednost, medtem ko račun in geslo ostaneta veljavna, zato lahko konfiguracija, ki je delovala prejšnje četrtletje, to spodleti, ne da bi se kdo dotaknil poverilnic. Po vsaki reorganizaciji primerjajte konfigurirani niz s trenutnim atributom imenika. To naredite tudi po tihi selitvi, ne le po prijavljeni prekinitvi.

Osnova iskanja ni storitveni račun

Identiteta bind in osnova iskanja odgovarjata na različni vprašanji: kot kdo se vtičnik preverja in kje išče ljudi. Uspešen bind, ki mu ne sledi ustrezen uporabnik, je težava obsega, filtra ali pravice branja, in zamenjava razločevalnega imena računa z osnovo uporabnikov tega ne spremeni.

Potrdite, da je storitev naložila konfiguracijo, ki ste jo uredili, in da se njen končna točka, zaupanje TLS in način preverjanja ujemajo z delujočim administrativnim testom. Ročno iskanje z drugim računom ali proti drugemu krmilniku domene ni enakovreden poskus.

Preverite shranjeno skrivnost in preverite, ali je račun omogočen, potekel ali zaklenjen, ne da bi geslo kjer koli natisnili. Potek je lahko spregledati, ker račun deluje do dneva, ko neha. Zaklep, podedovan po nepovezani storitvi, je prav tako tih. Nobeno od teh dveh stanj ne ustvari sporočila, ki bi imenovalo storitveni račun.

Pravila skupin pridejo na koncu

Avtorizacija se izvaja po uspešnih bindih, zato preverjanje skupine ne more biti vzrok za neuspeh bind in odstranitev zahteve po skupini tega ne more popraviti. Če prijava zdaj doseže stopnjo skupine, je preostala težava članstvo, ne poverilnice.

Dodelitev širokih pravic imenika storitvenemu računu, da bi napaka izginila, spremeni politiko dostopa celotne namestitve. Obravnavajte to kot varnostno odločitev z lastnim pregledom, ne kot popravek za sporočilo, ki ga še niste pripisali identiteti.