So here I am again dealing with probably the number one support question on IIS, SPNs. I am not a novice when it comes to this, having lived the pains of getting SSRS front ends to delegate for SQL and SSAS back-ends in a number of different environments over the last few years.
But Microsoft has now upped the ante with a redesigned IIS7 interface and Windows 2008 with kernel mode, and I'm right back there pulling all-nighters and pounding my head on the desk.
In the past I have successfully used Brian Booth's DelegConfig tool to quickly get to the bottom of issues, but in my current case I'm getting results that I don't know that I trust and I'm questioning if the tool is accurately portraying issues, or just wasting my time with issues that don't exist.
So, maybe now its time to get a second (and third and fourth) opinion.
From a high-level I have a web server that is going to run applications that need to act as delegates for access to SQL and SSAS back-end instances. Sounds simple enough on the surface.
The good news is the back-end instances are already set up and working. Those are named instances, running on domain service accounts, with the appropriate SPNs already in place.
The front end server looks like this:
O/S: Windows Server 2008 R2 Enterprise IIS: 7.5.7600.16385
Machine account
- NetbiosName: COLOVWEB
- ServerFQDN: colovweb.co.local
Using host headers
- IISSiteName: CONET
- IISSiteNameFQDN: conet.co.local
Application pool
- PoolName: CONET
- Identity: NETWORK SERVICE
The web site [CONET] hosts ~50 'Applications' and ~20 'Virtual Directories'. There is one (1) application of interest for this exercise, lets call it 'MyApplication'. The DelegConfig application also lives in this web site for now.
At the top level [CONET] 'Anonymous Authentication' and 'Windows Authentication {kernelModeAuthentication = true}' are enabled.
At the MyApplication level 'Windows Authentication {kernelModeAuthentication = true}' is enabled. The same is true for DelegConfig.
Its my understanding that the servers domain computer account [CO\COLOVWEB$] needs the following:
ServicePrincipalName:
- HTTP/conet.co.local
- HTTP/conet
msDS-AllowedToDelegateTo:
- MSOLAPSvc.3/colosql3.co.local:MyInstance
- MSOLAPSvc.3/colosql3:MyInstance
- MSOLAPDisco.3/colosql3.co.local
- MSOLAPDisco.3/colosql3
- MSSQLSvc/colosql3.co.local
- MSSQLSvc/colosql3
- MSSQLSvc/colosql3.co.local:MyInstance
- MSSQLSvc/colosql3:MyInstance
My understanding is that, while not required in this case, the following is also appropriate:
ServicePrincipalName:
- HTTP/colovweb.co.local
- HTTP/colovweb
And everything should work, right?
Well, it doesn't. Depending on the exact syntax I use for the front end host name DelegConfig complains about:
The domain or workstation membership of NETWORK SERVICE (http://conet$) could not be determined.
OR
Service account NETWORK SERVICE (COLOVWEB$) is not a domain account.
I know I'm fighting a problem with Kerberos delegation but I'm not sure if DelegConfig is helping or hurting. Answers to either appreciated.
EDIT - 20130403
The application ConnectString has been verified and is shown below:
Data Source=colosql3\MyInstance;Catalog=OurCatalog;Integrated Security=SSPI;SSPI=negotiate;Impersonation Level=Delegate;SspropInitAppName=MyApplication
The login hitting the OLAP server is still CO\COLOVWEB$ and not the account of the user.
I run elmah on the server in the root web so I get a good capture of the users session:
AUTH_TYPE negotiate
AUTH_USER CO\user
HTTP_AUTHORIZATION Negotiate YIIKMwYGKwYBBQ....
So, the client browser is clearly submitting the appropriate request.
setspn -L CO\AccountThatRunsYourAppPool