The below problem (different service accounts) goes away with Windows Server 2008 / IIS7, provided it's a standalone box (not load balanced). You need to register the SPNs under the computer account (and use kernel mode Kerberos). I have a blog post on that :)
Otherwise, if you are using an older Windows Server (e.g. 2003), or you are not using kernel mode authN, then you'll need to use the same service account. Use of http/server:5555 requires the browser to support this - I forgot what version of IE introduces support for HTTP SPNs on non-standard ports (i.e. not 80 and not 443) Delegation is not required to be configured unless you are actually delegating credentials (a multi-hop scenario), where one service is passing the end-user's credentials to another. So, if you are using SharePoint 2010 to pass the users credentials back to SSRS, then you might need this. If they are just two stand-alone services, which the user authenticates to both directly, then delegation is not configured. If you can explain what "does not work" means in more detail, that might help :) Cheers Ken From: [email protected] [mailto:[email protected]] On Behalf Of Chris Walsh Sent: Wednesday, 23 November 2011 5:03 AM To: ozDotNet Subject: RE: Kerberos Pt 2 Richard, Typically, if you are running SSRS and SP2010 on the same boxes, they need to run the same service accounts for that very issue where two accounts can't use the same SPN's. Also, SharePoint creates sites on port 80, the 5555 site you might have configured could be the Administration port. Have you enabled delegation on these service accounts in Active Directory? You also need an FQDN SPN entry for each URL too. And yes, you can't use a CNAME DNS entry for Kerberos, it must be an A record. From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Richard Carde Sent: Wednesday, 23 November 2011 7:47 AM To: ozdotnet Subject: Kerberos Pt 2 Simon's recent issue with Kerberos reminded me of an issue I faced recently where Kerberos was failing. This is possibly a question to Ken, but anyone else might want to chip in. I do often refer people to Ken's multi-part blog on Kerberos. It must have been written when Ken had some spare time, before he started sparring with Silky. I digress. Imagine we have DEVSERVER with SSRS 2008 R2 and SharePoint 2010 installed. I believe: * SSRS was installed and configured to use service account domain\svcSSRS and listen on port 80, and * SP2010 was installed and configured to use service account domain\svcSP2010 and listen on port 5555. Initially, the domain controllers were complaining about a duplicate SPN because "HTTP/devserver" was registered against both of the above service accounts. This may have been because the guys were mucking around with SPNs trying to "make things work". So, to fix that I removed the SPN "HTTP/devserver" from domain\svcSP2010 and added the SPN as "HTTP/devserver:5555". No more complaints about duplicate SPNs. Still didn't work though. Introduce another server. Lets call it PITA - she, sadly, runs BizTalk 2010. I NetMon'd with WireShark which showed that any process running on PITA still requested Kerberos tickets for HTTP/devserver no matter whether the ultimate request was for http://devserver:80 or http://devserver:5555. In fact, I found that most (all?) requests do not add the port number. SPNs support port numbers, clients don't request tickets with a port number? My suggestion was to create DNS A records for the two servers and add the respective SPN to each service account (I already knew one cannot use a CNAME as the underlying hostname will be used anyway). Have I not read something in the docs or is this a general gotcha that one should be aware of? -- Richard Carde E: [email protected]<mailto:[email protected]>
