Supporting replication of security attributes between master and replica server in Tivoli Directory Server Version 6.3 fix pack 10 (6.3.0.10)

Content

Introduction:
To implement password policy in a replication environment, the global password policy entry “cn=pwdpolicy, cn=ibmpolicies” must be replicated to all the consumers of “cn=ibmpolicies” subtree. For all the servers to have same password policy entries, the password policy entries must be defined under the “cn=ibmpolicies” entry.

Password policy related details of a user are stored in the password policy operational attributes of the user entry and are used for account access and lockout operation. To maintain consistency when implementing password policy, certain password policy attributes must be replicated to all the servers within the replication topology. Currently, when password policy operational attributes are replicated to all servers they are consumed depending on the type of server that is receiving the replication updates.

As per the current design, password policy operational attributes such as pwdAccountLockedTime, pwdExpirationWarned, pwdFailureTime, and pwdGraceUseTime are not consumed by read-only replica servers when they are replicated by master servers. Similarly, changes to these attributes on the read-only replica servers do not get updated on their respective master servers. However, these password policy operational attributes are replicated and consumed between write replicas (peer servers) to make password policy consistent globally across write replicas. Therefore, replicating these attributes must be carefully considered.

Based on the current behavior, if there is any update to the password policy operational attributes of a user entry on a replica server because of a bind attempt then these updates are not propagated to other servers in the replication topology. Similarly, when password policy operational attributes updates for a user are replicated from a master server to a read-only replica server, they are not updated for the user on the read-only replica server.

Currently, the number of password failures, the number of grace logins, and the account locking take place on each read-only replica server independently for a user. Since a user can perform bind failure attempts against other servers in the replication topology, the user can use these additional bind failure attempts than that is defined in the enforced password policy for the user. For example, if the effective password failure count set for the user is M (value of pwdMaxFailure attribute). A user on a master-replica replication topology can use N x M attempts, where N is the number of servers and M is the value of pwdMaxFailure attribute. Out of N number of servers, for write replicas the count is considered as 1. This is because when there is an update against password policy operational attributes of a user entry on a master/peer server then these updates are replicated to write replicas. The remaining N-1 servers is the count of read-only replica servers, since each replica server stores updates against password policy operational attributes of a user entry in its own database.

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


Enabling the feature:
Before using this feature, user must ensure that the configured replication meets the listed conditions for the feature to function consistently. The conditions are:

• Real-time replication on all the required subtrees is recommended to be set between all the servers in the replication topology.
• Password policy must be set on all the servers.
• The count of failed bind attempts must be in sync for the users on all the servers with in the replication topology.
• The feature is enabled on all the servers participating in replication. To enable the feature and for the feature to function properly, user must set the following:
• Add the ibm-replicareferralURL attribute for the required replication contexts on the replica servers, if not present.
• Set the REPLICATE_SECURITY_ATTRIBUTES environment variable to TRUE on all directory server instances participating in the replication.

Note: There is no change in the usage of the ibm-slapdMasterReferral attribute in this feature.

Adding the ibm-replicareferralURL attribute:
For a replication context, there can be multiple master servers configured in a replica server. From Tivoli Directory Server Version 6.3 fix pack 10 (6.3.0.10), to notify about a bind on a replica server that affects password policy operation attributes of a user entry to its master servers, administrator must add the ibm-replicareferralurl attribute on the replica servers. Administrator must add the ibm-replicareferralurl attribute on the replica servers for all the required replication contexts. Ensure that the ibm-replicareferralurl attribute in the replica server contain valid IP addresses or fully qualified domain names with ports of the master servers as its value.
Notes:

• Even if the REPLICATE_SECURITY_ATTRIBUTES environment variable is set, the feature might not function properly if the ibm-replicareferralURL attribute is not set.
• It is advisable to specify all the master servers of a replica server for the configured replication context in the ibm-replicareferralurl attribute. Replica server uses the ibm-replicareferralurl attribute to identify the master servers to which it must notify. If the first master server is unavailable because of network failure or the server is offline, the request is sent to the next master server from the list, and then to the subsequent server. Even if one of the master servers from the list is reachable, the replica server notifies about the bind request to that master server.

If the ibm-replicareferralurl attribute is not present for a replication context, for example: cn=ibmpolicies, then add the attribute to the cn=ibmpolicies replication context. Run the idsldapmodify command, for example:
#idsldapmodify -h <hostname> -p <port> -D <adminDN> -w <adminPWD>
dn: cn=ibmpolicies
changetype: modify
add: ibm-replicareferralurl
ibm-replicareferralurl: ldap://<server>:<port> ldaps://<server1>:<port1>

