Integrated Windows Authentication

Overview

The article describes Integrated Windows Authentication (IWA) with DirX Access. This mechanism allows for the integration of authentication credentials maintained in Windows domains.
The article assumes some familiarity with the authentication and SSO concepts of Windows domains and the Kerberos authentication system in particular.

Use Cases

The following use cases need to be distinguished with respect to an integration of authentication credentials that are maintained in Windows domains:

  • DirX Access consumes authentication statements issued for a Windows domain. In this case, Kerberos is used as an authentication protocol and DirX Access consumes Kerberos tickets issued by a Windows domain controller. This setup provides SSO with the Windows domain.

  • DirX Access interacts with services in the Windows domain to validate authentication credentials maintained in Windows domains. In this case, a variety of frontend and backend protocols can be used, in particular.

    • NTLM authentication for HTTP, making use of NTLM-specific HTTP authentication headers in the frontend and NTLM-based validation request/response messages exchanged with the Windows domain controller in the backend.

    • Arbitrary frontend protocol (for example, HTML form-based authentication) with Kerberos as a backend protocol between DirX Access and the Windows domain controller.

The article focuses on the use cases of the Kerberos authentication system (where DirX Access consumes authentication statements issued by a Windows domain controller) as well as the NTLM protocol sub-case in which DirX Access interacts with services in the Windows domain to validate authentication credentials maintained in Windows domains.

Architectural Overview

The following entities need to be distinguished from an architectural perspective:

  • Windows domain controller: a Windows server that provides the Active Directory server (persisting user and service accounts) and the Kerberos KDC (authenticating users and issuing Kerberos-based service tickets) for a Windows domain.

  • User clients: the client-side applications employed by users; for example, Web browsers.

  • Web containers: container components, for example, Servlet containers hosting the (third-party) Web applications.

  • DirX Access PEPs: policy enforcement components securing the Web containers and its embedded Web applications.

  • DirX Access Authentication Application (AA): the service where the authentication can be delegated.

  • DirX Access Server: the services container supporting the DirX Access PEPs.

With respect to IWA, the work split between Web containers and DirX Access is important:

  • From the communication protocols perspective, the authentication protocols needed for IWA (HTTP with SPNEGO/KRB/NTLM authentication headers) are terminated by the Web containers. The Web container needs to be IWA-enabled (for example, Kerberized) to participate in IWA.

  • The actual IWA enablement is provided by the DirX Access PEPs or DirX Access PEPs and Authentication Application. Beyond DirX Access PEP deployment or DirX Access PEP and Authentication Application deployment, no change is needed for the Web containers and their applications.

With respect to IWA, the work split between DirX Access PEPs/AA and DirX Access Server is also important:

  • From the frontend protocols perspective (HTTP with SPNEGO/KRB/NTLM authentication headers), the DirX Access PEPs/AA terminate the communications in the server role and present the components that are Kerberized.

  • In case DirX Access PEP approach only:

    • The DirX Access PEPs offload the processing of the Kerberos and NTLM-based credentials they obtain to the DirX Access servers, which means if there is a need to interact with Windows domain controllers (see the Use Cases described above), DirX Access Server (not DirX Access PEPs) act in a client role with respect to the Windows domain controllers.

  • In case DirX Access PEP delegate the authentication to DirX Access AA:

    • DirX Access AA offloads the processing of the Kerberos and NTLM-based credentials to the DirX Access servers.

Integrated Windows Authentication Enablement

