Passwords in DS

This book provides information on passwords in DS and includes a chapter on the Password Synchronization Plugin.


How does DS (All versions) store password values?

The purpose of this article is to provide information on the password storage scheme formats used in DS. This information can help you understand the secureness of different schemes and how they compare. Additionally this information may be helpful if you have passwords hashed in another system and want to convert them for import into DS.

Overview

DS 7 introduces new password storage schemes, and also disables less secure and reversible schemes by default for improved security. See Default Security Settings for further information.

The password storage schemes that are enabled by default are as follows:

  • Bcrypt
  • PBKDF2-HMAC-SHA256
  • PBKDF2-HMAC-SHA512
  • SCRAM-SHA-256
  • SCRAM-SHA-512

Password storage scheme formats

The following table provides details of the password scheme formats in use in DS, where:

  • <digest> is the bytes returned from the relevant asymmetric hashing function.
  • <encrypted> is the bytes returned from the relevant symmetric encryption function.
  • <salt> is the salt bytes.
  • base64(...) is the standard base64 encoding of ...
  • "" surrounds literal characters in the password value.

Password Schemes 

Name Applicable versions Salt size (bytes) Key size (bits) Format
AES All ±   128 "{AES}" base64(<encrypted>)
Base64 All     "{BASE64}" base64(<password>)
Bcrypt * All 16   "{BCRYPT}" <digest>
Blowfish All ±   128 "{BLOWFISH}" base64(<encrypted>)
Clear All     "{CLEAR}" <password>

Crypt

  • UNIX **
  • MD5 ***
  • SHA256 ***
  • SHA2512 ***
All

     

  • 2
  • 8
  • 8
  • 8
 

      

  • "{CRYPT}" <digest>
  • "{CRYPT}" "$1$" <digest>
  • "{CRYPT}" "$5$" <digest>
  • "{CRYPT}" "$6$" <digest>
