Kerberos Constrained Delegation with Protocol Transition and Claims to Windows Token Service

Configuring Kerberos Constrained Delegation with Protocol Transition and the Claims to Windows Token Service

Image for post
Image for post
C2WTS Sharepoint Protocol Transition

In order to configure identity delegation for a Web Application in Claims mode within Web application like SharePoint we must configure Kerberos Constrained Delegation with Protocol Transition. Because in Claims mode there is no identity with which to perform either impersonation, basic delegation or true Constrained Delegation using Kerberos.

Using Windows Identity Framework component, Claims to Windows Token Service (C2WTS) to mock real delegation using a Windows Logon Token. C2WTS itself makes use of Service For User (S4U). S4U does NOT perform real delegation, it cannot because there are no user credentials to delegate. It instead grabs a bunch of SIDs for the user (in this case a service identity). What all this means is that there is a hard requirement to use Protocol Transition. Protocol Transition is named in the UI of ADUC as “Use any authentication protocol”.

In order to set things up, settings in Active Directory for the C2WTS service identity and the application pool identity of the service application endpoint must be configured to perform Kerberos Constrained Delegation using Protocol Transition to the back end services.

For example allowing the C2WTS account to delegate to SQL Server Database Services and SQL Server Analysis Services using the SPNs which already exist on their service accounts. Repeat same configuration on the application pool identity of the service application endpoint.

In order to see delegation tab in ADUC we must create a Service Principal Name (SPN) on the accounts first. Otherwise the Delegation tab in the account properties does not show up.

Also to configure the attributes using ADUC in Advanced Features mode, or ADSIEdit there must be an SPN for the delegation to succeed.

The services to delegate to are exposed by the AD schema extended attribute msDS-AllowedToDelegateTo. This can be manipulated using the standard Set-ADUser -Add pattern. As can the SPN itself.

The setting for Protocol Transition is actually a UserAccountControl attribute. It’s enumeration is ADS_UF_TRUSTED_FOR_DELEGATION or 524288.

It can be configured with the Set-ADAccountControl cmdlet with the -TrustedToAuthForDelegation parameter.

Note TrustedToAuthForDelegation == Protocol Transition, -TrustedForDelegation == Kerberos Only

And that’s it. Two cmdlets basically.

OK, so that’s the AD account configuration.

By default C2WTS as it’s default identity, LocalSystem, we don’t need to do anything. In a real farm you have more than one machine running C2WTS. That means multiple points of configuration (on each computer object in AD).

We need to run the identity to a named service account. Also have to grant additional User Rights Assignments to the account in order for it to be able to call S4U. These are Act as part of the Operating System and Impersonate a Client after Authentication. The account must also be a member of the Local Administrators group on each server it runs. All of this can be done via Computer Management and Local Security Policy, or properly via Group Policy.

Published By Eray ALTILI

Originally published at

Written by

I am passionate about Technology, Cloud Computing, Machine Learning and Blockchain

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store