If the ibm-replicareferralurl attribute is already present for a replication context, then modify the attribute. For example:
#idsldapmodify -h <hostname> -p <port> -D <adminDN> -w <adminPWD>
dn: cn=ibmpolicies
changetype: modify
replace: ibm-replicareferralurl
ibm-replicareferralurl: ldap://<server>:<port> ldaps://<server1>:<port1>

Setting the REPLICATE_SECURITY_ATTRIBUTES environment variable:
To enable this feature, user must set the REPLICATE_SECURITY_ATTRIBUTES environment variable to TRUE on all directory server instances in a replication topology. Setting the environment variable to TRUE, overrides the default behavior and propagates the password policy operation attributes between master and replica servers.
To set the value of the environment variable, administrator can use either of the listed methods.

Using ldap client utility (preferred method):
To set the variable in the configuration file, run the ldapmodify command. For example:
ldapmodify -h <hostname> -p <port> -D <adminDN> -w <adminPW>
dn: cn=Front End, cn=configuration
changetype: modify
add: ibm-slapdSetEnv
ibm-slapdSetEnv: REPLICATE_SECURITY_ATTRIBUTES=TRUE

To effect the changes made to the ibm-slapdSetEnv attribute, administrator must restart the directory server instance.

Using command prompt:
On AIX, Linux, and Solaris platforms
$export REPLICATE_SECURITY_ATTRIBUTES=TRUE

On Windows platforms
c:\>set REPLICATE_SECURITY_ATTRIBUTES=TRUE
If you are using the bash shell on a Windows system, you can use the UNIX conventions.

After setting the environment variable, administrator must restart the directory server instances from the same command prompt to effect the changes made.

If the variable is not set or set to FALSE, then this feature is disabled and the behavior of the servers in the replication topology function as per the existing design. If the environment variable is not set on all replica servers with in a replication topology, then the changes to password policy operational attributes are not updated in consistent manner.


Working of the feature:
When a bind is performed by a user against a master server that affects the password policy attributes in the user entry, the master server records user entry updates in its database. The master server then replicates the updates to other servers with in the replication topology. If the feature is enabled on the replica server, the replica server updates password policy operation attributes in the user entry based on the replication updates. If the feature is disabled on the replica server, then the replica server does not update password policy operational attributes in the user entry that it received in replication updates.

If a bind is performed by a user against a replica server that affects the password policy attributes in the user entry, then the following scenarios can be considered based on the bind considering the feature is enabled on master and replica servers:

Scenario 1: An invalid bind on replica server resulting in updating of password policy operational attributes
If an invalid bind is performed by a user on a replica server, the replica server in turn notifies its identified master server using the user credentials with the replication bind failure timestamp control. The master server records the updates to password policy operational attributes for the user in its database and then replicates the updates to other servers. Simultaneously, the master server sends password failure timestamp in the control in its response to the replica server. The replica server updates password policy operation attributes of the user in its database with the timestamp received from the master server.

Scenario 2: A valid bind on replica server resulting in updating of password policy operational attributes
A valid bind by a user on a master or replica might result in updating of password policy operational attributes for a user. If a user entry has records of password failure timestamp, then these password failure records are cleared for a user on a successful bind if all of the listed conditions are met:
• The user account is not locked
• At least 1 password failure timestamp is present in the user entry
If a successful bind is performed by a user on a replica server after a few invalid binds and the account is not locked, then the password policy operational attribute are updated for the user in its database. This results in clearing of the password failure timestamp records for the user on the replica server. Simultaneously, the replica server also notifies the master server using the user credentials and updates the password policy operational attributes for a user in the database of master server. This also results in clearing of the password failure timestamp records for the user on the master server.

When a bind operation is performed by a user, the timestamp of the user entry does not get modified and does not differ between master and replica servers resulting in replication conflict. If the password policy is set, for a bind operation the password policy operational attributes are modified. These changes do not result in updating of user attribute such as modifyTimestamp that contribute to replication attribute. Since the modifyTimestamp attribute of user entry is not changed, it does not result in replication conflict.

If Tivoli Directory Servers earlier than v6.3 fix pack 10 (6.3.0.10) are used as master server or the feature is disabled on the master server, then the server does not recognize the control since the feature is not available. Therefore in such cases, master server does not return password failure timestamp with control to the replica server. If the replica server is of v6.3 fix pack 10 (6.3.0.10) level and the feature is enabled, then the replica server updates the password failure timestamp in the user entry with its own timestamp if a timestamp is not received from the master server. Recording its own timestamp by replica ensures that the user attempts are restricted to defined maximum failure count. Otherwise, if for any reason the replica server does not get the timestamp from the master server or is delayed then a user can perform unlimited bind attempts on the replica server.

