Use Case:
In an enterprise setup you would likely want to know when a user has locked their account (e.g. too many failed password attempts) and more than likely want to distribute that information to other systems in your environment. One solution would be to enable OpenIDM to monitor the user identity repository for changes to the user’s status.
This post will demonstrate one possible configuration for this use case.
Starting out with a typical ForgeRock set up … OpenIDM to provision and synchronize users, OpenAM to manage access and OpenDJ and the configuraton and user data store.
Assumptions:
- OpenDJ is already Installed ( or you plan to use the OpenAM’s embedded directory store )
- OpenAM is already configured to use OpenDJ as it’s configuration store and user identity store
- OpenIDM is already installed (and using OrientDB as the repo DB)
- The OrientDB console has been installed (not part of the ForgeRock software stack)
Steps to Configure:
OpenDJ:
- Modify the Default Password Policy (using OpenDJ’s dsconfig tool)
- Set the # of Password Failures before Lockout
- Enable Change Logs (by enabling replication)
- Using OpenDJ’s ./dsconfig tool
- Create a replication server
- Create a replication domain
- Using OpenDJ’s ./dsconfig tool
OpenIDM
- Create a connector to OpenDJ
- Create an OpenIDM to OpenDJ Mapping
- Create an OpenDJ to OpenIDM Mapping
Testing
First Lock the Account by failing the login. I am using the REST API but this can be done via the OpenAM UI as well.
Once the account is locked, verify that the attribute (pwdAccountLockedTime) now has a date time stamp as a value.
Now, verify that the OpenIDM repostitory has been updated with the same value.
Unlocking the Account
Unlocking the account is as simple as changing the password in OpenAM. Once you change the password you should be able to repeat the Testing steps to ensure that the pwdAccountLockedTime attribute has been returned to null.
Next Steps
Now that the pwdAccountLockedTime attribute is syncing between OpenDJ and OpenIDM you can take the next steps and have OpenIDM syncronize the changed value out to other systems as well.
Give us a call if you need help implementing this use case or any other similar use cases.
Disclaimers:
- OrientDB is not supported by ForgeRock for production installs
- Whether you use the embedded OpenDJ as part of your architecture would depend on your performance and scalability requirements.
- This particular architecture is for demo purposes and may not be suitable for your specific requirements. Give us a call if you need assistance in designing an appropriate architecture for your specific requirements.
Great!!! But the interesting here is the sync with others PasswordAccountLocked in others systems (AD, OID, Novell, adam,,….) and the conversion timestamps or the logical to locked accounts in the target systems (maybe force locked through ramdom password login).
I hope this is a second part of the PoC.
Hey Isaac,
First off, thanks for reading and commenting on my blog post.
You are right … just syncing the account locked time stamp back to OpenIDM is not very interesting. You would definitely want to sync downstream to your target systems. I haven’t had a chance to follow up on that but will if I have time. The systems that you mentioned … are those the ones that you are primarily interested in?
Thanks,
Brad