Face Recognition as an Authentication Method

You can configure Entra ID as an IdP to authenticate users to the Imprivata Access Management console. You require access to the following to complete the configuration:

• The Imprivata Access Management setup.

• The Microsoft Entra Admin center.

Save the Imprivata SP Metadata

Use the Imprivata Access Management setup to create the Imprivata SP metadata file. You require this file when configuring the Entra ID enterprise application.

To create the metadata file:

1. Open the Imprivata Access Management setup.

2. Agree to the Cloud Features Agreement and enter information about your organization.

3. Skip to the Identity Provider Connect screen.

4. Copy the Imprivata SP metadata URL, paste it into a new browser tab, and save the page as an XML file.

Do not close the setup. You finish configuring the connection here after you configure the enterprise application.

Configure the Entra ID App

An Entra ID enterprise application is required to allow SAML-based SSO to the Imprivata Access Management console.

To configure the enterprise application:

1. From the Azure portal, go to Microsoft Entra ID.

2. Click Manage > Enterprise Applications > New application.

3. Click Create your own application.

4. Enter a name for the application, select Integrate any other application you don't find in the gallery, and then click Create.

5. From the Overview page, click Assign users and groups, and then add the Imprivata admin user group.

6. Go to the Overview page, click Set up single sign-on, and then select SAML.

7. Click Upload metadata file, and upload the Imprivata SP metadata file you created previously.

8. Under Basic SAML Configuration, click Edit, and enter the following Sign on URL: https://access.imprivata.com.

9. Save the settings.

Copy and Save Entra App Values

Copy and save required federation and group attribute values from the enterprise application. You will use these values to complete the SAML configuration and specify the Imprivata admin group.

To locate the required values:

1. Go to SAML certificates, and copy the App Federation Metadata URL.

2. Under Attributes & Claims, click Edit, and copy the claim name for the user groups value.

   Example: http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

   NOTE:

   If the user group claim does not exist, create it. When creating it, select Groups assigned to the application and use Group ID as the source attribute.

3. Return to the Microsoft Entra ID Overview page.

4. Click Manage > Groups >All groups.

5. Locate the admin group and copy its object ID.

Return to the Imprivata Access Management setup to finish the configuration.

Use the Entra App Values to Finish the Configuration

With the federation and group attribute values you had previously saved, use the Imprivata Access Management setup to finish the SAML configuration and specify the Imprivata admin group.

To finish the configuration:

1. Open the Imprivata Access Management setup, and return to the Identity Provider Connect screen.

2. Enter your organization's domain and a user-friendly display name.

3. Enter the SAML IdP metadata URL from the enterprise application, and click Continue.

4. Enter the user group claim name in to SAML attribute name.

5. Enter the object ID of the admin group in to SAML attribute value, and click Continue.

   If you are specifying multiple admin groups, the object IDs must be comma-separated.

6. Click access.imprivata.com to log in to the Imprivata Access Management portal.

NOTE:

Specifying a metadata URL allows for easier maintenance. The system automatically polls the URL at regular intervals.

This ensures that your IdP configuration stays up to date with the latest metadata, such as certificate changes.

If you upload a metadata file instead, the system does not update it automatically. From the Imprivata Access Management portal, you must edit the configuration to replace the file manually or switch to a URL.

The following are generic steps to configure any external third-party IdP to authenticate users to the Imprivata Access Management console. For example, these steps apply to Ping Identity and Okta.

To configure your IdP:

1. Open the Imprivata Cloud Tenant Setup wizard.

2. If you have not already, agree to the Cloud Features Agreement and enter information about your organization.

3. Go to the Identity Provider Connect screen.

4. Copy the Imprivata SP metadata URL and provide it to your IdP. When configuring the IdP's application:

   • Specify https://access.imprivata.com for the single sign-on URL.

   • Recommended: configure email address as the NameID format for user identity.

   • Recommended: configure Group ID (rather than group name) as the source attribute for group claims.

5. Enter the SAML IdP metadata URL, and click Continue.

6. Enter the SAML name/value pair that identifies users with administrative access, and click Continue.

7. Click Go to Access URL: access.imprivata.com to test the authentication workflow to access Imprivata Access Management.

Add the Required Host to Your Firewall Allowlist

Ensure that your firewall policy is configured to allow:

• Communication between the Imprivata appliances and the production Imprivata Cloud Platform.

• Communication between your endpoints and the production Imprivata Cloud Platform.

Add the following hosts to your firewall allowlist:

• <tenantID>.sys.imprivata.com

• astra.sys.imprivata.com

• <tenantID>.access.imprivata.com

• access.imprivata.com

• metadata.app.imprivata.com

• file-access.app.imprivata.com

• idp.app.imprivata.com

Consider the following:

• For non-US regions, replace the .com with the appropriate domain suffix for your region, for example, *.sys.imprivata.eu.

• You can locate your Imprivata Cloud Platform tenant ID by clicking the link to the Imprivata Access Management setup in the welcome email. The tenant ID appears in the URL. For example:

  

Certificate Revocation Checking and Outbound Communication on TCP Port 80

