avoiding unnecessary password updates?

Tagged: ,

This topic has 2 replies, 2 voices, and was last updated 4 years, 11 months ago by [email protected].

  • Author
    Posts
  • #14053

    Hi all,

    there is lots of documentation about syncing passwords from OpenDJ/AD to OpenIDM, but very little on syncing passwords out of OpenIDM to OpenLDAP/OpenDJ/AD.
    A simple setup certainly works, e.g. following http://stackoverflow.com/questions/23951651/how-to-do-password-synchronization-between-openidm-and-opendj

    It is fine when a password is really changed and there is no issue for livesync, but it is really bad for a full reconciliation. Since the hashed passwords in OpenLDAP/OpenDJ/AD are never equal to the passwords stored in OpenIDM, reconciliation triggers updates of (unchanged) passwords for all users. I’m quite unhappy, especially since I use the powershell-connector for AD, so speed isn’t great anyway.

    Are there any ideas or best practice advice? Since I’m controlling the password-change-process I consider adding some kind of “password-revision” that is incremented every time the password is changed. Then I just need a minor update to my LDAP-schema to include a passwordRev attribute so I can remove the password from my mapping and try some onUpdate-script like

    if (source.passwordRev !== target.passwordRev) {
    target.passwordRev = source.passwordRev;
    target.ldapPassword = openidm.decrypt(source.password);
    }

    An alternative would be to remove the password-attribute from all mappings and have a password-change-endpoint updating system/ad/__ACCOUNT__ and system/openldap/__ACCOUNT__ directly. But I would face a risk of inconsistent passwords, since there is no good way to retry if for example one of the servers involved isn’t operational. In reality I would perform openidm.read on both system/ad/__ACCOUNT__ and system/openldap/__ACCOUNT__ before changing the first password, hoping that no server goes down between verifying I get openidm.read and actually performing openidm.uodate, but still… One workaround could be to create an activiti workflow changing the passwords in sequence and performing retries in the workflow. Doesn’t feel great, though.

    I’d appreciate any advice.

    #14056

    One possibility is to use password change timestamp, which is a common attribute in many systems. Then in the mapping you can compare if password in IdM is newer than password in the target system. Of course you need to make sure that the time within your environment is synced.

    #14077

    Hmmm, I don’t really like timestamps, using slightly different formats and resolutions on all components involved. But since both AD and OpenDJ have a password-timestamp anyway (wasn’t aware of the operational attribute in OpenDJ) and it’s easy to enable the ppolicy-overlay in OpenLDAP, that’s probably the way to go…

    OpenLDAP has “lastPasswordSet”, which is used in the samples only. I just hope it is safe using that attribute…

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

©2021 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?