MD5 Pre-DS 7     "{MD5}" base64(<digest>)
PBKDF2 (PBKDF2-HMAC-SHA1) All 16 (8 in pre-DS 7)   "{PBKDF2}" <iterations> ":" base64(<digest> <salt>)
PBKDF2-HMAC-SHA256 DS 7 and later 16   "{PBKDF2-HMAC-SHA256}" <iterations> ":" base64(<digest> <salt>)
PBKDF2-HMAC-SHA512 DS 7 and later 16   "{PBKDF2-HMAC-SHA512}" <iterations> ":" base64(<digest> <salt>)
PKCS5S2 (PKCS#5 V2.0 Scheme 2) **** All 16   "{PKCS5S2}" base64(<digest> <salt>)
RC4 Pre-DS 7 ±   128 "{RC4}" base64(<encrypted>)
Salted MD5 Pre-DS 7 8   "{SMD5}" base64(<digest> <salt>)
Salted SHA-1 All 16 (8 in pre-DS 7)   "{SSHA}" base64(<digest> <salt>)
Salted SHA-256 All 16 (8 in pre-DS 7)   "{SSHA256}" base64(<digest> <salt>)
Salted SHA-384 All 16 (8 in pre-DS 7)   "{SSHA384}" base64(<digest> <salt>)
Salted SHA-512 All 16 (8 in pre-DS 7)   "{SSHA512}" base64(<digest> <salt>)
SCRAM-SHA-256 DS 7 and later     Refer to RFC 5802, RFC 5803 and RFC 7677 for further details on the format.
SCRAM-SHA-512 DS 7 and later     Refer to RFC 5802, RFC 5803 and RFC 7677 for further details on the format.
SHA-1 All     "{SHA}" base64(<digest>)
Triple-DES All ±   168 "{3DES}" base64(<encrypted>)

± Deprecated in DS 7

* This <digest> is OpenBSD's bcrypt implementation, which uses a custom base64 encoding. See bcrypt - A FutureAdaptable Password Scheme for further information.

** This is a traditional Unix algorithm (12-bit salt).

*** See Modular Crypt Format for further information.

**** See Atlassian’s PBKDF2-based Hash for further information.

See Password Storage Scheme for details of what properties are allowed for each scheme.

Example Using Salted SHA-1

The following Java 11 code breaks apart a password hashed using the Salted SHA-1 scheme. The SHA-1 algorithm always returns 20 bytes, and the example code works successfully with passwords encoded with different size salts:

package org.example; import java.util.Arrays; import java.util.Base64; public class Demo {    static final int SHA_ALGORITHM_SIZE = 20; // Number of bytes returned from a SHA-1 hash     static final String PREFIX = "{SSHA}"; // Salted SHA-1 prefix     public static void main(String[] args)     {         var original = "{SSHA}jDgrs5iv+guDhuU9tuWp3Y4NIMxJ8jb8Cd1uu8w/urdrRB5V"; // "secret"         var base64 = original.substring(PREFIX.length());         var bytes = Base64.getDecoder().decode(base64);         var hashBytes = Arrays.copyOfRange(bytes, 0, SHA_ALGORITHM_SIZE);         var saltBytes = Arrays.copyOfRange(bytes, SHA_ALGORITHM_SIZE, bytes.length);         System.out.println("Hash length = " + hashBytes.length);         System.out.println("Salt length = " + saltBytes.length);     } }

See Also

FAQ: Passwords in DS

Password Storage

Related Training

N/A

Related Issue Tracker IDs

N/A


How does password expiration work in DS (All versions)?

The purpose of this article is to provide information on how password expiration works in DS. It assumes you have warnings enabled.

Password expiration

If you set up password expiration, the warning gets triggered when the user authenticates during the password expiration warning interval and the ds-pwp-warned-time attribute is set. If the user does not authenticate before the password expiry time, the ds-pwp-password-expiration-time value will keep increasing until the user password is changed and the expiry time is reset.

In the following examples, the password policy will expire a password one hour after it has been changed and warn 30 minutes before expiry time: 

  • The first example demonstrates what happens if the user does not authenticate before their password expires and explains why you might see the password expiry time continually increasing.
  • The second example demonstrates the expected outcome where the user authenticates before their password expires and within the warning period.

Scenario 1 - User does not authenticate before password expiry

In this example, the user does not authenticate before their password expires; this causes the password expiry time to keep increasing and the user to be locked out:

  • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time
  • DS 7:;$ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time
  • Pre-DS 7: $ ./ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "cn=Directory Manager" --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time

Example response:dn: uid=user.6,ou=People,dc=example,dc=com pwdChangedTime: 20170208115546.098Z ds-pwp-password-expiration-time: 20170208125546.098Z

Note

Notice that for some accounts, the ds-pwp-password-expiration-time attribute keeps changing once the password-expiration-warning-interval has passed, which means the password never expires.

When the expiry time is reached and the user attempts to authenticate, the user is locked out:

  • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN "uid=user.6,ou=People,dc=example,dc=com" --bindPassword cangetin uid=user.6 cn
  • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN "uid=user.6,ou=People,dc=example,dc=com" --bindPassword cangetin uid=user.6 cn
  • Pre-DS 7: $ ./ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "uid=user.6,ou=People,dc=example,dc=com" --bindPassword cangetin uid=user.6 cn

Example response:The simple bind attempt failed Result Code: 49 (Invalid Credentials)

The password expiry time continues to increase to keep the account locked until the password is reset:

  • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time
  • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time
  • Pre-DS 7: $ ./ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "cn=Directory Manager" --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time

Example response:dn: uid=user.6,ou=People,dc=example,dc=com pwdChangedTime: 20170208115546.098Z ds-pwp-password-expiration-time: 20170208133604.100Z

Once the password is changed, the expiry time is reset to one hour:

  • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time
  • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time
  • Pre-DS 7: $ ./ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "cn=Directory Manager" --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time

Example response:dn: uid=user.6,ou=People,dc=example,dc=com pwdChangedTime: 20170208131848.246Z ds-pwp-password-expiration-time: 20170208141848.246Z

Scenario 2 - User authenticates before password expires and within warning period of 30 minutes

In this example, the user authenticates before their password expires and within the warning period; this triggers the notification they see warning that their password is due to expire.

DS 7.1 and later $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time dn: uid=user.6,ou=People,dc=example,dc=com ds-pwp-password-expiration-time: 20170208141848.246Z pwdChangedtime: 20170208131848.246Z $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN "uid=user.6,ou=People,dc=example,dc=com" --bindPassword cangetin1 uid=user.6 cn # Your password will expire in 30 minutes, 0 seconds dn: uid=user.6,ou=People,dc=example,dc=com cn: Abagail Abadines $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time dn: uid=user.6,ou=People,dc=example,dc=com ds-pwp-password-expiration-time: 20170208142000.923Z pwdChangedtime: 20170208131848.246Z ds-pwp-warned-time: 20170208135000.923Z

DS 7

$ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time dn: uid=user.6,ou=People,dc=example,dc=com ds-pwp-password-expiration-time: 20170208141848.246Z pwdChangedtime: 20170208131848.246Z $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN "uid=user.6,ou=People,dc=example,dc=com" --bindPassword cangetin1 uid=user.6 cn # Your password will expire in 30 minutes, 0 seconds dn: uid=user.6,ou=People,dc=example,dc=com cn: Abagail Abadines $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN dc=example,dc=com --bindDN uid=admin --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time dn: uid=user.6,ou=People,dc=example,dc=com ds-pwp-password-expiration-time: 20170208142000.923Z pwdChangedtime: 20170208131848.246Z ds-pwp-warned-time: 20170208135000.923Z

Pre-DS 7

$ ./ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "cn=Directory Manager" --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time dn: uid=user.6,ou=People,dc=example,dc=com ds-pwp-password-expiration-time: 20170208141848.246Z pwdChangedtime: 20170208131848.246Z $ ./ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "uid=user.6,ou=People,dc=example,dc=com" --bindPassword cangetin1 uid=user.6 cn # Your password will expire in 30 minutes, 0 seconds dn: uid=user.6,ou=People,dc=example,dc=com cn: Abagail Abadines $ ./ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "cn=Directory Manager" --bindPassword password uid=user.6 ds-pwp-password-expiration-time pwdChangedtime ds-pwp-warned-time dn: uid=user.6,ou=People,dc=example,dc=com ds-pwp-password-expiration-time: 20170208142000.923Z pwdChangedtime: 20170208131848.246Z ds-pwp-warned-time: 20170208135000.923Z

See Also

FAQ: Passwords in DS

How does DS (All versions) store password values?

Passwords

Related Training

N/A

Related Issue Tracker IDs

N/A


How do I change the admin account password used for replication in DS 5.x or 6.x?

The purpose of this article is to provide information on changing the admin account password used for replication in DS.

Changing the admin account password used for replication

There is no default admin account password used for replication. When you enable replication for the first time using the dsreplication configure command, you set the password to be used for this account. This user is created in the cn=admin data backend, which is replicated across all servers.

You can change the password using a standard LDAP operation. For example, you would use a command such as the following if the user was 'admin':

$ ./ldappasswordmodify --bindDN "cn=Directory Manager" --bindPassword password --port 4444 --newPassword Passw0rd --authzID "cn=admin,cn=Administrators,cn=admin data" --trustAll --useSSL

You can then test the new password with the dsreplication status command, for example:

$ ./dsreplication status --adminUID admin --adminPassword Passw0rd --hostname ds1.example.com --port 4444 --trustAll

See Also

FAQ: Passwords in DS

Troubleshooting DS

Administration Guide › Resetting Administrator Passwords

Reference › dsreplication

Related Training

N/A

Related Issue Tracker IDs

N/A


How do I add multiple values for the same password attribute using different hashing algorithms in DS (All versions)?

The purpose of this article is to provide information on adding multiple values for the same password attribute using different hashing algorithms in DS. This article assumes you are using the userPassword attribute for passwords, but the process still applies if you are using a different attribute for passwords.

Adding multiple values (DS 7 and later)

You can add multiple values as follows:

  1. Encode a password using your first required hashing algorithm, for example PBKDF2-HMAC-SHA256: $ ./encode-password --storageScheme PBKDF2-HMAC-SHA256 --clearPassword password1Example output: {PBKDF2-HMAC-SHA256}10:6xNamSSJePXtWOwptGXPhvx6ilc4EP6D4/s67ZcHrzJ4cT1VSgH9h2KxifRvv2RV
  2. Encode a password using your second required hashing algorithm, for example PBKDF2-HMAC-SHA512: $ ./encode-password --storageScheme PBKDF2-HMAC-SHA512 --clearPassword password2Example output: {PBKDF2-HMAC-SHA512}10000:HGVd9luGmMIfgbSnmczc2aZegohTub37Y8kHNwAtHzq5NIvUWMGqefm7mkUhY2NqslTHEpQHi4R5abFtMLZ0h1jGa120oS7mXpxiyV0wxpk=
  3. Update DS to allow encoded passwords to be imported. You can do this by setting the advanced password policy property: allow-pre-encoded-passwords using dsconfig. For example:
    • DS 7.1 and later: $ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --advanced --set allow-pre-encoded-passwords:true --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
    • DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --advanced --set allow-pre-encoded-passwords:true --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
  4. Add these encoded passwords to a user entry and import or add: dn: uid=user.2000,ou=People,dc=example,dc=com objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: top uid: user.2000 cn: Jane Doe sn: Doe mail: user.2000@example.com userPassword: {PBKDF2-HMAC-SHA256}10:6xNamSSJePXtWOwptGXPhvx6ilc4EP6D4/s67ZcHrzJ4cT1VSgH9h2KxifRvv2RV userPassword: {PBKDF2-HMAC-SHA512}10000:HGVd9luGmMIfgbSnmczc2aZegohTub37Y8kHNwAtHzq5NIvUWMGqefm7mkUhY2NqslTHEpQHi4R5abFtMLZ0h1jGa120oS7mXpxiyV0wxpk=
  5. Bind using this user entry and each encoded password:
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN "dc=example,dc=com" --bindDN "uid=user.2000,ou=People,dc=example,dc=com" --bindPassword password1 "(uid=user.2000)" userPassword dn: uid=user.2000,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:6xNamSSJePXtWOwptGXPhvx6ilc4EP6D4/s67ZcHrzJ4cT1VSgH9h2KxifRvv2RV userPassword: {PBKDF2-HMAC-SHA512}10000:HGVd9luGmMIfgbSnmczc2aZegohTub37Y8kHNwAtHzq5NIvUWMGqefm7mkUhY2NqslTHEpQHi4R5abFtMLZ0h1jGa120oS7mXpxiyV0wxpk= $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --baseDN "dc=example,dc=com" --bindDN "uid=user.2000,ou=People,dc=example,dc=com" --bindPassword password2 "(uid=user.2000)" userPassword dn: uid=user.2000,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:6xNamSSJePXtWOwptGXPhvx6ilc4EP6D4/s67ZcHrzJ4cT1VSgH9h2KxifRvv2RV userPassword: {PBKDF2-HMAC-SHA512}10000:HGVd9luGmMIfgbSnmczc2aZegohTub37Y8kHNwAtHzq5NIvUWMGqefm7mkUhY2NqslTHEpQHi4R5abFtMLZ0h1jGa120oS7mXpxiyV0wxpk=
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN "dc=example,dc=com" --bindDN "uid=user.2000,ou=People,dc=example,dc=com" --bindPassword password1 "(uid=user.2000)" userPassword dn: uid=user.2000,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:6xNamSSJePXtWOwptGXPhvx6ilc4EP6D4/s67ZcHrzJ4cT1VSgH9h2KxifRvv2RV userPassword: {PBKDF2-HMAC-SHA512}10000:HGVd9luGmMIfgbSnmczc2aZegohTub37Y8kHNwAtHzq5NIvUWMGqefm7mkUhY2NqslTHEpQHi4R5abFtMLZ0h1jGa120oS7mXpxiyV0wxpk= $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --baseDN "dc=example,dc=com" --bindDN "uid=user.2000,ou=People,dc=example,dc=com" --bindPassword password2 "(uid=user.2000)" userPassword dn: uid=user.2000,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:6xNamSSJePXtWOwptGXPhvx6ilc4EP6D4/s67ZcHrzJ4cT1VSgH9h2KxifRvv2RV userPassword: {PBKDF2-HMAC-SHA512}10000:HGVd9luGmMIfgbSnmczc2aZegohTub37Y8kHNwAtHzq5NIvUWMGqefm7mkUhY2NqslTHEpQHi4R5abFtMLZ0h1jGa120oS7mXpxiyV0wxpk=

Adding multiple values (Pre-DS 7)

You can add multiple values as follows:

  1. Encode a password using your first required hashing algorithm, for example SSHA256: $ ./encode-password --storageScheme SSHA256 --clearPassword password1Example output: {SSHA256}roHY0/rfiO8+q/DZ+km9UG2UiL7AO6RuQ4oFefRDmEYHbeBEkNzmaQ==
  2. Encode a password using your second required hashing algorithm, for example SSHA512: $ ./encode-password --storageScheme SSHA512 --clearPassword password2Example output: {SSHA512}RypyBA65dxSQP0Zd2HZ2Ue7C2/FEQ/7YU0FU59jhD8kirLXToEaMelrY90/21QJcr3mfyB1KXPSZjCgq6OcQqIOsklOGlXOH
  3. Update DS to allow encoded passwords to be imported. You can do this by setting the advanced password policy property: allow-pre-encoded-passwords using dsconfig. For example:$ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --hostname ds1.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --advanced --set allow-pre-encoded-passwords:true --trustAll --no-prompt
  4. Add these encoded passwords to a user entry and import or add: dn: uid=user.2000,ou=People,dc=example,dc=com objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: top uid: user.2000 cn: Jane Doe sn: Doe mail: user.2000@example.com userPassword: {SSHA256}roHY0/rfiO8+q/DZ+km9UG2UiL7AO6RuQ4oFefRDmEYHbeBEkNzmaQ== userPassword: {SSHA512}RypyBA65dxSQP0Zd2HZ2Ue7C2/FEQ/7YU0FU59jhD8kirLXToEaMelrY90/21QJcr3mfyB1KXPSZjCgq6OcQqIOsklOGlXOH
  5. Bind using this user entry and each encoded password:$ ./ldapsearch --port 1389 --hostname localhost --baseDN "dc=example,dc=com" --bindDN "uid=user.2000,ou=People,dc=example,dc=com" --bindPassword password1 "(uid=user.2000)" userPassword dn: uid=user.2000,ou=People,dc=example,dc=com userPassword: {SSHA256}roHY0/rfiO8+q/DZ+km9UG2UiL7AO6RuQ4oFefRDmEYHbeBEkNzmaQ== userPassword: {SSHA512}RypyBA65dxSQP0Zd2HZ2Ue7C2/FEQ/7YU0FU59jhD8kirLXToEaMelrY90/21QJcr3mfyB1KXPSZjCgq6OcQqIOsklOGlXOH $ ./ldapsearch --port 1389 --hostname localhost --baseDN "dc=example,dc=com" --bindDN "uid=user.2000,ou=People,dc=example,dc=com" --bindPassword password2 "(uid=user.2000)" userPassword dn: uid=user.2000,ou=People,dc=example,dc=com userPassword: {SSHA256}roHY0/rfiO8+q/DZ+km9UG2UiL7AO6RuQ4oFefRDmEYHbeBEkNzmaQ== userPassword: {SSHA512}RypyBA65dxSQP0Zd2HZ2Ue7C2/FEQ/7YU0FU59jhD8kirLXToEaMelrY90/21QJcr3mfyB1KXPSZjCgq6OcQqIOsklOGlXOH

See Also

FAQ: Installing and configuring DS

FAQ: Passwords in DS

How does DS (All versions) store password values?

Configure Password Policies

Related Training

ForgeRock Directory Services Core Concepts (DS-400)

Related Issue Tracker IDs

N/A


How do I change a password storage scheme and apply a new password policy to users in DS (All versions)?

The purpose of this article is to provide assistance if you want to migrate users to a new password policy in DS. It also provides information on changing the storage scheme associated with a password policy (for example, from PBKDF2-HMAC-SHA256 to PBKDF2-HMAC-SHA512), without applying a new policy.

Overview

If you want to change the storage scheme associated with your password policy, you do not have to create a new password policy to achieve this nor do users necessarily have to change their passwords.

You have the following options if you want to change the storage scheme (without creating a new policy): 

The option you choose depends on the vulnerability of your existing storage scheme. If you have any concerns, you will want users to change their password anyway, in which case the first option is the most suitable. If you are changing the storage scheme for other reasons, the second option may be suitable and less disruptive.

If you want to change the policy applied to users, you have the following options:

Attributes

The following attributes are referred to in this article:

Attribute  Meaning
pwdPolicySubentry This attribute indicates which password policy applies to the user.
ds-pwp-password-policy-dn This attribute is used to assign password policies to any given user or group of users.
collectAttributeSubentries This attribute is used to set the ds-pwp-password-policy-dn for group member entries. 

Changing the storage scheme associated with a server-based policy

You can change the storage scheme associated with a server-based password policy as follows:

  1. Update the storage scheme associated with your existing password policy using a dsconfig command such as this:
    • DS 7.1 and later: $ ./dsconfig set-password-policy-prop --policy-name "Current Password Policy" --set default-password-storage-scheme:PBKDF2-HMAC-SHA512 --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
    • DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Current Password Policy" --set default-password-storage-scheme:PBKDF2-HMAC-SHA512 --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
    • Pre-DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Current Password Policy" --set default-password-storage-scheme:"Salted SHA-512" --hostname ds1.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --trustAll --no-prompt

Once the policy is updated, authentication will continue to work seamlessly since the passwords themselves are unchanged. All newly created and updated passwords will be stored using the new storage scheme.

  1. Force all users to update their passwords to ensure they are stored using the new scheme. An administrator can reset users' passwords, and assuming the force-change-on-reset property is set to true, users would have to change their password the next time they log in. See Require Password Change on Add or Reset for further information on this setting.

Testing

The following process demonstrates how to check that the new storage scheme is used once the user's password has been changed:

  1. Search the userPassword with a ldapsearch command to confirm that the user still has their password stored under the existing storage scheme (PBKDF2-HMAC-SHA256 in this example):
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --baseDN dc=example,dc=com "uid=user.1" userPassword
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --baseDN dc=example,dc=com "uid=user.1" userPassword
    • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --baseDN dc=example,dc=com "uid=user.1" userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:Hy+ZwmElbGT4va+Yb84LoIffAJVKXzVIY7XrFzdKxFl5rOB/j9y+9pwdub8rwfVa

  1. Update the user's password using a ldappasswordmodify command:
    • DS 7.1 and later: $ ./ldappasswordmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
    • DS 7: $ ./ldappasswordmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
    • Pre-DS 7: $ ./ldappasswordmodify --port 1389 --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
  2. Search the userPassword again to verify that the user's password is now stored under the new storage scheme (PBKDF2-HMAC-SHA512 in this example):
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword
    • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA512}10000:kPItID0Y7ydkMwjDyUhvuowuKs4RSraKcINuDVyQdqG/PLrPLeA/0dpfCsFPN2WEo0MFYcdKa7Gs3DXP/t9XEfiYzhXTD2PHR6VwdNtBnDg=

Deprecating the old storage scheme and applying a new one (server-based policy)

You can deprecate the old storage scheme as follows:

  1. Deprecate the storage scheme associated with your existing server-based password policy and set the new storage scheme using a dsconfig command such as this:
    • DS 7.1 and later: $ ./dsconfig set-password-policy-prop --policy-name "Current Password Policy" --set deprecated-password-storage-scheme:PBKDF2-HMAC-SHA256 --set default-password-storage-scheme:PBKDF2-HMAC-SHA512 --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
    • DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Current Password Policy" --set deprecated-password-storage-scheme:PBKDF2-HMAC-SHA256 --set default-password-storage-scheme:PBKDF2-HMAC-SHA512 --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
    • Pre-DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Current Password Policy" --set deprecated-password-storage-scheme:"Salted SHA-256" --set default-password-storage-scheme:"Salted SHA-512" --hostname ds1.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --trustAll --no-prompt

Once the user successfully authenticates, their password is stored under the new storage scheme.

Testing

The following process demonstrates how to check that the new storage scheme is used for a user's password once they have authenticated:

  1. Search the userPassword with a ldapsearch command to confirm that the user still has their password stored under the existing storage scheme (PBKDF2-HMAC-SHA256 in this example):
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --baseDN dc=example,dc=com "uid=user.1" userPassword
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --baseDN dc=example,dc=com "uid=user.1" userPassword
    • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --baseDN dc=example,dc=com "uid=user.1" userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:Hy+ZwmElbGT4va+Yb84LoIffAJVKXzVIY7XrFzdKxFl5rOB/j9y+9pwdub8rwfVa

  1. Authenticate as the user using their existing password. Do not change their password. 
  2. Search the userPassword again to verify that the user's password is now stored under the new storage scheme (PBKDF2-HMAC-SHA512 in this example):
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword
    • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA512}10000:kPItID0Y7ydkMwjDyUhvuowuKs4RSraKcINuDVyQdqG/PLrPLeA/0dpfCsFPN2WEo0MFYcdKa7Gs3DXP/t9XEfiYzhXTD2PHR6VwdNtBnDg=

