A pretty common issue out there in the real world is an error of something like
“There are multiple accounts with name XXX/YYYYYYYYYY of type DS_SERVICE_PRINCIPAL_NAME” or maybe that last bit is “of type 10”
floating about.
The general guidance is to find the objects with the same SPNs and clean all but one of them up. Some people get touchy about this because they think cleaning these dupes up will break kerberos… News flash if you are seeing these errors, Kerberos already is broken for those objects. Nuff said; clean them up.
Well then you get the folks who say “Well I searched like you told me to (or like KB321044 told me to) and I couldn’t find but the one object with that SPN set.”
The problem with this is that not all SPNs are explicitly registered in Active Directory. So the guidance from many people as well as from KB321044 is not altogether good enough. KB321044 hints to a solution for the problem but it is such an afterthought in the article most people blow right past it, specifically the line that says “Note If you do not receive the expected result, try searching for ” HOST/” as opposed to searching only for the exact SPN in the event ID.”
I think they should add a whole section to that KB concerning what I am about to write below, in fact, just append this blog article to any note or anything else you respond to when telling someone how to troubleshoot this. Think of this article as KB321044++…
So back to point… I said, and meant it when I said it, that not all SPN’s are explicitly registered in Active Directory. Microsoft did something that I personally think was very intelligent. They set up a bunch of SPN types that by default any HOST object can automatically be tied to even if they aren’t explicitly stated – i.e. these types will be mapped to HOST/whatever when they are encountered by AD. Currently in my Windows 2008 Test forest, that list of types that map to HOST is
- alerter
- appmgmt
- browser
- cifs
- cisvc
- clipsrv
- dcom
- dhcp
- dmserver
- dns
- dnscache
- eventlog
- eventsystem
- fax
- http
- ias
- iisadmin
- mcsvc
- messenger
- msdtc
- msiserver
- netdde
- netddedsm
- netlogon
- netman
- nmagent
- oakley
- plugplay
- policyagent
- protectedstorage
- rasman
- remoteaccess
- replicator
- rpc
- rpclocator
- rpcss
- rsvp
- samss
- scardsvr
- scesrv
- schedule
- scm
- seclogon
- snmp
- spooler
- tapisrv
- time
- trksvr
- trkwks
- ups
- w3svc
- wins
- www
That means if an application or machine asks for says CIFS/machinename or CIFS/machinename.domain.com Active Directory will look up that specified SPN but also HOST/machinename or HOST/machinename.domain.com. This is why Microsoft has that small note in the article… Because if the SPN has type of any of the above types, you very likely WON’T find the SPN by searching for the specific SPN specified in the event log entry.
You too can easily see which HOST mappings you have by running the following command with my very own AdFind command line tool
adfind -config -f spnmappings=* spnmappings
The output looks like this on my brand spanking new Windows Server 2008 Server…
C:\>adfind -config -f spnmappings=* spnmappings
AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007
Using server: TROUBLE-DC1.trouble.loc:389
Directory: Windows Longhorn
Base DN: CN=Configuration,DC=trouble,DC=locdn:CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=trouble,DC=loc
>sPNMappings: host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,ne
tman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trk
svr,trkwks,ups,time,wins,www,http,w3svc,iisadmin,msdtc1 Objects returned
Quick Note: To my friends at MSFT who I know for sure read the blog… Eric, Brett, Moon, Nathan, and others…. The name of the domain is indeed “Trouble”, this is not in any way shape or form a reference to Microsoft nor Windows Server 2008. Seriously. This is a reference to my black cat who was walking across my keyboard whapping me in the face with her tail as I made that domain and was thinking, what should this domain be named? <WHAP>
<…and we’re back>
So when you are looking for these duplicated, just expand the query to look for the specific SPN you want as well as the SPN with the type replaced with HOST. Actually Microsoft’s QuerySPN.VBS script should do exactly that but it doesn’t.
I say, don’t even bother with that script, don’t bother with LDIFDE (can ya say yuck?), and don’t even bother with LDP (even though it rocks in general); just use AdFind to go looking for these objects. Do something like
adfind -sc c:computername
Why will just looking for the computer name work? Because almost certainly (like 99.999% chance) the computer name is duplicated in your forest and even though you may not be using WINS (hahahahaha sure…), you still can’t duplicate machine names in a forest. They have to be unique so you can have unique SPNs for the short host name versions. For example, one of my Windows Server 2008 machines has the following SPNs
dn:CN=TROUBLE-DC1,OU=Domain Controllers,DC=trouble,DC=loc
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/TROUBLE-DC1.trouble.loc:50000
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2-ADAM/TROUBLE-DC1:50000
>servicePrincipalName: TERMSRV/TROUBLE-DC1
>servicePrincipalName: TERMSRV/TROUBLE-DC1.trouble.loc
>servicePrincipalName: NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/TROUBLE-DC1.trouble.loc
>servicePrincipalName: Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/TROUBLE-DC1.trouble.loc
>servicePrincipalName: GC/TROUBLE-DC1.trouble.loc/trouble.loc
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc/TROUBLE
>servicePrincipalName: HOST/TROUBLE-DC1
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc
>servicePrincipalName: HOST/TROUBLE-DC1.trouble.loc/trouble.loc
>servicePrincipalName: E3514235-4B06-11D1-AB04-00C04FC2DCD2/02cd7861-be73-4ef5-9892-fcd35231ac27/trouble.loc
>servicePrincipalName: ldap/02cd7861-be73-4ef5-9892-fcd35231ac27._msdcs.trouble.loc
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc/TROUBLE
>servicePrincipalName: ldap/TROUBLE-DC1
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc
>servicePrincipalName: ldap/TROUBLE-DC1.trouble.loc/trouble.loc
Notice that some of those SPNs do not have a FQDN in them… Specifically
>servicePrincipalName: TERMSRV/TROUBLE-DC1
>servicePrincipalName: HOST/TROUBLE-DC1
>servicePrincipalName: ldap/TROUBLE-DC1
These all would have collisions if you had the same machine name in two domains in the same forest. Hence any app that used them would fail to use kerberos for the authentication because AD cannot map the name to a unique object.
So anything else? I think not, this is good… What did we learn?
- Don’t duplicate machine names in a forest, period.
- If you have duplicate SPN issues, use AdFind to find all computers with the name in the SPN.
- Duplicate SPNs means kerberos is already not working right for those machines so cleaning it up isn’t going to break anything worse.
joe
Little confused here Joe. I have 1 forest with 2 child domains, domain 1 is prod and domain 2 is QA. Automated installs only work in domain 1 so we move the servers over to domain 2, but the machine accounts in domain 1 dont get deleted. In both domains we have constrained delegation for our iis apps setup. These apps traverse up to 6 different services using kerberos, btw ntlm can only do 2. I am having no kerberos issues with this setup but I am getting the dup warnings in the event logs… All of my network traces are clean of kerberos related errors.. so you can you see my delima.. clean these servers right away or wait for them to age as I do now and auot clean them up after 3 months with a script
I may be getting around the issue by using fqdn in all the apps.. what do you think?
I have a problem that is not referrenced anywhere on google or plausably on the web. You seem to know a ton about SPNs so I am hoping for some help, if possible.
I have a 2003 standard webserver, fully patched todate.
It runs several websites that require integrated windows authentication (internal only) including sharepoint. So the machine has http/machine.domain.com registered in AD.
Well I installed Office Communication Server 2007 and communicator web access, in doing so, OCS2007 created a service account called cwaservice and gave it the same SPN http/machine.domain.com. If I change or remove either, something breaks. Either communicator stops being able to sync the Exchange address book or the websites stop using integrated authentication.
Not sure what to do or how to get around this. I am getting the KDC error on DCs for duplicate SPNs.
I always hated using thos other tools to find errors like this, this is a fantastic tool, keep up the good work.