LDAP error 49: invalid credentials" when binding from the helpdesk tool

TL;DR

Error 49 means the bind DN or password was rejected; the subcode tells you why. Check the account state for the bind DN, verify the password, and watch for expired passwords or must-change-at-next-logon flags, which also surface as 49.

The query

"LDAP error 49: invalid credentials" when binding from the helpdesk tool

Use this when

• an LDAP bind returns error code 49
• a helpdesk tool suddenly cannot authenticate to AD
• the same credentials work interactively but fail over LDAP

Not for

• LDAP connection timeouts or server-down errors
• TLS certificate trust failures on LDAPS
• search-result issues after a successful bind

Steps

1. Read the full error data field for the subcode: 52e means bad password, 533 disabled, 701 expired, 773 must change password, 775 locked. Expected output: you have a specific subcode, not just 49.
2. Verify the bind DN format the tool sends, usually a full DN or user principal name, and that the account exists. Expected output: the DN resolves to the intended account.
3. Test the bind manually with ldapsearch against YOUR_HOST using the same DN and password. Expected output: either a successful bind or the same 49, isolating the tool from the credentials.
4. Fix what the subcode says: reset an expired password, clear the must-change flag via an admin reset, or unlock the account. Expected output: the manual bind succeeds.
5. Retry from the helpdesk tool and confirm normal operation. Expected output: the tool authenticates and performs lookups.

Applies to

Active Directory LDAP/LDAPS, any LDAP client or helpdesk tool, ldapsearch on Linux/macOS, current Windows Server versions.

Variant phrasings

Error 49 with data 52e after a password change

The tool cached the old password; update its stored bind credential.

Error 49 only over LDAPS

Bind credentials fine; the failure is TLS trust. Check the DC certificate chain on the client.

Why it happens

AD returns 49 for any credential rejection, and tools often hide the data subcode. Expired passwords and must-change flags reject the bind even though the password is technically correct.

Edge cases

• Service accounts with password-never-expires can still lock out and produce 775.
• Special characters in passwords can break tools that do not escape the bind DN properly.
• If the DC recently failed over, confirm the tool points at a healthy DC, not a stale IP.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-KFJOy-Wvm2EBY-lJirCqg