Dieser LDAP-Passwortfehler ist vielleicht gar nicht das Passwort des Benutzers

Das Passwort eines Benutzers zurückzusetzen ist der falsche erste Schritt, wenn das Protokoll nur meldet, dass eine Bindung abgelehnt wurde. Bei einem Verzeichnis-Plugin gibt es mehr als eine Bindung in einer einzigen Anmeldung, und die Ablehnung kann zum Dienstkonto gehören, das die Suche ausführt. Die Zugangsdaten des Benutzers in diesem Fall zurückzusetzen ändert nichts. Es sperrt außerdem jemanden aus, der nie das Problem war.

Eine Anmeldung, mehrere Bindungen

Eine Konfiguration mit einem eigenen Verzeichniskonto führt normalerweise vier Schritte in fester Reihenfolge aus, und jeder davon kann die Anmeldung beenden.

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

Das Plugin baut seine Verbindung zur Benutzerauthentifizierung über denselben Helfer auf, der die erste Verbindung abwickelt, sodass dieser Helfer beim Verbinden, bei der TLS-Aushandlung oder beim Binden als Dienstkonto scheitern kann. Die übergeordnete Meldung über ein Passwort entsteht später und enthält nicht, welche Identität beteiligt war. Deshalb kann der Fehlertext allein nicht sagen, ob der Benutzer oder das Dienstkonto abgelehnt wurde.

Lesen Sie die Zeilen vor der Meldung und notieren Sie den Moment des Fehlers. Eine Ablehnung beim Start, bevor ein Benutzer eintrifft, deutet auf das konfigurierte Konto oder den Endpunkt hin. Eine Ablehnung, die nur für eine Person nach einer erfolgreichen Suche auftritt, deutet auf deren Eintrag oder Kontostatus hin.

Verbinden Sie den Fehler mit einer Identität

Die praktische Regel lautet, drei Dinge gemeinsam festzuhalten: wann es fehlschlug, welcher Vorgang lief und welche Identität vorgelegt wurde. Ohne diese Dreierangabe sehen zwei sehr verschiedene Störungen in einem Protokoll, das nur den letzten Satz behält, identisch aus.

Wenn das konfigurierte Konto scheitert, prüfen Sie dieses Konto und die Verbindung, bevor Sie irgendeinen Benutzereintrag anfassen. Wenn die Benutzerbindung nach einer erfolgreichen Suche scheitert, prüfen Sie den Eintrag, den die Suche zurückgab, statt den, von dem Sie annahmen, dass sie ihn zurückgeben würde. Die beiden Wege teilen eine Meldung und sonst nichts. Notieren Sie, welchen Sie ausgeschlossen haben, denn die nächste Person fragt genau danach.

Der distinguished Name sind Daten, keine Vermutung

Eine Namenskomponente zu ändern, weil sie unbekannt aussieht, ist ein häufiger Weg, eine funktionierende Konfiguration zu zerstören. Der Standardort für Benutzerobjekte in Active Directory ist ein Container namens Users, und ein Container ist nicht dieselbe Art Objekt wie eine Organisationseinheit mit ähnlichem Namen.

Fragen Sie den Verzeichnisadministrator nach dem tatsächlichen distinguished Name des Kontos, oder lesen Sie ihn aus dem Objekt selbst. Beide der folgenden Beispiele können in ihrem eigenen Verzeichnis richtig sein, weshalb keines aus dem Gedächtnis eingetippt werden sollte.

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

Ein Verschieben oder Umbenennen ändert diesen Wert, während Konto und Passwort gültig bleiben, sodass eine Konfiguration, die im letzten Quartal funktionierte, in diesem scheitern kann, ohne dass jemand Zugangsdaten angefasst hat. Vergleichen Sie die konfigurierte Zeichenfolge nach jeder Umorganisation mit dem aktuellen Attribut des Verzeichnisses. Tun Sie das auch nach einer stillen Migration, nicht nur nach einer gemeldeten Störung.

Ein Suchbereich ist kein Dienstkonto

Die Bind-Identität und der Suchbereich beantworten verschiedene Fragen: als wer sich das Plugin authentifiziert und wo es nach Personen sucht. Eine erfolgreiche Bindung ohne passenden Benutzer ist ein Problem von Bereich, Filter oder Leserecht, und den distinguished Name des Kontos durch die Benutzerbasis zu ersetzen ändert daran nichts.

Bestätigen Sie, dass der Dienst die von Ihnen bearbeitete Konfiguration geladen hat und dass sein Endpunkt, TLS-Vertrauen und Authentifizierungsmodus zu einem funktionierenden administrativen Test passen. Eine manuelle Abfrage mit einem anderen Konto oder gegen einen anderen Domänencontroller ist kein gleichwertiges Experiment.

Prüfen Sie das gespeicherte Geheimnis und prüfen Sie, ob das Konto aktiviert, abgelaufen oder gesperrt ist, ohne das Passwort irgendwo auszugeben. Ein Ablauf wird leicht übersehen, weil das Konto bis zu dem Tag weiterarbeitet, an dem es das nicht mehr tut. Eine von einem unabhängigen Dienst geerbte Sperre ist genauso still. Keiner der beiden Zustände erzeugt eine Meldung, die das Dienstkonto nennt.

Gruppenregeln kommen zuletzt

Die Autorisierung läuft, nachdem die Bindungen erfolgreich waren, sodass eine Gruppenprüfung nicht die Ursache einer fehlgeschlagenen Bindung sein kann und das Entfernen der Gruppenanforderung sie nicht reparieren kann. Wenn die Anmeldung jetzt die Gruppenphase erreicht, ist das verbleibende Problem die Mitgliedschaft, nicht die Zugangsdaten.

Dem Dienstkonto weitreichende Verzeichnisrechte zu geben, damit der Fehler verschwindet, ändert die Zugriffsrichtlinie der gesamten Bereitstellung. Behandeln Sie das als Sicherheitsentscheidung mit eigener Prüfung, nicht als Korrektur einer Meldung, die Sie noch keiner Identität zugeordnet haben.