Forum Discussion
Any potential problems with mixed OS versions for Active Directory PDC?
Hi All, Just wanted to get people's opinions on the following: I have a customer with multiple sites, and 3 domain controllers. They also have a Microsoft volume license account so licensing...
I'm late for the party here but want to clear an important topic up for other’s awareness.
A few of the uninformed responses here will result in full blown incident response if it happens in an enterprise environment. I’ve witnessed it firsthand and have helped major corporations investigate, perform RCAs, and resolve partial, yet very large scale outages due to the encouraged actions stated within this discussion.
What some of the people have said here is completely wrong.
Yes, you can have DCs on the same domain with (reasonably) different OS versions. However, only if your DC OS versions are in Mainstream Support.
If the DC OS versions stay aligned with Mainstream Support, they’ll typically be reasonably close in OS version either way.
The concerning part, however, is the responses to whether DCs can or cannot be on different update/patch (CU) levels.
In summary, unless you want to get deep into the trenches with what configurations change, and what varying problems to expect on DCs (and therefore AD itself), consider this response to the question a big no. Strive to keep them all on the same CU at all times, regardless of OS versions.
Will they still work as expected? Maybe. Will there be issues if the CU versions are vastly different between DCs? Absolutely. Contrary to assumption here, Microsoft has been progressively "hardening" auth and security related requirements, such as requiring Kerberos PAC, Kerberos PAC Signatures, RPC sealing, NTLM, and other areas as well.
These changes, that become increasingly more “aggressive” through each update, results in, for example, unsuccessful creation of Kerberos tickets between patched DCs and DCs that are not.
Regardless of OS version, if you don't have every DC on the same, or at least very close CU (within a month or so), access and authentication will break for many of the AD objects.
For example:
If you have multiple sites, with multiple DCs and AD objects, you won't be able to authenticate via. Kerberos to/on a "computer" on a different site than you are in, as the remote site will not send the required Kerberos PAC and PAC signatures at all or in a way that the patched DC expects.
Then there's also the issue of the issues. There are a ton of known unique problems that arise with each CU version.
As of the last few years you can't simply pull the trigger, apply the latest patch on everything, and hope for the best.
In a critical production environment, prior to patching, research of each CU version is a necessity so you can determine which of the latest versions' pros exceed the cons (security vulnerability patching vs known issues that the CU causes vs configuration changes that will affect systems and/or users..)
Additionally, unless a critical need arises such as for a zero-day type patch, or substantial vulnerability remediation requirements, the CUs should be first tested in non-prod that emulates your prod environment (if budget allows).
..Of course, security is and always should be #1 priority, so always strive to be on the latest CUs for all systems either way.
Another Example:
With one of the somewhat recent CUs , if you have certain encryption attributes (Support AES 256 or 128 bit) set on any of your AD objects, you won't be able to authenticate via Kerberos for said objects against the patched DCs.
Yet another recent version can cause auth to fail in scenarios with 3-part SPNs. (Sometimes you can get lucky and hit NTLM fallback for auth, however it is substantially easier to "hack")
If you then in the above example have said CU on some of the DCs, but not on other DCs, it becomes a nightmare trying to troubleshoot issues. What is causing what undesired action? What object is communicating with what DC during the occurrence? Which is causing the issue? Potentially both or all of them.
In summary, you should always strive to be on the latest updates. If the OS is too old, demote it, and bring a new one up. Never be inconsistent with patching, most importantly with DCs in the same domain and forest (additionally consider the implications on trusts with other domains, as that is impacted as well). Keep the DC CUs consistent across the board. Strive to stay on the same CU for all DCs. Never stray more than 1-2 months of difference. Research to determine the impact each will have on your environment. Determine what commands or scripts need to be ran to check objects for atypical configurations that could/will result in failed auth after patches are applied.
Each of the updates comes with fixes, changes, and unique issues that will affect your environment. Do you research and test prior to going prod, but don’t wait too long, as the bad guys are always at your door.
A few of the uninformed responses here will result in full blown incident response if it happens in an enterprise environment. I’ve witnessed it firsthand and have helped major corporations investigate, perform RCAs, and resolve partial, yet very large scale outages due to the encouraged actions stated within this discussion.
What some of the people have said here is completely wrong.
Yes, you can have DCs on the same domain with (reasonably) different OS versions. However, only if your DC OS versions are in Mainstream Support.
If the DC OS versions stay aligned with Mainstream Support, they’ll typically be reasonably close in OS version either way.
The concerning part, however, is the responses to whether DCs can or cannot be on different update/patch (CU) levels.
In summary, unless you want to get deep into the trenches with what configurations change, and what varying problems to expect on DCs (and therefore AD itself), consider this response to the question a big no. Strive to keep them all on the same CU at all times, regardless of OS versions.
Will they still work as expected? Maybe. Will there be issues if the CU versions are vastly different between DCs? Absolutely. Contrary to assumption here, Microsoft has been progressively "hardening" auth and security related requirements, such as requiring Kerberos PAC, Kerberos PAC Signatures, RPC sealing, NTLM, and other areas as well.
These changes, that become increasingly more “aggressive” through each update, results in, for example, unsuccessful creation of Kerberos tickets between patched DCs and DCs that are not.
Regardless of OS version, if you don't have every DC on the same, or at least very close CU (within a month or so), access and authentication will break for many of the AD objects.
For example:
If you have multiple sites, with multiple DCs and AD objects, you won't be able to authenticate via. Kerberos to/on a "computer" on a different site than you are in, as the remote site will not send the required Kerberos PAC and PAC signatures at all or in a way that the patched DC expects.
Then there's also the issue of the issues. There are a ton of known unique problems that arise with each CU version.
As of the last few years you can't simply pull the trigger, apply the latest patch on everything, and hope for the best.
In a critical production environment, prior to patching, research of each CU version is a necessity so you can determine which of the latest versions' pros exceed the cons (security vulnerability patching vs known issues that the CU causes vs configuration changes that will affect systems and/or users..)
Additionally, unless a critical need arises such as for a zero-day type patch, or substantial vulnerability remediation requirements, the CUs should be first tested in non-prod that emulates your prod environment (if budget allows).
..Of course, security is and always should be #1 priority, so always strive to be on the latest CUs for all systems either way.
Another Example:
With one of the somewhat recent CUs , if you have certain encryption attributes (Support AES 256 or 128 bit) set on any of your AD objects, you won't be able to authenticate via Kerberos for said objects against the patched DCs.
Yet another recent version can cause auth to fail in scenarios with 3-part SPNs. (Sometimes you can get lucky and hit NTLM fallback for auth, however it is substantially easier to "hack")
If you then in the above example have said CU on some of the DCs, but not on other DCs, it becomes a nightmare trying to troubleshoot issues. What is causing what undesired action? What object is communicating with what DC during the occurrence? Which is causing the issue? Potentially both or all of them.
In summary, you should always strive to be on the latest updates. If the OS is too old, demote it, and bring a new one up. Never be inconsistent with patching, most importantly with DCs in the same domain and forest (additionally consider the implications on trusts with other domains, as that is impacted as well). Keep the DC CUs consistent across the board. Strive to stay on the same CU for all DCs. Never stray more than 1-2 months of difference. Research to determine the impact each will have on your environment. Determine what commands or scripts need to be ran to check objects for atypical configurations that could/will result in failed auth after patches are applied.
Each of the updates comes with fixes, changes, and unique issues that will affect your environment. Do you research and test prior to going prod, but don’t wait too long, as the bad guys are always at your door.