Chapter 14. Managing User Authentication

When a user connects to the Red Hat Directory Server, first the user is authenticated. Then, the directory grants access rights and resource limits to the user depending upon the identity established during authentication.
This chapter describes tasks for managing users, including configuring the password and account lockout policy for the directory, denying groups of users access to the directory, and limiting system resources available to users depending upon their bind DNs.

14.1. Managing the Password Policy

A password policy minimizes the risks of using passwords by enforcing a certain level of security. For example, a password policy can define that:
  • Users must change their passwords according to a schedule.
  • Users must provide non-trivial passwords.
  • The password syntax must meet certain complexity requirements.
For an overview on password policy, see "Designing a Password Policy" in the "Designing a Secure Directory" chapter in the Deployment Guide.

Warning

When using a password administrator account or the Directory Manager (root DN) to set a password, password policies are bypassed and not verified. Do not use these accounts for regular user password management. Use them only to perform password administration tasks that require bypassing the password policies.
Directory Server supports fine-grained password policy, so password policies can be applied to the entire directory (global password policy), a particular subtree (subtree-level or local password policy), or a particular user (user-level or local password policy).
The complete password policy applied to a user account is comprised of the following elements:
  • The type or level of password policy checks. This information indicates whether the server should check for and enforce a global password policy or local (subtree/user-level) password policies.
    Password policies work in an inverted pyramid, from general to specific. A global password policy is superceded by a subtree-level password policy, which is superceded by a user-level password policy. Only one password policy is enforced for the entry; password policies are not additive. This means that if a particular attribute is configured in the global or subtree-level policy, but not in the user-level password policy, the attribute is not used for the user when a login is attempted because the active, applied policy is the user-level policy.
  • Password add and modify information. The password information includes password syntax and password history details.
  • Bind information. The bind information includes the number of grace logins permitted, password aging attributes, and tracking bind failures.

Note

After establishing a password policy, user passwords can be protected from potential threats by configuring an account lockout policy. Account lockout protects against hackers who try to break into the directory by repeatedly guessing a user's password.

14.1.1. Configuring the Global Password Policy

Note

After configuring the password policy, configure an account lockout policy. For details, see Section 14.4, “Configuring a Password-Based Account Lockout Policy”.

14.1.1.1. Configuring a Global Password Policy Using the Console

A global password policy applies to every entry in the entire directory.
  1. Select the Configuration tab and then the Data node.
  2. In the right pane, select the Passwords tab.
    This tab contains the password policy for the entire Directory Server.
  3. Set the password policies for how users can change their own passwords.
    • To require users to change their password the first time they log on, select the User must change password after reset check box.

      Note

      If users are required to reset their password, only the Directory Manager is authorized to reset the user's password. A regular administrative user cannot force the users to update their password.
    • To allow users to change their own passwords, select the User may change password check box.
    • To prevent users from changing their password for a specific duration, enter the number of days in the Allow changes in X day(s) text box. This keeps users from quickly cycling through passwords to reuse a password in their password history.
    • For the server to maintain a history list of passwords used by each user, select the Keep password history check box. Enter the number of passwords for the server to keep for each user in the Remember X passwords text box.
  4. Set the policies for when passwords expire.
    • If user passwords should not expire, select the Password never expires radio button.
    • To require users to change their passwords periodically, select the Password expires after X days radio button, and then enter the number of days that a user password is valid.
      The maximum value for the password age is derived by subtracting January 18, 2038, from today's date. The entered value must not be set to the maximum value or too close to the maximum value. Setting the value to the maximum value can cause the Directory Server to fail to start because the number of seconds will go past the epoch date. In such an event, the error log will indicate that the password maximum age is invalid. To resolve this problem, correct the passwordMaxAge attribute value in the dse.ldif file.
      A common policy is to have passwords expire every 30 to 90 days. By default, the password maximum age is set to 8640000 seconds (100 days).
    • If the Password expire after X days radio button is selected, specify how long before the password expires to send a warning to the user. In the Send Warning X Days Before Password Expires text enter the number of days before password expiration to send a warning.

      Note

      It is not necessary to configure the Directory Server to send a warning to users. The Directory Server automatically issues a warning the next time the user attempts to log into the Directory Server Console that the password will soon expire or has expired. This is analogous to an operating system warning that reads "Warning: password will expire in 7 days" when a user logs in.
  5. For the server to check the syntax of a user password to make sure it meets the minimum requirements set by the password policy, select the Check Password Syntax check box. Then, specify required password complexity, such as the minimum length and required number of numeric and special characters. The password syntax requirements are described more in Table 14.1, “Password Policy Attributes”.
  6. From the Password Encryption pull-down menu, select the encryption method for the server to use when storing passwords.
    For detailed information about the encryption methods, see the passwordStorageScheme attribute in Table 14.1, “Password Policy Attributes”.
    The Password Encryption menu might contain other encryption methods, as the directory dynamically creates the menu depending upon the existing encryption methods it finds in the directory.
  7. Click Save.

