Den LDAP-adgangskodefejl er måske slet ikke brugerens adgangskode

At nulstille en brugers adgangskode er det forkerte første skridt, når loggen kun siger, at et bind blev afvist. Med et bibliotek-plugin er der mere end ét bind i én login, og afvisningen kan tilhøre den tjenestekonto, der udfører søgningen. At nulstille brugerens loginoplysninger ændrer intet i det tilfælde. Det låser også nogen ude, som aldrig var problemet.

Ét login, flere bind

En konfiguration med en dedikeret bibliotekskonto udfører normalt fire trin i rækkefølge, og ethvert af dem kan afslutte login.

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

Pluginet opbygger sin forbindelse til brugerverifikation gennem den samme hjælper, som håndterer den første forbindelse, så den hjælper kan fejle under forbindelsen, under TLS-forhandlingen eller under bindet som tjenestekonto. Beskeden på højt niveau om en adgangskode genereres senere, og den bærer ikke, hvilken identitet der var involveret. Derfor kan fejlteksten alene ikke fortælle, om brugeren eller tjenestekontoen blev afvist.

Læs linjerne før beskeden, og notér det øjeblik, fejlen opstod. En afvisning ved opstart, før nogen bruger ankommer, peger på den konfigurerede konto eller på endepunktet. En afvisning, der kun vises for én person efter en vellykket søgning, peger på den persons post eller kontoens tilstand.

Kobl fejlen til en identitet

Den praktiske regel er at notere tre ting sammen: hvornår det fejlede, hvilken handling der kørte, og hvilken identitet der blev præsenteret. Uden den tredjedel ser to meget forskellige fejl ens ud i en log, der kun gemmer den sidste sætning.

Hvis den konfigurerede konto fejler, undersøg den konto og forbindelsen, før du rører nogen brugerpost. Hvis brugerbindet fejler efter en vellykket søgning, undersøg den post, søgningen returnerede, i stedet for den, du antog, den ville returnere. De to veje deler en besked og intet andet. Skriv ned, hvilken du udelukkede, for den næste person spørger præcis om det.

Det unikke navn er data, ikke et gæt

At ændre en navnekomponent, fordi den ser ukendt ud, er en almindelig måde at ødelægge en fungerende konfiguration. Standardplaceringen for brugerobjekter i Active Directory er en beholder ved navn Users, og en beholder er ikke samme type objekt som en organisationsenhed med et lignende navn.

Spørg biblioteksadministratoren om kontoens faktiske unikke navn, eller læs det fra objektet selv. Begge de følgende kan være korrekte i deres eget bibliotek, og derfor bør ingen af dem skrives fra hukommelsen.

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

Flytning eller omdøbning ændrer den værdi, mens kontoen og adgangskoden forbliver gyldige, så en konfiguration, der virkede sidste kvartal, kan fejle i dette, uden at nogen har rørt en loginoplysning. Sammenlign den konfigurerede streng med bibliotekets aktuelle attribut efter enhver omorganisering. Gør det også efter en stille migrering, ikke kun efter et rapporteret nedbrud.

Et søgeområde er ikke en tjenestekonto

Bind-identiteten og søgeområdet besvarer forskellige spørgsmål: som hvem pluginet godkender, og hvor det leder efter personer. Et vellykket bind uden en matchende bruger er et problem med område, filter eller læserettighed, og at erstatte kontoens unikke navn med brugernes base ændrer intet ved det.

Bekræft, at tjenesten har indlæst den konfiguration, du redigerede, og at dens endepunkt, TLS-tillid og godkendelsestilstand svarer til en fungerende administrativ test. En manuel opslagning med en anden konto eller mod en anden domænecontroller er ikke et tilsvarende eksperiment.

Kontroller den gemte hemmelighed, og kontroller, om kontoen er aktiveret, udløbet eller låst, uden at printe adgangskoden nogen steder. Udløb er let at overse, fordi kontoen fortsætter med at virke indtil den dag, den ikke gør. En låsning, der er arvet fra en urelateret tjeneste, er lige så stille. Ingen af de to tilstande frembringer en besked, der navngiver tjenestekontoen.

Grupperegler kommer sidst

Autorisation kører, efter at bindene lykkes, så en gruppekontrol kan ikke være årsag til en bind-fejl, og at fjerne gruppekravet kan ikke reparere en. Hvis login nu når gruppefasen, er det resterende problem medlemskab, ikke loginoplysninger.

At give tjenestekontoen brede biblioteksrettigheder for at få fejlen til at forsvinde ændrer adgangspolitikken for hele udrulningen. Behandl det som en sikkerhedsbeslutning med sin egen gennemgang, ikke som en rettelse af en besked, du endnu ikke har tilskrevet en identitet.