Using the pwdPolicy object class to assign subentry based password policies

The following process demonstrates applying a subentry based password policy to all members of a branch, with the following example values (where both the policy and users are directly under: ou=People,dc=example,dc=com):

  • The policy DN is: cn=PBKDF2-HMAC-SHA512 Policy,ou=People,dc=example,dc=com
  • The users are in the following branch: ou=People,dc=example,dc=com

You can apply a password policy to all your users as follows 

  1. Create a ldif file for the new custom password policy. For example: $ cat new-policy.ldif dn: cn=PBKDF2-HMAC-SHA512 Policy,dc=example,dc=com objectClass: top objectClass: subentry objectClass: pwdPolicy cn: PBKDF2-HMAC-SHA512 Policy pwdAttribute: userPassword [..., etc] subtreeSpecification: {base "ou=people", specificationFilter   "(isMemberOf=cn=Directory Administrators,ou=Groups,dc=example,dc=com)" }
  2. Apply the new policy using the following ldapmodify command depending on your version:
    • DS 7.1 and later: $ ./ldapmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password new-policy.ldif
    • DS 7: $ ./ldapmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password new-policy.ldif
    • Pre-DS 7: $ ./ldapmodify --port 1389 --bindDN "cn=Directory Manager" --bindPassword password new-policy.ldif

