Password Policy Compatibility

For migration purposes, the new password policy maintains compatibility with previous Directory Server versions by implementing a compatibility mode. The compatibility mode determines whether password policy attributes are handled as old attributes or new attributes, where old refers to Directory Server 5.2 password policy attributes.

This section contains information to help you set the compatibility mode and to decide which mode is appropriate for your deployment.

Setting the Compatibility Mode

The compatibility mode can be read using dsconf command as follows:

$ dsconf get-server-prop pwd-compat-mode

The pwd-compat-mode property can have one of the following values:

DS5-compatible-mode

The purpose of DS5-compatible-mode is to allow an existing replicated topology to be migrated from Directory Server 5.2 instances to Directory Server 11g Release 1 (11.1.1.5.0) instances. A Directory Server 11g Release 1 (11.1.1.5.0) instance in DS5-compatible-mode accepts updates containing either old or new password policy attributes, and produces updates containing both sets of attributes. Updates can arrive from an LDAP client or from replication, and changes are produced locally as a result of password policy evaluation (for example, as a result of a failed authentication or a password change). Note that any version 5.2 instance consuming replicated updates produced by a version 11g Release 1 (11.1.1.5.0) instance (either directly or through another instance) must have its schema updated with 00ds6pwp.ldif as described in Issues With the Password Policy in Oracle Directory Server Enterprise Edition Upgrade and Migration Guide. While the Directory Server 5.2 instance will ignore any new attributes during password policy processing, when an entry containing the new attributes is modified at that instance, without the schema update, the schema check will fail when the modified entry is written.

DS6-migration-mode

DS6-migration-mode is an intermediate step between DS5-compatible-mode and DS6-mode, All policy decisions are based on the new password policy attributes and the old (Directory Server 5.2) password policy attributes are removed from the server's data. Since the number of policy configuration entries is small, the old password policy configuration attributes are cleaned from all policy entries as soon as the instance is advanced to DS6-migration-mode. However, the cleanup of a user entry is deferred until the entry is modified as part of normal password policy processing during a password modify operation. This approach allows the cleanup to proceed gradually, so as to not degrade the server's performance. The modifications necessary to remove any old policy attributes are not replicated so that they do not interfere with the operation of instances still in DS5-compatible-mode.

DS6-mode

A Directory Server instance in DS6-mode uses only new policy attributes in computing password policy decisions. Any old password policy attributes remaining in an entry are ignored.

The compatibility mode is set using the dsconf command as follows:

$ dsconf pwd-compat new-mode

The new-mode action takes one of the following values:

to-DS6-migration-mode

Change to DS6-migration-mode from DS5-compatible-mode.

Once the change is made, only DS6-migration-mode and DS6-mode are available.

to-DS6-mode

Change to DS6-mode from DS6-migration-mode.

Once the change is made, only DS6-mode is available.

The server state can move only towards stricter compliance with the new password policy specifications.

Guidelines for Choosing a Compatibility Mode

The pwd-compat-mode setting affects the internal server operation and is largely isolated from the password policy behavior seen by an LDAP client. In particular, the pwd-compat-mode setting does not affect the range of server responses to an LDAP client authentication (bind).

This section provides details about the compatibility mode appropriate to your Directory Server deployment.

New Directory Server 11g Release 1 (11.1.1.5.0) Deployment

If you install a standalone Directory Server instance or are deploying a new replicated topology, set the compatibility mode to DS6-mode to immediately take advantage of the features available in the new password policy implementation. Since a new Directory Server 11g Release 1 (11.1.1.5.0) instance is created with the compatibility mode set to DS5-compatible-mode, you will need to remember to advance the instance to DS6-mode before installing it into a replicated topology whose instances are already set to DS6-mode.

Migrating a Deployment to Directory Server 11g Release 1 (11.1.1.5.0)

If you are migrating an existing replicated topology, as long as at least one Directory Server 5.2 instance remains in the replication topology, all of the Directory Server 11g Release 1 (11.1.1.5.0) instances must be set to DS5-compatible-mode.