In this scenario, there is a possibility of user account getting locked on the replica server before a user reaches the maximum failure count. For example, the effective maximum failure count for a user is 2 . If an invalid bind is attempted by the user on the replica server then the password failure timestamp is recorded in the database of the replica server for the user and the failure count is set to 1. Now, when the replication schedule is reached the updates from master server are replicated to other servers in the replication topology. The replication updates might result in setting the password failure count to 2 if the password failure timestamp is different than the timestamp recorded in the user entry. In this example, since the maximum allowed failure count is 2 the user account gets locked.

With earlier releases this feature is not available and updates to password policy operational attributes are treated as per existing design on both master and replica server.

Summarizing the working of the feature:
A summary on working of the feature when master and replica servers are running in normal state:

• Setting different values for the REPLICATE_SECURITY_ATTRIBUTES variable on the master and replica server and performing an invalid bind on the master server
• Setting different values for the REPLICATE_SECURITY_ATTRIBUTES variable on the master and replica server and performing an invalid bind on the replica server
• Setting different values for the REPLICATE_SECURITY_ATTRIBUTES variable on the master and replica server and performing a valid bind on the master server
• Setting different values for the REPLICATE_SECURITY_ATTRIBUTES variable on the master and replica server and performing a valid bind on the replica server

The assumption considered here is that the replica server has information about the list of master servers that it must notify.

Based on the availability of the master servers identified by the replica server, the timestamp recorded by the replica server in its database might differ.

• When all the identified master servers are unavailable, then for an invalid bind on the replica server the local timestamp of the replica server gets recorded its database.
• When one of the master server is available and the feature is enabled on master and replica servers, then for an invalid bind on either servers the password failure timestamp recorded on the master server is recorder on the replica server.
• When one of the master server is available and the feature is disabled on it and is enabled on the replica server, then for an invalid bind on master server the replica server depends on the replication updates to record the password failure timestamp. And for an invalid bind on replica server, the server notifies the master server about the invalid bind. If the master server does not acknowledge with a timestamp in the control, then the replica server updates the password failure timestamp in the user entry with its own timestamp.

Table1. Behavior of the feature based on the environment variable value for an invalid bind on master server

	Value of the variable		Updating of password policy operational attributes
Conditions under which password policy operational attributes are updated	On master	On replica	On master	On replica
Scenario 1	TRUE	TRUE	YES	YES*
Scenario 2	TRUE	FALSE / Not set	YES	NO
Scenario 3	FALSE / Not set	TRUE	YES	YES*
Scenario 4	FALSE / Not set	FALSE / Not set	YES	NO

Note: YES* : Updates the password policy operational attributes for a user based on the replication updates that are received from the master server.

Table 2. Behavior of the feature based on the environment variable value for an invalid bind on replica server

	Value of the variable		Notifying about an invalid bind with control	Acknowledging replica with timestamp in control	Updating of password policy operational attributes
Conditions under which password policy operational attributes are updated	On master	On replica	Replica -> Master	Master -> Replica	On master	On replica
Scenario 1	TRUE	TRUE	YES	YES	YES	YES
Scenario 2	TRUE	FALSE / Not set	NO	NO	NO	YES*
Scenario 3	FALSE / Not set	TRUE	YES	NO	YES	YES**
Scenario 4	FALSE / Not set	FALSE / Not set	NO	NO	NO	YES*

Note:

• YES* : Updates the password policy operational attributes for a user based on the bind on the replica server. These updates are not propagated to other servers in the replication topology.
• YES** : Updates the password policy operational attributes for a user based on the bind on the replica server. These updates are propagated by the master server to other servers of the replication topology.

Table 3. Behavior of the feature based on the environment variable value for a valid bind on master server

	Value of the variable		Updating of password policy operational attributes
Conditions under which password policy operational attributes are updated	On master	On replica	On master	On replica
Scenario 1	TRUE	TRUE	YES	YES*
Scenario 2	TRUE	FALSE / Not set	YES	NO
Scenario 3	FALSE / Not set	TRUE	YES	YES*
Scenario 4	FALSE / Not set	FALSE / Not set	YES	NO

Note: YES* : Updates the password policy operational attributes for a user based on the replication updates that are received from the master server.

Table 4. Behavior of the feature based on the environment variable value for a valid bind on replica server

	Value of the variable		Notifying about valid bind with control	Acknowledging replica with timestamp in control	Updating of password policy operational attributes
