Now that Windows Server 2003 end of life (July 14th, 2015) is on the horizon, many customers are updating their Active Directory (AD) Domain Controllers (DC) from 2003. The first item to consider is which Windows Server Operating System (OS) you will be moving to for your DC’s. There are several options to consider today: 2008, 2008R2, 2012, or 2012R2 operating systems. However, no matter which newer OS you move your DC’s to, coming from 2003, the krbtgt account will reset its’ password when you update the Domain Functional Level (DFL), which is the concern that could break Exchange.
Note: If your DFL is already set to 2008 or higher, then you do not need to worry about this article.
It is a good idea to know that during the process of raising the Domain Functional Level (DFL) of your Active Directory structure from 2003, the krbtgt account password gets changed. This password replication is a separate change within AD and occurs after the DFL has been raised. This change should have no impact on any applications that depend on Active Directory, but sometimes it does cause applications to stop authenticating, one of them being Exchange.
Since raising functional levels is an irreversible operation (in many situations, but not always anymore), it should be planned with care and only after having verified that it will not impact any applications that rely heavily on Directory Services. Mostly any in-house written and/or third party products are the main concern. A lab environment for testing the applications would be the best option, which is why we recommend a lab for Exchange.
After you’ve made the DFL change from 2003, then you’ll want to watch for any Event ID 14 or Event ID 10 errors in the System Event Viewer on the DC’s.
If you do see these events appear after the DFL has been raised, then there are a couple of options available to resolve the authentication error.
Option 1: Restart the Kerberos Key Distribution Center service on all DC’s (short impact, service restart)
- Command line option steps:
- SC \\ComputerName Stop kdc
- SC \\ComputerName Start kdc
- Active Directory PowerShell module steps:
- $DC=Get-ADDomainController
- Get-Service KDC –ComputerName $DC | Restart-Service
- GUI steps:
- Open the Services mmc (services.msc) on the DC’s
- Select the Kerberos Key Distribution Center service and click the restart button
Option 2: Restart all DC’s in the Forest (greatest impact, restarting of servers could take time)
- Manually log into each DC and restart them all, OR
- Within the Active Directory PowerShell module:
- $DC=Get-ADDomainController
- Restart-Computer $DC
Why is this important?
While there should be zero impact to applications, the fact that the krbtgt account password does get reset and it could impact the speed in which Exchange (or other applications) waits for that accounts’ password to be updated via the normal AD replication process. We are recommending that you know how to perform the given resolution steps and that you do this change during a change notification process.
Why does this happen only during the 2003 DFL change?
The underlying issue is due to the addition of the AES hashes (128 and 256) introduced. The changes only add the AES hashes during the one DFL change from 2003 to any higher level (’08, ‘08R2, ’12, ‘12R2) domain functional level. The potential to implement other newer/updated encryption types in future OS versions does exist and we once again could run into this issue.
Knowing is half the battle. It is very unlikely that you’ll run into this issue, but now that you know how to solve it and be prepared IF you run into it, you now have easy and quick solutions at the ready. Plan your change, move up to the newer version OS/AD functional levels, enjoy the new features that are available today, and don’t let this change break Exchange.