Replication of password policy operational attributes

Edit online

To implement password policy consistently within a replication topology, you must replicate certain password policy operational attributes to all the servers in the topology.

To implement password policy in a replication environment, you must replicate the global password policy entry, cn=pwdpolicy, cn=ibmpolicies, to all the consumers of cn=ibmpolicies subtree. Password policy-related details of a user are stored in the password policy operational attributes of the user entry. These operational attributes govern the account access and lockout operations of user entries. For all the servers to have same password policy entries, define the password policy entries under the cn=ibmpolicies entry. The password policy operational attributes are replicated to all servers. The server that receives these replication updates decides whether to record these updates.

When the master replicates password policy operational attributes, such as pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime, and pwdGraceUseTime, of a user entry to a read-only replica, it does not record these values. Similarly, changes to these attributes of a user entry on a read-only replica server are not updated on their respective master servers. To make password policy consistent across write replicas (peer servers), the write replicas replicate and record these operational attributes. Therefore, replication of these attributes must be considered based on your directory server requirements.

In servers earlier than 6.3.0.10, the number of password failures, grace login, and account locks are updated on each read-only replica independently for a user. In a replication topology, a user can run bind operations against servers more that is defined in the enforced password policy for the user. A user can use these additional bind operations, even if bind fails on some servers.

If the effective password failure count set for a user is M (value of the pwdMaxFailure attribute), a user on a master-replica topology can use N * M attempts. N is the number of servers and M is the value of the pwdMaxFailure attribute. Out of the N number of servers, for write replicas the count is considered as 1. If the password policy operational attributes of a user entry is updated on a peer server, these updates are replicated to all the write replicas. The remaining N-1 servers are the count of read-only replicas. Each read-only replica stores updates to password policy operational attributes of a user entry in its own database.

With the replication of password policy operational attributes, an administrator can enforce strong password policy in a replication topology. You can ensure that the password policy operational attributes for a user is updated on all the servers, including the read-only replica servers. With this feature, a bind with invalid credentials that result in an LDAP_INVALID_CREDENTIAL error is considered as an invalid bind. A successful bind with valid credentials is considered as a valid bind.

You must cryptographically synchronize the server instances in a replication topology to obtain better performance.

To replicate password policy operational attributes consistently across all server, you must ensure that the replication meets the following conditions:

  • Set real-time replication on all the required subtrees across all the servers in the replication topology.
  • Set password policy on all the servers.
  • Synchronize the count of failed bind attempts for the users on all the servers with in the replication topology.
  • Enable the feature on all the servers that are participating in replication. You must also set the following attributes:
    • Add the ibm-replicareferralURL attribute for the required replication contexts on the read-only replicas, if not present.
    • Set the ibm-slapdReplicateSecurityAttributes attributes to true on all the servers that are participating in the replication.
Note: In this feature, there is no change in the usage of the ibm-slapdMasterReferral attribute.

The root DSE search result

If the servers in a replication topology support the following operations, the root DSE search returns the ibm-supportedCapabilities attribute with the 1.3.18.0.2.32.105 OID value:

  • The read-only replica accepts the replication updates for password policy operational attributes. The read-only replica can notify its master servers about a bind operation that affects password policy operational attributes of a user.
  • The master server can accept notifications from a read-only replica about a bind operation that affects password policy operational attributes of a user.

If you configure the feature successfully on servers, the root DSE search returns the ibm-enabledCapabilities attribute with the 1.3.18.0.2.32.105 OID value.

You can also run a root DSE search to verify the value that is assigned to the ibm-slapdReplicateSecurityAttributes attribute. If the attribute value is true, the server supports replication of password policy operational attributes.

Server performance in a replication topology

When a user attempts bind operation against a read-only replica, it processes the following operations:

  1. Verifies whether the bind operation affects the password policy operational attributes of the user.
  2. Identifies the master server to notify about the bind operation.
  3. Propagates the bind operation from the read-only replica to the master server.

To complete these operations, the read-only replica server does more processing. Therefore, it might degrade the performance of the read-only replica server as a trade-off against the security enhancement.

Audit and log information

The server logs the information that is related to replication of password policy operational attributes in the following log files:

  • If audit feature is set, the read-only replica records the following information in the audit.log file:
    • Bind operation details that include failed bind and successful bind operations.
  • The read-only replica records the following operations that require it to bind and notify a master server in the audit.log file:
    • All bind requests that affect password policy operational attributes for a user on the read-only replica server.
    An administrator can use these logs to check the operations that are initiated and completed by the servers.
  • The server records the ibm-slapdReplicateSecurityAttributes attribute value in the ibmslapd.log and  traceibmslapd.log files.
  • If a read-only replica does not contain the list of masters to notify about a bind, then the server records an appropriate message in the ibmslapd.log file.
  • The read-only replica also records the password failure timestamp that it updates for a user entry in the traceibmslapd.log file. The password failure timestamp that the read-only replica records can be from the following source:
    • The timestamp that the read-only replica generates at its end.
    • The timestamp in the response control from the master server.
    • The replicated timestamp from the master server.
  • The servers in a replication topology records all failure path error messages in the traceibmslapd.log file.