Conditions under which password policy operational attributes are updated	On master	On replica	Replica -> Master	Master -> Replica	On master	On replica
Scenario 1	TRUE	TRUE	YES	YES	YES	YES
Scenario 2	TRUE	FALSE / Not set	NO	NO	NO	YES*
Scenario 3	FALSE / Not set	TRUE	YES	NO	YES	YES**
Scenario 4	FALSE / Not set	FALSE / Not set	NO	NO	NO	YES*

Note:

• YES* : Updates the password policy operational attributes for a user based on the bind on the replica server. These updates are not propagated to other servers in the replication topology.
• YES** : Updates the password policy operational attributes for a user based on the bind on the replica server. These updates are propagated by the master server to other servers of the replication topology.

Replication bind failure timestamp control

Description:
This control is used to propagate bind failure timestamp value from a master server to a replica server in a replication environment.

This control is honored by a server in a replication topology only when REPLICATE_SECURITY_ATTRIBUTES is set to TRUE.

If the REPLICATE_SECURITY_ATTRIBUTES variable is set on a replica server, an invalid bind on the replica server results in notifying the identified master server by passing this control along with the bind operation for the same credentials.

If the variable is set on the master server, the master server propagates bind failure timestamp value to the replica server in its response. The replica server on obtaining the failure timestamp from master, records this timestamp in its database so that both replica and master servers record the same password failure timestamp for same bind failure.

If the variable is not set on the master server, then the master server does not interpret the control received from the replica server. Since the master is unable to interpret the control, it does not return the password failure timestamp in its response to the replica server. However, master server updates its password failure count and then replicates it to other servers. If the replica server does not receive the password failure timestamp from the master in its response, then the replica records the password failure timestamp at its end in the database.

OID:
1.3.18.0.2.10.34

Syntax:
The response value is set to the bind failure timestamp of the master server in string format.

Behavior:
This control is registered only for a bind operation.

The control is sent to an identified master server by a replica server as an internal request along with a bind operation using the same user credentials. The replica server sends the request when a bind operation is performed by the user on the replica server resulting in invalid credentials, password expiration, or password grace use time. In the control response, a timestamp value of invalid credentials, password expiration, or password grace use time is sent from the master to replica server. The control is meant for RDBM back-end and is honored by master server only.

This control can be sent by any user but is expected to be sent by a replica server. If this control is sent by any external client or any other user, master server functions in the same way and returns password failure timestamp. The control is a non critical control and return code does not vary.

No additional information is required for the control. If any additional information is sent, it is ignored. The return response from master server might contain password failure timestamp value.

The timestamp returned as response in the control as additional information is parsed using the regular LDAP ldap_get_result_control call. If there is an error in the format of the timestamp, then instead of the return timestamp from master server, the current timestamp of the replica server is recorded in the database of replica server.

This control operates independent of other controls. Therefore, the control does not depend on other control and does not affect the behavior of other controls.
This control is not supported by the Administration Server.

Scope:
The control lasts for the term of one operation.

Auditing:
In this control, the following information is audited:
• OID
• Timestamp in string format

Special considerations:
When using this feature, user must consider the listed points to determine any possible change in behavior.

