Reset the Directory Manager Password in 389 Directory Server

When cn=Directory Manager binds fail with invalid credentials, the recovery path depends on whether you still know the current password. When error 49 has causes beyond a wrong Directory Manager secret, start with fix invalid credentials.

Examples use instance ldap1 on ldap1.example.com with suffix dc=example,dc=com. Test against the individual server hostname rather than a load balancer when you verify a reset.

Determine whether to change or reset the password

Directory Manager bypasses suffix ACIs. Ordinary ACIs cannot grant or remove its privileges. If binds are blocked by time, host, or IP rules, fixing RootDN Access Control may be required even after a successful password reset.

Confirm the instance and Directory Manager DN

List local instances before you touch configuration. Instance names and offline stop/start operations use dsctl:

sudo dsctl -l

Sample output:

slapd-ldap1

The prefix before the instance name is slapd-. The short name ldap1 is what you pass to dsctl and dsconf.

Confirm the target instance is running:

sudo dsctl ldap1 status

Sample output:

Instance "ldap1" is running

Read the configured root DN from the instance configuration file:

sudo grep '^nsslapd-rootdn:' /etc/dirsrv/slapd-ldap1/dse.ldif

Sample output:

nsslapd-rootdn: cn=Directory Manager

The default root DN is cn=Directory Manager. Do not append the suffix.

Test the current credentials against the hostname you intend to manage:

export LDAPTLS_CACERT=/etc/dirsrv/slapd-ldap1/ca.crt
ldapwhoami -x -H ldaps://ldap1.example.com:636 -D "cn=Directory Manager" -y /root/dm.pw

Sample output:

dn: cn=directory manager

A failed bind with the wrong password returns ldap_bind: Invalid credentials (49). Confirm you are testing the intended instance before you reset anything. A trailing newline inside a -y password file becomes part of the password and can cause false error 49 results.

Change the password when the current password is known

Change Directory Manager over an encrypted connection. The dedicated directory_manager password_change subcommand prompts for the current password, the new password, and confirmation without placing the new value in the written command.

On the Directory Server host, point the client at the instance CA certificate:

export LDAPTLS_CACERT=/etc/dirsrv/slapd-ldap1/ca.crt
dsconf -D "cn=Directory Manager" ldaps://ldap1.example.com:636 directory_manager password_change

Sample prompts:

Enter password for cn=Directory Manager on ldaps://ldap1.example.com:636:
Enter new directory manager password :
CONFIRM - Enter new directory manager password :

Directory Server applies the change while the instance keeps running. Do not change this password over unencrypted ldap:// in production.

A lower-level alternative is to replace nsslapd-rootpw directly over LDAPS. Directory Server hashes a plain-text value using the scheme in nsslapd-rootpwstoragescheme:

export LDAPTLS_CACERT=/etc/dirsrv/slapd-ldap1/ca.crt
dsconf -D "cn=Directory Manager" -y /root/dm.pw ldaps://ldap1.example.com:636 config replace nsslapd-rootpw='NEW_DIRECTORY_MANAGER_PASSWORD'

Sample output:

Successfully replaced "nsslapd-rootpw"

Prefer directory_manager password_change when you want interactive prompts instead of placing the new password on the command line or in shell history. Verify the new password immediately before you close the administrative session that performed the change.

Reset a forgotten Directory Manager password offline

When the password is lost, generate a new hash with pwdhash, stop the instance, back up the stopped instance's dse.ldif, replace nsslapd-rootpw, and start the instance again.

Generate a hash with the instance storage scheme:

sudo pwdhash -D /etc/dirsrv/slapd-ldap1 'NEW_DIRECTORY_MANAGER_PASSWORD'

Sample output:

{PBKDF2-SHA512}100000$KH1n7CMFpAfGU+sqrUNWBnvEux7eSj8+$Ixjr2vaOOakfVxu3Ah9jZuRnTEHNl/wYX6YbkeFq8A1kYvJ3sKcxM9kLa93hhJsC0N+FpADKvgiVgkWq+UlXcg==

Stop the instance before you edit dse.ldif. Manual changes made while the server is running can be overwritten:

sudo dsctl ldap1 stop

Back up the stopped instance configuration:

sudo cp -a /etc/dirsrv/slapd-ldap1/dse.ldif /etc/dirsrv/slapd-ldap1/dse.ldif.before-dm-reset

Open /etc/dirsrv/slapd-ldap1/dse.ldif and replace only the nsslapd-rootpw value. Copy the complete pwdhash output without deleting or inserting characters. A single physical line is valid:

nsslapd-rootpw: {PBKDF2-SHA512}100000$COMPLETE_HASH_VALUE

LDIF permits optional line folding. If you intentionally fold the value across multiple physical lines, begin every continuation line with one leading space so the LDIF parser joins the value correctly:

nsslapd-rootpw: {PBKDF2-SHA512}100000$FIRST_PART
 SECOND_PART
 THIRD_PART

Do not alter nsslapd-rootdn. Do not create duplicate nsslapd-rootpw attributes.

Start the instance:

sudo dsctl ldap1 start

Sample output:

Instance "ldap1" has been started

