Det där LDAP-lösenordsfelet är kanske inte användarens lösenord alls

Att återställa en användares lösenord är fel första steg när loggen bara säger att en bind avvisades. Med en katalogplugin finns det mer än en bind i en enda inloggning, och avvisningen kan tillhöra tjänstekontot som utför sökningen. Att återställa användarens inloggningsuppgifter ändrar ingenting i det fallet. Det låser också ute någon som aldrig var problemet.

En inloggning, flera bindar

En konfiguration med ett dedikerat katalogkonto utför vanligtvis fyra steg i ordning, och vilket som helst av dem kan avsluta inloggningen.

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

Pluginen bygger sin anslutning för användarautentisering genom samma hjälpare som hanterar den första anslutningen, så den hjälparen kan misslyckas vid anslutning, vid TLS-förhandling eller vid bind som tjänstekontot. Meddelandet på hög nivå om ett lösenord genereras senare och bär inte vilken identitet som var inblandad. Därför kan feltexten ensam inte säga om användaren eller tjänstekontot avvisades.

Läs raderna före meddelandet och notera ögonblicket då felet inträffade. En avvisning vid start, innan någon användare kommer, pekar på det konfigurerade kontot eller slutpunkten. En avvisning som bara visas för en person, efter en lyckad sökning, pekar på den personens post eller kontostatus.

Koppla felet till en identitet

Den praktiska regeln är att registrera tre saker tillsammans: när det misslyckades, vilken åtgärd som kördes och vilken identitet som presenterades. Utan den trion ser två mycket olika fel identiska ut i en logg som bara behåller den sista meningen.

Om det konfigurerade kontot misslyckas, granska det kontot och anslutningen innan du rör någon användarpost. Om användarens bind misslyckas efter en lyckad sökning, granska posten som sökningen returnerade, inte den du antog att den skulle returnera. De två vägarna delar ett meddelande och inget annat. Skriv ner vilken du uteslöt, för nästa person kommer att fråga exakt det.

Det unika namnet är data, inte gissning

Att ändra en namndel för att den verkar obekant är ett vanligt sätt att bryta en fungerande konfiguration. Standardplatsen för användarobjekt i Active Directory är en container som heter Users, och en container är inte samma typ av objekt som en organisationsenhet med liknande namn.

Be katalogadministratören om kontots faktiska unika namn, eller läs det från objektet självt. Båda följande kan vara korrekta i sin egen katalog, därför bör ingen av dem skrivas från minnet.

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

En flytt eller namnändring ändrar det värdet medan kontot och lösenordet förblir giltiga, så en konfiguration som fungerade förra kvartalet kan misslyckas detta utan att någon rör en inloggningsuppgift. Jämför den konfigurerade strängen med katalogens aktuella attribut efter varje omorganisation. Gör det också efter en tyst migrering, inte bara efter ett rapporterat avbrott.

En sökbas är inte ett tjänstekonto

Bind-identiteten och sökbasen svarar på olika frågor: som vem pluginen autentiserar och var den letar efter människor. En lyckad bind följd av ingen matchande användare är ett problem med omfång, filter eller läsbehörighet, och att ersätta kontots unika namn med användarnas bas ändrar ingenting i det.

Bekräfta att tjänsten laddade konfigurationen du redigerade och att dess slutpunkt, TLS-förtroende och autentiseringsläge matchar ett fungerande administrativt test. En manuell sökning med ett annat konto, eller mot en annan domänkontrollant, är inte ett likvärdigt experiment.

Kontrollera den lagrade hemligheten och kontrollera om kontot är aktiverat, utgånget eller låst, utan att skriva ut lösenordet någonstans. Utgång är lätt att missa eftersom kontot fortsätter att fungera till den dag det inte gör det. En låsning som ärvts från en orelaterad tjänst är lika tyst. Ingen av de två förhållandena producerar ett meddelande som namnger tjänstekontot.

Gruppregler kommer sist

Auktorisering körs efter att bindarna lyckas, så en gruppkontroll kan inte vara orsaken till ett bind-fel, och att ta bort gruppkravet kan inte reparera det. Om inloggningen nu når gruppsteget är det kvarvarande problemet medlemskap, inte inloggningsuppgifter.

Att ge tjänstekontot breda katalogrättigheter för att få felet att försvinna ändrar åtkomstpolicyn för hela utrullningen. Behandla det som ett säkerhetsbeslut med egen granskning, inte som en rättelse för ett meddelande du ännu inte har tillskrivit en identitet.