This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(124.80000000000001, 27%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Hi.
Customer has an environment with an AD forest consisting of root and child domain, each has 2 DCs.
Both DCs in the child domain (but not those in the root) contain KDC errors claiming there's a duplicate SPN of cifs\dc1.<rootNS> for a domain controller in the root domain.
Exact error:
The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is cifs/dc1.<rootNS> (of type DS_SERVICE_PRINCIPAL_NAME). This may result in authentication failures or downgrades to NTLM. In order to prevent this from occurring remove the duplicate entries for cifs/dc1.<rootNS> in Active Directory.
However, I haven't been able to find any duplicates using:
As a note, none of the DCs actually have a cifs/ SPN registered, which makes it even more confusing.
Furthermore, as stated above, setspn -X doesn't show any duplicates in either domains, but a forest-wide search using setspn -X -F finds number of duplicate SPNs for the problematic DC (but only when running the search from the child domain), however none of them are cifs/.
Here's the list:
Operation will be performed forestwide, it might take a while.
Processing entry 0
HOST/dc1.<rootNS> is registered on these accounts:
CN=dc1\0ACNF:481721ed-bfa1-4146-a190-1a279501cab6,CN=Computers,dc=rootdomain,dc=local
CN=dc1,OU=Domain Controllers,dc=rootdomain,dc=localHOST/dc1 is registered on these accounts:
CN=dc1\0ACNF:481721ed-bfa1-4146-a190-1a279501cab6,CN=Computers,dc=rootdomain,dc=local
CN=dc1,OU=Domain Controllers,dc=rootdomain,dc=localRestrictedKrbHost/dc1 is registered on these accounts:
CN=dc1\0ACNF:481721ed-bfa1-4146-a190-1a279501cab6,CN=Computers,dc=rootdomain,dc=local
CN=dc1,OU=Domain Controllers,dc=rootdomain,dc=localTERMSRV/dc1 is registered on these accounts:
CN=dc1\0ACNF:481721ed-bfa1-4146-a190-1a279501cab6,CN=Computers,dc=rootdomain,dc=local
CN=dc1,OU=Domain Controllers,dc=rootdomain,dc=localRestrictedKrbHost/dc1.<rootNS> is registered on these accounts:
CN=dc1\0ACNF:481721ed-bfa1-4146-a190-1a279501cab6,CN=Computers,dc=rootdomain,dc=local
CN=dc1,OU=Domain Controllers,dc=rootdomain,dc=localTERMSRV/dc1.<rootNS> is registered on these accounts:
CN=dc1\0ACNF:481721ed-bfa1-4146-a190-1a279501cab6,CN=Computers,dc=rootdomain,dc=local
CN=dc1,OU=Domain Controllers,dc=rootdomain,dc=local
So, eventlog complains about non-existent SPN, domain-wide search finds no duplicates, forest-wide does, the object (account), which the duplicate references (the renamed CNF object), doesn't exist.
Any ideas?
One option may be to move roles off, demote, reboot, promo the problematic one again.
--please don't forget to upvote and Accept as answer if the reply is helpful--
Hi @MarkosP
The reason you are not seeing an CIFS SPN entry is because there are a number of common SPN services that are mapped back to the host SPN entry. The services that are mapped back to the host SPN is defined by the sPNMappings attribute of the CN=Directory Service,CN=Windows NT,CN=Services,DC=<domain> object.
This the default list of services that are defined in the sPMMappings attribute and are mapped back to host SPN: alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,time,wins,www,http,w3svc,iisadmin,msdtc
In your case, I would check if the HOST/dc1 SPN has been registered against multiple computer accounts using the GC with a search from the forest root down. NetTools does provide the SPN option to do this search and list which accounts the SPN has been assigned.
The other thing of note is that you have a Conflict object for dc01 in your root domain, these are caused when the same object is created at the same time on two different DCs and then causes a conflict object to be created when the DC replicate, as the DCs don't know which one is meant to be master, so it keeps a copy as a conflict object. I would look to clean up these objects as they may be causing your problem. If you can confirm that there has been no updates to this object since it was created, it would be safe to delete the object. If you are a little nervous about deleting it, I would suggest that you clear the serviceprincipalname attribute to see if it fixes your problem.
Gary.
GaryReynolds, thanks for the information regarding sPMMappings, I wasn't aware of those.
As for the conflicting object (CN=dc1\0ACNF:481721ed-bfa1-4146-a190-1a279501cab6,CN=Computers,dc=rootdomain,dc=local), as I've said above, it doesn't not exist, so setspn won't allow me to delete that SPN. It's also not in deleted objects, which makes sense, since it would have the 0DEL prefix then.
If you know of other methods how to delete the SPN of an non-existent object, then I'm all ears.
DSPatrick, I'm not too keen on removing the DC yet, because I'd like to resolve the issue without having to remove it plus it's confusing (at least to me), why this duplicate issue is only reported from the child domain (since otherwise synchronization, authentication etc. work fine).
Hi,
If you are getting the conflict objects displayed when you use the /F option on the child domains, it's likely that the GC partition on the child domain controller has the elusive object. I would browse to CN=Computers,dc=rootdomain,dc=local container using the GC on the child domain to see if you can find the object. I would also check if the object also exists in the LDAP\389 partition as well. You can do this with ADSIEdit or NetTools. If the object exists only in the GC and not the LDAP partition, understanding why GC replication is not working will be the next problem to solve, as you can't delete objects from the GC.
Gary.
The duplicate does not exist, I've tried searching using nettools, ldp, adsiedit (tried both ldap and gc) etc. from both domains and all domain controllers, none of them is showing this object.
NetTools SPN search doesn't not return the duplicates at all, I guess that search is similar to the setspn without the -F parameter.
Setspn -D won't let me delete it, since it's also claiming the account doesn't exist and -F option can't be combined with -D.
Interesting and annoying, I can't think why it's not visible, unless it's hidden in some way, maybe by permissions. I try and play with the /f option later to see if I can workout how it's doing the search.
Another option to try but not sure if this will work or not due to the potential length of the serviceprincipalname attribute, but should include enough text to include the server name at least once. You could try dumping the AD database and seeing if it's contains the addition object entry. Use this article to dump the database, just specify the serviceprincipalname as the only attribute to include, I would do it on both root and child domains. Then just search the dump files for dc1.
Gary
From the network traces for the -X -F options its a simple query against the GC at the root level down for (serviceprincipalname=*), there is no additional filters or controls used to find hidden items, one would assume that on the client side it's doing some sort of dictionary sort on all the returned SPNs to find any duplicates.
I would suggest doing a selective search against the root domain against LDAP to see if a search will find the object. Try a search using the following filter (serviceprincipalname=host/dc1*) and see what you get back from AD.
Gary.
Hi @MarkosP
If the issue is only occurring in the child domain and you have multiple DCs in the domain, you could remove the GC, wait 60 mins, and then reboot the DC, then re-enable the GC, repeat on each DC in turn, this will force the GC partition to be resynced from the root domain.
Gary.
Thanks, I'll try the idea with removing/adding GC.
I've tried dumping the database per the article and only put "serviceprincipalname" (without the quotes) in the attributes field, but it didn't work - I clicked the Go button, but it didn't generate any ntds.dmp in the NTDS folder (or elsewhere).
As for the selective search ... did you mean something like Get-ADObject -LDAPFilter "(serviceprincipalname=host/dc1*)" -SearchBase 'dc=rootdomain,dc=local' -SearchScope Subtree ? That still returns only the correct DC object.
The NetTools configuration should look like this to dump the database and include the serviceprincipalnames, if you are running on the DC you must use run as administrator to launch NetTools
Try the same Get-ADobject command against the GC, you will need to include the -server option, i.e. -server servername:3268
Gary.
Hi @MarkosP
Any update on this one?
I've tried the dump again and in the attributes field entered exactly per the screenshot, but that gives me an error: > dumpdatabase: Error: (0x10) Requested attribute does not exist, Server Error: 00000057: LdapErr: DSID-0C090FEC, comment: Error in attribute conversion operation, data 0, v4563, Ext Error: (87) The parameter is incorrect.
Then I've changed it to: dumpdatabase=servicePrincipalName, that gave me no errors, but also no ntds.dmp file:
DN> DC=rootdomain,DC=local
dumpdatabase: servicePrincipalName
1 records returned
Search Complete - 16ms
Shouldn't the search scope be subtree instead of the default Base?
I've also created a ticket with MS support, I'll update this thread with any relevant info.
Hi,
The error is occurring because you have the BaseDN field populated, it needs to be blank to write to the RootDSE, the search scope must be Base Level. The Attribute field should be dumpdatabase==serviceprincipalname or dumpdatabase=="serviceprincipalname".
The Enable Update must be selected and the Preview option unchecked, you should see a Go button change to red text. On my test environment it takes about 30 seconds to run the query and dump the database.
Gary.
I blame the guide, because the DN got populated per the instructions ("click on the populate button") :)
Anyway, finally got the dump created:
Hi Markos,
The favorite should have cleared the BaseDN, I've updated the post to include a check to clear the BaseDN.
Have a look at this post which will give you a bit more insight into the file format. As the record only exists on the child DC, I would trying running a semantic database analysis on the child DC to see if it finds anything, if you don't want to remove the GC.
Gary.