If the instance fails to start, restore the backup shown in the troubleshooting section before you attempt another edit.

Verify the new password

After an online change or offline reset, confirm the bind with ldapwhoami before you rely on a stored password file. OpenLDAP reads the entire -y file, including a trailing newline, so an outdated or padded file can return error 49 even when the password change succeeded.

Commands that use /etc/dirsrv/slapd-ldap1/ca.crt run on the Directory Server host. From a remote administration host, set LDAPTLS_CACERT to the CA certificate installed on that client, such as /etc/pki/ca-trust/source/anchors/ds-ca.crt.

Prompt for the new password on the server host:

LDAPTLS_CACERT=/etc/dirsrv/slapd-ldap1/ca.crt \
ldapwhoami -x \
  -H ldaps://ldap1.example.com:636 \
  -D "cn=Directory Manager" \
  -W

The same test from a remote administration host:

LDAPTLS_CACERT=/etc/pki/ca-trust/source/anchors/ds-ca.crt \
ldapwhoami -x \
  -H ldaps://ldap1.example.com:636 \
  -D "cn=Directory Manager" \
  -W

Sample output:

dn: cn=directory manager

Update the stored password file on the administration host without adding a trailing newline:

sudo bash -c '
umask 077
read -rsp "New Directory Manager password: " password
printf "%s" "$password" > /root/dm.pw
echo
'

Retest with the updated file:

LDAPTLS_CACERT=/etc/dirsrv/slapd-ldap1/ca.crt \
ldapwhoami -x \
  -H ldaps://ldap1.example.com:636 \
  -D "cn=Directory Manager" \
  -y /root/dm.pw

Run a harmless configuration read with the updated file:

dsconf -D "cn=Directory Manager" -y /root/dm.pw ldap1 config get nsslapd-rootdn

Sample output:

nsslapd-rootdn: cn=Directory Manager

Locate the latest Directory Manager bind in the access log:

sudo grep 'BIND dn="cn=Directory Manager"' /var/log/dirsrv/slapd-ldap1/access | tail -1

Sample output:

[22/Jul/2026:10:10:31.826034033 +0530] conn=9 op=0 BIND dn="cn=Directory Manager" method=128 version=3

Search for the matching RESULT line using the same conn= and op= values from that bind:

sudo grep 'conn=9 op=0 RESULT' /var/log/dirsrv/slapd-ldap1/access | tail -1

Sample output:

[22/Jul/2026:10:10:31.917364251 +0530] conn=9 op=0 RESULT err=0 tag=97 nentries=0 wtime=0.000740710 optime=0.091353699 etime=0.092088525 dn="cn=directory manager"

err=0 on the bind RESULT line confirms authentication succeeded only when the conn= and op= values match the preceding BIND record. On a busy server, unrelated nearby RESULT lines can also show err=0.

Troubleshoot a failed password reset

Check service state first:

sudo dsctl ldap1 status

If the instance is not running, read the systemd journal:

sudo journalctl -u dirsrv@ldap1 -n 20 --no-pager

Inspect the errors log for hash or configuration problems:

sudo tail -n 20 /var/log/dirsrv/slapd-ldap1/errors

A truncated or malformed offline hash can produce messages similar to these when the copied value is incomplete rather than because Directory Server shortens every long single-line hash:

[22/Jul/2026:10:01:14.765351521 +0530] - ERR - plugins/pwdchan/src/lib.rs:181 - Invalid Base 64 TRUNCATEDONLY -> InvalidLength
[22/Jul/2026:10:01:14.775194149 +0530] - ERR - plugins/pwdchan/src/lib.rs:208 - invalid hashed pw -> InvalidBase64

When the server still starts but binds fail, restore the backup and return to a known-good configuration:

sudo dsctl ldap1 stop
sudo cp -a /etc/dirsrv/slapd-ldap1/dse.ldif.before-dm-reset /etc/dirsrv/slapd-ldap1/dse.ldif
sudo dsctl ldap1 start

Handle multiple instances and replication

Each 389 Directory Server instance keeps its own configuration tree:

/etc/dirsrv/slapd-<instance>/dse.ldif

Resetting ldap1 does not reset ldap2. Test each hostname directly. Perform the procedure separately on every instance that should use the new password.

The Directory Manager password is not the replication-agreement password. Changing it does not update application, backup, monitoring, or replication credentials automatically. After a reset, review dependent tools:

• Administration scripts and cron jobs
• Backup and restore utilities
• Monitoring and health checks
• LDAP browsers and IDE connectors
• dsconf password files passed with -y
• Secret stores outside Directory Server

In a replicated topology, plan the rollout instance by instance. Document which servers were updated and which clients still hold the previous secret.

References

• 389 Directory Server documentation
• Red Hat Directory Server 13 — changing and resetting the Directory Manager password
• 389 Project howto: reset Directory Manager password

Summary

Confirm the instance name and nsslapd-rootdn, then choose the online dsconf directory_manager password_change path when the current password is known or the offline pwdhash and dse.ldif path when it is forgotten. Stop the instance, back up dse.ldif, replace only nsslapd-rootpw, verify with -W before updating stored password files, and reset each replica independently. Update every stored secret that still references the old password.