Configuring Kerberos Constrained Delegation (KCD)

Products

• ProxySG Software - SGOS

Issue/Introduction

You would like to allow the proxy to authenticate to an internal server on behalf of a client

You would like to configure the more secure method of kerberos delegation for credential forwarding

Resolution

 Configuring Kerberos Constrained Delegation

The setup should be logically similar to the following:

 

The desired result is that the client authenticates once with the proxySG, and when the client attempts to access the server, the proxy will authenticate to the server on behalf of the client. Please see Chapter 51 of the administrator guide for more details

On the proxy:

1.       Setup IWA realm as per normal procedures (refer to KB Set up IWA authentication using BCAAA for ProxySG)

2.       Enable the proxy to use SSL, ensure allow Kerberos credentials is enabled

3.       Import the domain CA and the proxy certificate into the proxy as per normal procedures

4.       Define a new ssl device profile and include the domain CA and proxy certificate

5.       Ensure the proxy is using a domain DNS server that can resolve the Origin Content Server (OCS) names. Note that kerberos delegation only works with FQDNs)

6.       Define a web authentication  layer that requires constrained kerberos delegation for the appropriate OCS. CPL code:

CPL example when SPN is a HOST (example: standalone web server):

<Proxy>

url.domain=http://aaaaa.example.com server.authenticate.constrained_delegation(origin, test_iwa) server.authenticate.constrained_delegation.spn(host/aaaaa.example.com)
 

 

CPL example when SPN is not a HOST (example: server farm) and HTTP service type is used instead:

<Proxy>

url.domain=http://aaaaa.example.com server.authenticate.constrained_delegation(origin, test_iwa) server.authenticate.constrained_delegation.spn(http/aaaaa.example.com)

Note: It is important that the service type is included as shown in the example "http/aaaaa.example.com". Without the service type (example: "http/"), KCD authentication will fail.

 

On the BCAAA server:

1.       Setup BCAAA as normal. During install ensure that you allow SSL connections. There is no need to require SSL connections unless desired

2.       Open the bcaaa.ini and ensure the following option is set correctly: VerifySG=1

3.       Change the BCAAA service to make sure it is running as a domain user (for example a  domain admin) using services.msc

4.       Open gpedit.msc and under security settings > local policies > user rights assignment, make sure the BCAAA user is allowed to run as part of operating system. Note, if the BCAAA agent is installed on the domain controller, modify the Default Domain Controller policy instead of the local policy.

At this point, test if normal IWA authentication works, by defining some policy which only allows authenticated IWA users out to the internet. It should allow only authenticated IWA users to access the internet.

On the active directory domain controller:

1.       Open Active Directory “Users and Computers”. Select the server where the BCAAA program is installed. Right click and click on the delegation tab.  The view will be similar to below:

Where “appserver.davidv.local” is the OCS you want the end user to authenticate to. In this case it’s an HTTP server. Note: You can use the HOST service type if the OCS is a standalone server or just use the HTTP service type when hosted by a server farm.

2.       Select the BCAAA user account and do the same as above for delegation

Note : If you do not see the correct service or computer in the above list, you will need to run the setspn command, eg: setspn –a http/appserver.davidv.local DAVIDV\administrator. DO NOT define the same service / spn twice or the KRB will break (setspn –l [user] is useful here…)

On the OCS (in this case “appserver.davidv.local”, a IIS webserver):

Ensure IWA authentication is enabled, and define the correct permissions on the files/folders that the webserver serves to users.