Fix LDAP Invalid Credentials Error 49 in 389 Directory Server

LDAP result code 49 means 389 Directory Server rejected the credentials presented during a bind. Clients usually print:

ldap_bind: Invalid credentials (49)

That message appears in ldapwhoami, ldapsearch, application logs, SSSD, Apache mod_authnz_ldap, and replication status output. Error 49 is an authentication failure. Authorization and ACIs apply only after a successful bind, so changing ACIs will not fix a bind that never authenticates.

RFC 4511 defines result code 49 as invalidCredentials, 19 as constraintViolation, and 53 as unwillingToPerform. Always read the diagnostic message alongside the number. In 389 DS, 49 usually identifies invalid credentials, 19 commonly identifies active password-policy lockout or inactivity constraints, and 53 can identify an operation blocked until the user changes a temporary password or a manually inactivated account is restored.

Use the cause table below to jump to the fix that matches your situation. Password-policy design, lockout thresholds, replication agreement management, and client integration stay in the linked chapters.

Examples use instance ldap1 on ldap1.example.com:389 with suffix dc=example,dc=com and user uid=user1,ou=people,dc=example,dc=com. Create a disposable test user through manage users and groups before lockout or password-reset exercises, or substitute any existing lab account whose current password you know. Replication examples use agreement ldap1-to-consumer1 and destination consumer1.example.com:1389 from the shared replication lab.

Causes and fixes at a glance

The access log at /var/log/dirsrv/slapd-INSTANCE/access records bind requests and bind results as operation pairs identified by the same connection and operation numbers. A failed bind pair looks like this:

conn=19 op=0 BIND dn="uid=user1,ou=people,dc=example,dc=com" method=128 version=3
conn=19 op=0 RESULT err=49 tag=97 nentries=0 - Invalid credentials

Search historical failures with the bind line included:

sudo grep -B1 'RESULT err=49' /var/log/dirsrv/slapd-ldap1/access | tail -10

The -B1 flag includes the BIND request immediately before each RESULT err=49 line so you can compare the received DN with the error.

Fix wrong password

An incorrect password or nonexistent bind DN normally returns error 49. Confirm the DN before you reset credentials, because Directory Server returns the same code for several authentication failures.

Reset the password as an administrator with dsidm:

dsidm -y /root/dm.pw ldap1 account reset_password "uid=user1,ou=people,dc=example,dc=com"

Enter a new password twice when prompted. Sample output:

reset password for uid=user1,ou=people,dc=example,dc=com

The value must satisfy the effective password policy on the instance.

Confirm the bind with ldapwhoami:

ldapwhoami -x -H ldap://ldap1.example.com:389 -D "uid=user1,ou=people,dc=example,dc=com" -W

A successful bind prints the entry DN:

dn: uid=user1,ou=people,dc=example,dc=com

If automation still fails after a reset, check the secret file. OpenLDAP clients read the entire file contents with -y, including any unintended trailing newline:

read -rsp 'LDAP password: ' LDAP_PASSWORD
printf '%s' "$LDAP_PASSWORD" > /root/user1.pw
unset LDAP_PASSWORD
chmod 600 /root/user1.pw

printf '%s' avoids the newline that echo commonly appends. Test the file:

ldapwhoami -x -H ldap://ldap1.example.com:389 -D "uid=user1,ou=people,dc=example,dc=com" -y /root/user1.pw

Apply only the fix supported by your bind test and access-log evidence. Resetting passwords blindly can hide the original cause and leave stale application credentials unchanged.

Fix incorrect bind DN

Applications often send a username or an outdated DN while the directory entry lives at a different distinguished name. LDAP does not compare DN strings through simple character-for-character equality; DN matching uses distinguishedNameMatch and the naming-attribute matching rules. Search as an administrator to read the exact DN. Directory queries use the ldapsearch command:

ldapsearch -LLL -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -y /root/dm.pw -b "dc=example,dc=com" "(uid=user1)" uid