14.1.1.2. Configuring a Global Password Policy Using the Command Line

To set up the password policy for a subtree or user, add the required entries and attributes at the subtree- or user-level, set the appropriate values to the password policy attributes, and enable fine-grained password policy checking.
No password policy attributes are set by default. Each password policy attribute must be added manually to the cn=config entry to create a global policy. These can be passed all together by passing an LDIF file with ldapmodify.
  1. Create the LDIF file. Each statement is the same as inputting the changes through stdin, with separate update statements separated by a dash (-). 
    dn: cn=config
changetype: modify
add: passwordChange
passwordChange: on
-
add: passwordExp
passwordExp: on
-
add: passwordMaxAge
passwordMaxAge: 8640000
-
add: passwordCheckSyntax
passwordCheckSyntax: on
-
add: passwordMinCategories
passwordMinCategories: 3
-
add: passwordStorageScheme
passwordStorageScheme: SSHA512
^D
  2. Pass the LDIF file to the server using the -f option with the ldapmodify command. 
    [root@server ~]# ldapmodify -D "cn=directory manager" -W -x -f user-pwdpolicy.ldif
Table 14.1, “Password Policy Attributes” describes the attributes available to configure the password policy.

Table 14.1. Password Policy Attributes

Attribute Name Definition
passwordTrackUpdateTime This attribute sets whether to record a separate timestamp specifically for the most recent update to the password attribute. This can be useful to help coordinate sycnhronization updates or changes between other LDAP servers, like Active Directory. By default, this is turned off.
passwordGraceLimit This attribute indicates the number of grace logins permitted when a user's password is expired. When set to a positive number, the user will be allowed to bind with the expired password for that many times. For the global password policy, the attribute is defined under cn=config. By default, this attribute is set to 0, which means grace logins are not permitted.
passwordMustChange When on, this attribute requires users to change their passwords when they first login to the directory or after the password is reset by the Directory Manager. The user is required to change their password even if user-defined passwords are disabled. If this attribute is set to off, passwords assigned by the Directory Manager should not follow any obvious convention and should be difficult to discover. This attribute is off by default.
passwordChange When on, this attribute indicates that users may change their own password. Allowing users to set their own passwords runs the risk of users choosing passwords that are easy to remember. However, setting good passwords for the user requires a significant administrative effort. In addition, providing passwords to users that are not meaningful to them runs the risk that users will write the password down somewhere that can be discovered. This attribute is on by default.
passwordExp When on, this attribute indicates that the user's password will expire after an interval given by the passwordMaxAge attribute. Making passwords expire helps protect the directory data because the longer a password is in use, the more likely it is to be discovered. This attribute is off by default.
passwordMaxAge This attribute indicates the number of seconds after which user passwords expire. To use this attribute, enable password expiration using the passwordExp attribute. This attribute is a dynamic parameter in that its maximum value is derived by subtracting January 18, 2038, from today's date. The attribute value must not be set to the maximum value or too close to the maximum value. If the value is set to the maximum value, Directory Server may fail to start because the number of seconds will go past the epoch date. In such an event, the error log will indicate that the password maximum age is invalid. To resolve this problem, correct the passwordMaxAge attribute value in the dse.ldif file. A common policy is to have passwords expire every 30 to 90 days. By default, the password maximum age is set to 8640000 seconds (100 days).
passwordWarning This attribute indicates the number of seconds before a warning message is sent to users whose password is about to expire. Depending on the LDAP client application, users may be prompted to change their password when the warning is sent. By default, the directory sends the warning 86400 seconds (1 day) before the password is about to expire. However, a password never expires until the warning message has been sent. Therefore, if users do not bind to the Directory Server for longer than the passwordMaxAge, they will still get the warning message in time to change their password.
passwordMinAge This attribute indicates the number of seconds that must pass before a user can change their password. Use this attribute in conjunction with the passwordInHistory attribute to discourage users from reusing old passwords. For example, setting the minimum password age to 2 days prevents users from repeatedly changing their passwords during a single session to cycle through the password history and reuse an old password once it has been removed from the history list. The minimum age can be from 0 to 2147472000 seconds (24,855 days). A value of zero indicates that the user can change the password immediately. The default value of this attribute is 0.
passwordHistory This attribute indicates whether the directory stores a password history. When set to on, the directory stores the number of passwords specified in the passwordInHistory attribute in a history. If a user attempts to reuse one of the passwords, the password will be rejected. When this attribute is set to off, any passwords stored in the history remain there. When this attribute is set back to on, users will not be able to reuse the passwords recorded in the history before the attribute was disabled. This attribute is off by default, meaning users can reuse old passwords.
passwordInHistory This attribute indicates the number of passwords the directory stores in the history. There can be 2 to 24 passwords stored in the history. This feature is not enabled unless the passwordHistory attribute is set to on. This attribute is set to 6 by default.
passwordCheckSyntax When on, this attribute indicates that the password syntax is checked by the server before the password is saved. Password syntax checking ensures that the password string meets or exceeds the length and complexity requirements and that the string does not contain any trivial words. A trivial word is any value stored in the uid, cn, sn, givenname, ou, or mail attributes of the user's entry. This attribute is off by default.
passwordMinLength This attribute specifies the minimum number of characters that must be used in passwords. Shorter passwords are easier to crack. Passwords can be two (2) to 512 characters long. Generally, a length of eight characters is long enough to be difficult to crack but short enough for users to remember without writing it down. This attribute is set to 8 by default.
passwordMaxRepeats This attribute set the maximum number of times that the same character can be used in row, such as aaaaa. Setting the attribute to 0 means that there is no limit on how many time a character can be repeated. This attribute is set to 0 by default.
passwordMinAlphas This attribute sets the minimum number of alphabetic characters that must be used in the password. This setting does not set any requirements for the letter case; requirements for the minimum number of lowercase and uppercase letters are set in the passwordMinLower and passwordMinUpper attributes, respectively. By default, this attribute is set to 0, meaning there is no required minimum.
passwordMinDigits This attribute sets the minimum number of numeric characters (0 through 9) which must be used in the password. By default, this attribute is set to 0, meaning there is no required minimum.
passwordMinSpecials This attribute sets the minimum number of special ASCII characters, such as !@#$., which must be used in the password. By default, this attribute is set to 0, meaning there is no required minimum.
passwordMinLowers This attribute sets the minimum number of lower case alphabetic characters, a to z, which must be used in the password. By default, this attribute is set to 0, meaning there is no required minimum.
passwordMinCategories This attribute sets the minimum number of categories which must be used in the password. There are several categories available:
Uppercase letters (A to Z)
Lowercase letters (a to z)
Numbers (0 through 9)
Special ASCII characters, such as $
8-bit characters
This attribute is set to 3 by default.
passwordMinUppers This attribute sets the minimum number of upper case alphabetic characters, A to Z, which must be used in the password. By default, this attribute is set to 0, meaning there is no required minimum.
passwordMinTokenLength A trivial word check identifies dictionary or common words used in a password string. This attribute sets the minimum length for tokens or strings which are checked by the passwordSyntaxCheck attributes. This can be from 1 to 64 characters. This attribute is set to 3 by default, meaning that the password cannot contain a three-character (or longer) sequential string taken from their user name, common name, first or last name, mail, or other relevant attributes.
For example, for a token length of three, if the user name is jsmith, then the password 123smi! would be rejected because it has three sequential characters which match the user name.
passwordMin8bit This attribute sets the minimum number of 8-bit characters used in the password. The default number is 0, meaning none are required.
passwordStorageScheme This attribute specifies the type of encryption used to store Directory Server passwords. The following encryption types are supported by Directory Server:
SSHA (Salted Secure Hash Algorithm). This method is recommended as it is the most secure. The Directory Server supports SSHA, SSHA256, SSHA384, and SSHA512. SSHA is the default method.
SHA (Secure Hash Algorithm). A one-way hash algorithm; it is supported only for backwards compatibility with Directory Server 4.x and should not be used otherwise. This includes support for SHA, SHA256, SHA384, and SHA512 algorithms, which protects against some insecurities in the SHA1 algorithm.
MD5. MD5 is not as secure as SSHA but is available for legacy applications require it.
Salted MD5. This storage scheme is more secure than plain MD5 hash, but still less secure than SSHA. This storage scheme is not included for use with new passwords but to help with migrating user accounts from directories which support salted MD5.
crypt. The UNIX crypt algorithm, provided for compatibility with UNIX passwords.
clear. This encryption type indicates that the password will appear in plain text.
The only password storage scheme that can be used with SASL DIGEST-MD5 is CLEAR. Passwords stored using crypt, SHA, or SSHA formats cannot be used for secure login through SASL DIGEST-MD5. To provide a customized storage scheme, consult Red Hat professional services.

