Single sign-on using KCD or RBCD — configuration

Single sign-on (SSO) is a critical component of a Pointsharp solution. One of the methods the Pointsharp system can provide SSO is by using Kerberos Constrained Delegation (KCD) and Microsoft’s extension for constrained delegation.

This guide will give an overview over the two methods of constrained delegation and provide configuration examples of each type of delegation.

SSO	Single sign-on
KCD	Kerberos Constrained Delegation
RBCD	Resource Based Constrained Delegation
SPN	Service Principal Name
IIS	Internet Information Services
RF	Resource Forest
AF	Account Forest
DC	Domain Controller

Delegation types

Microsoft provides two ways of doing constrained delegation. While the end result is the same, the configuration and requirements differ significantly between the two methods.

KCD: The original, KCD, was introduced in Windows Server 2003 and still is the most common method used for constrained delegation.
RBCD: In Windows server 2012, Microsoft extended its delegation functionality to include resource based constrained delegation (RBCD).

Choosing delegation type

KCD provides SSO just as well as the newer RBCD. The difference between the two types is not in the SSO functionality. The difference is in the limitations of the traditional KCD in certain environments.

Forests and domains

The traditional KCD is limited by domain and forest boundaries. RBCD does not suffer from these limitations.

This limitation is the main reason to deploy RBCD over KCD. Please consult the table below for a comparison between different environments and whether KCD or RBCD works. All trust relationships are assumed to be transitive forest trusts.

Account forest(s)/domain(s)	Resource forest(s)/domain(s)	Trust relationship	KCD	RBCD
Single	None	N/A	Yes	Yes
Single	Single	Forest Two-way	Yes	Yes
Multiple	Single	Forest Two-way	Yes	Yes
Multiple	Multiple	Forest Two-way	Yes	Yes
Single	Single	Forest One-way	No	Yes
Single	Multiple	Forest One-way	No	Yes
Multiple	Single	Forest One-way	No	Yes
Multiple	Multiple	Forest One-way	No	Yes

Account forest(s)/domain(s)

Resource forest(s)/domain(s)

Trust relationship

KCD

RBCD

Single

None

N/A

Yes

Single

Forest Two-way

Yes

Multiple

Single

Forest Two-way

Yes

Multiple

Forest Two-way

Yes

Single

Forest One-way

Yes

Single

Multiple

Forest One-way

Yes

Multiple

Single

Forest One-way

Yes

Multiple

Forest One-way

Yes

As the table clearly shows; traditional KCD cannot handle one-way trust scenarios.

While Kerberos Constrained Delegation will work in a two-way trust scenario, multiple RFs would require additional servers for each RF.

Resource Based Constrained Delegation requirements

Where traditional KCD does not have any requirements apart from the above mentioned trust relationships, RBCD has a number of requirements. All the requirements in the following table must be fulfilled.

Requirement	Note
At least one R/W DC running Windows Server 2012 or later in the domain where the Access Gateways that will provide SSO are joined.	2012 domain functional level is not required.
At least one R/W DC running Windows Server 2012 or later where the resource is joined.	2012 domain functional level is not required.
At least one R/W DC running Windows Server 2012 or later where any users that will use the system are located.	2012 domain functional level is not required.
All 2008/2008R2 DCs must apply KB2665790.	If the patch reports that it is “not applicable”, this requirement is fulfilled.
The Access Gateways that provides SSO must be running Windows Server 2012 or later.
The back-end resource must be running Windows Server 2008 R2 or later.

Requirement

Note

At least one R/W DC running Windows Server 2012 or later in the domain where the Access Gateways that will provide SSO are joined.

2012 domain functional level is not required.

At least one R/W DC running Windows Server 2012 or later where the resource is joined.

2012 domain functional level is not required.

At least one R/W DC running Windows Server 2012 or later where any users that will use the system are located.

2012 domain functional level is not required.

All 2008/2008R2 DCs must apply KB2665790.

If the patch reports that it is “not applicable”, this requirement is fulfilled.

The Access Gateways that provides SSO must be running Windows Server 2012 or later.

The back-end resource must be running Windows Server 2008 R2 or later.

Service Principal Names (SPNs)

Kerberos relies on SPNs to identify services when creating its tickets. Like its user counter-part (user principal name) a SPN must be unique in a domain.

When Pointsharp Access Gateway creates Kerberos tickets, regardless of delegation type used, it requests tickets for the SPN matching the “back-end server url”-setting on the rule. This means that an SPN matching the settings has to be registered to the back-end resource. The below commands are used to handle SPNs.

List registered SPNs

 setspn -L <computer account>

Example: List registered SPNs

setspn -L exchange01