You will see the following response:Processing ADD request for cn=PBKDF2-HMAC-SHA512 Policy,ou=People,dc=example,dc=com ADD operation successful for DN cn=PBKDF2-HMAC-SHA512 Policy,ou=People,dc=example,dc=com

Testing

The following process demonstrates how to check that the new password policy has been applied and that the storage scheme is updated once the user's password has been changed:

  1. Verify that the new password policy has been applied, for example:
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword
    • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:Hy+ZwmElbGT4va+Yb84LoIffAJVKXzVIY7XrFzdKxFl5rOB/j9y+9pwdub8rwfVa pwdPolicySubentry: cn=PBKDF2-HMAC-SHA512 Policy,dc=example,dc=com entryUUID: ad55a34a-763f-358f-93f9-da86f9ecd9e4 etag: 000000003e23b18a structuralObjectClass: inetOrgPerson numSubordinates: 0 collectiveAttributeSubentries: cn=PBKDF2-HMAC-SHA512 Password Policy for all Users,dc=example,dc=com hasSubordinates: false subschemaSubentry: cn=schema entryDN: uid=user.1,ou=People,dc=example,dc=com ds-pwp-password-policy-dn: cn=PBKDF2-HMAC-SHA512 Policy,dc=example,dc=comNotice that the password has not yet updated to the new PBKDF2-HMAC-SHA512 storage scheme but the new password policy has been applied.

  1. Update the user's password using the ldappasswordmodify command, for example:
    • DS 7.1 and later: $ ./ldappasswordmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
    • DS 7: $ ./ldappasswordmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
    • Pre-DS 7: $ ./ldappasswordmodify --port 1389 --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
  2. Search the userPassword again to verify that the user's password is now stored under the new storage scheme (PBKDF2-HMAC-SHA512 in this example):
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword
    • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA512}10000:kPItID0Y7ydkMwjDyUhvuowuKs4RSraKcINuDVyQdqG/PLrPLeA/0dpfCsFPN2WEo0MFYcdKa7Gs3DXP/t9XEfiYzhXTD2PHR6VwdNtBnDg=

