Die LDAP-wachtwoordfout is misschien helemaal niet het wachtwoord van de gebruiker

Het wachtwoord van een gebruiker resetten is de verkeerde eerste stap als het log alleen zegt dat een bind is geweigerd. Met een directoryplugin zijn er meer dan één bind in één aanmelding, en de weigering kan bij het serviceaccount horen dat de zoekopdracht uitvoert. De inloggegevens van de gebruiker resetten verandert in dat geval niets. Het sluit ook iemand buiten die nooit het probleem was.

Eén aanmelding, meerdere binds

Een configuratie met een toegewezen directoryaccount voert meestal vier stappen in volgorde uit, en elk daarvan kan de aanmelding beëindigen.

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

De plugin bouwt zijn verbinding voor gebruikerauthenticatie via dezelfde helper die de eerste verbinding afhandelt, dus die helper kan falen tijdens het verbinden, tijdens het onderhandelen over TLS of tijdens het bind als het serviceaccount. Het bericht op hoog niveau over een wachtwoord wordt later gegenereerd en draagt niet welke identiteit betrokken was. Daarom kan de fouttekst alleen niet zeggen of de gebruiker of het serviceaccount is geweigerd.

Lees de regels vóór het bericht en noteer het moment waarop de fout optrad. Een weigering bij het opstarten, voordat er een gebruiker komt, wijst op het geconfigureerde account of het eindpunt. Een weigering die alleen voor één persoon verschijnt, na een geslaagde zoekopdracht, wijst op de vermelding of de accountstatus van die persoon.

Koppel de fout aan een identiteit

De praktische regel is drie dingen samen vast te leggen: wanneer het mislukte, welke bewerking liep en welke identiteit werd gepresenteerd. Zonder dat drietal lijken twee heel verschillende storingen identiek in een log dat alleen de laatste zin bewaart.

Als het geconfigureerde account faalt, inspecteer dat account en de verbinding voordat u een gebruikersrecord aanraakt. Als de bind van de gebruiker faalt na een geslaagde zoekopdracht, onderzoek dan de vermelding die de zoekopdracht opleverde, niet degene waarvan u aannam dat die zou worden opgeleverd. De twee paden delen een bericht en niets anders. Schrijf op welke u hebt uitgesloten, want de volgende persoon zal precies dat vragen.

De distinguished name is data, geen gok

Een naamcomponent wijzigen omdat hij onbekend lijkt, is een veelvoorkomende manier om een werkende configuratie te breken. De standaardlocatie voor gebruikersobjecten in Active Directory is een container met de naam Users, en een container is niet hetzelfde soort object als een organisatie-eenheid met een vergelijkbare naam.

Vraag de directorybeheerder om de werkelijke distinguished name van het account, of lees die uit het object zelf. Beide hieronder kunnen in hun eigen directory correct zijn, daarom zou geen van beide uit het geheugen moeten worden getypt.

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

Een verplaatsing of naamswijziging verandert die waarde terwijl het account en het wachtwoord geldig blijven, dus een configuratie die vorig kwartaal werkte kan dit kwartaal falen zonder dat iemand een inloggegeven aanraakt. Vergelijk de geconfigureerde tekenreeks met het huidige attribuut van de directory na elke reorganisatie. Doe dat ook na een stille migratie, niet alleen na een gemelde storing.

Een zoekbasis is geen serviceaccount

De bind-identiteit en de zoekbasis beantwoorden verschillende vragen: als wie de plugin zich authenticeert en waar hij mensen zoekt. Een geslaagde bind gevolgd door geen overeenkomende gebruiker is een probleem met bereik, filter of leesrecht, en het vervangen van de distinguished name van het account door de basis van de gebruikers verandert daar niets aan.

Bevestig dat de service de configuratie heeft geladen die u hebt bewerkt en dat zijn eindpunt, TLS-vertrouwen en authenticatiemodus overeenkomen met een werkende administratieve test. Een handmatige zoekopdracht met een ander account, of tegen een andere domeincontroller, is geen gelijkwaardig experiment.

Controleer het opgeslagen geheim en controleer of het account is ingeschakeld, verlopen of vergrendeld, zonder het wachtwoord ergens af te drukken. Verloop is gemakkelijk te missen omdat het account blijft werken tot de dag dat het dat niet meer doet. Een vergrendeling die van een niet-gerelateerde service is geërfd, is net zo stil. Geen van beide omstandigheden levert een bericht op dat het serviceaccount noemt.

Groepsregels komen als laatste

Autorisatie loopt nadat de binds zijn geslaagd, dus een groepscontrole kan niet de oorzaak van een bind-fout zijn, en het verwijderen van de groepsvereiste kan die niet repareren. Als de aanmelding nu de groepsfase bereikt, is het resterende probleem lidmaatschap, niet inloggegevens.

Het serviceaccount brede directoryrechten geven om de fout te laten verdwijnen, verandert het toegangsbeleid van de hele implementatie. Behandel dat als een beveiligingsbeslissing met een eigen beoordeling, niet als een oplossing voor een bericht dat u nog niet aan een identiteit hebt toegewezen.