Fix OpenLDAP Invalid Credentials Error 49

OpenLDAP returns Error 49 when a bind identity cannot be authenticated.

Common command-line output includes:

ldap_bind: Invalid credentials (49)

Applications and SSSD logs may show variations such as:

ldap_simple_bind_s failed: Invalid credentials

pam_sss(sshd:auth): authentication failure

Authentication failure

OpenLDAP uses distinct result codes for authentication and authorization:

If authentication succeeds but the operation is denied, follow Fix OpenLDAP Insufficient Access Error 50.

Error 49 usually points to:

• An incorrect bind DN
• An incorrect password
• A bind DN that does not exist
• A missing or unusable userPassword
• An ACL that prevents authentication against userPassword
• A locked or expired account
• An invalid SSSD service-bind password

SSSD and PAM can also report a generic authentication failure when no LDAP bind reaches slapd. In that case, the failure is occurring in the client authentication path rather than being an OpenLDAP Error 49. The SSSD sections later in this guide show how to distinguish the two cases.

This guide first tests the password directly against OpenLDAP and then follows the request through SSSD, PAM, and SSH. It does not replace OpenLDAP client authentication with SSSD for installation, Manage OpenLDAP users and groups for routine password commands, or OpenLDAP password policy with ppolicy for policy design.

The procedure applies to OpenLDAP 2.6 and SSSD across the RHEL family:

• Red Hat Enterprise Linux
• Rocky Linux
• AlmaLinux
• Oracle Linux
• CentOS Stream

Tested on: Rocky Linux 10.2 with openldap-servers 2.6.10-1.el10_2 from EPEL 10.2 and the RHEL-family SSSD packages.

The lab uses:

Complete these lessons first:

• Install and Configure OpenLDAP on the RHEL Family
• Secure OpenLDAP with TLS
• OpenLDAP client authentication with SSSD
• Manage OpenLDAP users and groups
• OpenLDAP ACL configuration
• OpenLDAP password policy with ppolicy

Use this table to open the matching fix.

Diagnose Error 49 Before Changing Passwords

Separate the authentication path into layers:

Use this diagnostic sequence:

Verify TLS first

A TLS or hostname error is not Error 49. Confirm certificate trust before troubleshooting passwords.

openssl s_client -starttls ldap -connect ldap-server.example.com:389 -servername ldap-server.example.com -CAfile /etc/openldap/certs/example-ldap-ca.crt -verify_return_error </dev/null

Sample output:

Verify return code: 0 (ok)

Search for the user without testing the password

Use an administrator or permitted service account to confirm the account exists and copy the exact DN.

ldapsearch -x -ZZ -H ldap://ldap-server.example.com -D "cn=admin,dc=example,dc=com" -W -b "ou=people,dc=example,dc=com" -LLL "(uid=jdoe)" dn uid uidNumber gidNumber

Sample output:

dn: uid=jdoe,ou=people,dc=example,dc=com
uid: jdoe
uidNumber: 10001
gidNumber: 10001

Test the password directly

Use the complete DN returned by the search. Password binds are easiest to confirm with ldapwhoami before you trace SSSD or PAM.

ldapwhoami -x -ZZ -H ldap://ldap-server.example.com -D "uid=jdoe,ou=people,dc=example,dc=com" -W

Interpret the result:

When the password is wrong, OpenLDAP returns:

ldap_bind: Invalid credentials (49)

When the password is correct, ldapwhoami returns the authenticated DN:

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

Fix 1: Verify the Bind DN and Password

Use the complete LDAP distinguished name:

uid=jdoe,ou=people,dc=example,dc=com

Do not assume these are equivalent bind identities:

jdoe
uid=jdoe
[email protected]
uid=jdoe,ou=people,dc=example,dc=com

OpenLDAP simple bind normally expects the complete DN unless an overlay or application first searches for the DN.

Search for the actual account:

ldapsearch -x -ZZ -H ldap://ldap-server.example.com -D "cn=admin,dc=example,dc=com" -W -b "dc=example,dc=com" -LLL "(uid=jdoe)" dn

Check for:

• Incorrect OU
• Incorrect suffix
• Misspelled uid
• Account renamed from an old UID
• Duplicate usernames under multiple subtrees
• Client using an old cached DN
• Special DN characters that require escaping

Use -W rather than placing the password in a command:

ldapwhoami -x -ZZ -H ldap://ldap-server.example.com -D "uid=jdoe,ou=people,dc=example,dc=com" -W

Avoid -w PlainTextPassword because shell expansion, command history, process listings, and screenshots can expose or alter the password.