14.1.2. Configuring a Local Password Policy

Note

After configuring the password policy, configure an account lockout policy. For details, see Section 14.4, “Configuring a Password-Based Account Lockout Policy”.

14.1.2.1. Configuring a Subtree/User Password Policy Using the Console

  1. Enable a fine-grained password policy globally, as described in Section 14.1.1.1, “Configuring a Global Password Policy Using the Console”. Be sure to check the Enable fine-grained password policy check box to allow user-level password policies.

    Note

    The password policy must be enabled globally before it will be applied locally. No other global password policy features must be set, and the global password policy will not override the local policy if they differ.
  2. Create the local password policy for the subtree or user.
    1. Select the Directory tab.
    2. In the navigation pane, select the subtree or user entry for which to set up the password policy.
    3. From the Object menu, select the Manage Password Policy option, and then select the For user or For subtree.
    4. In the Passwords tab, select the Create subtree/user level password policy check box to add the required attributes. The password policy settings — resetting, expiration, syntax, and encryption — are the same as for the global policy in Section 14.1.1.1, “Configuring a Global Password Policy Using the Console”.
    5. In the Account Lockout tab, specify the appropriate information, and click Save.

14.1.2.2. Configuring Subtree/User Password Policy Using the Command Line

  1. Add the required attributes to the subtree or user entries by running the ns-newpwpolicy.pl script.
    The command syntax for the script is as follows: 
    ns-newpwpolicy.pl [-D rootDN]  -w password | -w - | -j filename [-p port] [-h host] -U userDN -S suffixDN
    For updating a subtree entry, use the -S option. For updating a user entry, use the -U option. The ns-newpwpolicy.pl script accepts only one user or subtree entry at a time. It can, however, accept both user and suffix entries at the same time. For details about the script, see the Directory Server Configuration and Command-Line Tool Reference.
  2. The script adds the required attributes depending on whether the target entry is a subtree or user entry.
    For a subtree (for example, ou=people,dc=example,dc=com), the following entries are added:
    • A container entry (nsPwPolicyContainer) at the subtree level for holding various password policy-related entries for the subtree and all its children. For example: 
      dn: cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer
    • The actual password policy specification entry (nsPwPolicyEntry) for holding all the password policy attributes that are specific to the subtree. For example: 
      dn: cn=cn=nsPwPolicyEntry\,ou=people\,dc=example\,dc=com,
     cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: ldapsubentry
