## 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
```text
"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