As you might already know, “Service Principal Names” plays an important role in authentication process of Active Directory. If you haven’t watched my video on Kerberos, I suggest you have a look at that video because I explain Kerberos and use of SPNs in Active Directory. However, I will produce a separate video dedicated to SPN later on, so make sure to follow my YouTube channel for more videos. Anyways, in this article, I am going to briefly talk about one of the common problems of authentication and consequently “Secure Channel” which falls to the category of “Duplicated SPN”.
Recently, I was working on a funny and interesting subject of customizing icons of security principals within ADUC, but I came across another problem which led me to dig deeper the environment in order to find the root cause of the problem. During investigating different areas of Active Directory in my test environment, as a test, I wanted to join a PC to domain. The operating system of the PC was 2008 R2 and my AD test environment was 2012 R2. The PC could simply join to the domain with no issue, but right after I clicked ‘Ok’, it threw an error indicating: “While processing a change to the DNS hostname for an object, the Service Principal Name could not be kept in sync.”
The PC was however joined to the domain, but the error was a bit scary. Service Principal Name not kept in sync? This sounds like a bad issue! However in most articles, people were suggesting to ignore this problem, I was not quite comfortable with this manner. So I decide not to ignore the error and instead dig the problem.
So I tried to login to the system to see what is going on over there. Tried to login with appropriate username and password, but this time the error was a bit funny!
At first I thought it might be another typical problem of “Broken Secure Channel”, but the problem was, I had joined the PC to domain nearly 5 minutes ago, how that was possible for secure channel to break? I guessed this is something related to the first error indicating SPN not kept in sync. So the best thing in this case, was to check SPN attribute of the computer account and verify if they exist. After navigating through the attribute editor and find the serviceprincipalname attribute, I noticed the problem below:
Not a single SPN for this computer account? That is the problem indeed! When there is no SPN inside computer account, there would be no Kerberos process for the PC. How someone can login to a PC where there is no SPN written to serviceprincipalname attribute of that PC?
So I decided to manually write the default SPNs into the computer account. Having exported service principal names of a computer account, I tried to import the SPN for the corrupted computer account. These default SPNs were:
However, once I was importing the SPN, I noticed that one of the SPNs could not be written to attribute of the corrupted PC, throwing error related to duplicate SPN! I was wondering why duplicate? There is no computer within my forest with the same name. But I could not easily rely on my memory, so I searched the entire forest for similar name and amazingly I found out that there is a computer account with identical name of the computer account where I was troubleshooting. So basically everything became clear to me. “SPNs must be unique for the entire forest, if not, Kerberos cannot issue tickets for them”. Since it was clear then, I removed the old PC from remote domain and then rejoined the PC back to the domain. This time there was no error and of course serviceprincipalname attribute was populated.
Tip of the day: Computers are joined to domain in first step, once it is joined and computer account is created, SPNs will get written to that computer account. So when there is duplicate SPN within your forest, the SPN will not get written to PC because it is duplicate! The PC is joined to domain but with no SPN is written.
Update: A little right after that I found about the issue, Guillaume LUANAIS, pointed out the there are some more reasons for this error. Things like wrong SRV records and missing FSMO roles can be also the root causes of this problem. Also a full article of this issue can be found here: Duplicate SPN check on Windows Server 2012 R2-based domain controller causes restore, domain join and migration failures