This section briefly identifies the tasks required to enable IWA according to the architectural entities described in the previous section:

  • Windows domain controller: the actual enablement for IWA is done by promoting a Windows server to a domain controller. This is part of a normal Windows domain deployment and nothing special or DirX Access-specific is needed.

  • User clients: need to be Windows authentication-enabled in order to participate in IWA. For Web browsers, this translates to the need to support SPNEGO/KRB/NTLM authentication headers in HTTP. The actual enablement for IWA depends on the client implementation (for example, Microsoft Internet Explorer, Mozilla Firefox or Google Chrome) and mostly requires some explicit configuration settings. Nothing DirX Access-specific is needed.

  • Web containers: the IWA enablement is offloaded to DirX Access PEPs and nothing is needed beyond deploying a DirX Access PEP.

  • DirX Access PEPs or DirX Access PEPs and DirX Access AA: need to be configured for IWA enablement (see the Integration Settings described below).

  • DirX Access Server: need to be configured for IWA enablement (see the Integration Settings described below).

Configuration Steps

As described above, the DirX Access servers are the actual components that need to be enabled to participate in IWA. This section describes this enablement. Since the Kerberos authentication system and its common implementations such as in Windows and Java allow a variety of approaches to integrate, the integration is first described on a conceptual level.

Integration Concept

Integration comprises the following steps:

  1. Create a service account as the side of Windows domain controller for the service to be IWA-enabled. The next step associates the service account with the SPN (Service Principal Name) and the service password.

  2. Use ktpass.exe (part of the Windows support tools) to bind the SPN to the service account created in step 1 and provide the service password. The SPN and service password values need to be configured in DirX Access (detailed below).

    the Windows domain controller supports the export of Kerberos-specific keying material in the form-factor of so-called keytab files via ktpass.exe. This is optional and not used by DirX Access. Hence keytab files eventually created by ktpass.exe can be ignored.

  3. Edit the krb5.conf file on the DirX Access Server machines to point to the Windows KDC. This is a file object owned and consumed by the JRE which is not provided with the JRE installation. To simplify its creation, the DirX Access Server provides a stub krb5.conf file object which is provided in {installation_folder}/Services/instances/{instance}/etc/krb5.conf. This file object needs to be edited accordingly Kerberos V5 System Administrator’s Guide.

  4. Set the encryption types allowed for the Kerberos protocol with the Windows Security Policy “Network security: Configure encryption types allowed for Kerberos” (see Network Security: configure encryption on types allowed for Kerberos for details).

    Integrated Windows Authentication was successfully tested with the Kerberos types DES_CBC_MD5, RC4_HMAC_MD5 and AES128_HMAC_SHA1.

Integration Settings

To enable IWA, you need to make the following DirX Access-specific configurations:

  1. Create an authentication method configuration object for the authentication type windows (that is, IWA). The structure of this configuration object is defined in the Administration Guide - Windows Authentication Methods section. Use DirX Access Manager - Configuration | Authentication | Authentication Methods | Windows page to create it.

    Because Kerberos tickets and NTLM tokens do not (by their definition) contain rich context about the authenticated subject, it is important to administer the user account correlation appropriately in an authentication method configuration object for IWA if the intent is to work with information-rich subject representations (for authorization or personalization usages, for example). If the context natively provided in Kerberos tickets and NTLM tokens is sufficient, there is no need to work with user account correlation.

  2. Bind the IWA authentication method configuration object to some resources via the authentication policy. This is not IWA-specific task and is thus not further detailed here.

  3. Use the DirX Access Manager - Configuration | Policy Enforcement Points page to specify the following configuration items for each IWA-enabled PEP. These settings must reflect the SPN and service password of the Kerberized service (see the Integration Concept - step 2 described above). These configuration parameters are defined in the Administration Guide - Policy Enforcement Points section.

    • Kerberos SPN table reference: the reference to the configuration object defined in the Administration Guide - Kerberos SPN Table section.

      • Kerberos service principal name (SPN), e.g. HTTP/my-server.my-company.example@MY-COMPANY.EXAMPLE

      • Kerberos service password of the service account used for binding to the SPN.

    • Domain name: Windows domain name; required only when enabling NTLM in addition to Kerberos.

    • Windows domain controller: host name of the Windows domain controller; required only when enabling NTLM in addition to Kerberos.