Once a replicated topology has been completely migrated (in DS5-compatible-mode), you can consider advancing from maintaining compatibility with the old password policy to using the new password policy exclusively. Moving from DS5-compatible-mode to DS6-mode occurs in two phases, which includes an intermediate stage in DS6-migration-mode. First, the Directory Server 11g Release 1 (11.1.1.5.0) instances must be left in DS5-compatible-mode for an entire password expiration cycle so that the user entries are populated with the new pwdChangedTime attribute. Any applications that depend on the old password policy attributes must also be migrated to the new attributes while the Directory Server 11g Release 1 (11.1.1.5.0) instances are in DS5-compatible-mode, since the old attributes are no longer available in DS6-migration-mode. At this point, the instances comprising the replicated topology can be advanced to DS6-migration-mode.

The second phase consists of running all instances of the replicated topology in the intermediate DS6-migration-mode to clean out the old operational attributes in the entries. This cleanup must occur before advancing from DS6-migration-mode to DS6-mode. Otherwise, the stale attributes will remain in the entries. To mitigate the overhead of cleaning the old password policy operational attributes, the Directory Server 11g Release 1 (11.1.1.5.0) instance only removes the attributes in conjunction with a password modify. Thus a simple approach to the cleanup, assuming the password expiration feature is enabled, is to leave the Directory Server 11g Release 1 (11.1.1.5.0) instances in DS6-migration-mode for an entire password expiration cycle. Finally, once the old password policy attributes have been cleaned from the entries, the instances can be moved to DS6-mode. Remember that the new Directory Server 11g Release 1 (11.1.1.5.0) instance is created and set to DS5-compatible-mode. You will need to remember to advance the instance to DS6-mode before installing it into a replicated topology whose instances are already at DS6-mode.

The following table shows the allowed combinations of Directory Server versions and password policy compatibility modes. Note that at most two variations are allowed in a replicated topology at any time. For example, if a topology contains a Directory Server 11g Release 1 (11.1.1.5.0) instance in DS5-compatible-mode and one in DS6-migration-mode, then those are the only two variants allowed: no legacy Directory Serverinstances or Directory Server 11g Release 1 (11.1.1.5.0) instances in DS6-mode are allowed.

Table 7-1 Directory Server Password Policy Mode Interoperability

Administrative Password Reset Classification

Password policy features such as must-change-on-reset (pwd-must- change-enabled) and administrative bypass of password quality checks (pwd-root-dn-bypass-enabled) depend on classifying the modification of the userPassword attribute as either a self-change or an administrative reset.

In Directory Server 5.2, by default, only the Directory Manager can perform an administrative reset of a user's password. Any other password change is considered as a self-change. Directory Server 5.2p4 introduced the password policy configuration attribute passwordNonRootMayResetUserpwd that, when enabled, limits the userPassword modify operations that are considered as a self-change to the following two cases:

1. A user is authenticated and changing the password of his or her own account.

2. An administrator changes the password, but the LDAP Proxied Authorization Control (http://www.ietf.org/rfc/rfc4370.txt) is set for the userPassword modify operation, and the proxied user DN is the target of the modify operation.

Any other password change is considered as an administrative reset. This feature eliminates the requirement of using Directory Manager for routine password administration, while the simple other-than- self (password change made by any other user but not by self) test avoids the complexity of a separate scheme to identify administrative users.

In this version, Directory Server evaluates password changes similar to Directory Server 5.2 with passwordNonRootMayResetUserPassword enabled. That is, Directory Server considers a password change as an administrative reset except for a user changing his or her own password, or when the proxied authorization control is used. Even though the passwordNonRootMayResetUserpwd attribute can be present in a Directory Server password policy configuration entry when the instance is in Directory Server 5.2 compatible mode, the attribute can not be modified and the feature is always enabled.

If your Directory Server 5.2 based LDAP application uses an administrative account other than Directory Manager to change a password on behalf of a user (that is, the change should be a self-change), when the application is used with Directory Server 7.0, the change will be considered as an administrative reset. You can restore the original behavior by using the LDAP Proxied Authorization Control (http://www.ietf.org/rfc/rfc4370.txt) with the userPassword modify operation. The proxied authorization control handles the operation as if it is invoked by the proxied user. The control is available in the LDAP C SDK (https://wiki.mozilla.org/LDAP_C_SDK) and LDAP SDK for Java (http://www.mozilla.org/directory/javasdk.html), and the ldapmodify command. Invoke the proxied authorization control using the ldapmodify command as follows:

$ ldapmodify -D <administrative-user-DN > -Y <proxied-user-DN>