Configuring Kerberos Authentication

Enabling support for Kerberos authentication lets you extended your existing Kerberos infrastructure to Imprivata with SSO Authentication Management. Configuring Kerberos authentication delegates user authentication from the Imprivata agent to a non-Imprivata credential collector that is Kerberos-enabled.

In an Imprivata Enterprise Access Management deployment where Kerberos authentication is enabled:

  • Enterprise Access Management implicitly trusts the Kerberos ticket that Windows issues. If the user is successfully authenticated by Windows, Enterprise Access Management authenticates the user, as well.

  • The Imprivata agent is installed on all endpoint computers, but the Imprivata login module is disabled. The user authenticates to Enterprise Access Management through Windows or some other third-party software, such as disk encryption software.

  • If the user policy is configured for single sign-on (SSO), the authenticated user continues to access to their SSO-enabled applications. The Imprivata agent continues to proxy all user credentials to enabled applications. For more information, see Single Sign-On.

Prerequisites

Review the following prerequisites before you begin:

  • Verify that Kerberos is configured and enabled in your Windows environment. This topic details how to configure Enterprise Access Management for Kerberos authentication and assumes that the Kerberos deployment is running normally.

  • The Imprivata keytab utility (keytab utility), which you use to create and upload a keytab file to an appliance, uses ktpass to create and upload a keytab file to an appliance. The keytab utility is installed with the Imprivata agent.

    Ktpass is part of the Microsoft Windows Server resource kit. Beginning with Windows Server 2008, the resource kit tools are installed as part of the server role installation.

  • The endpoint computer from which you run the keytab utility and the primary appliance to which the Imprivata agent communicates must be in the same Active Directory domain.

    For example, if the fully qualified domain name (FQDN) of the endpoint computer is endpoint.example.com, then the Imprivata appliance FQDN could be server_name.example.com.

  • The Service Principal Name (SPN) of the appliance that the keytab utility registers with Active Directory is case-sensitive.

    The hostname and the domain name that appear in the Imprivata Appliance Console of this appliance must contain all lowercase letters.

  • If the Imprivata enterprise includes more than one domain that share a trust relationship, for example a parent company (company.com) and two subdomains (us.company.com and eu.company.com), make sure that at least one appliance is placed in company.com.

    Upload the keytab file to this appliance. Uploading to the appliance that is in the second-level domain (SLD) ensures that the keytab file is valid for all domains.

Authentication Workflow

The following diagram illustrates the authentication workflow between a Windows/Kerberos environment and Enterprise Access Management. The illustration details the following components:

  • A Windows endpoint computer with a non-Imprivata credential collector that is Kerberos-enabled. In this use case, the user authenticates using the Windows login screen.

  • An Imprivata single-user computer agent. The Imprivata agent login module is disabled (unregistered).

  • The Imprivata appliance.

Authentication workflow between a Windows/Kerberos environment and Imprivata OneSign

  1. The user authenticates to the Windows endpoint computer using the Windows login screen. Windows issues the Kerberos ticket.

  2. The Imprivata agent acquires the Windows-issued Kerberos ticket. The agent treats the Kerberos ticket, which contains the users credentials, as a successful capture of login credentials.

  3. The Imprivata agent passes the Kerberos ticket to the Imprivata appliance.

  4. The Enterprise Access Management server verifies that the Kerberos ticket is valid, extracts the user identity for the Kerberos ticket and validates it, and creates the SSO session.

NOTE: Although not illustrated, any software that includes a credential provider and is configured to authenticate users is considered a non-Imprivata credential collector. An example of such is a Check Point® Full Disk Encryption deployment configured to authenticate the user before loading the operating system (pre-boot authentication).

Configuring Kerberos Authentication

Configuring Kerberos authentication requires that you: