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 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
instances to Directory Server 6.2 instances. A Directory Server 6.2 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 instance consuming replicated updates produced by
a version 6.2 instance (either directly or through another
instance) must have its schema updated with 00ds6pwp.ldif as
described in Issues With the New Password Policy.
While the Directory Server 5 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) 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 6.2 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. Compatibility with the old password policy
will not be supported indefinitely. You should therefore migrate to the new
password policy as soon as is feasible for your deployment.

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).

Note –

The configuration and operational attributes used to implement
the password policy depend on the pwd-compat-mode setting.
Therefore, an LDAP application that accesses the old (Directory Server 5)
attributes will need to be modified prior to advancing the pwd-compat-mode beyond the initial DS5-compatible-mode.

Note –

DS5-compatible-mode is the default setting.
If you upgrade an existing server to Directory Server 6.2 or
if you create a new Directory Server 6.2 instance, the
compatibility state is set to DS5-compatible-mode.

New Directory Server 6.2 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 6.2 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.

If you are migrating an existing replicated topology, as long as at
least one Directory Server 5 instance remains in the replication topology,
all of the Directory Server 6.2 instances must be set to
DS5-compatible-mode.

Once a replicated topology has been completely migrated from Directory Server 5
to Directory Server 6.2 (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 6.2 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 6.2 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 6.2 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 6.2 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 6.2 instance is
created 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 6.2 instance in DS5-compatible-mode and one in DS6-migration-mode, then those are
the only two variants allowed: no Directory Server 5 instances or Directory Server 6.2 instances
in DS6-mode are allowed.

Table 5–4 Directory Server Password Policy Mode
Interoperability

Directory Server 5

Directory Server 6.2 in DS5-compatible-mode

Directory Server 6.2 in DS6-migration-mode

Directory Server 6.2 in DS6-mode

Directory Server 5

X

X

Directory Server 6.2 in DS5-compatible-mode

X

X

X

Directory Server 6.2 in DS6-migration-mode

X

X

X

Directory Server 6.2 in DS6-mode

X

X

Changes to 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, 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:

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

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.

Directory Server 6.x evaluates password changes similar to Directory Server 5.x
with passwordNonRootMayResetUserPassword enabled. That
is, Directory Server 6.x 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 6.x password
policy configuration entry when the instance is in Directory Server 5.x
compatible mode, the attribute can not be modified and the feature is always
enabled.

If your Directory Server 5 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 6.x, 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 (http://wiki.mozilla.org/LDAP_C_SDK) and LDAP SDK
for Java (http://www.mozilla.org/directory/javasdk.html),
and the ldapmodify command included with DSRK 6. Invoke
the proxied authorization control using the ldapmodify command
as follows:

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

Note –

The ldapmodify commands from other products
might use a different flag, or might not support the proxied authorization
control at all.