This should not be attempted until it has been configured and tested in development exactly as it will be in production. Using Windows authentication and impersonation with IIS and custom applications can be very complex. Even if it were to magically work in production without having a development environment that accurately reflects production, you would be completely lost if you had to investigate an issue.
When an SPN is created, it is customary to create an SPN for both the fqdn and the short name. Example:
setspn.exe -A http/computer
setspn.exe -A http/computer.domain.com
It is advisable for these to match the pre-windows 2000 name (netbios name) and the dns name that will be used when connecting to the service. If neither of these are the name that will be used to connect to the service, there should be an SPN for that name as well.
Duplicate SPN's registered for the same service/name on different accounts/computers are a common cause for Kerberos delegation not working. Setspn will happily let you create duplicate SPN's. Microsoft has issued a hotfix that corrects this behavior:
A duplicate SPN is registered when you run the setspn command together with the -a switch in Windows 7 or in Windows Server 2008 R2
The target computer where the service will be located needs the SPN.
Trusted For Delegation
The computer or user account that will be performing the impersonation needs to be specified as Trusted For Delegation. If a user account is performing the impersonation, the computer account where the impersonation is performed must also be configured as Trusted for Delegation in the same way.
In Active Directory Users and Computers, click the Delegation tab on the computer or user account. (User accounts do not show the Delegation tab unless it has an SPN. It may be necessary to assign an SPN like RPC/username to the user account for the Delegation tab to appear).
On the delegation tab, select "Trust this user/computer for delegation to any service (Kerberos only)" for unconstrained delegation.
For Constrained delegation, select "Trust this user/computer for delegation to specified services only." Select "Use any authentication protocol." You can click Add and browse to the computer where the service SPN's are advertised, and add them. Note that these will not appear as SPN's when you run setspn.exe -L domain\useraccount.
You need to determine which delegation model to use. This decision may be compelled by security reasons.
Unconstrained allows a computer or service account to impersonate any user. This is extremely powerful, and was avoided by many organizations.
Constrained delegation limits the impersonation activity to specific target computers and services (HTTP, CIFS, ...) that a service account that is performing impersonation may connect to. It also has the added convenience that it enables impersonation of any account without having the account's credentials or a pre-existing Windows/Kerberos security token.
Constrained delegation does not work if the FE/BE servers are in different domains.
With Constrained delegation, the account/computer performing the impersonation must be in the same domain as the target resource/service. This domain is typically the "resource" domain. The accounts that are being impersonated may be in any trusted domain, including trusted domains in other forests.
The user account performing impersonation must hold the SetTCB privilege (Act as part of the operating system) on the computer where the code is running that will perform the impersonation. Note that on Windows Vista/7/2008 SetTCB privilege may only be held by processes with a High Integrity Level, so it may be necessary to add the account to the local Administrators group.
The Authorized Users identity must be a member of the local Users group on the computer where the impersonation will be performed.
Act as part of the operating system may be assigned using gpedit.msc or gpmc.msc. It is located under Computer > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
How the Kerberos Version 5 Authentication Protocol Works
- If the Use Kerberos Only option is selected, then the account is using constrained delegation without protocol transition.
- If the Use any authentication protocol option is selected, then the account is using constrained delegation with protocol transition.
Whew! After you have everything configured correctly, you can distill all of it to a simple test case that is easy to troubleshoot. Let's say you have created an SPN for CIFS\fileserver.company.com and want to impersonate anotherUser@trustedDomain.company.com and access a share on that server:
// no password required with constrained delegation
using (WindowsIdentity id = new WindowsIdentity("anotherUser@trustedDomain.company.com"))
using (WindowsImpersonationContext wic = id.Impersonate())
// ImpersonationLevel will be "Impersonation" when constrained delegation is setup correctly
// It will be "Identification" if the account performing impersonation does not have SetTCB privilege
Debug.WriteLine("ImpersonationLevel: " + id.ImpersonationLevel);
// Authentication type should be "Kerberos"
Debug.WriteLine("AuthenticationType: " + id.AuthenticationType);
Debug.WriteLine("Username: " + WindowsIdentity.GetCurrent().Name);
foreach (IdentityReference identity in id.Groups)
NTAccount ntaccount = identity.Translate(typeof (NTAccount)) as NTAccount;
Debug.WriteLine("Account: " + ntaccount.Value + " SID: " + identity.Value);
// This will fail with access denied if constrained delegation is not setup properly.
// On the target server/resource, if it fails it may show an attempt to logon using anonymous
string fileNames = Directory.GetFiles(@"\\fileserver.company.com\ShareName");
foreach (string fileName in fileNames)