Getting Started with Identity Bridging: Kerberos Setup

VMware Workspace ONE UEM 9.5 and later VMware Unified Access Gateway 3.3 and later

Getting Started with Identity Bridging: Kerberos Setup

Introduction

Today's workforce depends on mobility and organizations must enable their workforce through multiple ways—this enablement can lead to a review of internal procedures, technologies, IT security requirements, and so on. As part of this process, providing external access to internal web applications is one of the top priorities for IT leaders to enable the workforce. Security is the primary requirement; providing the best user experience without compromising security is key.

Unified Access Gateway allows secure access to internal applications through multiple edge services. This section demonstrates how identity bridging can provide external access and single sign-on to internal legacy applications (non-SAML applications) using Kerberos constrained delegation(KCD).

Identity bridging on Unified Access Gateway acts as a proxy that sits in front of web applications and translates the user identity to Kerberos. The user provides their identity through SAML or a certificate, and Unified Access Gateway translates that identity and uses KCD to perform the authentication against the internal applications.

The identity bridging mode can be configured with Workspace ONE in the cloud to authenticate users. When a user requests access to a legacy Web application, the identity provider (IdP) applies the applicable authentication and authorization policies.

This section guides you through the entire process on how to configure identity bridging and covers all the requirements.

These exercises cover Kerberos configuration on Windows Server 2016.

Procedures include:

  • Understanding Kerberos Delegation
  • Configuring Internet Information Server (IIS) to support Kerberos Authentication
  • Configuring Kerberos Delegation on the Service Account

After you complete the initial identity bridging configuration, you can configure one of two options:

 The steps are sequential and build upon one another, so make sure that you complete each step before going to the next step.

Architecture

The architectural diagram below shows an example environment which emulates a typical environment, including DMZ and internal networks.

In this example, external requests to the vApp are sent to the vPod Router, which directs those requests to the appropriate resource, based on the incoming port. Ports 4000-6500 are reserved for the environment components so all traffic coming in on these ports is forwarded to the appropriate Edge Service for the Unified Access Gateway server. In addition, ports 443 and 9443 are forwarded to the Unified Access Gateway server over the respective ports.

The vApp networks (internal, DMZ, and transit) are created within the vApp. The internal and transit networks are NATed to the SE-UCS-Network for outbound internet connectivity while the DMZ network routes through the vPod Router for inbound and outbound access. Note that the vPodRouter does not have a NIC on the internal network and therefore cannot route external traffic to resources on the internal network.

vPod Router | ESXi01 6.5.0 U1 | Control Center | vCenter Server 6.5 U1 hosted on ESXi01

Architecture Overview Diagram

The following architectural diagram shows an example of two major networks that you can deploy your servers into. For this set of exercises, you deploy the Unified Access Gateway appliance on a DMZ and assign the respective NICs.

At the top of the diagram is vCenter Networking. At the bottom of the diagram is the vApp network required to support the environment. For these exercises, the focus is on the network hosted on the ESXi, and represented by the following three networks:

  • VM Network & Management: Represents the dedicated network to access the Management Console
  • Internal Network: Represents the internal network on 172.16.0.x range. The Control Center, ESXI, and vCenter are part of the internal network.
  • DMZ Network: Represents the DMZ network on 192.168.110.x which is where the Unified Access Gateway appliance is to be deployed. The Unified Access Gateway Internet-facing NIC is associated to this network.

Network Interfaces

Unified Access Gateway supports deployments with one, two, or three NICs. This means that the server can be partitioned to receive traffic on a single interface or to route traffic to different interfaces, based on the source of the request. Most often, if you need to implement multiple NICs, you already follow this standard with other web applications in your organization.

You must determine what is appropriate for your environment when selecting the number of NICs during installation. It is important for you to understand the expected behavior when two or three NICs are enabled.

To explore these options, see Deploying VMware Unified Access Gateway: VMware Workspace ONE Operational Tutorial.

General Considerations

In the exercises for deploying the Unified Access Gateway server through vSphere, the vCenter setup is hosted in a nested template. This is not usually the case when working with users in a live environment.