Sample output:

dn: uid=user1,ou=people,dc=example,dc=com
uid: user1

The search should return exactly one entry. No result means the DN is wrong or the entry is absent; multiple results mean the application's username search is ambiguous.

Clients frequently confuse these values:

Typical bind DN mistakes:

• Wrong organizational unit or suffix, such as using ou=Users when the entry is under ou=People, or using the wrong dc= suffix. A case-only difference is normally normalized; the container hierarchy and attribute values must identify the real entry.
• Using cn= when the entry RDN is uid=
• Entry renamed or moved without updating clients
• Using the search base as the bind DN
• Supplying only a username where the client must send a full DN

Copy the dn: line from the search result into every client, service account, and agreement that binds as that user. The access log BIND dn="..." line shows the DN the server received when a client still sends the wrong value.

Fix missing userPassword

A user entry can exist without a usable password attribute. Creation with dsidm user create does not always set userPassword; administrators assign it separately.

Check whether userPassword is present:

ldapsearch -LLL -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -y /root/dm.pw -b "uid=user1,ou=people,dc=example,dc=com" -s base userPassword

When the attribute is absent, the search returns only the DN line or omits userPassword. Assign one with:

dsidm -y /root/dm.pw ldap1 account reset_password "uid=user1,ou=people,dc=example,dc=com"

The reset creates or replaces userPassword and lets the user bind on the next attempt. The manage users and groups chapter covers the full create-and-password workflow.

Fix expired password

An expired password with no remaining grace logins returns error 49. A grace login may still permit the bind, while a mandatory-change password can allow the bind and reject later operations with error 53. For that pattern, follow fix LDAP unwilling to perform error 53.

Request policy details on bind with -e ppolicy:

ldapsearch -LLL -x -H ldap://ldap1.example.com:389 -D "uid=user1,ou=people,dc=example,dc=com" -W -b "" -s base -e ppolicy namingContexts

On a healthy account with no expiration warning, the response may show only that the bind succeeded:

dn:
namingContexts: dc=example,dc=com

Password expiration and grace-login information appears only when the server returns a password-policy response control; a healthy account may produce no additional policy text.

When warnings or grace counts appear in the response, the account needs a password change rather than another retry with the old secret. An administrator can reset the password:

dsidm -y /root/dm.pw ldap1 account reset_password "uid=user1,ou=people,dc=example,dc=com"

Users who must change password at next login should complete the change over LDAPS or StartTLS per your deployment rules. Full expiration and grace-login configuration lives in the password policy chapter.

Fix locked or inactive account

Password or account-policy state behaves differently from a simple wrong password:

Check manual activation state on the server:

dsidm -y /root/dm.pw ldap1 account entry-status "uid=user1,ou=people,dc=example,dc=com"

Sample output for a healthy account:

Entry DN: uid=user1,ou=people,dc=example,dc=com
Entry State: activated

Entry State: activated proves the entry is not manually disabled through the account-state mechanisms checked by dsidm. It does not prove that failed-password retry counters are clear. When password-policy lockout is suspected, inspect passwordRetryCount, retryCountResetTime, and accountUnlockTime as documented in account lockout.

When Entry State is not activated, the entry was manually locked or inactivated. Unlock direct inactivation:

dsidm -y /root/dm.pw ldap1 account unlock "uid=user1,ou=people,dc=example,dc=com"

Sample output:

Entry uid=user1,ou=people,dc=example,dc=com is unlocked

This command clears direct account inactivation such as nsAccountLock. It does not necessarily clear password-policy retry lockout. Follow the account lockout chapter when passwordRetryCount or accountUnlockTime is present. Manual inactivation outside password policy is covered in disable and inactivate user accounts.

Confirm the password is correct before you retry repeatedly during troubleshooting. Each wrong attempt can advance lockout counters on a production account.

Fix wrong LDAP server or replica

Error 49 for every user often means the client points at the wrong host, port, or protocol, or at a replica that does not yet hold the bind entry or its latest password.