Fix 2: Verify the User Entry and Password

If the user entry exists but direct bind fails, verify whether it contains userPassword.

Run this only as a protected administrator:

ldapsearch -x -ZZ -H ldap://ldap-server.example.com -D "cn=admin,dc=example,dc=com" -W -b "uid=jdoe,ou=people,dc=example,dc=com" -s base -LLL userPassword

Do not publish the returned password hash.

Possible cases:

Reset the user password:

ldappasswd -x -ZZ -H ldap://ldap-server.example.com -D "cn=admin,dc=example,dc=com" -W -S "uid=jdoe,ou=people,dc=example,dc=com"

The command prompts for the new password and confirmation.

Immediately verify it directly:

ldapwhoami -x -ZZ -H ldap://ldap-server.example.com -D "uid=jdoe,ou=people,dc=example,dc=com" -W

Do not diagnose SSSD until this direct bind succeeds.

Fix 3: Reset the OpenLDAP Root DN Password

Use this section when the configured database administrator returns Error 49.

Discover the MDB configuration:

MDB_DN=$(sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(&(objectClass=olcMdbConfig)(olcSuffix=dc=example,dc=com))' dn | awk '/^dn: / {sub(/^dn: /, ""); print; exit}')

Stop if discovery fails. An empty $MDB_DN would query the root DSE instead of the MDB configuration entry:

if [[ -z "$MDB_DN" ]]; then
    echo "No MDB database was found for dc=example,dc=com" >&2
    exit 1
fi

printf 'MDB database DN: %s\n' "$MDB_DN"

Verify the suffix and root DN:

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b "$MDB_DN" -s base olcSuffix olcRootDN

Sample output:

dn: olcDatabase={2}mdb,cn=config
olcSuffix: dc=example,dc=com
olcRootDN: cn=admin,dc=example,dc=com

Use the exact returned olcRootDN in later bind tests. OpenLDAP treats olcRootDN and olcRootPW as the database superuser identity and credentials, and that identity bypasses normal access restrictions on its database.

Generate a new password hash:

slappasswd

Create a private reset-root-password.ldif file:

umask 077

cat > reset-root-password.ldif <<EOF
dn: ${MDB_DN}
changetype: modify
replace: olcRootPW
olcRootPW: REPLACE_WITH_GENERATED_HASH
EOF

Replace REPLACE_WITH_GENERATED_HASH with the hash from slappasswd, then apply through cn=config:

sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f reset-root-password.ldif

Test the root DN:

ldapwhoami -x -ZZ -H ldap://ldap-server.example.com -D "cn=admin,dc=example,dc=com" -W

Sample output when the password is correct:

dn:cn=admin,dc=example,dc=com

Remove the LDIF after a successful verification:

rm -f reset-root-password.ldif

Do not manually edit /etc/openldap/slapd.d/.

Fix 4: Correct the userPassword Authentication ACL

A password bind requires authentication access to userPassword.

Recommended rule:

to attrs=userPassword
    by self =xw
    by anonymous auth
    by * none

Each simple bind begins without an authenticated LDAP identity. OpenLDAP must compare the supplied password with userPassword. General read access to password hashes is neither required nor safe. When authentication access is denied, OpenLDAP can still return Error 49.

Discover the MDB database DN:

MDB_DN=$(sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(&(objectClass=olcMdbConfig)(olcSuffix=dc=example,dc=com))' dn | awk '/^dn: / {sub(/^dn: /, ""); print; exit}')

Validate the result before querying olcAccess:

if [[ -z "$MDB_DN" ]]; then
    echo "No MDB database was found for dc=example,dc=com" >&2
    exit 1
fi

printf 'MDB database DN: %s\n' "$MDB_DN"

Inspect the current ACL order:

sudo ldapsearch -Q -LLL -o ldif-wrap=no -Y EXTERNAL -H ldapi:/// -b "$MDB_DN" -s base olcAccess

Ensure the userPassword rule appears before broad rules such as to *.

Bad order:

{0}to *
    by users read
    by * none

{1}to attrs=userPassword
    by anonymous auth
    by self write
    by * none

Correct order:

{0}to attrs=userPassword
    by self =xw
    by anonymous auth
    by * none

{1}to *
    by users read
    by * none

Use OpenLDAP ACL configuration with practical examples for safe indexed replacement and rollback.

Fix 5: Check ppolicy Lockout and Expiration

When ppolicy is enabled, Error 49 can hide:

• Temporary account lockout
• Permanent administrative lock
• Password expiration
• Exhausted grace logins
• Password reset requiring a change
• Password validity start or end time

Test authentication while requesting the password-policy response control:

ldapwhoami -x -ZZ -e ppolicy -H ldap://ldap-server.example.com -D "uid=jdoe,ou=people,dc=example,dc=com" -W

OpenLDAP returns the password-policy control only when the client requests it. That can expose account lockout or forced-change details that would otherwise appear only as Invalid credentials.

Inspect policy state using a permitted password administrator:

ldapsearch -x -ZZ -H ldap://ldap-server.example.com -D "uid=pwdadmin,ou=system,dc=example,dc=com" -W -b "uid=jdoe,ou=people,dc=example,dc=com" -s base -LLL pwdChangedTime pwdFailureTime pwdAccountLockedTime pwdGraceUseTime pwdReset pwdStartTime pwdEndTime

Sample output when the account is locked or requires a password change:

dn: uid=jdoe,ou=people,dc=example,dc=com
pwdReset: TRUE

When lockout is active, pwdAccountLockedTime may also be present.

Interpret:

Do not delete policy attributes without understanding the configured policy. Use OpenLDAP password policy with ppolicy for the tested unlock, expiry, and forced-change procedures.

Fix 6: Correct the SSSD LDAP Service Bind

SSSD can use a service identity to search for users and groups:

ldap_default_bind_dn = uid=sssd-reader,ou=service-accounts,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = REPLACE_WITH_SECRET

This token is stored in SSSD's root-only configuration. Do not copy the value into commands, logs or screenshots.

These credentials are for LDAP searches. They are not the end user's login password.

Test the exact service bind from ldap-client:

ldapwhoami -x -ZZ -H ldap://ldap-server.example.com -D "uid=sssd-reader,ou=service-accounts,dc=example,dc=com" -W

Test the search SSSD needs:

ldapsearch -x -ZZ -H ldap://ldap-server.example.com -D "uid=sssd-reader,ou=service-accounts,dc=example,dc=com" -W -b "ou=people,dc=example,dc=com" -LLL "(uid=jdoe)" uid uidNumber gidNumber homeDirectory loginShell

If this returns Error 49:

1. Verify the service-account DN.
2. Reset its password.
3. Update ldap_default_authtok.
4. Protect /etc/sssd/sssd.conf with root:root ownership and mode 0600.
5. Validate the configuration.
6. Restart SSSD.

sudo chown root:root /etc/sssd/sssd.conf

sudo chmod 600 /etc/sssd/sssd.conf

sudo sssctl config-check

Sample output:

Issues identified by validators: 0

sudo systemctl restart sssd

When anonymous LDAP searches are intentionally used, remove stale service-bind settings rather than retaining an invalid bind DN and token.

Fix 7: Troubleshoot SSSD User Authentication

First confirm identity lookup:

getent passwd jdoe

When SSSD has not resolved the user yet, the command returns no output.

Check UID and group membership:

id jdoe

Interpret:

Review the relevant domain configuration:

[domain/example.com]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldap://ldap-server.example.com
ldap_search_base = dc=example,dc=com

ldap_id_use_start_tls = true
ldap_tls_cacert = /etc/openldap/certs/example-ldap-ca.crt
ldap_tls_reqcert = hard

cache_credentials = true

Validate the configuration:

sudo sssctl config-check

Check SSSD state:

systemctl status sssd --no-pager

sudo sssctl domain-status example.com

Check the authentication and account phases separately:

sudo sssctl user-checks -a auth -s sshd jdoe

sudo sssctl user-checks -a acct -s sshd jdoe

The first focuses on authentication. The second checks whether the account is allowed to use the SSH PAM service.

Fix 8: Refresh SSSD Identity Cache and Confirm Online State

A password recently changed on the LDAP server may not behave as expected when:

• SSSD is offline
• The client cannot reach the server
• A cached password is still being used
• SSSD is contacting another replica
• Identity data contains an old DN after a rename
• The new password was never successfully authenticated online

Check domain status:

sudo sssctl domain-status example.com

Confirm the client reaches the intended LDAP server:

getent hosts ldap-server.example.com

Test the new password directly against that server:

ldapwhoami -x -ZZ -H ldap://ldap-server.example.com -D "uid=jdoe,ou=people,dc=example,dc=com" -W

sssctl cache-expire invalidates cached identity information. It does not change the LDAP password or repair a locked or expired account. Confirm that the SSSD domain is online before testing the new password; otherwise SSSD may use offline cached credentials instead of contacting OpenLDAP.

Expire only the affected user first:

sudo sssctl cache-expire -u jdoe

Restart SSSD when configuration or online state changed:

sudo systemctl restart sssd

Avoid immediately deleting /var/lib/sss/db/*. Removing SSSD databases also removes cached identities and cached credentials. Use that only for a diagnosed database-level problem while the LDAP server is reachable.

Fix 9: Troubleshoot PAM and SSH Login

When direct LDAP authentication succeeds, Error 49 is no longer the primary cause.

Verify the selected authselect profile:

authselect current

Sample output:

Profile ID: sssd

Confirm SSSD is selected and PAM files are valid:

sudo authselect check

Verify SSH uses PAM:

sudo sshd -T | grep -E 'usepam|passwordauthentication|kbdinteractiveauthentication'

Sample output:

usepam yes
passwordauthentication yes
kbdinteractiveauthentication no

Force a password-based SSH test so a key does not bypass password authentication:

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive [email protected]

Ensure at least one intended password or keyboard-interactive authentication method is enabled.

Check access authorization:

sudo sssctl user-checks -a acct -s sshd jdoe

Review:

• access_provider
• simple_allow_users
• simple_allow_groups
• simple_deny_users
• simple_deny_groups
• /etc/security/access.conf
• SSH AllowUsers, DenyUsers, AllowGroups, and DenyGroups
• User shell
• Account UID relative to UID_MIN

Do not interpret an SSSD account-access denial as an incorrect LDAP password.

Verify the Fix End to End

Use the tests in order.

1. Direct OpenLDAP bind

ldapwhoami -x -ZZ -H ldap://ldap-server.example.com -D "uid=jdoe,ou=people,dc=example,dc=com" -W

2. SSSD identity lookup

getent passwd jdoe

id jdoe

3. SSSD PAM checks

sudo sssctl user-checks -a auth -s sshd jdoe

sudo sssctl user-checks -a acct -s sshd jdoe

4. End-to-end password login

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive [email protected]

5. Expected negative test

Enter a deliberately incorrect password once and confirm:

• The direct bind fails with Error 49.
• The correct password still succeeds.
• The account is not unintentionally locked by repeated testing.

If one of the steps above still fails, use the log collection section next.

Collect Logs If Error 49 Remains

Use this section when the verification sequence above still fails and you need coordinated client and server evidence.

Start with temporary SSSD debug level 6:

sudo sssctl debug-level 6

Expire the affected user:

sudo sssctl cache-expire -u jdoe

Remove old SSSD troubleshooting logs:

sudo sssctl logs-remove

Record timestamps and reproduce one failure:

date

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password,keyboard-interactive [email protected]

date

Review client logs:

sudo journalctl -u sssd --since "10 minutes ago" --no-pager

sudo journalctl -u sshd --since "10 minutes ago" --no-pager

When /var/log/secure exists, search it for PAM and SSSD authentication messages:

if [[ -f /var/log/secure ]]; then
    sudo grep -iE 'pam_sss|authentication failure|invalid credentials|offline' /var/log/secure
fi

The SSSD component logs under /var/log/sssd/ and the system journal remain the primary troubleshooting sources.

Review SSSD component logs:

/var/log/sssd/sssd_example.com.log
/var/log/sssd/sssd_pam.log
/var/log/sssd/sssd_nss.log

On ldap-server, review the same time window:

sudo journalctl -u slapd --since "10 minutes ago" --no-pager

Interpret the log location:

Restore the debug level used before troubleshooting. When the host normally uses the default level, run:

sudo sssctl debug-level 2

Do not leave highly verbose authentication logging enabled indefinitely.

Troubleshoot Remaining Error 49 Cases

References

• OpenLDAP 2.6 Administrator's Guide — LDAP result codes
• OpenLDAP 2.6 Administrator's Guide — Access Control
• ldapwhoami(1)
• ldapsearch(1)
• ldappasswd(1)
• sssd-ldap(5) — upstream SSSD source
• sssd.conf(5)
• sssctl(8)
• Red Hat Enterprise Linux 10 — Troubleshooting SSSD

Summary

You learned how to diagnose OpenLDAP Error 49 by separating direct LDAP authentication from SSSD identity lookup, PAM authentication, access authorization, and SSH. You verified the exact bind DN, reset user and root DN passwords safely, corrected userPassword authentication ACLs, checked ppolicy lockout and expiration state, tested the SSSD service bind, distinguished identity lookup from password authentication, refreshed stale identity cache while confirming online state, validated PAM and SSH settings, repeated end-to-end verification, collected coordinated SSSD and slapd logs when failures remained, and worked through the remaining symptom table.