PingDirectory

Configuring password validators for updates and binds

The PingDirectory server supports invoking password validators while processing both updates and bind operations.

Updates

Password policies contain the following properties for configuring the set of password validators that are invoked for add operations, modify operations, and password modify extended operations.

password-validator

The set of password validators that should be invoked. Zero or more validators can be configured.

skip-validation-for-administrators

Indicates whether to allow administrators to set passwords that do not satisfy the password validation requirements.

No validators are included in the out-of-the-box configuration for the default password validator. Unless the --allowWeakRootUserPassword argument is provided when running setup, or the equivalent option is chosen when setting up the server in interactive mode, the passwords for root users and topology administrators are subject to the following requirements:

  • The password must contain at least 12 characters.

  • The password must not be contained in a dictionary of common words in various languages

  • The password must not be contained in a dictionary of commonly used passwords

The skip-validation-for-administrators property is false by default in both the default password policy and the policy for root users and topology administrators.

Binds

The PingDirectory server also provides support for invoking password validators while processing bind operations in which the server has access to the user’s clear-text password.

This can be useful in at least a couple of key circumstances:

  • If you use a service like Pwned Passwords that is regularly updated with information from new data breaches

  • If you maintain one or more dictionaries of banned passwords and update them with new values

  • If you enable a new validator or change the configuration of an existing validator

The set of password validators that are configured for add, modify, and password modify operations is not automatically used for bind operations. Rather, you can explicitly configure which validators (if any) should be invoked for binds.

Similarly, password validators do not have to be invoked for every bind. In many cases, it might be better to only periodically invoke validators to reduce the potential impact on performance. This is especially true for cases in which validation might interact with external systems like the Pwned Passwords service.

Password policies provide the following configuration properties related to invoking password validators on bind:

bind-password-validator

The set of password validators to invoke for bind operations. Zero or more validators can be configured, and none are configured by default.

minimum-bind-password-validation-frequency

The minimum frequency that can be used when invoking validators for users. If this is set to zero seconds, then password validators will be invoked for each bind. If it is set to a value that is greater than zero, then the server keeps track of the last time it invoked bind password validators for that user and only invokes the validators if at least that much time has passed since the last set of validation. The default validation frequency is 30 days.

bind-password-validation-failure-action

The action that the server should take if a user’s password fails validation during a bind. Allowed values include:

  • force-password-change: Indicates that the bind attempt should succeed, but the user will be forced to choose a new password before they are allowed to perform any other operations in the server. The bind response includes a password expired response control and a diagnostic message that describes the problems identified with the password. This is the default behavior.

  • reject-bind: Indicates that the bind attempt should fail and the user’s account should be locked. An administrative password reset is required to restore access to the user’s account.

  • generate-account-status-notification: Indicates that the bind attempt should succeed, but that the server should generate an account status notification to make the user or server administrators aware of the weakness, or potentially to take custom action in response to it.

See the config/sample-dsconfig-batch-files/enable-password-validation-for-binds.dsconfig batch file for more information about enabling password validators for binds.