• User might see inconsistent behavior in the updating of password policy operational attributes if this feature is disabled on some servers within a replication topology.
• If the password failure count is not in sync for a user on all servers, then a successful bind by the user on a server might not reset the password failure count on all servers. For example, consider a master server already has two invalid bind attempts by a user and no invalid bind attempts on a replica before the feature is enabled. After enabling the feature, if a user performs a successful bind on the replica server then the bind does not trigger in resetting of the password failure counts on the master server. This is because on the replica server the password failure count was 0.
• Usually, clearing of invalid bind attempts is done by performing a successful bind or unlocking of the account at one of master servers unlocks user account on all servers. In exceptional cases, password administrator might need to unlock user account for a user specifically on a particular server. Consider a replication topology consisting of a master and replica server where the feature is enabled on both the servers and the maximum allowed failure attempts is 3. After two failed bind attempts, the master and replica have password failure attempts as 2 for the user on each server. Now, if the master server fails and an invalid bind is attempted on the replica server then the user accounts gets locked on the replica since it has logged 3 password failure attempts. At this time, the password failure attempts for the user on master remains at 2. When master server is brought online, a successful bind attempt by the user on the
• master server resets the password failure attempts to 0. Whereas, this successful bind on master server does not reset the password failure attempts to 0 on the replica server for the user since the account is already locked. In this example scenario, password administrator needs to unlock the user account for the user to access the replica server.
• When a user performs invalid bind attempts on a master server, multiple pwdFailureTime entries are recorded on the master server for the user. When the master server replicates these updates to the replica server, only the pwdFailureTime entries with distinct timestamp values are recorded in the database of the replica server for the user. That is, out of the multiple pwdFailureTime entries with the same timestamp value in the master server only one pwdFailureTime entry is recorded on the replica server for a user and the remaining entries with the same timestamp are not recorded. An example of a user entry from the master server running on port 389 and replica server running on port 2389 with multiple pwdFailureTime records.
# idsldapsearch -p 389 -D <adminDN> -w <adminPWD> -s sub -b "cn=user02,ou=pu,o=sample" objectclass=* +ibmpwdpolicy
cn=user02,ou=pu,o=sample
pwdChangedTime=20110914053218.807758Z
pwdAccountLockedTime=20111014080533.000000Z
pwdFailureTime=20111014080532.000000Z
pwdFailureTime=20111014080532.000000Z
pwdFailureTime=20111014080533.000000Z
#
# idsldapsearch -p 2389 -D <adminDN> -w <adminPWD> -s sub -b "cn=user02,ou=pu,o=sample" objectclass=* +ibmpwdpolicy
cn=user02,ou=pu,o=sample
pwdChangedTime=20110914053218.807758Z
pwdAccountLockedTime=20111014080533.000000Z
pwdFailureTime=20111014080532.000000Z
pwdFailureTime=20111014080533.000000Z
#
• When a user performs valid bind attempts on a master server after the password expiry, then the pwdGraceUseTime entries are recorded on server for the user if the pwdGraceLoginLimit attribute is set. When the master server replicates these updates to the replica server, only the pwdGraceUseTime entries with distinct timestamp values are recorded in the database of the replica server for the user. That is, out of the multiple pwdGraceUseTime entries with the same timestamp value in the master server only one pwdGraceUseTime entry is recorded on the replica server for a user and the remaining entries with the same timestamp are not recorded. An example of a user entry from master server running on port 3389 and replica server running on port 13389 with multiple pwdGraceUseTime records.
# idsldapsearch -p 3389 -D <adminDN> -w <adminPWD> -s sub -b "cn=user01,ou=mum,o=sample" objectclass=* +ibmpwdpolicy
cn=user01,ou=mum,o=sample
pwdChangedTime=20111014103004.000000Z
pwdExpirationWarned=20111014103143.000000Z
pwdHistory=20111014102507Z#2.5.4.35#32#{AES256}gXurNKCz6CYROt8miTtVRw==
pwdHistory=20111014103004Z#2.5.4.35#32#{AES256}1yfDaLmvJ7RpW42kDKSN+A==
pwdGraceUseTime=20111014103305.000000Z
pwdGraceUseTime=20111014103308.000000Z
pwdGraceUseTime=20111014103308.000000Z
#
# idsldapsearch -p 13389 -D <adminDN> -w <adminPWD> -s sub -b "cn=user01,ou=mum,o=sample" objectclass=* +ibmpwdpolicy
cn=user01,ou=mum,o=sample
pwdChangedTime=20111014103004.000000Z
pwdExpirationWarned=20111014103143.000000Z
pwdGraceUseTime=20111014103305.000000Z
pwdGraceUseTime=20111014103308.000000Z

Server performance:

When a bind request is performed on a replica server that affects password policy operational attributes in a user entry, then this feature performs additional tasks:

• Identifying the master server to notify
• Propagating the bind from replica to master server

These additional operations might have some impact on the performance of the servers in a replication environment as a trade-off against security enhancement.
Note: When configuring replication, you must cryptographically synchronize the server instances to obtain better performance.


Log details:
Logs related to the replication of password policy operational attributes are logged in the listed files:

• The information about the REPLICATE_SECURITY_ATTRIBUTES environment variable state is logged in the ibmslapd.log and traceibmslapd.log files.
• If a replica server does not have the list of master servers to notify about bind information, then the feature is disabled and appropriate message is logged in the ibmslapd.log file.
• The password failure timestamp that gets updated on the replica server can be the timestamp generated at its end, timestamp in response control from the master server, or replicated timestamp from the master server. This information about which timestamp is recorded by the replica server is logged in the traceibmslapd.log file.
• All failure path error messages are recorded in the traceibmslapd.log file.
• All bind related operations, which include failed binds and successful binds, and password policy operational attributes are logged in the audit log.
• All bind requests that affect password policy operational attributes for a user on the replica server and are notified to the master server are treated as a special bind. Such bind details are logged in the audit log. These logs can be used by the administrator to check the operations performed by the servers.