Assigning password policies to users

Each user is associated with a password policy that governs their activity in the server, and different users can have different password policies.

Whenever the server processes an operation that attempts to authenticate a user, change their password, or interact with their password policy state in some way, it needs to select an appropriate password policy to use for that processing.

A user can be associated with a password policy through the ds-pwp-password-policy-dn operational attribute. If this attribute exists in the user’s entry and refers to a valid password policy, then the user is subject to that password policy. If that attribute exists but refers to a nonexistent policy, then that user is unable to authenticate or be used as an alternate authorization identity. If a user’s entry does not include the ds-pwp-password-policy-dn operational attribute, then that user is subject to the server’s default password policy, which is specified by the default-password-policy property in the global configuration.

The ds-pwp-password-policy-dn operational attribute can be either real or virtual. You can explicitly set a value for the attribute in a user’s entry, but it is also possible to have the server generate a value for that attribute based on some criteria using the virtual attribute subsystem. For example, you could use a virtual attribute to automatically assign the same password policy to all members of a specified group or to all users in a specified portion of the DIT.

A user should not be conditionally subjected to different password policies under different circumstances. While it is technically possible to use virtual attributes that assign different values to the same attribute under different conditions, this capability should not be used for the ds-pwp-password-policy-dn attribute.

For example, you should not attempt to detect which application has issued a request and select a password policy based on that application. The server only maintains one set of password policy state for each user, and attempting to access the same user under different password policies might have unexpected adverse effects and can introduce security risks.

Maintaining password policies in user data

While password policies are typically defined in the server configuration, it is also possible to define them in user data.

This is particularly useful when the PingDirectory server is used to back a multi-tenant application, in which information about many different organizations is maintained in the same server instance, typically with a separate branch for each organization. You can configure password policies on a per-organization basis.

Each password policy must be defined in an entry containing the ds-cfg-password-policy structural object class. The definition of this object class can be found by querying the server schema over LDAP, by retrieving the "cn=schema" entry, or by looking in the config/schema/02-config.ldif schema definition file. The names of the LDAP attribute types which should correspond to names of the password policy configuration properties that are available in dsconfig or the administration console with a "ds-cfg-" prefix.

For example, the following entry represents a minimal password policy that might be defined in user data:

dn: cn=Org X Password Policy,ou=Org X,ou=tenants,dc=example,dc=com
objectClass: top
objectClass: ds-cfg-password-policy
cn: Org X Password Policy
ds-cfg-password-attribute: userPassword
ds-cfg-default-password-storage-scheme: cn=Salted SHA-256,cn=Password Storage
  Schemes,cn=config

Assign users to password policies contained in the user data in the same way that you assign them to policies in the configuration. Include the ds-pwp-password-policy-dn operational attribute in their entry as either a real or a virtual attribute.

While password policies can reside in user data, any other configuration elements that they reference, including password storage schemes, password validators, password generators, account status notification handlers, and failure lockout actions, must reside within the configuration.

For improved performance, the PingDirectory server maintains a cache of password policy entries that are defined in the user data. This cache holds up to 500 policies by default, but you can tune that through the maximum-user-data-password-policies-to-cache property in the global configuration.