Event ID 11 - Service Principal Name Configuration

Event ID 11 – Service Principal Name Configuration

In the wee hours of the morning, a colleague and I set to changing out administrative passwords and migrating some admin accounts to service accounts to better reduce our security risk footprint. We completed the task and began double checking services and applications. It quickly became clear that we were no longer able to log into one of our domain controllers, a Windows Server 2008 R2 machine. Red Alert! We began receiving the following message when attempting to log into the DC.

The security database on the server does not have a computer account for this workstation trust relationship.

After a lot of odd looks and log reviews, we decided to restart the DC into safe mode WITHOUT networking. Doing so allowed us to log into the DC with the previous administrator password. (Remember we had just changed the master admin password from one of the other DC’s). Now that we were in the problem DC, we could see the event logs. Two sets or errors peaked our interest.

Provider: Microsoft-Windows-Security-Kerberos
Event ID: 3
Error Message: KDC_ERR_S_PRINCIPAL_UNKNOWN

Provider: Microsoft-Windows-Kerberos-Key-Distribution-Center
Event ID: 11
Error Message: The KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is ProtectedStorage/servername.example.com (of type DS_SERVICE_PRINCIPAL_NAME). This may result in authentication failures or downgrades to NTLM. In order to prevent this from occuring remove the duplicate entries for ProtectedStorage/servername.example.com in Active Directory.

A bit of Googling found us narrowing things down to what seemed to be a problem with an SPN (Service Principal Name) entry somewhere.

http://technet.microsoft.com/en-us/library/cc733945(v=ws.10).aspx

http://support.microsoft.com/kb/321044

All of the recommended means of finding the missing or duplicate SPN were failing to show us exactly where to resolve the issue. Finally, a simple ping from the MacBook Pro terminal window gave the answer. Pinging the IP address of the problem DC showed a round robin effect with each ping response resolving to two DNS host names.

The Solution in a CNAME

Recently we had created a CNAME entry that pointed to a specific DC for use by all of our applications need Active Directory integration of LDAP authentication. Our thought was that doing so would mean no application configuration changes when we rebuilt/renamed our DC’s over the next month. Doh! Since we created a CNAME in the Active Directory DNS zone, it actually registered the SPN entries resolving both to this particular DC. This was the cause of the problem

Removing the CNAME record and replacing with an A host record solved the problem.

Thanks be to God for that solution without ill effect. Event ID 11   Service Principal Name Configuration