14.6. Replicating Account Lockout Attributes
14.6.1. Managing the Account Lockouts and Replication
- Password policies are enforced on the data master.
- Account lockout is enforced on all servers participating in replication.
- 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 of
20380119031407Z(the top of the valid range).
alwaysRecordLoginparameter set to
yes, the value of the
lastLoginTimeattribute can be different on masters and read-only replicas. For example, if a user logs in to a read-only replica, the
lastLoginTimeattribute is updated locally but the value is not replicated to the master servers.
14.6.2. Configuring Directory Server to Replicate Password Policy Attributes
passwordIsGlobalPolicyattribute, which is enabled in the consumer Directory Server configuration to allow the consumer to accept password policy operational attributes.
passwordIsGlobalPolicyconfiguration attribute on the consumer:
[root@server ~]# ldapmodify -D "cn=directory manager" -W -x -h consumer1.example.com dn: cn=config changetype: modify replace: passwordIsGlobalPolicy passwordIsGlobalPolicy: on
accountUnlockTimeto be replicated. No other configuration is necessary for the attributes to be included with the replicated attributes.
14.6.3. Configuring Fractional Replication for Password Policy Attributes
passwordIsGlobalPolicyattribute 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.
passwordIsGlobalPolicyattribute is set to
offon the consumer, so no password policy attributes should be replicated, use fractional replication (described in Section 11.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 11.4.3, “Creating the Replication Agreement”, select the Enable Fractional Replication check box.
- By default, every attribute is listed in the Replicated Attributes box. Select the
accountUnlockTimeparameters and click the arrow button to move them into the Do Not Replicate box.
- Finish configuring the replication agreement.