7.1. Managing the Password Policy
A password policy minimizes the risks of using passwords by enforcing the following:
Users must change their passwords according to a schedule.
Users must provide non-trivial passwords.
The password syntax must meet certain complexity requirements.
After establishing a password policy, which can be for the entire directory or for specific subtrees or users, 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.
This section provides information about configuring password and account lockout 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).
Essentially, the password policy is comprised of the following information:
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 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.
The sections that follow describe the procedures for configuring the password policy:
Section 7.1.1.1, “Configuring a Global Password Policy Using the Console”
Section 7.1.1.2, “Configuring a Subtree/User Password Policy Using the Console”
Section 7.1.1.3, “Configuring a Global Password Policy Using the Command-Line”
Section 7.1.1.4, “Configuring Subtree/User Password Policy Using the Command-Line”
After configuring the password policy, we recommend configuring an account lockout policy. For details, see Section 7.1.4, “Configuring the Account Lockout Policy”.
To set up or modify the password policy for an entire directory, do the following:
In the Directory Server Console, select the Configuration tab and then the Data node.
In the right pane, select the Passwords tab.
This tab contains the password policy for the entire Directory Server.
Check the Enable fine-grained password policy checkbox. Enabling the password policy makes the other sections on the screen active.
To require users to change their password the first time they log on, select the User must change password after reset checkbox. If this checkbox is selected, 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 checkbox.
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.
For the server to maintain a history list of passwords used by each user, select the Keep password history checkbox. Enter the number of passwords for the server to keep for each user in the Remember X passwords text box.
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.
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.
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 checkbox. 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 7.1, “Password Policy Attributes”.
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, refer to the passwordStorageScheme
attribute in Table 7.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.
Click Save.
Enable fine-grained password policy globally.
Select the Configuration tab, then click the Data node.
In the right pane, select the Passwords tab.
Check the Enable fine-grained password policy checkbox.
Click Save.
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.
Create the local password policy for the subtree or user.
Select the Directory tab.
In the navigation pane, select the subtree or user entry for which to set up the password policy.
From the Object menu, select the Manage Password Policy option, and then select the For user or For subtree.
Either the User Password Policy or Subtree Password Policy window appears.
In the Passwords tab, select the Create subtree/user level password policy checkbox to add the required attributes, fill in the appropriate values, and click Save.
In the Account Lockout tab, specify the appropriate information, and click Save.
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.
This section describes the attributes to create a password policy for the entire server (globally) using ldapmodify
to change these attributes in the cn=config
entry.
Table 7.1, “Password Policy Attributes” describes the attributes available to configure the password policy.
To configure a subtree or user level password policy, do the following:
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, Command, and File Reference.
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=nsPwPolicy_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
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=nsPwPolicyEntry,uid=jdoe,ou=people,dc=example,dc=com", cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
Set the password policy attributes of subtree or user entry with the appropriate values.
Table 7.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 cn=config
entry.
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: [6]
ldapmodify -h myserver -p 389 -D "cn=directory manager" -w secretpwd dn: cn=config changetype: modify replace: nsslapd-pwpolicy-local: on nsslapd-pwpolicy-local: off
This attribute can also be disabled by modifying it directly in the configuration file (dse.ldif
).
Stop the server. [7]
service dirsrv stop instance
Open the dse.ldif
file in a text editor.
Set the value of nsslapd-pwpolicy-local
to off
, and save.
nsslapd-pwpolicy-local: off
Start the server.
service dirsrv start instance
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
.[6]
For information on creating and modifying directory entries, see Chapter 2, Creating Directory Entries. For information on inactivating user accounts, refer to Section 7.2, “Inactivating Users and Roles”.
Passwords can also be set and reset in the Users and Groups area of the Red Hat Administration Server or the Directory Server Gateway. For information on how to use the Users and Groups area, see the online help that is available in the Red Hat Administration Server. For information on how to use the Gateway to create or modify directory entries, see the Gateway online help.
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. Directory Server does not include a client application for the password change extended operation. However, the ldappasswd
utility can be used as follows:
ldappasswd -hhostname
-psecure_port
-Z -P/path/to/
cert8.db -DbindDN
-wbindPassword
[-aoldPassword
] -snewPassworduser
Parameter | Description |
---|---|
-h | Gives the hostname 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.
|
-Z |
Requires SSL for the connection. A secure connection is required for the password change operation.
NOTE
|
-P |
Gives the full path to the certificate database which contains the CA certificate of the CA that issued the Directory Server client certificate. If the ldappasswd command is run on the same machine that the Directory Server is installed on, this can be /etc/dirsrv/slapd- . If this is not given, the default is the current directory.
|
-D | Gives the bind DN. |
-w | Gives the password for the bind DN. |
-a | Optional. Gives the old password, which is being changed. |
-s | Sets the new 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 -hhostname
-pstandard_port
-ZZ -P/path/to/
cert8.db -DbindDN
-wbindPassword
-snewPassworduser
[-aoldPassword
]
Use the -ZZZ
for additional certificate hostname validation.
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 -h ldap.example.com -p 389 -ZZ -D "uid=jsmith,ou=People,dc=example,dc=com" -w rootpassword -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 -h server.example.com -p 389 -ZZ -D "cn=Directory Manager" -w rootpassword -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.
The lockout policy works in conjunction with the password policy to provide further security. The account lockout feature protects against hackers who try to break into the directory by repeatedly trying to guess a user's password. The password policy can be set so that a specific user is locked out of the directory after a given number of failed attempts to bind.
Configuring the account lockout policy is described in the following sections:
To set up or modify the account lockout policy for the Directory Server, do the following:
Select the Configuration tab and then the Data node.
In the right pane, select the Account Lockout tab.
To enable account lockout, select the Accounts may be locked out checkbox.
Enter the maximum number of allowed bind failures in the Lockout account after X login failures text box. The server locks out users who exceed the limit specified here.
In the Reset failure counter after X minutes text box, enter the number of minutes for the server to wait before resetting the bind failure counter to zero.
Set the interval for users to be locked out of the directory.
Select the Lockout Forever radio button to lock users out until their passwords have been reset by the administrator.
Set a specific lockout period by selecting the Lockout Duration radio button and entering the time (in minutes) in the text box.
Click Save.
This section describes the attributes to create an account lockout policy to protect the passwords stored in the server. Use ldapmodify
to change these attributes in the cn=config
entry.
Table 7.3, “Account Lockout Policy Attributes” describes the attributes available to configure the account lockout policy.
Attribute Name | Definition |
---|---|
passwordLockout |
This attribute indicates whether users are locked out of the directory after a given number of failed bind attempts. Set the number of failed bind attempts after which the user will be locked out using the passwordMaxFailure attribute. Users can be locked out for a specific time or until an administrator resets the password. This attribute is set to off by default, meaning that users will not be locked out of the directory.
|
passwordMaxFailure |
This attribute indicates the number of failed bind attempts after which a user will be locked out of the directory. This attribute takes affect only if the passwordLockout attribute is set to on . This attribute is set to 3 bind failures by default.
|
passwordLockoutDuration |
This attribute indicates the time, in seconds, that users will be locked out of the directory. The passwordUnlock attribute specifies that a user is locked out until the password is reset by an administrator. By default, the user is locked out for 3600 seconds.
|
passwordResetFailureCount |
This attribute specifies the time, in seconds, after which the password failure counter will be reset. Each time an invalid password is sent from the user's account, the password failure counter is incremented. If the passwordLockout attribute is set to on , users will be locked out of the directory when the counter reaches the number of failures specified by the passwordMaxFailure attribute. The account is locked out for the interval specified in the passwordLockoutDuration attribute, after which time the failure counter is reset to zero (0 ). Because the counter's purpose is to gauge when a hacker is trying to gain access to the system, the counter must continue for a period long enough to detect a hacker. However, if the counter were to increment indefinitely over days and weeks, valid users might be locked out inadvertently. The reset password failure count attribute is set 600 seconds by default.
|
Password and account lockout policies are enforced in a replicated environment as follows:
Password policies are enforced on the data master.
Account lockout is enforced on all servers participating in replication.
Some of the password policy information in the directory is replicated:
passwordMinAge
and passwordMaxAge
passwordExp
passwordWarning
However, the configuration information is kept locally and is not replicated. This information includes the password syntax and the history of password modifications. Account lockout counters and tiers are not replicated, either.
When configuring a password policy in a replicated environment, consider the following points:
Warnings from the server of an impending password expiration will be issued by all replicas. This information is kept locally on each server, so if a user binds to several replicas in turn, they will be issued the same warning several times. In addition, if the user changes the password, it may take time for this information to filter to the replicas. If a user changes a password and then immediately rebinds, he may find that the bind fails until the replica registers the changes.
The same bind behavior should occur on all servers, including suppliers and replicas. Make sure to create the same password policy configuration information on each server.
Account lockout counters may not work as expected in a multi-mastered environment.
Entries that are created for replication (for example, the server identities) need to have passwords that never expire. To make sure that these special users have passwords that do not expire, add the passwordExpirationTime
attribute to the entry, and give it a value of 20380119031407Z
(the top of the valid range).
Password changes in a Directory Server entry can be synchronized to password attributes in Active Directory entries by using the Password Sync utility.
When passwords are synchronized, password policies are enforced on each sync peer locally. The syntax or minimum length requirements on the Directory Server apply when the password is changed in the Directory Server. When the changed password is synched over to the Windows server, the Windows password policy is enforced. The password policies themselves are not synchronized.
Configuration information is kept locally and cannot be synchronized, including the password change history and the account lockout counters.
When configuring a password policy for synchronization, consider the following points:
The Password Sync utility must be installed locally on the Windows machine that will be synchronized with a Directory Server.
Password Sync can only link the Windows machine to a single Directory Server; to sync changes with multiple Directory Server instances, configure the Directory Server for multi-master replication.
Password expiration warnings and times, failed bind attempts, and other password-related information is enforced locally per server and is not synchronized between sync peer servers.
The same bind behavior should occur on all servers. Make sure to create the same or similar password policies on both Directory Server and Active Directory servers.
Entries that are created for synchronization (for example, the server identities) need to have passwords that never expire. To make sure that these special users have passwords that do not expire, add the passwordExpirationTime
attribute to the Directory Server entry, and give it a value of 20380119031407Z
(the top of the valid range).
See Chapter 19, Synchronizing Red Hat Directory Server with Microsoft Active Directory for more information on synchronizing Directory Server and Windows users and passwords.
[6]
The LDAP tools referenced in this guide are Mozilla LDAP, installed with Directory Server in the /usr/lib/mozldap
directory on Red Hat Enterprise Linux 5 i386; directories for other platforms are listed in Section 1.2, “LDAP Tool Locations”. However, Red Hat Enterprise Linux systems also include LDAP tools from OpenLDAP. It is possible to use the OpenLDAP commands as shown in the examples, but you must use the -x
argument to disable SASL and allow simple authentication.
[7] The commands to stop and start the Directory Server on platforms other than Red Hat Enterprise Linux is described in Section 1.3, “Starting and Stopping Servers”.