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]
