Den LDAP-passordfeilen er kanskje ikke brukerens passord i det hele tatt

Å tilbakestille en brukers passord er det gale første trekket når loggen bare sier at en bind ble avvist. Med en katalogplugin er det mer enn én bind i én innlogging, og avvisningen kan tilhøre tjenestekontoen som utfører søket. Å tilbakestille brukerens påloggingsinformasjon endrer ingenting i det tilfellet. Det låser også ute noen som aldri var problemet.

Én innlogging, flere bind

En konfigurasjon med en dedikert katalogkonto utfører vanligvis fire trinn i rekkefølge, og hvilket som helst av dem kan avslutte innloggingen.

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 bygger brukerautentiseringsforbindelsen gjennom samme hjelper som håndterer den første forbindelsen, så den hjelperen kan feile under tilkobling, under TLS-forhandling eller under bind som tjenestekonto. Meldingen på høyt nivå om et passord genereres senere, og den bærer ikke hvilken identitet som var involvert. Derfor kan feilteksten alene ikke fortelle deg om brukeren eller tjenestekontoen ble avvist.

Les linjene før meldingen, og noter øyeblikket feilen skjedde. En avvisning ved oppstart, før noen bruker kommer, peker på den konfigurerte kontoen eller endepunktet. En avvisning som bare vises for én person, etter et vellykket søk, peker på den personens oppføring eller kontotilstand.

Kople feilen til en identitet

Den praktiske regelen er å registrere tre ting sammen: når det feilet, hvilken operasjon som kjørte, og hvilken identitet som ble presentert. Uten den trioen ser to svært forskjellige feil identiske ut i en logg som bare beholder den siste setningen.

Hvis den konfigurerte kontoen feiler, undersøk den kontoen og forbindelsen før du berører noen brukerpost. Hvis brukerens bind feiler etter et vellykket søk, undersøk oppføringen søket returnerte, i stedet for den du antok at det ville returnere. De to veiene deler en melding og ingenting annet. Skriv ned hvilken du utelukket, fordi neste person vil spørre om nettopp det.

Det unike navnet er data, ikke gjetning

Å endre en navnekomponent fordi den virker ukjent er en vanlig måte å ødelegge en fungerende konfigurasjon. Standardplasseringen for brukerobjekter i Active Directory er en beholder kalt Users, og en beholder er ikke samme type objekt som en organisasjonsenhet med lignende navn.

Spør katalogadministratoren om kontoens faktiske unike navn, eller les det fra objektet selv. Begge de følgende kan være riktige i sin egen katalog, og derfor bør ingen av dem skrives fra hukommelsen.

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

En flytting eller omdøping endrer den verdien mens kontoen og passordet forblir gyldige, så en konfigurasjon som virket forrige kvartal kan feile dette uten at noen berører en påloggingsdetalj. Sammenlign den konfigurerte strengen med katalogens gjeldende attributt etter enhver omorganisering. Gjør det også etter en stille migrering, ikke bare etter et rapportert avbrudd.

En søkebase er ikke en tjenestekonto

Bind-identiteten og søkebasen svarer på forskjellige spørsmål: som hvem plugin-en autentiserer, og hvor den leter etter folk. En vellykket bind etterfulgt av ingen samsvarende bruker er et problem med omfang, filter eller lesetilgang, og å erstatte kontoens unike navn med brukernes base endrer ingenting ved det.

Bekreft at tjenesten lastet konfigurasjonen du redigerte, og at dens endepunkt, TLS-tillit og autentiseringsmodus samsvarer med en fungerende administrativ test. Et manuelt oppslag med en annen konto, eller mot en annen domenekontroller, er ikke et likeverdig eksperiment.

Kontroller den lagrede hemmeligheten, og kontroller om kontoen er aktivert, utløpt eller låst, uten å skrive ut passordet noe sted. Utløp er lett å overse fordi kontoen fortsetter å virke til den dagen den ikke gjør det. En låsing arvet fra en urelatert tjeneste er like stille. Ingen av de to tilstandene produserer en melding som navngir tjenestekontoen.

Grupperegler kommer sist

Autorisasjon kjøres etter at bindene lykkes, så en gruppesjekk kan ikke være årsaken til en bind-feil, og å fjerne gruppekravet kan ikke reparere den. Hvis innloggingen nå når gruppetrinnet, er det gjenværende problemet medlemskap, ikke påloggingsdetaljer.

Å gi tjenestekontoen brede katalogrettigheter for å få feilen til å forsvinne endrer tilgangspolicyen for hele utrullingen. Behandle det som en sikkerhetsbeslutning med sin egen gjennomgang, ikke som en rettelse for en melding du ennå ikke har tilskrevet en identitet.