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:
- 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 13.3, “Account Lockout Policy Attributes” describes the attributes available to configure the account lockout policy.
Table 13.3. Account Lockout Policy Attributes
| 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.
|
| passwordUnlock | This attribute sets whether a user can log back into the server without administrator intervation. The default is for this attribute to be on, meaning that the user can log back into the server after a certain lockout period has passed. If this attribute is turned off, then the user cannot log back in using that account until it is manually unlocked by an administrator. |
| passwordLockoutDuration |
This attribute indicates the time, in seconds, that users will be locked out of the directory. The passwordUnlock attribute specifies if a user is locked out until the password is reset by an administrator (which means that the user is locked out indefinitely). If the passwordUnlock attribute is set to on, then the use can log in again as soon as the lockout duration time is reached. 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 gage 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.
|
Account lockout policies will block a user ID from being able to access the Directory Server if the login attempt fails a set number of times. This prevents hackers or other malicious people from illegitimately accessing the Directory Server by guessing a password. Password policies are set locally, and generally account lockout attributes are local to each replica. This means that a person can attempt to log in to one replica until the account lockout count is reached, then try again immediately on another replica. The way to prevent that is to replicate the attributes related to the account lockout counts for an entry, so that the malicious user is locked out of every supplier and consumer replica in the configuration if a login attempt fails on a single master.
By default, three password policy attributes are not replicated, even if other password attributes are. These attributes are related to of login failures and lockout periods:
passwordRetryCountretryCountResetTimeaccountUnlockTime
Password and account lockout policies are enforced in a replicated environment slightly differently:
- 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 automatically:
passwordMinAgeandpasswordMaxAgepasswordExppasswordWarning
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, unless specifically configured for replication.
When configuring a password policy in a replicated environment, make sure that these elements are in place, so password policies and account lockout settings are enforced consistently:
- Warnings from the server of an impending password expiration are 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. Account lockout counters are not replicated by default (although this can be configured). If account lockout attributes are not replicated at all, then a user could be locked out from one server but could successfully bind to another server (or, conversely, a user may be unlocked on one server and still blocked on another). If account lockout attributes are replicated, then there could be lags between an account lockout change on one server and when that change is propagated to the other servers. It depends on the replication schedule.
- 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
passwordExpirationTimeattribute to the entry, and give it a value of20380119031407Z(the top of the valid range).
A special core configuration attribute controls whether password policy operational attributes are replicated. This is the
passwordIsGlobalPolicy attribute, which is enabled in the consumer Directory Server configuration to allow the consumer to accept password policy operational attributes.
By default, this attribute is set to
off.
To enable these attributes to be replicated, change the
passwordIsGlobalPolicy configuration attribute on the consumer:
/usr/lib64/mozldap/ldapmodify -D "cn=directory manager" -w secret -p 389 -h consumer1.example.com dn: cn=config changetype: modify replace: passwordIsGlobalPolicy passwordIsGlobalPolicy: on
Changing that value to
on allows the passwordRetryCount, retryCountResetTime, and accountUnlockTime to be replicated. No other configuration is necessary for the attributes to be included with the replicated attributes.
Setting the
passwordIsGlobalPolicy attribute affects the consumer in replication, in that it allows the consumer to receive updates to those attributes. To control whether the password policy attributes are actually replicated by the supplier, use fractional replication, which controls what specific entry attributes are replicated.
If the password policy attributes should be replicated, then make sure these attributes are included in the fractional replication agreement (as they are by default).
If the
passwordIsGlobalPolicy attribute is set to off on the consumer, so no password policy attributes should be replicated, use fractional replication (described in Section 9.1.7, “Replicating a Subset of Attributes with Fractional Replication”) to enforce that on the supplier and specifically exclude those attributes from the replication agreement.
- When configuring the replication agreement on the supplier, as described (for example) in Section 9.4.3, “Creating the Replication Agreement”, select the Enable Fractional Replication checkbox.
- By default, every attribute is listed in the Replicated Attributes box. Select the
passwordRetryCount,retryCountResetTime, andaccountUnlockTimeparameters and click the arrow button to move them into the Do Not Replicate box.
- Finish configuring the replication agreement.