PingDirectory

Password policy tips to improve performance

Consider these best practices for server performance when configuring your password policies.

For your environment, you might configure password policies for different account types and operations so that your policies apply beyond user password changes. For example, when a user signs on, these policies could be triggered to update the last-login-timestamp or validate a password during a bind operation.

Given that password policies can affect many server operations, they can also affect server performance. Poorly configured password policies can lead to some of the following issues:

  • Slow password binds, replication, or replication topology changes

  • A growing replication backlog

  • Timing out of replication topology changes

  • Excessive use of heap memory indicated by unexpected garbage collection cycles

Create explicit password policies scoped to groups of users or organizations and be careful when changing the default password policy.

The following table describes password policy configurations that can limit server performance and corresponding recommendations to avoid these limitations:

Limiting configuration Recommended configuration

Creating a last-login-timestamp that includes milliseconds.

This can limit performance as follows:

  • Every bind triggers an update of the entry.

    • The updated entry has to be replicated.

    • The change to the entry gets recorded in the ds-sync-hist operational attribute.

  • If a service account is within the scope of the policy (for example, the default policy or a group for a virtual attribute), and the service account binds frequently, replication or memory garbage collection could affect service availability.

  • Limit the resolution of any last-login-timestamp attributes using the yyyymmdd format.

    • If you need more precise time resolution, limit the bytes of replication-history-limit or the duration of sync-hist-purge-delay.

  • Create special password policies for service accounts and keep updates to a minimum.

Creating a bind scoped validator that accesses an external service (such as a pwned password validator).

Every bind validation is as slow as the response of the external service. While this configuration might not have a large impact in many cases, it can limit performance where bind password validation frequency is high. The server performs bind password validation according to the minimum-bind-password-validation-frequency configuration property, which is set to 30 days by default.

Learn more in Configuring password validators for binds.

Avoid external validation services if you set a high frequency for bind password validation.

Creating a password policy for a large number of users that uses a key derivation function.

This can limit performance by significantly increasing the CPU capacity required to process binds.

For version 10.2 and later:

While the processing cost for first-time user binds that use expensive password storage schemes is high, subsequent bind attempts by users who have previously authenticated since the server started could be significantly reduced by Encoded password caching.

Consider reducing widespread use of key derivation function password storage schemes.

Creating a password policy that relies on interacting with external services such as HashiCorp Vault, CyberArk Conjur, AWS Secrets Manager, or Azure Key Vault.

This can limit performance because each bind authentication is as slow as the response of the external service and can’t be mitigated by encoded password caching.

Limit password polices that require external services to sensitive accounts.

Creating a password policy that updates root user or topology administrator entries, which are stored in the config.ldif file.

This can limit performance because every bind operation triggers the following:

  • The config.ldif file gets completely rewritten.

  • The config.ldif file gets backed up.

    • Backups can slow down the completion of dsreplication subcommands including enable, disable, and remove-defunct-server.

  • The server raises an alert.

Changes to topology administrator entries are mirrored to other servers in the topology, further affecting performance.

Don’t add policy constraints that update the entry for root user or topology administrator accounts.