objectclass: passwordpolicy
    • The CoS template entry (nsPwTemplateEntry) that has the pwdpolicysubentry value pointing to the above (nsPwPolicyEntry) entry. For example: 
      dn: cn=cn=nsPwTemplateEntry\,ou=people\,dc=example\,dc=com,
     cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: costemplate
objectclass: ldapsubentry
cosPriority: 1
pwdpolicysubentry: cn=cn=nsPwPolicyEntry\,ou=people\,dc=example\,dc=com,
     cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
    • The CoS specification entry at the subtree level. For example: 
      dn: cn=newpwdpolicy_cos,ou=people,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosPointerDefinition
cosTemplateDn: cn=cn=nsPwTemplateEntry\,ou=people\,dc=example,dc=com,
     cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
cosAttribute: pwdpolicysubentry default operational
    For a user (for example, uid=jdoe,ou=people,dc=example,dc=com), the following entries are added:
    • A container entry (nsPwPolicyContainer) at the parent level for holding various password policy related entries for the user and all its children. For example: 
      dn: cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectClass: top
objectClass: nsContainer
cn: nsPwPolicyContainer
    • The actual password policy specification entry (nsPwPolicyEntry) for holding the password policy attributes that are specific to the user. For example: 
      dn: cn=cn=nsPwPolicyEntry\,uid=jdoe\,ou=people\,dc=example\,dc=com,
     cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: ldapsubentry
