20.11. Replicating Account Lockout Attributes

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 supplier.
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:
  • passwordRetryCount
  • retryCountResetTime
  • accountUnlockTime

20.11.1. Managing the Account Lockouts and Replication

Password and account lockout policies are enforced in a replicated environment slightly differently:
  • Password policies are enforced on the data supplier.
  • Account lockout is enforced on all servers participating in replication.
Some of the password policy information in the directory is replicated automatically:
  • 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, 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-suppliered 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 passwordExpirationTime attribute to the entry, and give it a value of 20380119031407Z (the top of the valid range).

Note

If the password policy is enabled and the alwaysRecordLogin parameter set to yes, the value of the lastLoginTime attribute can be different on suppliers and read-only replicas. For example, if a user logs in to a read-only replica, the lastLoginTime attribute is updated locally but the value is not replicated to the supplier servers.

20.11.2. Configuring Directory Server to Replicate Password Policy Attributes

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 parameter on the consumer: 
# dsconf -D "cn=Directory Manager" ldap://server.example.com pwpolicy set --pwdisglobal="on"
Changing that value to on allows the passwordRetryCount, retryCountResetTime, and accountUnlockTime to be replicated.

20.11.3. Configuring Fractional Replication for Password Policy 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 15.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.
For details about configuring replication, see:
When you create the replication agreement in the procedures linked above, configure fractional replication:
  1. When configuring the replication agreement on the supplier, click Show Advanced Settings.
  2. Enter the passwordRetryCount, retryCountResetTime, and accountUnlockTime attributes names in to the Exclude Attributes field.
  3. Finish configuring the replication agreement.