Imprivata cloud services rely on standard TLS certificate validation performed by the client platform. Depending on the operating system, browser, connector, application, and local security policy, certificate validation may include revocation checking for the TLS certificates used to establish trusted connections. During certificate validation, the client may retrieve certificate revocation information from the issuing Certificate Authority (CA)."

The location of this information is published in the certificate itself:

• The CRL Distribution Points (CDP) extension names where the Certificate Revocation List (CRL) can be downloaded

• Where applicable, the Authority Information Access (AIA) extension names the OCSP responder that can be queried for a certificate's status.

The revocation data itself is not carried in the certificate; the client uses these pointers to fetch it from the CA's endpoints.

Some of those CA revocation endpoints are published as HTTP URLs and therefore require outbound access over TCP port 80.

• This port 80 access is used only to retrieve CA-published certificate status information (CRLs or OCSP responses).

• It is separate from the encrypted application connection to Imprivata cloud services, which uses HTTPS/TLS.

Administrators who restrict outbound HTTP traffic should allow outbound TCP port 80 only from the systems that connect to Imprivata cloud services, and only to the CA revocation endpoints required by the certificate chain.

• Identify these endpoints from the CRL Distribution Points and Authority Information Access fields in the relevant certificates, or from the issuing CA's published revocation-service documentation.

• Enforce the restriction through firewall, secure web gateway, or explicit proxy rules that allow only the required CA hostnames and revocation paths.

• Allowlist by fully qualified hostname (FQDN), not by IP address.

  CA revocation endpoints are frequently served from content delivery networks whose IP addresses change without notice; an IP-based rule will break silently when the CA rotates infrastructure.

  General outbound web browsing over port 80 is not required, and no inbound port 80 access to the customer environment is required for this purpose.

Do not disable certificate revocation checking to work around blocked CRL or OCSP access. If a system cannot reach the required CA revocation endpoints, one of two things happens depending on the client's revocation policy:

• Validation may hard-fail, and the connection is refused;

• Validation may soft-fail, and the connection proceeds without confirming revocation status, silently weakening the protection the check was meant to provide.

Disabling revocation checking guarantees the second, weaker outcome for every connection.

By default, the Imprivata Cloud Connect service is disabled. You must enable the service before configuring the connection to the Imprivata Cloud Platform.

To start the service:

1. In the Imprivata Appliance Console, go to System > Operations.

2. Locate Imprivata Cloud Connect, and click Stop/restart options.

3. Select Restart Imprivata Cloud Connect on all appliances, and click Go.

Using the Imprivata Admin Console, copy your enterprise integration ID. You require this value to use the Imprivata Access Management setup to create an integration token.

To copy your integration ID:

1. In the Imprivata Admin Console, click the gear icon > Imprivata Access Management integrations.

   NOTE:

   A status message of Unable to verify integration. Unable to connect to Imprivata Access Management is expected.

2. Copy the enterprise integration ID to your clipboard.

3. Do not log out. You finish configuring the connection here after using the Imprivata Access Management setup to create the integration token.

Using the Imprivata Access Management setup, enter your enterprise integration ID to create an integration token. This token is required to finish configuring the connection in the Imprivata Admin Console.

To create the integration token:

1. Open the Imprivata Access Management setup.

2. If you have not already, agree to the Cloud Features Agreement and enter information about your organization.

3. Go to the Connect to Enterprise Access Management screen, and paste the integration ID into Enterprise integration ID.

4. Click Create integration token and copy it.

5. Return to the Imprivata Admin Console to finish configuring the connection.

Using the Imprivata Admin Console, finish configuring the connection to the Imprivata Cloud Platform using the integration token you created.

To finish the configuration:

1. In the Imprivata Admin Console, click the gear icon > Imprivata Access Management integrations.

2. Paste the integration token, and click Integrate.

3. Select Administrator console single sign-on using SAML.

   This setting is required to enable SSO access to your administrator consoles in the Imprivata Access Management console.

To add the trusted Imprivata IP addresses:

1. From the Azure portal, go to Microsoft Entra ID, and select > Manage > Security > Manage > Named locations.

2. Click IP ranges location.

3. Enter a name for the new location, and then select Mark as trusted location.

4. Add the following IP addresses:

   • 44.207.16.175/32

   • 44.196.189.191/32

   • 34.195.47.118/32

5. Click Add, and then Create.

If per-user multifactor authentication is enabled for users, adding the trusted Imprivata IP addressees to the list of MFA trusted IPs is required.

To add the IP addresses:

1. From the Microsoft Azure Portal, go to Microsoft Entra ID > Manage > Users, and click Per-user MFA.

2. Select the Service Settings tab.

3. Add the following IP addresses to Skip multifactor authentication for requests from following range of IP address subnets:

   • 44.207.16.175/32

   • 44.196.189.191/32

   • 34.195.47.118/32

4. Click Save.

By default, Microsoft Entra Connect Sync pass-through authentication or Password Hash Sync (PHS) is supported.

• If your environment is Entra ID only, neither pass-through authentication nor PHS is required.

• If your Entra ID environment is federated with a third-party IdP, however, PHS is required.

To verify whether PHS is enabled:

