That LDAP password error may not be the user's password at all
A bind failure can come from the service account or the search scope, not from the user. Separate the binds before resetting anybody's password.
Resetting a user's password is the wrong first move when the log only says a bind was refused. With a directory plugin there is more than one bind in a single login, and the refusal can belong to the service account that performs the search. Resetting the user's credentials in that case changes nothing. It also locks out somebody who was never the problem.
One login, several binds
A configuration with a dedicated directory account typically performs four steps in order, and any of them can end the 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 groupsThe plugin builds its user-authentication connection through the same helper that handles the first connection, so that helper can fail while connecting, while negotiating TLS, or while binding as the service account. The high-level message about a password is generated later, and it does not carry which identity was involved. That is why the error text alone cannot tell you whether the user or the service account was refused.
Read the lines before the message, and note the moment the failure happened. A refusal at start-up, before any user arrives, points at the configured account or the endpoint. A refusal that appears only for one person, after a successful search, points at that person's entry or account state.
Pair the error with an identity
The practical rule is to record three things together: when it failed, which operation was running, and which identity was presented. Without that triple, two very different faults look identical in a log that only keeps the final sentence.
| What the log shows | Identity likely refused | First thing to check |
|---|---|---|
| Failure at start-up, no user yet | Service account | DN, password, expiry, lockout |
| Search returns nothing | None, the search scope is wrong | Search base and filter |
| Failure only for one user | That user's entry | Entry state, bind DN, group rules |
If the configured account fails, inspect that account and the connection before touching any user record. If the user bind fails after a successful search, examine the entry the search returned rather than the one you assumed it would return. The two paths share a message and nothing else. Write down which one you ruled out, because the next person will ask exactly that.
The distinguished name is data, not a guess
Changing a name component because it looks unfamiliar is a common way to break a working configuration. The default location for user objects in Active Directory is a container named Users, and a container is not the same kind of object as an organizational unit with a similar name.
Ask the directory administrator for the account's actual distinguished name, or read it from the object itself. Both of the following can be correct in their own directory, which is why neither should be typed from memory.
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=exampleA move or a rename changes that value while the account and password stay valid, so a configuration that worked last quarter can fail this one without anyone touching a credential. Compare the configured string with the directory's current attribute after any reorganisation. Do it after a quiet migration too, not only after a reported outage.
A search base is not a service account
The bind identity and the search base answer different questions: who the plugin authenticates as, and where it looks for people. A successful bind followed by no matching user is a scope, filter or read-permission problem, and replacing the account's distinguished name with the users' base changes nothing about it.
Confirm that the service loaded the configuration you edited, and that its endpoint, TLS trust and authentication mode match a working administrative test. A manual lookup with a different account, or against a different domain controller, is not an equivalent experiment.
Check the stored secret, and check whether the account is enabled, expired or locked out, without printing the password anywhere. Expiry is easy to miss because the account keeps working until the day it does not. A lockout inherited from an unrelated service is just as quiet. Neither condition produces a message that names the service account.
Group rules come last
Authorization runs after the binds succeed, so a group check cannot be the cause of a bind failure, and removing the group requirement cannot repair one. If the login now reaches the group stage, the remaining problem is membership, not credentials.
Granting the service account broad directory rights to make the error disappear changes the access policy of the whole deployment. Treat that as a security decision with its own review, not as a fix for a message you have not yet attributed to an identity.