Using a collectiveAttributeSubentry object to assign password policies

The process you need to follow depends on whether you currently have the Default Password Policy assigned to your users or a custom one; you can check the pwdPolicySubentry entry using a ldapsearch command, for example:

  • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword
  • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword
  • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:Hy+ZwmElbGT4va+Yb84LoIffAJVKXzVIY7XrFzdKxFl5rOB/j9y+9pwdub8rwfVa pwdPolicySubentry: cn=Default Password Policy,cn=Password Policies,cn=config entryUUID: ad55a34a-763f-358f-93f9-da86f9ecd9e4 etag: 000000003e23b18a structuralObjectClass: inetOrgPerson numSubordinates: 0 hasSubordinates: false subschemaSubentry: cn=schema entryDN: uid=user.1,ou=People,dc=example,dc=com

If you already have a custom password policy (applied using collective attributes), you will see a collectiveAttributeSubentries entry in response to the ldapsearch, for example: collectiveAttributeSubentries: cn=Custom Password Policy for all Users,dc=example,dc=com

You should then follow the appropriate process below:

Note

If you already have a custom policy applied, you can remove it first and then follow the new password policy procedure if you prefer. You can remove it using ldapdelete, for example:

  • DS 7.1 and later: $ ./ldapdelete --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password cn=Custom Password Policy for all Users,dc=example,dc=com
  • DS 7: $ ./ldapdelete --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password cn=Custom Password Policy for all Users,dc=example,dc=com
  • Pre-DS 7: $ ./ldapdelete --port 1389 --bindDN "cn=Directory Manager" --bindPassword password cn=Custom Password Policy for all Users,dc=example,dc=com

Apply a new password policy 

The following process demonstrates applying a new password policy to all users under the base ou=People:

  1. Create a new custom password policy. See Configure Password Policies for further information.
  2. Apply the new password policy to all users under dn: ou=People,dc=example,dc=com as follows:
    1. Create a ldif file with the changes, for example: dn: cn=PBKDF2-HMAC-SHA512 Password Policy for all Users,dc=example,dc=com objectClass: collectiveAttributeSubentry objectClass: extensibleObject objectClass: subentry objectClass: top cn: PBKDF2-HMAC-SHA512 Password Policy for all Users ds-pwp-password-policy-dn;collective: cn=PBKDF2-HMAC-SHA512 Policy,cn=Password Policies,cn=config subtreeSpecification: {base "ou=people", specificationFilter  "(isMemberOf=cn=Directory Administrators,ou=Groups,dc=example,dc=com)" }
    2. Apply this update using the following ldapmodify command depending on your version:
      • DS 7.1 and later: $ ./ldapmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password pwp-policy.ldif
      • DS 7: $ ./ldapmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password pwp-policy.ldif
      • Pre-DS 7: $ ./ldapmodify --port 1389 --bindDN "cn=Directory Manager" --bindPassword password pwp-policy.ldif

You will see the following response:Processing ADD request for cn=PBKDF2-HMAC-SHA512 Password Policy for all Users,dc=example,dc=com ADD operation successful for DN cn=PBKDF2-HMAC-SHA512 Password Policy for all Users,dc=example,dc=com

Change the password policy 

The following process demonstrates changing the password policy applicable to all users under the base ou=People:

  1. Create a new custom password policy. See Configure Password Policies for further information.
  2. Change the password policy to the new policy for all users under dn: ou=People,dc=example,dc=com as follows:
    1. Create a ldif file with the change, for example: $ cat change-policy.ldif dn: cn=Custom Password Policy for all Users,dc=example,dc=com changetype: modify replace: ds-pwp-password-policy-dn;collective ds-pwp-password-policy-dn;collective: cn=PBKDF2-HMAC-SHA512 Policy,cn=Password Policies,cn=config
    2. Apply this update using the following ldapmodify command depending on your version:
      • DS 7.1 and later: $ ./ldapmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password change-policy.ldif
      • DS 7: $ ./ldapmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password change-policy.ldif
      • Pre-DS 7: $ ./ldapmodify --port 1389 --bindDN "cn=Directory Manager" --bindPassword password change-policy.ldif

You will see the following response:Processing MODIFY request for cn=Custom Password Policy for all Users,dc=example,dc=com MODIFY operation successful for DN cn=Custom Password Policy for all Users,dc=example,dc=com

Testing

The following process demonstrates how to check that the new password policy has been applied and that the storage scheme is updated once the user's password has been changed:

  1. Verify that the new password policy has been applied, for example:
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword
    • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDN dc=example,dc=com 'uid=user.1' pwdPolicySubentry + userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA256}10:Hy+ZwmElbGT4va+Yb84LoIffAJVKXzVIY7XrFzdKxFl5rOB/j9y+9pwdub8rwfVa pwdPolicySubentry: cn=PBKDF2-HMAC-SHA512 Policy,cn=Password Policies,cn=config entryUUID: ad55a34a-763f-358f-93f9-da86f9ecd9e4 etag: 000000003e23b18a structuralObjectClass: inetOrgPerson numSubordinates: 0 collectiveAttributeSubentries: cn=PBKDF2-HMAC-SHA512 Password Policy for all Users,dc=example,dc=com hasSubordinates: false subschemaSubentry: cn=schema entryDN: uid=user.1,ou=People,dc=example,dc=com ds-pwp-password-policy-dn: cn=PBKDF2-HMAC-SHA512 Policy,cn=Password Policies,cn=configNotice that the password has not yet updated to the new PBKDF2-HMAC-SHA512 storage scheme but the new password policy has been applied.

  1. Update the user's password using a ldappasswordmodify command:
    • DS 7.1 and later: $ ./ldappasswordmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
    • DS 7: $ ./ldappasswordmodify --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
    • Pre-DS 7: $ ./ldappasswordmodify --port 1389 --bindDN "uid=user.1,ou=people,dc=example,dc=com" --bindPassword changeit --newPassword strongPassw0rd
  2. Search the userPassword again to verify that the user's password is now stored under the new storage scheme (PBKDF2-HMAC-SHA512 in this example):
    • DS 7.1 and later: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword
    • DS 7: $ ./ldapsearch --hostname localhost --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword
    • Pre-DS 7: $ ./ldapsearch --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDN dc=example,dc=com "uid=user.1" userPassword

Example response:dn: uid=user.1,ou=People,dc=example,dc=com userPassword: {PBKDF2-HMAC-SHA512}10000:kPItID0Y7ydkMwjDyUhvuowuKs4RSraKcINuDVyQdqG/PLrPLeA/0dpfCsFPN2WEo0MFYcdKa7Gs3DXP/t9XEfiYzhXTD2PHR6VwdNtBnDg=

Note

If you have changed the password policy, the name on the collectiveAttribute will remain the same after the new policy has been applied.

See Also

How does DS (All versions) store password values?

How does password expiration work in DS (All versions)?

How do I add multiple values for the same password attribute using different hashing algorithms in DS (All versions)?

FAQ: Passwords in DS

Passwords in DS

Passwords

Related Training

N/A

Related Issue Tracker IDs

N/A


FAQ: Passwords in DS