objectclass: passwordpolicy
  3. Assign the value of the above entry DN to the pwdpolicysubentry attribute of the target entry. For example, this assigns the password policy to the user entry: 
    dn: uid=jdoe,ou=people,dc=example,dc=com
changetype: modify
replace: pwdpolicysubentry
pwdpolicysubentry: cn=cn=nsPwPolicyEntry\,uid=jdoe\,ou=people\,dc=example\,dc=com,
     cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
  4. Set the password policy attributes for the subtree or user entry with the appropriate values.
    Table 14.1, “Password Policy Attributes” describes the attributes available to configure the password policy. The ldapmodify utility can be used to change these attributes in the subtree or user entry which contains the nsPwPolicyEntry object class.

    Note

    The nsslapd-pwpolicy-local attribute of the cn=config entry controls the type of password policy the server enforces. By default, this attribute is disabled (off). When the attribute is disabled, the server only checks for and enforces the global password policy; the subtree and user-level password policies are ignored. When the ns-newpwpolicy.pl script runs, it first checks for the specified subtree and user entries and, if they exist, modifies them. After updating the entries successfully, the script sets the nsslapd-pwpolicy-local configuration parameter to on. If the subtree and user-level password policy should not be enabled, be sure to set nsslapd-pwpolicy-local to off after running the script.
To turn off user- and subtree-level password policy checks, set the nsslapd-pwpolicy-local attribute to off by modifying the cn=config entry. For example: 
ldapmodify -D "cn=directory manager" -W -p 389 -h server.example.com -x

dn: cn=config
changetype: modify
replace: nsslapd-pwpolicy-local
nsslapd-pwpolicy-local: off
This attribute can also be disabled by modifying it directly in the configuration file (dse.ldif).
  1. Stop the server. 
    service dirsrv stop instance
  2. Open the dse.ldif file in a text editor.
  3. Set the value of nsslapd-pwpolicy-local to off, and save. 
    nsslapd-pwpolicy-local: off
  4. Start the server. 
    service dirsrv start instance

14.1.2.3. Manually Setting Default Password Syntax Checking for Local Password Policies

The settings for the global password policy should be in effect for any local password policies, if those attributes are not explicitly set. If the password policy attribute is not set in either the global or the local policy, then the default values should be assumed.
However, there is a bug in Directory Server, so that if a password policy attribute is set in the global password policy but not in the local password policy, then neither the global setting nor the default settings is enforced by the local password policy. To work around this, set the password attributes explicitly in the local password policy.
  1. Enable global syntax checking, as in Section 14.1.1.1, “Configuring a Global Password Policy Using the Console”, and save the policy.
  2. Edit the local password policy to contain all password syntax
  3. Enable fine-grained password checking, as in Section 14.1.2.1, “Configuring a Subtree/User Password Policy Using the Console”, and save the policy.
  4. Edit the local password policy to contain all password syntax attributes. Set the values to something other than the default settings, as listed in the Configuration and Command-Line Tool Reference.
  5. Re-edit the local password policy with the desired values, even if they are the defaults.

14.1.3. Setting User Passwords

An entry can be used to bind to the directory only if it has a userPassword attribute and if it has not been inactivated. Because user passwords are stored in the directory, the user passwords can be set or reset with any LDAP operation, like ldapmodify.
For information on creating and modifying directory entries, see Chapter 3, Creating Directory Entries. For information on inactivating user accounts, see Section 14.11, “Manually Inactivating Users and Roles”.
Passwords can also be set and reset in the Users and Groups area of the Red Hat Admin Server or Directory Server Console. For information on how to use the Users and Groups area in the Admin Server Console, see the online help that is available in the Red Hat Admin Server.
Only password administrators, described in Section 14.1.4, “Setting Password Administrators”, and the root DN can add pre-hashed passwords. These users can also violate password policy.

