Pre-encoded passwords

Whenever possible, passwords to be stored in PingDirectory server should be provided in the clear.

This is likely not an option when migrating data from an existing system into PingDirectory server, as passwords from those systems are likely already encoded in a non-reversible form. However, passwords included in add, modify, and password modify operations should be provided in the clear. If users are allowed to provide passwords in pre-encoded form, then they might be able to exempt themselves from some of the server’s password quality constraints, including:

The server cannot validate a pre-encoded password to ensure that it meets password quality requirements. Allowing pre-encoded passwords can therefore allow users to choose weak passwords.
The server cannot ensure that a pre-encoded password is not just an alternative representation of the same password that they are currently using (for example, one that just uses a different salt), or a password that is already in their history. Allowing pre-encoded passwords can therefore allow users to circumvent restrictions around password expiration and password reuse.
The server cannot ensure that passwords are encoded using the desired scheme. Allowing pre-encoded passwords can permit clients to use encodings that are not as resistant to password cracking attacks, and can also make it harder to migrate to migrate to stronger schemes in the future.

By default, PingDirectory server does not permit clients to provide pre-encoded passwords. While this restriction can be lifted using the allow-pre-encoded-passwords in the password policy configuration, we discourage this for the reasons listed above. In the event that there are legitimate use cases in which some applications might need to set pre-encoded passwords, such as when synchronizing passwords from another system into the PingDirectory server, there are a couple of better alternatives:

You can update the account used by any such applications to grant them the bypass-pw-policy privilege. This privilege exempts the user from certain password policy restrictions when setting new passwords for other users, but not when changing the password for their own account. This includes:
- They are permitted to set pre-encoded passwords.
- They are permitted to set passwords that would otherwise fail password validation.
- They are permitted to set passwords that are already in the user’s password history.
The client can use the password update behavior request control to customize the behavior that the server exhibits for the associated operation.