The purpose of this FAQ is to provide answers to commonly asked questions regarding passwords in DS.

Frequently asked questions

Q. Can I change the password policy that applies to a user?

A. Yes, as a DS administrator, you can change the password policy that applies to a user.

See Assign Password Policies for further information.

Q. How do I reset the directory superuser's password?

A. You can reset the password for the directory superuser (uid=admin in DS 7 and later; cn=Directory Manager in pre-DS 7) as described in the relevant documentation:

The superuser is stored in the rootUser.ldif file (located in the /path/to/ds/db/rootUser directory) in DS 6 and later or the config.ldif file (located in the /path/to/ds/config directory) in DS 5.x.

Q. Does DS have a maximum password length?

A. The password length in DS is determined by the password scheme being used. For example, the UNIX® crypt scheme only uses the first 8 characters for compatibility, whereas the SHA512 scheme (like most schemes) is not limited.

Q. What is the default password storage scheme used in DS?

A. The default password storage scheme depends on which version of DS you are using:

  • DS 7 and later: the password storage scheme for the Default Password Policy and Root Password Policy is PBKDF2-HMAC-SHA256 with 10 iterations. See Default Security Settings for further information.
  • Pre-DS 7: the default password storage scheme is as follows:
    • Normal users - Salted SHA-512.
    • root DN users - PBKDF2.

See Password StorageHow does DS (All versions) store password values? and Password Storage Scheme for more information on password hashing in DS including all the supported storage schemes.

Q. Can I import an LDIF file that contains pre-encoded passwords?

A. Yes, you can by setting the advanced password policy property: allow-pre-encoded-passwords. You can set this using dsconfig, for example:

  • DS 7.1 and later: $ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --port 4444 --bindDN uid=admin --bindPassword password --advanced --set allow-pre-encoded-passwords:true --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
  • DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --port 4444 --bindDN uid=admin --bindPassword password --advanced --set allow-pre-encoded-passwords:true --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
  • Pre-DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --advanced --set allow-pre-encoded-passwords:true --trustAll --no-prompt
Note

The pre-encoded passwords in the LDIF file must be in the correct format required by your password storage scheme. See How does DS (All versions) store password values? for further information.

If you try to import an LDIF file with pre-encoded passwords without setting this property to true, you will see the following error:

Pre-encoded passwords are not allowed for the password attribute userPassword

Q. Does DS support using multiple attributes for a password, for example, to allow different hashing algorithms?

A. No, DS only uses one attribute for a password, but you can configure which attribute is used, for example, userPassword. Additionally, you can have multiple values for this attribute, with each value having a different hashing algorithm as described in How do I add multiple values for the same password attribute using different hashing algorithms in DS (All versions)?

See Configure Password Policies for further information.

Q. When an account is locked, when are the lockout attributes (pwdAccountLockedTime and pwdFailureTime) reset?

A. These lockout attributes remain set until the user attempts to log in. If the user tries to log in within the lockout duration, they are denied access, but if they log in after the lockout duration has passed, their account is unlocked and the lockout attributes are reset.

What happens to a user’s ds-pwp-password-expiration-time attribute when the max-password-age property is updated?

A. The max-password-age property is a password policy property not a user entry attribute or property.  A user entry has a ds-pwp-password-expiration-time attribute instead, which is linked to the max-password-age property.

When an admin updates the max-password-age property in a password policy, the ds-pwp-password-expiration-time attribute is automatically updated for any users who have been assigned that password policy. It is updated based on the new max-password-age in the password policy and the user's own pwdChangedTime attribute, that is:

max-password-age (password policy) + pwdChangedTime (user) = ds-pwp-password-expiration-time (user)

However, the calculation can be further complicated depending on the configuration and status of the expiration warning. For example, if the user has 10 days left and you have a 5 day warn time - then you change the maximum age from 40 to 30 days. In theory you would think you have 0 days left, but what would actually happen is the user would get their warning and then have a further 5 days until expiration.

Q. Can I define subentry based password validators or generators?

A. Yes, as of DS 7, DS servers support LDAP subentry password policies that match all features available in per-server password policies. See DS Subentry Password Policies for further information.

Resolved RFE: OPENDJ-286 (Finish implementation of password policy sub-entry support).

Q. Does DS support the two Behera password policy attributes to delay response for failed authentication: pwdMinDelay and pwdMaxDelay?

A. No. These attributes are introduced in version 10 of the Internet-Draft Password Policy for LDAP Directories and DS supports version 09.

Q. Where does DS define truststore files and passwords?

A. Truststores are used for public, signed certificates but there are also keystores, which are used for private keys.

By default, truststore and/or keystore files and passwords are stored in different stores depending on their purpose:

  • ads-truststore for replication purposes (Pre-DS 7 only).
  • admin-truststore and admin-keystore for administration purposes.
  • truststore and keystore for everything else.

These files are located in /path/to/ds/config; in DS 6.x, ads-truststore is located in /path/to/ds/db/ads-truststore for new installs.

See Cryptographic Keys for further information.

Q. Can I decrypt a currently stored password?

A. No. Non-clear text passwords in DS are encrypted or hashed and cannot be reverse-engineered through any DS related process or by ForgeRock. For example a password hashed using the Salted SHA-512 scheme is stored as follows:

userPassword: {SSHA512}RypyBA65dxSQP0Zd2HZ2Ue7C2/FEQ/7YU0FU59jhD8kirLXToEaMelrY90/21QJcr3mfyB1KXPSZjCgq6OcQqIOsklOGlXOH

When a user authenticates, the given clear text password is processed using the same algorithms. DS compares the authentication password to the stored userPassword version. If the comparison is true, the user is authenticated.

See Also

How does DS (All versions) store password values?

FAQ: Installing and configuring DS

FAQ: Upgrading DS

FAQ: General DS

Passwords in DS

Related Training

ForgeRock Directory Services Core Concepts (DS-400)


Password Synchronization Plugin


How do I upgrade DS (All versions) if I have the DS Password Sync Plugin for IDM installed?

The purpose of this article is to provide information on upgrading DS if you have the DS Password Sync Plugin for IDM installed.

Background Information

The password plugin configuration is specified in the openidm-accountchange-plugin-sample-config file.

Note

You must use the plugin version that corresponds to your DS version. See Before You Install for further information.

Upgrading DS

