Freigeben über

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

  • Artikel

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

  • Anonymous
    December 02, 2011
    Very Helpful. Thank You !!!!

  • Anonymous
    April 13, 2012
    just found the same issue with a customer.. great information, nice catch...

  • Anonymous
    March 31, 2013
    The comment has been removed