Checking replication of raising the Domain Functional Level to Windows Server 2008 in a pragmatic and programmatic way

Reading Time: 2 minutes

ActiveDirectoryI’ve referred to the Windows Server 2003 Domain Functional Level (DFL) as the ‘golden’ functional level a couple of times. Dave has a blogpost where he concludes the same from an Exchange Server point of view.

However, from an Active Directory point of view, the Windows Server 2008 Domain Functional Level (DFL) gains much traction and is required when you want to deploy Windows Server 2016-based Domain Controllers.

The challenge at hand, is to how to pragmatically and, thus, programmatically check the replication of the Domain Functional Level (DFL) change for domains in a multi-domain environment. This makes the process repeatable and perhaps even outsourceable.

Let’s look at the two ways you could check.

 

Check proper replication of the level change

As a true Active Directory admin, however, we want to check for proper replication, before we continue making other changes in Active Directory that might depend on the Domain Functional Level (DFL). Especially in large environments with elaborate replication technologies, replication might take a while.

Luckily, we can check it pretty easily. Use the following one-liner (either in an elevated command prompt or elevated PowerShell window) to this purpose:

repadmin.exe /showattr *.sub.domain.tld "dc=sub,dc=domain,dc=tld" /atts:msDS-Behavior-Version

This will check the value for the msDS-Behavior-Version attribute on each of the Domain Controllers in the respective Active Directory domain and return the value.

Obviously, in this case, we’re looking for Domain Controllers that are replication a change from 2, to 3.

 

Check proper replication of the krbtgt password

One of the other ways to check a successful raise of the Domain Functional Level (DFL) for an Active Directory Domain is to check for the password reset on the built-in krbtgt account.

The password for this account is used to create a symmetric key that is used to encipher all the Ticket Granting Tickets (TGTs) in Kerberos, issued by Read/Write Domain Controllers.

Raising the Domain Functional Level (DFL) to Windows Server 2008 triggers a one-time reset of the password, and thus the symmetric key used.

Note:
The Kerberos Service is equipped with a fall-back mechanism so it can stull decipher the tickets enciphered with the old key, derived from the old password. With the default values, Kerberos clients may use these tickets for a period as long as 7 days.

Use the following one-liner (either in an elevated command prompt or elevated PowerShell window) to check when each of the Domain Controllers in the Active Directory domain have seen the password change:

repadmin.exe /showattr *.sub.domain.tld "cn=krbtgt,cn=users,dc=sub,dc=domain,dc=tld" /atts:pwdLastSet

This will check the value for the pwdLastSet attribute for the KRBTGT account on each of the Domain Controllers in the respective Active Directory domain and return the value.

 

Further reading

The KRBTGT Account – What is it ?
How to raise Active Directory domain and forest functional levels
Raise the Domain Functional Level
What is the Impact of Upgrading the Domain or Forest Functional Level?
Raise the Forest Functional Level

One Response to Checking replication of raising the Domain Functional Level to Windows Server 2008 in a pragmatic and programmatic way

  1.  

    Thanks Sander, this is literally the only article on the web that tells us what to check other than the label!

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.