One commonly overlooked but absolutely critical piece of an Imprivata implementation is the ability to reset active directory passwords, expired or otherwise. It’s one of those things that tends to fade into the background in the midst of other pursuits and resolutions, but if it isn’t accounted for, it can cripple an entire environment. As soon as users’ passwords start expiring, and they are told they need to reset them before they can login, an incomplete or incorrect configuration on the appliance can result in users getting completely locked out of their desktops, relegating them to downtime procedures or worse.
There are a few different stars that need to align for the Imprivata password reset to work seamlessly. None of them are particularly hard to address if you know what you should be looking at:
- You may need to enable SSL. Navigate to the Users, Computers and Domains tab in the OneSign administrator console, then to the OneSign domains subtab, and select your domain. Ensure the “Use Secure Connection (SSL)?” checkbox is ticked. If it is not, tick it off and hit save. Imprivata will seek out the certificate, ask you whether you want to trust it, and once you answer affirmatively, SSL will be enabled. If instead you are met with an error indicating the connection fails after enabling SSL, you may need to upload the certificate yourself. This could possibly be happening because your certificate authority is not on the domain controller with which Imprivata is communicating. If that is the case, please reference this article for more information on generating the certificate, or this one about configuring LDAPS on your domain controller.
- Also on the Users, Computers, and Domains > OneSign Domains > [Your domain] page, you will have an Administrator User Name and Password. Confirm that the user listed has sufficient rights to reset passwords across the domain and be sure that its password is not set to expire at any point. If this account’s password has expired, it will be unable to perform the necessary functions. Imprivata recommends this account be a domain admin, but account operator status will suffice. You could get away with password reset/account unlock rights alone, but if you are having problems with limited privileges, promote it to domain admin and see if your problem is fixed. Furthermore…
- …Note that if you make the account anything less than a domain admin, the account will be unable to reset the passwords of other domain admins. This is per active directory, not a limitation of Imprivata itself.
If you have addressed all of the above and are still having problems, try accessing the domain controller itself as the Administrator account referenced in the second point. Attempt from there to reset a user’s password manually, without ever involving Imprivata to confirm it is not an issue with the account itself. I have heard rumors of people having to create a new account for no apparent reason, but if you find that it cannot change passwords from there, it certainly won’t work from the other side. Conversely, if it does work from there and still doesn’t work from the endpoints, you may want to confirm that your problem isn’t something a little more fundamental, like whether or not your machine is on the domain in the first place.