1. From the Microsoft Azure Portal, go to Microsoft Entra ID > Manage > Microsoft Entra Connect.

2. Click Connect Sync.

3. Under Microsoft Entra Connect sync, verify that Password Hash Sync is enabled.

4. If it is not enabled, configure Password Hash Synchronization from the server where the Microsoft Entra Connect Sync Agent is installed.

Configure Imprivata Enterprise Access Management as a directory. Doing so, provides full user sync capabilities.

Syncing your users requires one of the following:

• Entra ID Global Administrator rights

• Privileged Role Administrator rights

To sync Entra ID users:

1. Log into the Imprivata Access Management portal (access.imprivata.com).

2. Click the gear icon > Users > Entra ID users.

3. Click Add an Entra ID directory now.

4. Enter your Entra ID Tenant ID, and click Continue to Microsoft Authentication.

5. Using an Entra ID Global Administrator account, or another account with privileges to grant admin consent for application permissions, log in to Entra ID.

6. When prompted, review the required permissions, and click Accept.

7. Click Specify groups now. Enter one or more groups names, and click OK.

8. Click Update now to sync users.

If your Entra ID environment is federated with a third-party IdP, this step is required.

The Imprivata Cloud Platform must be able to validate user passwords when entered. In a federated environment, Imprivata needs to avoid these calls from being redirected to the federated identity provider (IdP). You must change the home realm discovery policy for authentication from the Imprivata Cloud to your Entra ID tenant only. This only applies to authentication calls made by the Imprivata Access Management Sync.

To create and apply the Home Realm Discovery policy:

1. Log in to Microsoft Graph Explorer.

   To make it more secure, log in as the Global Administrator.

2. Consent to the Microsoft Graph explorer application in your tenant.

   For more information, see the Microsoft Graph API documentation.

3. Create a home realm discovery policy by making the following HTTP request:

   POST - https://graph.microsoft.com/v1.0/policies/homeRealmDiscoveryPolicies

   Request body

   In the request body, supply a JSON representation of the homeRealmDiscoveryPolicy object:

   Copy

   {
           "displayName": "yourPolicyName",
           "definition": [
           "{\"HomeRealmDiscoveryPolicy\": 
           {\"AllowCloudPasswordValidation\":true, } }"
           ],
           "isOrganizationDefault": false
   }

   Response

   If successful, this method returns a 201 Created response code and a new homeRealmDiscoveryPolicy object in the response body.

   Example Response

   Copy

   {
           "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#policies/homeRealmDiscoveryPolicies",
           "value": [
           {
               "id": "239cbead-1111-654a-9f50-1467d691aaa",
               "deletedDateTime": null,
               "definition": [
               "{\"HomeRealmDiscoveryPolicy\" : { \"AllowCloudPasswordValidation\":true, } }"
               ],
               "displayName": "Exclude Federated Authentication ",
               "isOrganizationDefault": false
           }
       ]
   }

4. Assign the home realm discovery policy to the Imprivata Access Management Sync application by making the following HTTP request:

   POST - https://graph.microsoft.com/v1.0/servicePrincipals/<the Imprivata Access Management Sync application object id>/homeRealmDiscoveryPolicies/$ref

   Request body

   In the request body, supply the identifier of the homeRealmDiscoveryPolicy object that should be assigned.

   Copy

   {
       "@odata.id":"https://graph.microsoft.com/v1.0/policies/homeRealmDiscoveryPolicies/<yourHomeRealmDiscovery_PolicyID>"
   }

   Response

   If successful, this method returns a 204 No Content response code.

5. Verify that the home realm discovery policy was successfully applied to the service principal by making the following HTTP request:

   GET - https://graph.microsoft.com/v1.0/policies/homeRealmDiscoveryPolicies/<homeRealmDiscoveryPolicy object id>/appliesTo

   Response

   Copy

   {
           "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects",
           "value": [
           {
           "@odata.type": "#microsoft.graph.servicePrincipal",
           "id": "c1f8e0d4-25b0-46b2-aaa8-827822631a33",
   
   ...

You must exclude the Imprivata Access Management Sync application from all conditional access policies that would require MFA for Imprivata users.

To update a conditional access policy:

1. From the Microsoft Azure Portal, go to Microsoft Entra ID, select Manage > Security > Protect > Conditional Access > Policies.

2. Click the policy that applies to your Imprivata users.

3. Under Target resources, click All resources (formerly All Cloud apps).

4. Click Exclude, and then toggle Select resources.

5. Under Select specific resources, click None or any of the listed applications.

6. Search for Imprivata Access Management Sync, select it, and click Select.

7. Save the policy.

8. Repeat for all conditional access policies that would require MFA for Imprivata users.

You can identify Entra ID configuration issues early, before they affect user authentication, by running a password authentication test:

• This test can be run for any synced user.

• If password authentication fails, general guidance on possible causes along with the Entra ID error code are provided.

To run the test:

1. Log into the Access Management console (access.imprivata.com).

2. Click the gear icon > Users > Entra ID users.

3. Open the overflow menu in the upper-right corner of the page, and click Test Entra ID configuration.

4. Enter the user credentials of any synced user, and click Test.