You can upgrade DS as follows:

  1. Back up the password plugin configuration file (openidm-accountchange-plugin-sample-config, which is located in the /path/to/ds/config directory) as this contains your current configuration details.
  2. Update the Default Password Policy to remove the account-status-notification-handler attribute using a dsconfig command such as the following:
    • DS 7.1 and later: $ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --reset account-status-notification-handler --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
    • DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --reset account-status-notification-handler --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
    • Pre-DS 7: $ ./dsconfig set-password-policy-prop --policy-name "Default Password Policy" --reset account-status-notification-handler --hostname ds1.example.com --port 4444 --bindDn "cn=Directory Manager" --bindPassword password --trustAll --no-prompt
  3. Remove the changes made to the cn=config backend when the plugin was installed using a ldapdelete command such as the following:
    • DS 7 and later: $ ./ldapdelete --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password "cn=OpenIDM Notification Handler,cn=Account Status Notification Handlers,cn=config"
    • Pre-DS 7: $ ./ldapdelete --hostname ds1.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password "cn=OpenIDM Notification Handler,cn=Account Status Notification Handlers,cn=config"
  4. Stop the DS instance.
  5. Delete the following files that apply to the existing plugin:
    • openidm-accountchange-plugin-sample-config in the /path/to/ds/config directory.
    • 90-openidm-pwsync-plugin.ldif file in the /path/to/ds/config/schema directory; as of DS 6 and later, located in /path/to/ds/db/schema for new installs.
    • opendj-accountchange-handler-x.x.x.jar in the /path/to/ds/lib/extensions directory.
  6. Restart the DS instance.
  7. Upgrade to the new version of DS. See Upgrade Guide for further information.
  8. Install the new plugin per the instructions in Password Synchronization Plugin Guide › Installing and Configuring the DS Password Synchronization Plugin .
  9. Update the configuration file (openidm-accountchange-plugin-sample-config) with the details contained in the configuration file you backed up if you want to retain the same behavior you had previously.

See Also

DS (All versions) fail to start after upgrade if you use the Password Sync Plugin for IDM

How do I troubleshoot the DS Password Synchronization plugin in IDM (All versions)?

Password Synchronization Plugin Guide › Synchronizing Passwords With ForgeRock Directory Services (DS)

Related Training

N/A

Related Issue Tracker IDs

N/A


How do I troubleshoot the DS Password Synchronization plugin in IDM (All versions)?

The purpose of this article is to provide assistance if you are experiencing issues with the DS password sync plugin in IDM. This article also includes information on enabling debug logging for just the DS password sync plugin to minimize the size of the resulting DS logs.

Overview

This article includes the following details that you should check (and rectify) in order to troubleshoot the DS password sync plugin in IDM:

Note

If you are still unable to solve your issues, you should attach the collected log files and outputs when you raise a ticket to enable us to help you more quickly. See Sending troubleshooting data to ForgeRock Support for analysis for further information.

DS password sync flow

The expected DS password sync plugin flow is as follows:

  1. DS receives an operation to modify an account password.
  2. The DS password sync plugin is invoked and passes the cleartext password.
  3. The DS password sync plugin encrypts the password and performs a Patch operation against the corresponding IDM managed user's ldapPassword attribute.
  4. The onUpdate trigger within managed.json assigns the decrypted ldapPassword attribute value to the password attribute.
  5. The Implicit sync process is triggered for the managed user to LDAP mapping.
  6. The condition associated with the password attribute mapping is evaluated and returns false as the cleartext ldapPassword and password attribute values are the same.
  7. The LDAP Connector does not perform an update to DS as there are no modifications to be performed.

Avoiding loops

To ensure this flow is followed correctly and you do not end up with a loop whereby the password change originating from DS results in an update from IDM back to DS for the same LDAP entry, the condition associated with the password attribute mapping (sync.json file) should be similar to the following:

{   "source" : "password",                       "condition" : {         "type" : "text/javascript",         "source" : "object.ldapPassword != null && (openidm.decrypt(object.password) != openidm.decrypt(object.ldapPassword))" },

This mapping applies a condition to the sync of the password attribute, which is dependent upon the managed user's ldapPassword attribute value being different from the password attribute value.

Note

The ldapPassword attribute referred to above is configurable and may be different in your configuration; however, the DS password sync plugin must be configured to Patch an attribute other than password when performing a bi-directional sync else it is impossible to determine whether an update is needed or not.

If DS syncs passwords with IDM in both directions, you need to ensure you have configured IDM correctly to avoid an infinite loop. See Password Synchronization Plugin Guide › Preventing Infinite Loops for further information.

Keystores and certificates

Incorrect keystore and certificate details can cause issues with the DS password sync plugin (some of which have been shown in the IDM log section below). The key things to check are:

  1. The IDM certificate has been imported into the DS truststore.
  2. The DS certificate has been imported into the IDM keystore. This step only applies if you have implemented mutual SSL authentication (server and client certificate authentication); the password sync plugin is configured to use mutual SSL authentication by default
  3. The encryption key used for the password is correct and present in both the DS truststore and the IDM keystore.

IDM certificate

This process is documented in the Password Synchronization Plugin Guide › Enable DS to Trust the IDM Certificate.

You can check that the IDM certificate has been imported properly as follows:

  1. Use the keytool command to list the certificate aliases in the IDM keystore to check which certificate is being used; this could be the openidm-localhost certificate or a CA certificate depending on your setup.
  2. Use the keytool command to list the certificate aliases in the DS truststore and check that the certificate alias returned in step 1 is present. The following example keytool command shows that the openidm-localhost certificate has been imported into the DS keystore: $ keytool -list -keystore truststore -storetype JKS -storepass password -v Keystore type: JKS Keystore provider: SUN Your keystore contains 2 entries Alias name: openidm-localhost Creation date: May 19, 2021 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=openidm-localhost, O=OpenIDM Self-Signed Certificate, OU=None, L=None, ST=None, C=None Issuer: CN=openidm-localhost, O=OpenIDM Self-Signed Certificate, OU=None, L=None, ST=None, C=None Serial number: 152f283769d Valid from: Valid from: Wed May 19 10:11:34 BST 2021 until: Thu May 19 10:11:34 BST 2022 Certificate fingerprints:       SHA1: CC:09:33:57:F3:AE:BC:0F:D3:49:30:E2:5F:EA:AA:9F:43:67:65:B7         SHA256: B3:16:98:AD:97:D9:A0:5E:44:AE:FD:A8:35:4A:4E:84:59:EC:52:53:99:8C:4D:ED:DC:EB:1A:2B:22:0C:51:4A Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 ******************************************* *******************************************

DS certificate

This process is documented in the Password Synchronization Plugin Guide › Enable IDM to trust DS Certificates and is only required for mutual authentication, although the password sync plugin is configured to use mutual SSL authentication by default.

You can check that the DS certificate has been imported properly as follows:

  1. Use the keytool command to list the certificate aliases in the IDM keystore and check that the server-cert certificate (or equivalent CA certificate depending on your setup) is being used.
  2. Check that the certificate DN has been added as a value of the allowedAuthenticationIdPatterns property for the CLIENT_CERT authentication module in the authentication.json file (located in the /path/to/idm/conf directory).

Encryption key

The DS password is encrypted before it is sent to IDM. The encryption key used is openidm-localhost by default but could be different if you have changed it.

You should check the encryption key as follows:

  1. Check which encryption key is actually being used by DS using one of the following methods. If this is not the key you expected, you should update the ds-cfg-private-key-alias property in the config.ldif file with the correct key:
    • Look for the value of the ds-cfg-private-key-alias property in the config.ldif file (located in the /path/to/ds/config directory).
    • Check the value of the private-key-alias property using the dsconfig command.
  2. Check that this encryption key is present in both the DS truststore and the IDM keystore, otherwise IDM will not be able to decrypt the password when it is received. If it is not there, import it into the appropriate stores per the documentation links above.

IDM log

The IDM log (openidm.log, located in the /path/to/idm/logs directory) can be useful for identifying any issues with the password synchronization process from the IDM side. You should increase logging in the IDM debug log to FINEST (set the .level property to FINEST in logging.properties, which is located in the /path/to/idm/conf directory).

SSL and keys

If you see the following message in your IDM log after changing a password in DS, it means the SSL connection is working and the request has been received and successfully decrypted:

FINEST: Request: { "content": { "password": { "$crypto": { "value": { "data": "6m3EOH9Fs7gqKNlTphW8Iw==", "cipher": "AES/ECB/PKCS5Padding", "key": { "data": "SKZIzkHc4wSa56sfivwKpblZrN3a/d8H/M10C48VOiaMFwlGM311ISl6s620ysWWXNXyqU4E/+hQFRx4M9pG80aYWWbHZvaicAtXadEs3kPhC8ffpPu8cYmfYbryKzsgQ0CqR+Ke3qERWdLDXRRX+ionkC9CfY4nMMKGhYVXNW61/TtKBrn3g5/3RvmL+mI9IxDeMDTgPsMuqmJtkSwHe2do/WmgeTnMpzMHb3GuXBcbphilzsTtLQvfGFQMC/0WTgwy0tovASIcY0rPRiEm6ymVrYRZTD+Zqy9pTeSVPH+XrqJTJUafIbIQlA1gf54ZnOrB/7Sauyeo7FxS8CzhIQ==", "cipher": "RSA/ECB/OAEPWithSHA1AndMGF1Padding", "key": "openidm-localhost" } }, "type": "x-simple-encryption" } } }, "resourcePath": "policy/managed/user/7a2594ea-ae24-4084-a963-9fa95e1dccc5", "additionalParameters": { "external": "true" }, "action": "validateProperty", "method": "action", "fields": [ ] }

Although the SSL connection is working, you could still see errors if the provided key is unknown to IDM, for example:

FINEST: Resource exception: 500 Internal Server Error: "Wrapped org.forgerock.json.JsonException: org.forgerock.json.crypto.JsonCryptoException: key not found: openidm-unknown (/path/to/idm/bin/defaults/script/policy.js#690) in /path/to/idm/bin/defaults/script/policy.js at line number 690 at column number 0"

If the SSL connection is not working, you will see a SSL handshake exception, for example:

javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)     at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)     at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959)     at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077)     at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)     at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)     at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) 
Note

