ServicePrincipleName setup for Web Service on IIS 7

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:

http://blogs.msdn.com/b/webtopics/archive/2009/01/19/service-principal-name-spn-checklist-for-kerberos-authentication-with-iis-7-0.aspx

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.

Luke

Solution 1:

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.

SPN

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
https://support.microsoft.com/kb/2717045

The target computer where the service will be located needs the SPN.

   HTTP/computername.company.com
   HTTP/computername

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
http://technet.microsoft.com/en-us/library/cc772815%28WS.10%29.aspx

• 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 [email protected] and access a share on that server:

// no password required with constrained delegation
using (WindowsIdentity id = new WindowsIdentity("[email protected]"))
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);

    Debug.WriteLine("Groups:");
    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)
    {
        Console.WriteLine(fileName);
    }
}

Solution 2:

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.