Failed to bind with current password "data 52e"

[AugmentaCyber-Developers]

Affected component: vault-plugin-secrets-openldap (Vault LDAP secrets engine, mount type ldap) running in Vault server v3.0.0-beta1 (running_plugin_version: v3.0.0+builtin.vault).
Symptom: Any operation that triggers an LDAP simple bind as a managed user account - including ldap/static-role/ create, ldap/rotate-role/, and ldap/library/ create - fails immediately with:
failed to bind with current password: 1 error occurred:

• LDAP Result Code 49 "Invalid Credentials": 80090308: LdapErr: DSID-0C090527, comment: AcceptSecurityContext error, data 52e, v4563 Engine config: schema=ad, against an AD 2019/2022 domain controller over LDAPS (port 636), validated CA chain, working bind account with delegated Reset Password + write pwdLastSet on the target OU. Confirmed not the cause (all verified in the same session):

• AD password - direct ldapwhoami simple bind with the same DN+password succeeds (DN, UPN, and DOMAIN\sam forms all bind cleanly).

• Vault auth method (auth/ldap) login with the same user+password succeeds and returns correct group-mapped policies.

  • Bind-account credentials - ldapwhoami as the bind account succeeds; engine config write succeeds. - DN format - bind works with explicit dn=CN=… and with username=… (Vault-resolved). - Password handling - passing as password='literal' and password=@/file produce identical failure. - Audit log proves Vault receives the password (HMAC of supplied value matches HMAC of the request data field) - so it is not being dropped at the API layer.

• Both skip_static_role_import_rotation=true (config-level) and skip_import_rotation=true (role-level) only delay the failure to the first scheduled or manual rotation.

• Same bug appears on the library/check-out code path, ruling out a static-role-specific defect. Side observation in server logs (it may be a related symptom): [ERROR] secrets.ldap.: expected role to have WAL, but WAL not found in storage: role= WAL ID= …appearing on the periodic rotation loop after a failed create.

[dosubot]

I traced the "failed to bind with current password" error through the plugin source code and can explain what's happening.

The error originates from the service/bind account, not the managed user account. The bind() function in client/client.go uses the engine's configured BindDN + BindPassword (i.e. the service account from your ldap/config write) to authenticate the LDAP connection before performing any password modification operation [1]. It does not attempt a simple bind as the managed user account.

The relevant code path:

1. setStaticAccountPassword() → UpdateDNPassword() / UpdateUserPassword() → UpdateEntry() → bind(cfg, conn) [2]
2. bind() attempts conn.Bind(bindUser, cfg.BindPassword). If that fails, it checks whether to try cfg.LastBindPassword (only valid within 10 minutes of a root credential rotation). If both fail, it returns "failed to bind with current password" [1].

Why this fails when ldapwhoami with the bind account succeeds: The discrepancy likely comes from how bindUser is constructed in the plugin vs what you tested manually:

• If upndomain is set in your engine config, the plugin constructs bindUser as <BindDN>@<UPNDomain> (with LDAP value escaping applied) [3].
• If upndomain is not set, it uses the raw BindDN value.

With schema=ad, check whether your engine config has upndomain set. If so, the plugin will attempt to bind as e.g. svc-vault@contoso.com rather than the full DN CN=svc-vault,OU=Service Accounts,DC=contoso,DC=com. The LDAP escaping via ldaputil.EscapeLDAPValue() on the BindDN could also mangle the value unexpectedly if the DN contains special characters.

Regarding the WAL error — the "expected role to have WAL, but WAL not found in storage" message is logged when the rotation queue references a WAL ID for a role but that WAL entry no longer exists in storage [4]. This happens after a failed role creation attempt that partially cleaned up its WAL. It's a non-fatal condition — the plugin generates a new WAL and continues.

Suggestions to debug further:

1. Check upndomain in your engine config (vault read ldap/config). If set, try clearing it and using a full DN for binddn instead.
2. Enable TRACE-level logging on the plugin to see the exact bindUser string being constructed.
3. Check for special characters in your binddn value — the EscapeLDAPValue() call escapes characters like *, (, ), \, and null bytes, which could break the bind if your DN contains any of these legitimately.
4. If using a separate LDAP URL for rotation (added in recent versions), verify the rotation URL is correctly configured.

The library/check-out path exhibits the same bug because it uses the same UpdateUserPassword() → bind() code path [5].

This appears to be a configuration-level issue with how the plugin constructs the bind identity, rather than a code bug per se. Would you be willing to share your redacted engine config output (vault read ldap/config) so we can pinpoint which field is causing the mismatch?

Written by @dosu, approved by heatherezell

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.