Broken trust after configuring ADFS v2 and a single DC
This is not a critical issue by any means as I doubt this will occur in a real production environment; however I feel the need to alert everyone to a possible issue that will render their DC unusable. I’ve been playing around with ADFS v2 and SharePoint 2010 for a customer issue. Until recently I’ve always used the non-farm install of ADFS for my testing, but this time I was referencing a blog that I found specifically because it’s the User Profile portion of SharePoint that I’m interested in this time. The blog I was referencing appears complete:
Marc, does a good job of walking us through the configuration necessary for getting this setup, but he uses the farm setup of ADFS. For a test scenario I’m not sure it matters much, but one thing the farm setup does that I hadn’t considered before is that it creates an SPN (Server Principal Name) for ADFS service account in the form of host/<FQDN for adfs> .
After configuring ADFS, I had to manually configure the SPN for this account – this should have been my first clue that something was amiss. I still had some issues with the site I was attempting to access so as with any good trouble-shooting I rebooted the ADFS server for good measure. When it came back up and I tried to login I received the following error:
“The security database on the server does not have a computer account for this workstation trust relationship.”
Now… I haven’t been deeply involved in domain support for several years, but even I can realize that this is not a good sign. I performed a few cursory searches on Bing and found a few places that were mostly discussing the trust relationship between a workstation that had been joined to the domain. I then came across another blog that made a reference to a host SPN and the above error. (My apologies to the blog author as I don’t have that link handy and I cannot again locate it. 
)
So I started thinking that maybe I had inadvertently knee-capped my own DC. After a bit of distress and receiving responses to the tune of “you’re toast”, the resolution actually turned out to be relatively easy. I already had a Windows 7 client as a member of the domain. I logged into the Win7 client as the domain admin and installed the Windows Server 2003 Support Tools. I then used Setspn.exe to delete the SPN that I had manually added and now my DC was accessible again!
Why did I use the W2k3 Support Tools?
- It was the first thing I’d located when looking for setspn. I had tried to copy setspn directly from my Windows Server 2008 DC, but there may be some dependencies that did not allow it to work… I’m not sure.
What is the recommended method of using ADFS in this scenario?
- I’m not sure what the recommended method is, but from this point forward for my testing I’ll be using the non-farm configuration for ADFS.
Comments
- Anonymous
January 26, 2015
Brian,I know this blog is older but was your ADFS service name the same as the DC computer name? The one thing we don't recommend is that the ADFS service name ever match the actual computer its running on because it creates a duplicate SPN issue. Let me explain- the computer object (DC) in AD already has the host/server.domain.com SPN on it. When you performed this farm installation, you applied the host/server.domain.com SPN to a service account. Boom, duplicate SPN and the login issue you saw above. A quick fix for a test environment like this would be to change the SPN on the service account to http/server.domain.com. For a production environment, you'd obviously just ensure the ADFS service name differs from the actual computer account name. - Anonymous
January 26, 2015
Thanks for the explanation, DGreg, and yes this was quite a while ago and I have not experienced this issue since! :)