If you are experiencing issues with SSL or keys, you can enable SSL debugging as detailed in the SSL debugging section.

Configuration issues

The following message indicates there is an issue with your configuration that is causing a loop whereby the password change originating from DS results in an update from IDM back to DS for the same LDAP entry:

Caused by: org.identityconnectors.framework.common.exceptions.ConnectorException: javax.naming.ServiceUnavailableException: [LDAP: error code 51 - Entry uid=user.1,ou=People,dc=forgerock,dc=com cannot be modified because the server failed to obtain a write lock for this entry after multiple attempts]

To resolve this issue, you must prevent the managed user's password being synced to DS if the change originated from the DS password sync plugin. See the DS password sync flow section above for more details on achieving this. Alternatively, you can change the value of the ds-cfg-update-interval property (in the openidm-accountchange-plugin-sample-config file) to 1 or 2 seconds; this changes the sync operation to an asynchronous process and may resolve this issue

SSL debugging

SSL debugging traces the SSL handshaking phase. You can enable SSL debugging via the OPENIDM_OPTS environment variable.

On Unix® and Linux® systems:

$ cd /path/to/idm/ $ export OPENIDM_OPTS="-Djavax.net.debug=all" $ ./startup.sh

On Microsoft® Windows® systems:

C:\> cd \path\to\idm C:\path\to\idm> set OPENIDM_OPTS=-Djavax.net.debug=all C:\path\to\idm> startup.bat
Note

You can also edit the startup.sh or startup.bat files to update the default OPENIDM_OPTS values.

DS configuration files

The following configuration files are useful to check how DS has been configured and how the password sync plugin has been configured on the DS side:

  • config.ldif (located in the /path/to/ds/config directory).
  • openidm-accountchange-plugin-sample-config (located in the /path/to/ds/config directory).

You can then compare the configuration on the DS side with the configuration on the IDM side to ensure they correspond and correct if necessary.

IDM configuration files

The following configuration files (located in the /path/to/idm/conf directory) are useful to check how synchronization has been configured on the IDM side and compare with the DS configuration:

  • sync.json
  • managed.json
  • authentication.json
  • provisioner configuration file for DS, for example provisioner.openicf-ldap.json.
  • any associated scripts used to manage or transform the password attribute during sync, such as a separate onUpdate script (these are typically located in the /path/to/idm/script directory).
Note

It can be very useful to add logging to your scripts to help identify the point at which an issue can occur. Refer to How do I add logging to JavaScript files in IDM (All versions)? and How do I add logging to Groovy scripts in IDM (All versions)? for further information.

DS logs

The DS log files (access, errors and replication) can be useful for identifying any issues with the password synchronization process from the DS side. The logs collected should cover the period during which you are experiencing issues and the timestamps should correspond to the logs collected for IDM.

Enabling debug logging for the DS password sync plugin

You can enable debug logging for just the DS password sync plugin to minimize the size of the resulting DS logs as follows:

  1. Enable debug logging using one of the following dsconfig commands depending on your version:
    • DS 7.1 and later: $ ./dsconfig set-log-publisher-prop --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --publisher-name "File-Based Debug Logger" --set enabled:true --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
    • DS 7: $ ./dsconfig set-log-publisher-prop --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --publisher-name "File-Based Debug Logger" --set enabled:true --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
    • Pre-DS 7: $ ./dsconfig set-log-publisher-prop --hostname ds1.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --publisher-name "File-Based Debug Logger" --set enabled:true --trustAll --no-prompt
  2. Set the debug target class using one of the following dsconfig commands depending on your version:
    • DS 7.1 and later: $ ./dsconfig create-debug-target --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --publisher-name "File-Based Debug Logger" --type generic --target-name org.forgerock.openidm.accountchange.OpenidmAccountStatusNotificationHandler --set enabled:true --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --no-prompt
    • DS 7: $ ./dsconfig create-debug-target --hostname ds1.example.com --port 4444 --bindDN uid=admin --bindPassword password --publisher-name "File-Based Debug Logger" --type generic --target-name org.forgerock.openidm.accountchange.OpenidmAccountStatusNotificationHandler --set enabled:true --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --no-prompt
    • Pre-DS 7: $ ./dsconfig create-debug-target --hostname ds1.example.com --port 4444 --bindDN "cn=Directory Manager" --bindPassword password --publisher-name "File-Based Debug Logger" --type generic --target-name org.forgerock.openidm.accountchange.OpenidmAccountStatusNotificationHandler --set enabled:true --trustAll --no-prompt

IDM audit logs

The IDM audit logs (located in the /path/to/idm/audit directory) can be useful for tracking system activity; the activity.csv file is particularly relevant.

See Also

DS (All versions) fail to start after upgrade if you use the Password Sync Plugin for IDM

How do I upgrade DS (All versions) if I have the DS Password Sync Plugin for IDM installed?

Password Synchronization Plugin Guide

Related Training

ForgeRock Identity Management Core Concepts (IDM-400)

Related Issue Tracker IDs

N/A


Copyright and TrademarksCopyright © 2021 ForgeRock, all rights reserved.

This content has been optimized for printing.

Loading...