Add an SPN

 setspn -S <service>/<principal name> <computer account>

Example: Add an SPN

 setspn -S http/mail.contoso.com exchange01

Remove an SPN

 setspn -D <service/<principal name> <computer account>

Example: Remove an SPN

setspn -D http/mail.contoso.com exchange01

Search for duplicate SPNs

 setspn -X

Deployment

The following section outlines the configuration steps of the two different delegation types. Only one of the two types should be deployed.

Note that both delegation types require that the correct SPNs has been configured.

Kerberos Constrained Delegation (KCD)

The configuration of the traditional KCD is done using the Active Directory Users and Computers tool. In the example below <MG> is the computer account of the Access Gateway that will perform KCD. Furthermore, <resource> is a single back end server, <SfBKerbAuth> is a Skype Kerberos account and <ASA> is an Exchange Alternate Service Account>.

Locate the <MG> computer account.
Right-click <MG> and select “properties”.
 Select the “delegation” tab.
 Select “trust this computer for delegation to specified services only”.
 Select “use any authentication protocol”.
Click the “add” button”.
  Click the “users or computers” button.
  Enter the name for <resource>/<SfBKerbAuth>/<ASA>.
  Click the “check names” button.
Click “OK”.
Select the SPN to allow delegation to (i.e. http/<FQDN>).
Click “OK”.
Click “Apply”.
Click “OK”.

Resource Based Constrained Delegation (RBCD)

The configuration of RBCD is done using the PowerShell cmdlets Get ADComputer and Set-ADComputer.

Single Access Gateway to a resource

The following example configures delegation permissions for a single PSMG to a resource where <PSMG> is the computer name of the PSMG that will provide SSO and <Resource> is the computer name of a single resource.

$MG = Get-ADComputer –Identity <PSMG> -server <DC in PSMG domain>
Set-ADComputer –identity <Resource> -PrincipalsAllowedToDelegateToAccount
$MG

Multiple Access Gateways to a resource

The following example configures delegation permissions for multiple PSMGs to a resource where <PSMGx> is the computer name of the PSMG that will provide SSO and <Resource> is the computer name of a single resource.

$MG1 = Get-ADComputer –Identity <PSMG1> -server <DC in PSMG1 domain>
$MG2 = Get-ADComputer –Identity <PSMG2> -server <DC in PSMG2 domain>
Set-ADComputer –identity <Resource> -PrincipalsAllowedToDelegateToAccount
$MG1,$MG2

Multiple Access Gateways to Skype Kerberos account

The following example shows how to configure delegation permissions for multiple Access Gateways to a Skype for Business Kerberos account. In the example <PSMGx> is the computer name of the Access Gateway that will provide SSO and <SfBKerbAuth> is the name of the Skype Kerberos account.

$MG1 = Get-ADComputer –Identity <PSMG1> -server <DC in PSMG1 domain>
$MG2 = Get-ADComputer –Identity <PSMG2> -server <DC in PSMG2 domain>
Set-ADComputer –identity <SfBKerbAuth> -
PrincipalsAllowedToDelegateToAccount $MG1,$MG2

Note that an SPN matching the configured SfB pool’s external webservices from the topology builder must be added to the <SfBKerbAuth> account (http/skypeweb01.contoso.com).

Furthermore, the Access Gateway “back-end URL”-setting on the /webticket/webticketservice.svc-rule must be set to match the hostname of the SfB pool’s external webservices (https://skypeweb01.contoso.com:4443/webticket/webticketservice.svc).

This means that the local host file must contain an entry pointing <skypeweb01.contoso.com> to the IP address of the SfB pool.

Multiple Access Gateways to Exchange ASA

The following example shows how to configure delegation permissions for multiple Access Gateways to an Exchange ASA. In the example <PSMGx> is the computer name of the Mobile Gateway that will provide SSO and <ASA> is the name of the Exchange Alternative Service Account.

$MG1 = Get-ADComputer –Identity <PSMG1> -server <DC in PSMG1 domain>
$MG2 = Get-ADComputer –Identity <PSMG2> -server <DC in PSMG2 domain>
Set-ADComputer –identity <ASA> -PrincipalsAllowedToDelegateToAccount
$MG1,$MG2

Note that an SPN matching the external DNS record must be added to the <ASA> account (http/mail.contoso.com and http/autodiscover.contoso.com).

Furthermore, the Access Gateway “back-end URL”-setting on each respective rule must be set to match the hostname of the external DNS record (https://mail.contoso.com/Microsoft-Server-ActiveSync).

This means that the local host file must contain an entry pointing <mail.contoso.com> to the IP address of the loadbalancer in front of the Exchange servers.