Imprivata Self-Service Password Reset

By default, a user is logged in after they change their password. Requiring re-authentication ensures that authentication is enforced after a successful password reset.

Select Require users to re-authenticate after resetting their password to prompt the user to re-authenticate using the authentication factors specified in their EAM user policy.

If you want to allow remote users to use Imprivata self-service, then you can publish the Imprivata self-services web application via reverse SSL proxy. The following instructions are intended to provide a general overview of this functionality; your environment may require a different configuration.

Only allow HTTPS traffic to the following URLs and ports (the URLs are formatted as regular expressions). Do not allow POST or PUT requests to any URL other than the URL listed in the following table. For all other URLs, only allow GET requests.

The application startup URL is https://%ONESIGN_APPLIANCE_HOST_NAME%/sso/passwordhelp.

Load Balancing

Imprivata recommends that you maintain Imprivata appliance affinity for the duration of a user session, rather than proxying HTTPS traffic to only one Imprivata appliance for all users. A best practice for load balancing in a reverse SSL proxy environment is to proxy a particular Imprivata appliance, chosen at random, when the user session is created, and then to maintain that association for the duration of the user session.

Imprivata self-service for password management requires that users enroll security questions.

To enforce the enrollment of security questions when users log into Imprivata Enterprise Access Management for the first time:

1. In the Imprivata Admin Console, go to the Users menu > User Policies page to create or modify a user policy.
2. Click the Self-Service Password/Imprivata PIN Reset tab.
3. In the section Enroll options — Prompt to enroll security questions, select:
   • Prompt and must enroll;
   • Prompt and may delay enrolling; or
   • Do not prompt to enroll (this is the default.)
4. Enter the number of security questions that users in the policy must enroll.
5. Enter the number of security questions that users in the policy must answer correctly to authenticate.
6. Click Save.

The authentication questions are drawn randomly from the total entered at enrollment, so a user policy might specify six questions, and present three of the six questions when the user authenticates either to reset a primary authentication password or to request application credentials (Single Sign-On only).

You can create new questions, as well. When you create new questions, you can make them mandatory. Mandatory questions are always presented.

Users who are in a user policy configured for Self-Service Password Reset are prompted to enroll the next time they authenticate to Imprivata Enterprise Access Management.

Even if you select Do not prompt to enroll, the Imprivata enrollment utility always appears after login if the user has only password enrolled.

Users can defer enrolling in Imprivata password self-service. You can set a Self-Enrollment Declined notification to notify you whenever any user or a specific user declines to enroll in password self-service. The procedure for this and all other notifications is detailed in Configuring Event Notifications.

You can edit the password self-service questions, including adding and deleting questions to suit the needs of your organization.

Modifying Self-Service Password Reset Questions

You can access the list of security questions in the following ways:

From the user policy:

• Go to the Self-Service Password/Imprivata PIN Reset tab > Reset options section, and click View and modify security questions.

• Go to the Authentication tab > Primary factors section. If emergency access is enabled, click View and modify security questions.

• Go to the Authentication tab > Authentication method options section, and click View and modify security questions.

From the Settings page:

1. Go to the gear icon menu > Settings page.

2. Go to the EAM self-service web app section, and click Modify security questions.

See Configuring Authentication Methods in User Policies

Imprivata self-service supports the language setting from the user's browser.

If the browser is set to Brazilian Portuguese, Danish, Dutch, Finnish, English, French, Italian, German, Spanish, or Swedish, the Self Service Password Help feature will display in that language. If any other language is selected as the default language in the browser, the Self Service Password feature displays in English. For information on languages available for the Imprivata agent, see About the Imprivata Agent.

Imprivata self-service password management requires a secure SSL connection to the user directory.

When the user interacts with Imprivata Enterprise Access Management during enrollment and all subsequent logons to an Imprivata-enabled workstation and/or the Imprivata Self-Services home page, and if the user’s Microsoft Active Directory (AD) password is authenticated from LDAP, then the password is stored in the Imprivata database.

The AD password and challenge/response answers, like all of Imprivata Enterprise Access Management’s data, are stored in an encrypted Oracle database on the appliance. When the user answers the challenge questions, the Imprivata appliance will authenticate the user’s responses against the answers captured during enrollment.

When the user correctly answers the challenge questions, Imprivata Self-Services will verify if the user account is locked. If the account is locked, then Imprivata Enterprise Access Management will unlock the account in AD.

When a user accesses Imprivata self-service to change their password, Imprivata Enterprise Access Management resets the user's AD password to a temporary password of randomly generated characters. This first password change is done using the privileged Imprivata service account in case the user's account has been locked. The privileged service account has the ability to reset an expired account, and will do so as part of the password change.

When the user types in a new password, the Imprivata appliance uses the now-cached temporary password of randomly generated characters to submit the password change using the end user's account (instead of the privileged service account). The reason this happens is to ensure the new password entered conforms to the AD complexity rules set for the user.

Because of this, use of Imprivata self-service for password management requires that the domain's Computer Configuration > Windows Settings > Security Settings > Account Policies >“Minimum password age” policy is set to zero days, otherwise the password change will fail with a “password not meeting complexity” error.

Imprivata self-service has two paths for changing passwords:

• When Imprivata Enterprise Access Management has a valid stored AD password and the user account is not locked in AD, then Imprivata Enterprise Access Management will use the user’s credentials to initiate a password change in AD. The user will then be prompted to enter the new password.

• Imprivata Enterprise Access Management changes the password in AD to a temporary strong password that it subsequently enters into the password change dialog for the user where the user may enter a new password. This is all automated for the user and the user will only see the password change dialog.

Keep in mind the following various reasons for a user not being able to login to the domain:

• The user’s stored password in Imprivata Enterprise Access Management is not valid. This could be for a number of reasons, such as:
• • The user changed his password on a non-Imprivata enabled workstation.
  • The help desk changed the password to a temporary password.
• The user account is locked because the user has attempted the wrong password too many times and AD policy has locked the account.

• NOTE: This is different than if an account is disabled in AD. A disabled account will require intervention from the help desk.

• The user account is restricted by time of day policies in AD. Imprivata Enterprise Access Management does not do anything to change this or allow access.

Imprivata self-service works using Microsoft APIs and proprietary functionality built by Imprivata and does not require an agent to be installed on the AD controller.