AD Troubleshooting

AD and Domain-related issues and troubleshooting methods for Active Directory.

Problems with introducing a new Windows Server 2008 DC into a Windows 2003 forest

Problems with introducing a new Windows Server 2008 DC into a Windows 2003 forest

  • Comments 3
  • Likes

Windows Server 2008

The following case came in recently:

I’ve added a new W2k8 DC to our domain, it seemed to replicate fine and DCPROMO didn’t report any errors.  However, I seem to be getting authentication errors when trying to connect via RDP from the new W2k8 DC to other DC’s in the forest.

 I’m only seeing this when Vista and/or W2k8 are involved on both ends, I’m concerned that we may have an error in our AD after the W2k8 upgrade.

Here’s what turned out to be causing the issue:

-          With Windows 2008, the concept of RODC’s is introduced.  Each RODC has its own Kerberos Ticket Granting Ticket (krbtgt) account that it uses to issue Kerberos tickets (compared to RWDC’s which all share the same krbtgt account within the domain).  This is to make sure a compromise of an RODC doesn’t compromise the security of the krbtgt account on all DC’s.

-          The format of the RODC-specific KRBTGT principal is krbtgt_<RODC name> and this is what is used for registering the SPN’s for it as well.

-          To distinguish between Kerberos tickets issued by RODC’s vs. Kerberos tickets issued by full RWDC’s, the low 16 bits of the Property Version Number (PVN) of the 32-bit unicodePWD attribute of the relevant krbtgt account as the traditional Key Version Number (KVNO) and the high 16 bits as a branch ID.

-          When an object is authoritatively restored (in this case the KRBTGT account in the Users container) the PVN of all attributes on it are by default incremented by 100000.

 

-          The KVNO provided for the Kerberos TGT ticket a DC issues is calculated from the PVN of the unicodePWD attribute of the KRBTGT account it uses (this will be either the per-domain KRBTGT account for a RWDC or the per-machine krbtgt_$<RODC> accounts).

 

-          If the PVN of the unicodePWD attribute is greater than 0xffff (64k), Vista and W2k8 clients will consider a ticket issued from a W2k3 DC that uses it to be issued by an RODC and will attempt to request a Kerberos ticket for the RODC based on the high 16 bits in the KVNO of the Kerberos TGT that they have.

 

-          As no such RODC exists this will fail with a KDC_ERR_S_PRINCIPAL_UNKNOWN error being returned from the LDAP server and authentication fails.

 

-          Prior to the hotfix in KB 939820 - W2k3 DC’s don’t mask out the high-order 16 bits in any Kerberos tickets it issues to clients.
After the hotfix - all W2k3 DC’s will zero out the high-order 16-bits in issued Kerberos TGT’s. 

 

In short; a previous authoritative restore of a DC 5 years ago had increased the Property Version Number of the unicodePWD attribute for the domain-wide krbtgt account.  This in turn led all Vista and W2k8 clients to assume it was issued by an RODC which in turn led them to request Kerberos tickets based on a non-existent SPN.  Installing KB 939820 on all W2k3 DC’s resolved the issue.

 

Note that this will also happen in a Windows 2008 R2 implementation that still has W2k3 DC’s in it or even a W2k3 implementation without any W2k8 DC’s in it (the catalyst is a non-patched W2k3 server issuing the Kerberos TGT).

 

To spot whether the krbtgt account in your domain has been restored at some point, you can run the following:

repadmin /showmeta <DN of krbtgt account in the domain>

Sample output:
repadmin /showmeta
------------------

Loc.USN  Originating DC   Org.USN         Org.Time/Date             Ver   Attribute
=======  =============== =========    =============             ===   =========
11950     CONTOSO\DC1    10540508        2008-11-24 20:46:51  100002  description
11950     CONTOSO\DC1    10540508        2008-11-24 20:46:51  100002  name
11950     CONTOSO\DC1    10540508        2008-11-24 20:46:51  100002  unicodePwd
11950     CONTOSO\DC1    10540508        2008-11-24 20:46:51  100002  ntPwdHistory

 

In this case, the unicodePwd attribute PVN is 100002 which is usually caused by an authoritative restore of the object...which triggers the issue if the object turns out to be the krbtgt account.

 

Further details:

RODC Features
http://technet.microsoft.com/en-us/library/cc753223(WS.10).aspx

Events 1925, 1006, 1645, 1055, 40961 on a Windows Server 2008-based domain controller or error message: "No authority could be contacted for authentication" when you use Remote Desktop Connection
http://support.microsoft.com/?id=939820

Comments
  • Very Helpful. Thank You !!!!

  • just found the same issue with a customer.. great information, nice catch...

  • Just had the same issue that nagged us for 4 months before getting it resolved.  But in our case it affected our mixed Exchange 2007/2010 and just about caused everyone to have a meltdown with various components of Exchange breaking every week.  Applying the patch fixed it.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment