Den LDAP-passordfeilen er kanskje ikkje brukaren sitt passord i det heile

Å nullstille passordet til ein brukar er det gale første trekket når loggen berre seier at ein bind vart avvist. Med ein katalogplugin er det meir enn éin bind i éi innlogging, og avvisinga kan høyre til tenestekontoen som gjer søket. Å nullstille påloggingsinformasjonen til brukaren endrar ingenting i det tilfellet. Det låser òg ute nokon som aldri var problemet.

Éi innlogging, fleire bind

Ein konfigurasjon med ein dedikert katalogkonto utfører vanlegvis fire steg i rekkjefølgje, og kva som helst av dei kan avslutte innlogginga.

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

Plugin-en byggjer brukarautentiseringssambandet gjennom same hjelparen som handterer det første sambandet, så den hjelparen kan feile under tilkopling, under TLS-forhandling eller under bind som tenestekonto. Meldinga på høgt nivå om eit passord vert generert seinare, og ho ber ikkje kva identitet som var involvert. Derfor kan feilteksten åleine ikkje seie deg om brukaren eller tenestekontoen vart avvist.

Les linjene før meldinga, og noter augneblinken feilen skjedde. Ei avvising ved oppstart, før nokon brukar kjem, peikar på den konfigurerte kontoen eller endepunktet. Ei avvising som berre synest for éin person, etter eit vellukka søk, peikar på oppføringa eller kontotilstanden til den personen.

Kople feilen til ein identitet

Den praktiske regelen er å registrere tre ting saman: når det feila, kva operasjon som køyrde, og kva identitet som vart presentert. Utan den trioen ser to svært ulike feil identiske ut i ein logg som berre held på den siste setninga.

Viss den konfigurerte kontoen feilar, undersøk den kontoen og sambandet før du rører nokon brukarpost. Viss binden til brukaren feilar etter eit vellukka søk, undersøk oppføringa søket returnerte, i staden for den du antok at det ville returnere. Dei to vegane deler ei melding og ingenting anna. Skriv ned kva du utelukka, fordi neste person vil spørje om nettopp det.

Det unike namnet er data, ikkje gissing

Å endre ein namnekomponent fordi han verkar ukjend er ein vanleg måte å øydeleggje ein fungerande konfigurasjon. Standardplasseringa for brukarobjekt i Active Directory er ein behaldar kalla Users, og ein behaldar er ikkje same type objekt som ei organisasjonseining med liknande namn.

Spør katalogadministratoren om det faktiske unike namnet til kontoen, eller les det frå objektet sjølv. Begge dei følgjande kan vere riktige i sin eigen katalog, og derfor bør ingen av dei skrivast frå minnet.

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

Ei flytting eller omdøybing endrar den verdien medan kontoen og passordet held fram med å vere gyldige, så ein konfigurasjon som verka førre kvartal kan feile dette utan at nokon rører ein påloggingsdetalj. Samanlikn den konfigurerte strengen med den gjeldande attributten til katalogen etter kvar omorganisering. Gjer det òg etter ein stille migrering, ikkje berre etter eit rapportert avbrot.

Ein søkjebase er ikkje ein tenestekonto

Bind-identiteten og søkjebasen svarar på ulike spørsmål: som kven plugin-en autentiserer, og kvar han leitar etter folk. Ein vellukka bind følgd av ingen samsvarande brukar er eit problem med omfang, filter eller leserett, og å erstatte det unike namnet til kontoen med basen til brukarane endrar ingenting ved det.

Stadfest at tenesta lasta konfigurasjonen du redigerte, og at endepunktet, TLS-tillit og autentiseringsmodus hennar svarar til ein fungerande administrativ test. Eit manuelt oppslag med ein annan konto, eller mot ein annan domenekontrollør, er ikkje eit likeverdig eksperiment.

Kontroller den lagra løyndomen, og kontroller om kontoen er aktivert, utlopen eller låst, utan å skrive ut passordet nokon stad. Utløp er lett å oversjå fordi kontoen held fram med å verke til den dagen han ikkje gjer det. Ei låsing arva frå ei urelatert teneste er like stille. Ingen av dei to tilstandane produserer ei melding som namngjev tenestekontoen.

Gruppereglar kjem sist

Autorisasjon køyrer etter at bindane lukkast, så ein gruppesjekk kan ikkje vere årsaka til ein bind-feil, og å fjerne gruppekravet kan ikkje reparere han. Viss innlogginga no når gruppetrinnet, er det gjenverande problemet medlemskap, ikkje påloggingsdetaljar.

Å gje tenestekontoen breie katalogrettar for å få feilen til å forsvinne endrar tilgangspolitikken for heile utrulleringa. Handsame det som ei tryggingsavgjerd med si eiga gjennomgåing, ikkje som ei retting for ei melding du enno ikkje har tilskrive ein identitet.