User environments can include multiple networks and can optionally have a Network Protocol Profiles (NPP) that corresponds to the networks to connect to the Unified Access Gateway. Prior to version 3.3, NPP was a requirement. Since version 3.3, NPP is no longer required.

Note: Keep in mind that the Unified Access Gateway requires a netmask, default gateway, and subnet to be defined for each network enabled during deployment.

Prerequisites

To perform the steps in this exercise, the following prerequisites are required. The following steps focus only on Kerberos configuration and there is no need to download any VMware software:

  • AD account with administrator privileges to configure Kerberos delegation.
  • Administrator access to the IIS Web Server to perform Kerberos configuration on the websites that will be accessible through Unified Access Gateway.

 

Kerberos Delegation Overview

Kerberos delegation allows a configured system and user to request Kerberos tokens on behalf of another user.

Because Unified Access Gateway is not joined to the domain, you must add Active Directory (AD) domain Kerberos support to Unified Access Gateway. This process is done with a keytab file, which contains necessary security tokens/hashes for Unified Access Gateway to interact with AD. The keytab file also contains information about the user delegated to request Kerberos tokens on another users behalf.

Microsoft recommends that each internal web application has its own delegated user and therefore different keytab files. It is possible to have one delegated user and one keytab file for many different internal apps, but if the keytab file is compromised, you risk access to all internal apps. When you have one user and keytab file per application this allows you to disable access to only one system at a time.

Although creating the user and keytab file for each application requires more administration, there are clear security benefits.

A Kerberos realm is the domain over which a Kerberos server has the authority to authenticate. A realm is your trust boundaries. In AD Kerberos, your trust boundaries are your clients, AD servers, and application servers all joined to the domain. Each one trusts the other because they are all part of the same Kerberos realm.

This exercise uses the following environment configuration:

  • AD Domain / Kerberos realm — CORP.LOCAL
  • Internal web server computer name — INTRANET
  • Internal web server URL — http://it.corp.local
  • Internal web application (Kerberos enabled) — http://it.corp.local/itbudget
  • URL used in Workspace ONE Web to access the internal web site through Unified Access Gateway— https://uag.airwlab.com/itbudget
  • User for Kerberos delegation: iis_it (UPN: iis_it@CORP.LOCAL)

Authentication Flow

