Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm so confused.

Consider the following:

  • Active Directory environment with a domain called DOM
  • An IIS 7 box with a NetBIOS name VS1
  • A DNS record providing an alias for VS1 as pineapple.london.uk.corp
  • An Application Pool running as DOM\PineappleService
  • Windows Authentication enabled.
  • Clients use HttpWebRequest to call the XML/JSON ASP.NET services on the box.

The service calls out to workstations on the network to gather information. This works in development where I use IIS Express which runs as me, since IISX is just an .exe

In production, services work fine, authentication works, but invoking functions that cause the service (running as PineappleService) to access stuff on the network, fails.

I suspect an SPN registration issue but I don't know what SPNs to setup.

Most recently, I've stumbled across this article which seems to say fly in the face of some other articles:


Note that it says

The SPN requirements remain the same as above. You don't have to add SPNs like http/ for the Domain1\Username1 unlike in IIS 6.0 (where we had to add an SPN of the form http/ for the Application Pool identity).

So I don't know what's right anymore. I don't know if I need to register HTTP SPNs or HOST SPNs or use the DNS alias or the NetBIOS name, and set them on the PineappleService account or on the VS1 computer account.

I can't tell if when I try things that there's a slow AD replication issue that means I must wait an hour between trial and error.

It's all so complicated now. I've worked as a sysop and dev for 15 years and I sense the end of domains and workstations and rights and policies. It's all gotten too much.

Thanks for your help.


share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

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.

Delegation Model

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.

Multiple Domains

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.

Elevated Privileges

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)
share|improve this answer
Hi Greg, thank you very much for sparing your time to write all this. I'm looking into what you've said with a server guy here. For now, I'd like to clarify that I'm not using impersonation. Server-side code just calls out to resources on the LAN under the Application Pool context (i.e. PineappleService). –  Luke Puplett Aug 17 '12 at 9:14
add comment

This is most likely not a SPN issue at all. More than likely the application pool running under your service account (PineappleService) does not have permission to access the resources on the network. You didn't really provide any error messages but it really does sound like a simple permissions issue.

You would need to make sure your service account has access to whatever (you should detail this more in your question) you are trying to get, be it files, information, etc.

For testing you could just make your service account an administrator in the domain, but you sure as hell should not leave it like that post-production deployment.

share|improve this answer
Hey Brent, If I simply use RunAs or NET USE from the server with the PineappleService account creds, I can access remote resources. This is why I suspect that there's a Kerberossy SPNy type issue going. Thanks for your answer. –  Luke Puplett Aug 16 '12 at 11:15
Unless you are impersonating and jumping through multiple resources theres not reason the application or clients would need to execute kerberos lookups by default, they should just use plain old negotiate/NTLM access. Your setup sounds pretty standard for ASP.NET and I've never run across a SPN issue before like this. –  Brent Pabst Aug 16 '12 at 12:35
Hi Brent, I gave you points as although I never got to the bottom of it, I think there was some very elaborate policy in place to prevent even admins from meddling with some services. I didn't include the error since it was one of those odd ones where MS has not made good choices. It would have confused people more. –  Luke Puplett Dec 10 '12 at 18:48
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.