Warning

When using a password administrator account or the Directory Manager (root DN) to set a password, password policies are bypassed and not verified. Do not use these accounts for regular user password management. Use them only to perform password administration tasks that require bypassing the password policies.

14.1.4. Setting Password Administrators

The Directory Manager can add the password administrator role to a user or a group of users. Since access control instructions (ACI) need to be set, it is recommended that a group is used to allow just a single ACI set to manage all password administrators. A password administrator can perform any user password operations, including the following:
  • forcing the user to change their password,
  • changing a user's password to a different storage scheme defined in the password policy,
  • bypassing the password syntax checks,
  • and adding already hashed passwords.
As explained in Section 14.1.3, “Setting User Passwords”, it is recommended that ordinary password updates are done by an existing role in the database with permissions to update only the userPassword attribute. We recommend not to use the password administrator account for these ordinary tasks.
To specify a user or a group of users as password administrator in a local policy, use ldapmodify to set the passwordAdminDN attribute in the main configuration entry. 
[root@server ~]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -W
dn: cn=cn\3DnsPwPolicyEntry\2Cou\3DPeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=example,dc=com
changetype: modify
replace: passwordAdminDN
passwordAdminDN: cn=Passwd Admins,ou=groups,dc=example,dc=com
For setting in the global policy: 
[root@server ~]# ldapmodify -h localhost -p 389 -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: passwordAdminDN
passwordAdminDN: cn=Passwd Admins,ou=groups,dc=example,dc=com

14.1.5. Changing Passwords Stored Externally

While most passwords can be changed through the Console and other Directory Server features or through the ldapmodify operation, there are some passwords that cannot be changed through regular LDAP operations. These passwords may be stored outside the Directory Server, such as passwords stored in a SASL application. These passwords can be modified through the password change extended operation.
Directory Server supports the password change extended operation as defined in RFC 3062, so users can change their passwords, using a suitable client, in a standards-compliant way. The ldappasswd utility passes the changes for the password for the specified user: 
ldappasswd -x -D bind_dn -w password -p server_port -h server_hostname [-a oldPassword] [-s newPassword] [user]

Important

Password operations must be performed over a secure connection, meaning SASL, TLS/SSL, or Start TLS. For information on using secure connections with LDAP client tools, see Section A.2, “Using SSL/TLS and Start TLS with LDAP Client Tools”.

Table 14.2. ldappasswd Options

Parameter Description
-h Gives the host name of the Directory Server.
-p Gives the port number of the Directory Server. Since SSL is required for password change operations, this is usually give the TLS/SSL port of the Directory Server. With the -ZZ or -ZZZ for Start TLS, this can be the standard port.
-D Gives the bind DN.
-w Gives the password for the bind DN.
-x Disables SASL to allow a simple bind over an SSL/TLS connection.
-a Optional. Gives the old password, which is being changed.
-s Optional. Sets the new password.
user Optional. Gives the DN of the user entry for which to change the password.
To use Start TLS, which runs the command on a non-secure port, run ldappasswd with the -ZZ option and the standard LDAP port number. The password extended change operation has the following format: 
ldappasswd -x -D bind_dn -w password -p server_port -h server_hostname -Z  [-a oldPassword] [-s newPassword] [user]

Note

For Start TLS connections to work, the SSL/TLS environment variables must be configured as described in Section A.2, “Using SSL/TLS and Start TLS with LDAP Client Tools”.
Use the -ZZ to force the connection to be successful.
To modify an entry's password, run ldappasswd like any other LDAP operation. It is not necessary to specify a user if the account is the same as that given in the bind DN. For example: 
ldappasswd -x -h ldap.example.com -p 389 -ZZ -D "uid=jsmith,ou=People,dc=example,dc=com" -W -s newpassword
To change the password on an entry other than the one specified in the bind credentials, run ldappasswd as shown below, adding the user DN to the operation and providing separate credentials, as follows: 
ldappasswd -D "cn=directory manager" -w secret -p 389 -h server.example.com -x -ZZ -W -s newpassword "uid=jsmith,ou=People,dc=example,dc=com"
Access control is enforced for the password change operation. If the bind DN does not have rights to change the specified password, the operation will fail with an Insufficient rights error.