The following diagram describes all the steps used by identity bridging with SAML to Kerberos authentication on Unified Access Gateway. Understanding Kerberos is critical to successfully configure identity bridging.

  1. Client navigates to the application URL (https://uag.airwlab.com/itbudget).
  2. Client is redirected to the IdP (Workspace One) for authentication (https://vidm.airwlab.com). The IdP issues a SAML assertion upon authentication.
  3. Client passes the SAML assertion to Unified Access Gateway (http://uag.airwlab.com). Unified Access Gateway validates that the SAML assertion is from a trusted IdP.
  4. Unified Access Gateway extracts the client’s username from the SAML assertion and requests a Kerberos ticket from Active Directory (CORP.LOCAL) on behalf of that user.
  5. Unified Access Gateway authenticates against the internal web server (https://it.corp.local) using the Kerberos ticket obtained from AD.

Configuring Kerberos Delegation

This exercise helps you to configure Kerberos delegation for the IIS IT service account that has been assigned to handle Kerberos delegation for the IIS website.

1. Configuring Service Account in Active Directory

IIS IT User

Confirm that your service account (CORP\IIS_IT) is available in Active Directory Users and Computers management console. This example uses the CORP\IIS_IT (IIS IT) account.

  1. Click the Active Directory Users and Computers icon from the taskbar.
  2. Navigate to Users.
  3. Confirm your IT user exists.

1.1. Configure Service Principal Name (SPN) for Service Account

The next step is to assign a Service Principal Name (SPN) entry for the name the website has to respond to, for example, IT.CORP.LOCAL.

The SPN can be associated to a web server machine name or service account under which the application pool's web server will be running. It can be Local System, Network Service, or a domain account; the SPN must be unique.

If the IIS website only needs to be available by the server name on which it is located, you would not need to create additional SPN entries as these already exist in the server account INTRANET in Active Directory. In this example, the DNS name is IT.CORP.LOCAL and the web server machine is INTRANET, and you create an SPN entry HTTP/IT.CORP.LOCAL for the user account CORP\IIS_IT.

Important: For Kerberos authentication to succeed in a load-balanced scenario, the web servers must use an alternate credential that is shared by all members of the array. The credential must also be associated with the array-specific SPNs. This shared credential may be either a computer account or a service account and must be known by every web server within the array.

Load balancing is outside the scope of this exercise, however, for more information, see the Microsoft article: Using Kerberos with a Client Access Server Array or a Load-Balancing Solution.

1.2. Assign Service Principal Name to Service Account

Setspn for HTTP/it.corp.local
  1. Click the Command Prompt icon from the taskbar on the intranet VM.
  2. Enter the command setspn /s HTTP/it.corp.local CORP\iis_it and press Enter.
    Replace it.corp.local with your DNS name and CORP\iis_it with your IT service user.
  3. Confirm that the command was successful, noted by the Updated object output.

With this command, you are giving permission to the user, CORP\IIS_IT, to decrypt Kerberos tickets, when users access these addresses and authenticate sessions.

1.3. Assign Delegation Rights to the Service Account

Select IIS IT User

Return to the Active Directory Users and Computers management console.

  1. Click the Active Directory Users and Computers icon from the taskbar.
  2. Right-click your user, for example, IIS IT.
  3. Click Properties.

1.4. Update Delegation Settings

Set User account for Delegation
  1. Select the Delegation tab.
  2. Select Trust this user for delegation to specified services only.
  3. Select Use any authentication protocol.
  4. Click Add.

1.6. Search for the Intranet Object Name

Search Intranet computer
  1. Enter your machine name, for example, intranet.
  2. Click OK.

1.7. Select the HTTP Service

Select HTTP protocol
  1. Select http for INTRANET computer in the Available services list.
  2. Click OK.

1.8. Add HTTP Service for the Delegation

Add HTTP as Service
  1. Confirm that http for INTRANET computer was added to the list of services to which the IIS_IT account can present delegated credentials. The computer value refreshes the next time you select the Delegation tab; instead of INTRANET, you should see INTRANET.CORP.LOCAL.
  2. Click OK.

You have now authorized a specific user (IIS_IT) to delegate the user logged in credentials to any HTTP service on the INTRANET machine. This setting varies depending on the type of SPN you have registered and might fall under any one of the below categories.

2. Create a Keytab File

The keytab file is the token used to connect to Active Directory and request an authentication ticket without a login password. Keytab can only be generated through Windows Server OS.

Ensure you are logged in to your domain controller to generate the keytab file.

  1. Open Command Prompt.
  2. Enter the following command:
    ktpass /princ HTTP/it.corp.local@CORP.LOCAL /mapuser iis_IT@CORP.LOCAL /mapOp set /pass VMware1! /cypto all /ptype KRB5_NT_PRINCIPAL /out C:\it.keytab and press Enter.

Replace HTTP/it.corp.local@CORP.LOCAL with your service principal name.
Replace iis_IT@CORP.LOCAL with your service account user.
Replace VMware1! with your password.

This command creates a file named it.keytab in C:\ — This file will be used to configure identity bridging on Unified Access Gateway.

The following list describes the ktpass tool parameters.

  • /princ — Specifies the principal name in the form HTTP/it.corp.local@CORP.LOCAL that you created in Assign Service Principal Name to Service Account.
    Warning: This parameter is case sensitive and there is no validation to see if the parameter matches the exact case of the userPrincipalName attribute value when generating the keytab file.
  • /mapuser — Maps the name of the Kerberos principal, which is specified by the princ parameter, to the specified domain account.
  • /mapOp — Specifies how the mapping attribute is set, in this case, -Set sets the value for Data Encryption Standard (DES) - only encryption for the specified local user name.
  • /crypto — Specifies the keys that are generated in the keytab file.
  • /ptype — Specifies the principal type; KRB5_NT_PRINCIPAL is the general principal type (recommended).
  • /out — Specifies the name of the Kerberos version 5 keytab file to generate.

Configuring Kerberos Authentication on IIS Website

In this exercise, you connect to a machine in your intranet and configure Kerberos authentication on Internet Information Services (IIS). This example uses a VM called Intranet VM.

1. Log In to the Intranet VM

Enter your credentials on your intranet machine.

  1. Enter your password.
  2. Click the Login button, or press Enter.

2. Launch IIS

Click the IIS Manager icon from the toolbar.

3. Configure IIS Website

Configure Authentication Method
  1. Expand INTRANET.
  2. Expand Sites.
  3. Select IT Site.
  4. Double-click Authentication.

3.1. Enable Windows Authentication Method

  1. Select Windows Authentication.
  2. Click Enable.

Note: Make sure Anonymous Authentication, ASP.NET Impersonation, and Basic Authentication are Disabled. When you install IIS for the first time, Anonymous Authentication is always enabled by default.

3.2. Configure Authentication Providers

After you enable the Windows authentication method, you can set up the authentication providers.

Click Providers to open the list of providers available for Windows authentication.

3.3. Configure Providers

Configuring Providers

In this example, Negotiate and NTLM have already been configured as the two enabled providers available. In a new IIS installation, you must install the providers as part of the IIS installation, and add those here.  This procedure is outside the scope of this exercise.

Negotiate is a container that uses Kerberos as the first authentication method. If the authentication fails, NTLM is used, which means username and password will be used.

Important: It is mandatory that Negotiate comes first in the list of providers. Confirm that Negotiate is first and NTLM second.

Click X to close the dialog box.

3.4. Configure Kernel-Mode Authentication

Click Advanced Settings...

 

3.5. Enable Kernel-Mode Authentication

Enable Kernel Mode
  1. Select the Enable Kernel-mode authentication check box.
  2. Click OK.

Keep Extended Protection Off for this exercise. However, in a production environment you should configure this option, as it enhances the existing Windows Authentication functionality to mitigate authentication relay attacks. For more information about Extended Protection, see the Microsoft article Description of the update that implements Extended Protection for Authentication in Internet Information Services (IIS).

4. Configure IIS Application Pool

Confgure the Application Pool to launch from a specific account.

4.1. Configure Identity for an Application Pool

  1. Select Application Pools.
  2. Select IT in the Application Pools list.
  3. Click Advanced Settings.

4.2. Update the Application Pool Identity

Set new Identity

Click the dot icon for Identity under Process Model.

4.3. Select Custom Account

Set the account
  1. Select Custom account.
  2. Click Set...

4.4. Set Custom Account Credentials

Set Credentials

In this step, select an account to be used to launch the Pool. This example uses CORP\iis_it.

  1. Enter the User name, for example, corp\iis_it.
  2. Enter the Password, for example, VMware1!.
  3. Confirm the password.
  4. Click OK.

4.5. Confirm Custom Account for Application Pool Identity

Confirm Credentials

Click OK to confirm that corp\iis_it is the account to be used by this pool.

4.6. Confirm the Updated Application Pool Identity

Confirm
  1. Confirm that the correct account is listed for Identity.
  2. Click OK.

4.7. Configure Application Pool to use Identity Credentials

Access Configuration Editor
  1. Select the IT website.
  2. Double-click Configuration Editor.

4.8. Select Windows Authentication

Select Authentication Configuration
  1. Open the Section list.
  2. Navigate to system.webServer > security > authentication > windowsAuthentication.

4.9. Update Windows Authentication Configuration

  1. Click the dropdown arrow for useAppPoolCredentials.
  2. Select True for useAppPoolCredentials.
  3. Click Apply.

When you set useAppPoolCredentials to true you are telling IIS that it must use it's application pool identity (which you set for CORP\iis_it) to decrypt the Kerberos token/ticket which was obtained from AD and forwarded by the client to the server to authenticate the user.

4.10. Reset IIS

  1. Click the Command Prompt icon from the taskbar.
  2. Enter iisreset and press Enter.
  3. Confirm IIS successfully stops and then starts again.

Selecting Identity Bridging Option

Now that you have completed the initial configuration for identity bridging, select one of the following two options.