3.10.4 Protecting Kerberized Resources with Kerberos Constrained Delegation

Constrained Delegation and Protocol Transition are extensions of the Kerberos protocol (version 5). Protocol Transition allows a service to obtain a Kerberos service ticket to itself on behalf of the user without authenticating the user in Active Directory. Kerberos Constrained Delegation (KCD) allows a service to obtain the service tickets to a restricted list of services on behalf of the user.

For more information about the KCD technology, see Kerberos Protocol Transition and Constrained Delegation.

You can set up Access Gateway with KCD in Active Directory. After this configuration, any authenticated Active Directory user can access Kerberized web resources without logging in to the Active Directory domain.

This section discusses the following topics:

Architecture

The following diagram illustrates the architecture of the Access Manager Delegated Kerberos design:

Access Manager (Identity Server and Access Gateway) is deployed in front of the SharePoint server. Access Gateway intercepts all requests from the browser to the SharePoint server.
Access Gateway prompts the user for authentication at Identity Server.
Access Gateway requests KCD to generate a service ticket for the SharePoint server on behalf of the authenticated user through Constrained Delegation and Protocol Transition extensions.

Advantages

The following are the advantages of KCD implementation:

KCD is a more secure protocol. It delegates identities only to specified services.
KCD can transition non-Kerberos incoming authentication protocol to Kerberos so that the user can be granted or denied access to the kerberized services.

Limitations

The following are the limitations of KCD implementation:

It does not support the cross-domain transition.
It is supported only on Windows Access Gateway.
It requires additional setup configuration.

Prerequisites

Ensure that you meet the following requirements before implementing the KCD configuration:

Access Gateway is installed on Windows Server 2012 or 2016.
The domain controller in the internal network must be running Windows Server 2012 or 2016.
The LDAP user store must be part of the same Active Directory forest as of Access Gateways and Identity Servers.
In Access Gateway machine, allow the Kerberos port (88) from the Windows Firewall Outbound rules.

Setting Up Access Gateway with KCD

Setting up Access Gateway with KCD consists of the following actions:

Adding Access Gateway to the Active Directory Domain

Perform the following steps on the Access Gateway machine to add Access Gateway to domain on Windows Server:

Click Start > right-click Computer > click Manage.
Click Change System Properties in Server Manager.
Select the Computer Name tab and click Change.
In the Member Of section, select Domain, specify the name of the domain to join, and then click OK.
Click OK > Apply > Close.
Restart Access Gateway.
Proceed with Enabling KCD with Access Gateway.

Enabling KCD with Access Gateway

Delegation is not enabled by default for any user account. You need to enable it manually by adding services in Active Directory User or computer's properties.

Perform the following steps to enable KCD with Access Gateway:

Open the Active Directory Users and Computers folder in your Domain Controller.
Select Computers > Access Gateway computer.
Right-click and select Properties > Delegation.
Select Trust this user for delegation specified services only and Use any authentication protocol options.
Specify the services in Services to which this account can present delegated credentials.
Click Add.
Click Users or Computers to select the computer hosting these services.

NOTE:Constrained Delegation does not support services hosted in other domains even though there is a trust relationship to those domains.
Add services on the selected server.
Review and apply these settings in the Delegation tab.

Configuring Access Gateway for KCD

To protect your kerberized web resources with Access Gateway and enable single sign-on by using KCD, perform the following actions:

Create a reverse proxy service. SeeCreating a Reverse Proxy Service.
Configure an Identity Injection policy. See Configuring Identity Injection.

All instructions assume that you have implemented Kerberos in your environment, such as Active Directory domain with IIS servers configured for Integrated Windows authentication.

Creating a Reverse Proxy Service

Click Devices > Access Gateways > Edit > [Name of Reverse Proxy].
In the Proxy Service List section, click New.

Specify the following details:

Field	Description
Proxy Service Name	Specify a display name for the proxy service that Administration Console uses for its interfaces.
Multi-Homing Type	Select Domain-Based as the multi-homing method that Access Gateway must use to identify this proxy service.
Published DNS Name	Specify the DNS name you want the public to use to access the kerberized server. This DNS name must resolve to the IP address you set up as the listening address. If the DNS name of the reverse proxy is same as the DNS name of the kerberized server, no rewriting configuration is required. If they are different, there is a high probability that the application will respond incorrectly to user requests.
Web Server IP Address	Specify the IP address of the IIS web server.
Host Header	Select the Web Server Host Name option.
Web Server Host Name	Specify the DNS name of the kerberized server that Access Gateway must forward to the web server.

IMPORTANT:Web Server Host Name is a mandatory configuration because Delegated Kerberos in Access Gateway takes the service name from this field to request for a service ticket from the KCD server.

For more information about how to create a reverse proxy, see Section 3.8.3, Managing Reverse Proxies and Authentication.

Click OK.
Continue with Configuring Identity Injection.

Configuring Identity Injection

You must configure an Identity Injection policy to enable single sign-on with the kerberized Web Access server that has basic authentication configured. This Identity Injection policy must be configured to inject a Kerberos ticket. For information about creating this policy, see Section 8.4.2, Configuring an Identity Injection Policy.