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:

The set of password validators to invoke for bind operations. Zero or more validators can be configured, and none are configured by default.
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.
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.