Verify the URI, port, and transport match the instance you intend:

Search for the user on the same endpoint the client uses:

ldapsearch -LLL -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -y /root/dm.pw -b "dc=example,dc=com" "(uid=user1)" uid

When the entry is missing on one replica but present on another, replication may be behind or the agreement may not cover that suffix. Test each server directly with the same bind DN before you change passwords.

Fix application credentials

When ldapwhoami succeeds with the DN and password the application should use, the directory bind is healthy and the remaining problem is in the application configuration.

Inspect these settings:

• LDAP URI and TLS mode (ldap://, ldaps://, StartTLS)
• Bind DN versus username-only login mapped locally
• Stored password or secret file, including trailing newline or whitespace
• Shell or config escaping that alters the secret
• Whether the service was restarted after a password change
• Whether the application connects to a different host or port than your manual test

Update the stored secret, restart the service, and retest login. Apache LDAP authentication and SSSD LDAP authentication cover client-specific configuration when the directory side is already correct.

Fix Directory Manager authentication

When you know the current Directory Manager password, change it online with the command below. When the password is completely lost, follow reset the Directory Manager password for the full online and offline recovery workflow. Do not use dscreate or rebuild the instance solely to recover this password.

The Directory Manager bind DN is fixed and does not include the suffix:

cn=Directory Manager

A wrong password returns error 49:

ldap_bind: Invalid credentials (49)

When you know the current Directory Manager password, change it online:

dsconf -D "cn=Directory Manager" -y /root/dm.pw ldap1 directory_manager password_change

Do not use Directory Manager as an application bind account in production. Create a dedicated service entry with only the read and compare rights the application needs.

Fix replication authentication

Replication sessions bind to the consumer with the identity stored in the agreement. When that credential drifts, status output and the errors log report Invalid credentials (49). Real incidents also surface error 49 when the replication-manager password is changed but the sending agreement retains the old stored credential.

Inspect the agreement on its supplier:

dsconf -y /root/dm.pw ldap1 repl-agmt get --suffix "dc=example,dc=com" ldap1-to-consumer1

Record at least:

• nsDS5ReplicaHost
• nsDS5ReplicaPort
• nsDS5ReplicaBindDN
• nsDS5ReplicaBindMethod
• nsDS5ReplicaTransportInfo

Sample output (trimmed):

nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: simple
nsDS5ReplicaHost: consumer1.example.com
nsDS5ReplicaPort: 1389
nsDS5ReplicaTransportInfo: LDAP

When the agreement uses a simple bind, test the exact agreement identity against the destination:

ldapwhoami -x -H ldap://consumer1.example.com:1389 -D "cn=replication manager,cn=config" -y /root/consumer1-repl.pw

For StartTLS, add -ZZ. For LDAPS, use the configured ldaps:// URI and port. A successful bind returns:

dn: cn=replication manager,cn=config

Update the stored credential when it is stale. A password file passed to dsconf is an input used to update the agreement; the agreement subsequently uses the credential stored in its configuration:

dsconf -y /root/dm.pw ldap1 repl-agmt set --suffix "dc=example,dc=com" --bind-dn "cn=replication manager,cn=config" --bind-passwd-file /root/consumer1-repl.pw ldap1-to-consumer1

Sample output:

Successfully updated agreement

Trigger and verify an incremental session:

dsconf -y /root/dm.pw ldap1 repl-agmt poke --suffix "dc=example,dc=com" ldap1-to-consumer1

Sample output:

Agreement has been poked

Then check agreement status with dsconf repl-agmt status. Agreement creation, credential rotation, and status interpretation are in manage replication agreements. Broader replication diagnosis, including TLS and generation-ID problems, is in replication troubleshooting.

References

• RFC 4511 — LDAP result codes
• ldapwhoami(1)
• ldapsearch(1)
• Red Hat Directory Server — troubleshooting binds and authentication
• 389 Directory Server documentation