Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
|Maintenance: Administration tasks for the maintenance of Active Directory.|
There are multiple accounts with name <object name> of type <object type>.
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is the role of the KDC?
SETSPN -X (Windows 2008 / Windows 7) will return duplicate SPNs. From this, ADSIEDIT on the rogue entry to edit the servicePrincipalName attribute.
In my case, the error said: There are multiple accounts with name (domain) of type DS_USER_PRINCIPAL_NAME. We ran a script that propogated user accounts from an Excel file. Under the Account tab in the user account properties, the Top user logon name was blank. That was causing the error. The script created the user account in the pre-Windows2000 box, but left the one above it blank. I had to go through and copy the user account in the pre-Windows 2000 box into the blank box above it.
This happened to us when we replaced a server. During the replacement, the old server was renamed and physically removed, but was not removed from AD and DNS.
See ME911353 for a situation in which this event occurs.
In my case, there was a machine with SQL SERVER on it, with the MSSQLSERVER service running using the local machine account. In addition, there was also a user account running the same service with the same name. After I discovered which account was the offending one, I used ADSIEDIT to remove it.
We were getting this error from 3 machines, one SQL Server and two workstations.
1. In the case of the SQL Server, the SQL Administrator had all domain SQL Servers running their SQLSERVERAGENT and MSSQLSERVER services in a specific user context (e.g. "SQUIRREL") except for the offending machine. In the offending machine's case, the SQLSERVERAGENT and MSSQLSERVER services were running in the same user context as his SQL Administrator account (e.g. "SQUIRRELAdmin"). Changing the SQLSERVERAGENT and MSSQLSERVER service account contexts to the correct service account context (e.g. "SQUIRREL") helped but did not completely correct the problem. Use of ADSIEdit to remove the "servicePrincipalName:" entries from the "SQUIRRELADMIN" account (it was not used as a Service Account on any machine) completed the process of eliminating the event from this server. I used LDIFDE as described in MS Article ME321044 to ferret out the information needed. A chat with the SQL Admin confirmed the miss-applied service account context.
2. In the case of the two offending workstations, both machines had been replaced by new machines with names identical to those of the old machines. Prior to adding the replacement machines to the domain the old workstations had been "renamed" while still members of the domain. The replacement machines were then added to the domain. Simply renaming the old machines appears to have left some "servicePrincipalName" footprints in Active Directory that then conflicted with the similar information that was registered to the new machines. Deleting the replaced machine accounts ("OLD") from AD, after verifying that the old machines were indeed out of the picture, appears to have corrected the problem. My suggestion for our staff is to first REMOVE the machine being replaced from AD and then to add its replacement to AD, particularly if the replacement machine will have the same name as the old machine. Alternatively, delete the OLD machine as soon as possible following the installation of the replacement. Again, LDIFDE was used to identify the SPN duplicates and that was followed by a review of AD for the "OLD" computer accounts and a conversation with the techs responsible for installing the new machines. At this point, a good 24 hours later, I have no more instances of this event showing up on my DCs.
An even better ldifde command (then the one in Ionut Marin’s comment) for solving these errors, would look like this: ldifde -f GC.txt -t 3268 -d DC=xyz, DC=com -l serviceprincipalname –r (serviceprincipalname=*) -p subtree. Running this command on the root domain of the forest, finds conflict SPNs between child domains as well.
This error message came up after changing the login account for the SQL service from Administrator to another domain administrator (called Bob to save confusion) within Windows 2003. I changed the service login account back to administrator and restarted the service, then used the ADSI Edit tool to locate the Bob user, brought up the properties of this user, edited the ServicePrincipalName attribute and removed the SPN entries relating to the original message. This fixed the problem in my case.
My Log file was as follows: “There are multiple accounts with name MSSQLSvc/<MY DOMAIN>:1433 of type DS_SERVICE_PRINCIPAL_NAME”.
I previously had my SQL running with a user account then changed it to run with a system account. The error came up once every hour. I followed Ander Taylor's post and on a hunch, I checked the old service account and the current computer account. My results were as follows.
After running: “setspn -L <My Domain>\<The username I had been using for SQL>”, I received the following output:
”Registered ServicePrincipalNames for CN=<Old SQL username>, OU=Misc, DC=<My Domain>, DC=My Domain>: MSSQLSvc/<My Server.my domain:1433”.
After running: “setspn -L <My Domain>\<Computername>”, I received the following output:
”Registered ServicePrincipalNames for CN=<My Server>, CN=Computers, DC=<My Domain>DC=<My Domain>: MSSQLSvc/<my domain>.lan:1433”.
This seemed to indicate that both the System account and the user account were listed as SPNs for the same SQL server. I then deleted the old user accounts SPN my results were the following.
After running: “setspn -D MSSQLSvc/<My Domain\:1433 <The username I had been using for SQL>”, I received the following output:
Unregistering ServicePrincipalNames for CN=Username, OU=Misc, DC=<My Domain>, DC=<My Domain> MSSQLSvc/<My Domain>:1433
As per Microsoft: "Kerberos could not authenticate a principal name because the name was not configured correctly". See MSW2KDB for more details.
As per Microsoft: "There are two or more computer accounts that have the same service principal names (SPNs) registered".See ME321044 for more details.
From a newsgroup post: "It sounds like there is a service principal name in more than one place (on two different machine object's serviceprincipalname attributes) in your AD. The idea is to search for the duplicate and remove it.
I would suggest using LDIFDE to export the domain to text file and search for example: "Host/breflsdc.rita.ritaoh.net" (or whatever is reported in your event) in that file.
Syntax would be like: "LDIFDE -d DC=childdomain, DC=domain, DC=net -f c:\export.txt."
One of the entries will need to be removed. The trick can be determining which one. If that's an SPN for a service account for an application, it may require a service restart to see if the service reregisters that SPN after you delete it (whether you removed the correct or the incorrect one)".
From a nesgroup post: "Three general suggestions:
1. When replacing or removing machines, try to have them cleanly leave the domain. With the machine connected to the network, un-join the domain (e.g. change domain to WORKGROUP in UI). This will allow the machine to attempt to remove its DNS registration and computer object from Active Directory.
2. If you have a name collision (joining a new machine to the domain that has the same name of some now-missing machine), remember to both clean up the computer object and the stale DNS entries. Administrators often remember the machine object but forget the DNS entry.
3. If you turn on aging and scavenging of records in your DNS zone, you will automatically clean up old stale records. This will not solve the problem if you are rotating machines quickly, but will help mitigate the problem if you bring up a machine with the same name of another machine that has been missing for a long time. This is only available in Win2k and above".
From a newsgroup post: "We were receiving EventID 11 from source KDC because Microsoft Internet Information Services (IIS) was not enabled for both Kerberos and NTLM authentication. After we followed the instructions in ME215383, the problem disappeared".
I was seeing this error in my lab machines for multiple spns in the format cifs\<hostname>. However, I just could not find the object containing duplicate SPN. Then on searching for host\<hostname> using the methods given in other posts on this error, I saw duplicate entry of the <hostname> in the root domain where as the <hostname> belonged to the child domain.
So here is the explanation for my particular case causing these errors. In my lab machine, I first created the root domain and joined one host as a member server of the root domain. Then I promoted this host to create the child domain. DCpromo while creating the child domain disables the computer object of the child DC that was previously a domain member in the Root domain. It creates a new computer object of the DC in the “Domain Computers” OU of child domain. This causes the multiple SPN issue and KDC Event ID 11 error logs in event viewer.
The resolution to this issue is to find the multiple spns using LDP, LDIFDE or any other method and deleting it.
I had this problem occur after renaming a computer from <USERX> to <USERY> and then changing it back to <USERX>. Another computer got renamed to <USERY> a day later. I checked AD for the computer name and there was only one entry. Also checked the DNS forward lookup zone and found only one entry. However in the reverse lookup zone there were two entries with the same name. I deleted the incorrect entry and the problem has been solved.
1. Find and verify the multiple entries using LDP.exe. See Microsoft articles ME224543 and ME260745.
2. Base DN should be set to dc=domainname, dc=com or what ever your domain is.
3. Enter the string from the error message to the filter box, e.g. “servicePrincipalName=MSSQLSvc/SERVERNAME.domain.local:1433”.
4. Under Options, add "servicePrincipalName;" to the Attributes box.
You’ll get a search result with probably more than 1 entry. Which looks like this:
>> Dn: CN=Servername, OU=Domain Controllers, ...
>> Dn: CN=Administrator, OU=Users, ...
5. Verify which one of these entries is used to run the SQL Server. The other entries should be deleted.
6. Use ADSI Edit (adsiedit.msc) to connect to the Distinguished Names (enter the whole line from your search results, e.g. CN=Administrator, OU=Users, ...). Open the properties page of this DN and choose “serverPrincipalName” from the second listbox. Delete the unwanted entries.
Basically, if you have migrated computer accounts to a new domain using ADMT and there is still an account for that computer in the old domain, you will get this error message.
I had this issue when a SQL server instance was added twice. I used LDP instuctions as stated above to remove the duplicate. (Another Admin stated he added a SQL server to AD because since the button was available to do it, it must not have been added, he reasoned. Wrong, I always add SQL instances to AD upon initial config. Saw errors in DC log after he did this and immediately knew the cause.)
Problem developed because someone created an account in a sub-domain, and at a later date created the account in the root domain. Deleting account in sub-domain fixed the problem.
I was getting the following message: "There are multiple accounts with name MSSQLSvc/<domain name>:1433 of type 10". It turned out that the MSSQLSERVER & MSSQLSERVERAGENT services were using different user accounts and that both accounts had an identical SPN registered.
setspn –L OURSRVACCOUNT1
setspn –L OURSRVACCOUNT2 showed that both accounts had MSSQLSvc/OURSQLSERVER.OURDOMAIN.com.AU:1433 registered.
I changed the services to both use OURSRVACCOUNT1. Then using
setspn –D MSSQLSvc/<domain name>:1433 OURSRVACCOUNT2 removed the duplicate SPN from the second account. That has fixed the problem.
This type of errors have been reported after a disaster recovery.
If the accounts are known then use ADSI (Active Directory Serivces) edit and remove then SPN on the account that is no longer used to start the service on servername. An approach you can take would be to run LDP.exe (a utility available from the Windows 2000 resource kit). This utility is documented within the following articles. I am also posting possible steps you can take to resolve this using LDP. Use LDP.EXE to determine the location of the duplicate name:
1. Click Start & select Run.
2. Type LDP and click OK.
3. Click Connection and select Connect.
4. Leaving the Server field blank, click OK.
5. Click Connection and select Bind.
6. Leaving all fields blank, click OK.
7. Click View and select Tree.
8. Set the Base DN as DC=Home, DC=com
9. Click Browse and select Search.
10. Set the Base DN as DC=Home, DC=com.
11. Set the filter as the following: (serviceprincipalname=HOST/BOT-PC0295.home.com )
12. Set Scope to Subtree.
13. Click Run.
In either case, this indicates that you have a duplicate machine name registered within the Active Directory on your domain.
This error occurred on one of our DC's while updating info in Active Directory Users and Groups snap-in. Pop-up error said something like: Couldn't find Domain Controller, or couldn't apply change. After a quick reboot of the Domain Controller, I noticed under the System Properties -> Network ID tab, that the DNS name had changed to that of my workstation pc! (I thought you couldn't change a DC's name after installing AD!!!) So now it thought it was PC1 instead of SERVER1
I couldn't change the system's name from the System Properties -> Network ID tab, as it was a Domain Controller, so I attempted to change the entries in DNS, increment the version # and restart DNS Server. - IT DIDN'T WORK!
The entries kept being replaced, even after stopping DNS server on the affected server and manually forcing the entries in the AD-Enabled DNS.
FIX: (Well, it worked for me!)
The entries in DNS still showed incorrect hostname for Domain Controller, however the NetBIOS name was untouched.
After Several reboots of the affected DC, I resorted to changing every reference in the Registry to reflect the server's TRUE name. Globally replaced my pc's name with the original DC's name, and rebooted. BLAM! IT WORKED! SERVER1 was back to being SERVER1.domain.com in DNS... The name in the Network ID Tab was back to normal.
Still don't exactly know what caused it to it was another computer!
RELATED EVENT ID: (This also popped up during problem)
Event Type: Error
Event Source: DNS
EVENT ID: 6702
This can also occur when replacing an existing W2K DC using the same name. When the "old" server is demoted, it is moved to the Member Servers OU with its new name, this will need to be deleted. The "new" DC is then placed in the Domain Controllers OU. If you are going to bring the machine back in and you are adamant about using the same name, then you need to wait it out through several replication cycles. This is because you have to make sure that all of the Global Catalog servers have the information and the DNS servers as well as replication between sites. The replication between sites, by default, is 3 hours.You need to locate the duplicate object in Active Directory and delete it, as well as remove it from DNS. See ME305971.
|Private comment: Subscribers only. See example of private comment|
|Links: Setspn Overview|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated