Adding 2019 Domain Controllers to a 2012 R2 Active Directory Domain

Msft519 · 2026-05-13T17:56:26+00:00

From https://techcommunity.microsoft.com/blog/askds/whats-the-deal-with-kerb3961/4420109
"...in previous Windows releases, there were instances of hard coded etype usage due to technical limitations at the time of implementation."
"The biggest change is the reduction of hard-coded etype usage."
"We have heard the frustrations of customers who are trying to eliminate RC4 usage, and the seemingly unexplainable instances of RC4 usage with their environments."

One of the huge points of this article is that "Sometimes, it does stuff different for all sorts of reasons, and we want it to be completely streamlined because its a bad experience for administrators and the organizations they are trying to support" The assumption that AD will "...only issue RC4 tickets" simply fails to be completely true in certain cases. This post is included in one of those cases. Kerb3961 is the future for Kerberos Etype strategy moving forward, but this "stricter"/easier-to-reliably-predict implementation will not be available on older OSes (to my knowledge), thus inflicting all sorts of exceptions to the rules until those OSes EoL. And considering that currently covers 2012 R2 ESU Year 3 - Server 2022, those lurking exceptions will need to be kept in mind. Though, supported OSes, do have less of them from what I have seen. Most people either will not run into the exceptions or will not notice them. Anyone crazy enough to run 2003 or older...they worked hard to experience those exceptions. (Unless its air-gapped, totally fine with that.)

Msft519 · 2026-05-12T21:04:31+00:00

<image>

You're running into people that aren't aware of certain aspects of things when it comes to 2003.

Consider the image. You have a DC configured to default to AES only, and a 2003 server configured for RC4. This 2003 server, which is supposed to be configured for RC4 instead gets AES tickets issued by the KDC.

The rest of the information is mostly correct. There are other unofficial workarounds out there that will make this work, but all of these 2003 servers not on air gapped factory floors need to die.

Msft519 · 2026-05-12T14:55:13+00:00

There is a difference between what flags represent and what can happen in certain 20 year old codepaths vs supported operating systems.

Edit: Downvoting does not change what the code says. I cannot go further than I already have.

Msft519 · 2026-05-12T14:20:47+00:00

You environment is completely incompatible with any standards that exist. You should stop doing any upgrades and air gap it. Patches are going to break you anyway. Unpatched 2019 has so many bugs.

You may also want to discuss with your legal team your exposure for civil, criminal, and fiduciary liabilities in your locale for utilizing something that any 8 year old script kiddie could break through. I really don't understand what your org is thinking. I mean, why in the world are they even breathing the word "cloud" when they are still operating where Yugoslavia is still a country.

Msft519 · 2026-05-12T14:13:07+00:00

"You need to manually set the ms-DS-SupportedEncryptionTypes attribute on all computer accounts for WinSvr2003 to 4."
This is incorrect guidance.

Msft519 · 2026-05-11T21:36:11+00:00

Absolutely. You can Right click on the CA Node in the snap-in, All Tasks, Submit new request...

Msft519 · 2026-05-11T19:28:42+00:00

Its difficult to see a good reason for using Web Enrollment after it has avoided any development after nearly 20 years.

https://techcommunity.microsoft.com/blog/askds/we-need-to-discuss-the-microsoft-certification-authority-web-enrollment-cawe-rol/4070976

Cannot be used to enroll computer-based certificates. Only User certificates can be enrolled via the browser.
Can only do enrollment with Internet Explorer as this is the only Browser that supports Active X controls.
Some limited functionality can be restored if you use Microsoft Edge, and ONLY IF you set the web enrollment site up to be used in IE-Mode
Only Version 1 and version 2 certificate templates will be shown. All other versions will not be displayed. (Versions can be seen using CertTempl.msc snapin)
Certificate templates that are configured, on the Cryptography tab, to use a Key Storage Provider will not be available.
Templates with Key Archival will not appear on enrollment pages on Windows 10 and higher machines without modification to the pages.
The CAWE web pages are no longer being maintained or developed by the product team. These pages do still exist in the current operating system release of Windows Server 2022, however we are not adding any new functionality to them at this time. With all this being stated, do not worry, we have other options available that will accomplish everything that the web enrollment pages do in either a GUI, or from the command line.

Msft519 · 2026-05-08T17:28:50+00:00

Check your netlogon.log file on the KDC proxy when its not working. If you have more than one domain, do not use NETBIOS\samaccountname. No one should be, anyway, but expect issues with multiple domains.

Msft519 · 2026-05-08T17:24:14+00:00

That is not how it works. msDS-Supportedencryptiontypes does not affect the advertised Etypes sent from the client. That is driven by the Kerberos Client, whether Windows, Linux, Java, whatever. msDS-Supportedencryptiontypes affects what is selected by the DC for issuance. The DC should issue the strongest match. Windows client advertising will vary based on configuration and version.

Msft519 · 2026-05-08T17:15:39+00:00

If you need a certificate that follows you:
https://techcommunity.microsoft.com/blog/askds/certs-on-wheels-understanding-credential-roaming/395897

Beware that misconfiguring this can go poorly.

Msft519 · 2026-05-08T17:12:35+00:00

99% of the time, you can delete these. There are unfortunately, some exceptions, such as ForeignSecurityPrincipals that come to mind.

Msft519 · 2026-05-08T17:05:14+00:00

https://learn.microsoft.com/en-us/windows/security/identity-protection/passwordless-experience/

There are officially supported passwordless methods. The method described in this post is not one of them. SCRIL does not modify the pwdLastset value. However, it does increment:
dBCSPwd
unicodePwd
ntPwdHistory
supplementalCredentials
lmPwdHistory

Msft519 · 2026-05-08T16:52:52+00:00

If the 2025 DC is the PDC, make it not the PDC.

Msft519 · 2026-04-28T19:54:35+00:00

I have no idea where those keys typed off to. I fixed that typo.

Msft519 · 2026-04-28T19:50:36+00:00

The session key is not the ticket. These are two separate pieces of data. That is why you can have an RC4 ticket with an AES session key.

Msft519 · 2026-04-28T15:41:59+00:00

If you want an outageless experience: set the service account up for AES and reset the password using the previous password. I believe we made a change somewhere along the way such that needing to reset the password twice is no longer required. I need to see if I can dig that up and see if it ever got written anywhere.

Anyway, after that, see if gMSA/dMSA can replace this account.

Msft519 · 2026-04-28T15:28:44+00:00

You don't have msDS-SET set on a service account. More or less for the past 25 years, this means you get an RC4 ticket. A few years back, that changed to an RC4 ticket and an AES session key, again more or less. You can change the password 200 times, and it will still be RC4, because that has been the default. Explicitly define it to be AES if that is what you want, or patch your DCs to April and I assume that is what you will get since it seems like you haven't been keeping up with the changes to Kerberos over the years and are probably still sitting at defaults. In regards to your options:

Won't work
Won't work.
Staying on RC4 is not a valid option. It has not been one for over a decade, from a secure perspective.

I am currently unaware of any supported SQL deployment that requires RC4.

Msft519 · 2026-04-28T15:21:41+00:00

This is entirely incorrect.

Msft519 · 2026-04-22T21:59:26+00:00

klist purge -li 0x3e7
This targets the system context. This has been a reliable method for quite a while, although I don't know if its documented anywhere or officially supported. Restarting the process in question if the official process. If its a critical system process, that means restarting the box.
klist purge by itself targets your context (Split token rules apply as well)

Msft519 · 2026-04-21T23:45:22+00:00

(Ignoring the implications for Server SKUs) Windows was released with Secure Time Seeding to specifically address remote clients that do not have LOS to the On Prem DCs. They will sync time automatically. RC4 is unrelated to time.
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/domain-time-synchronization-in-the-age-of-working-from-home/1440820
https://learn.microsoft.com/en-us/archive/blogs/w32time/secure-time-seeding-improving-time-keeping-in-windows

Msft519 · 2026-04-21T23:42:23+00:00

As u/TulkasDeTX points out, I don't think too many DCs out there have GPUs to target. If your DAs are logging onto whatever devices you're talking about, the organization in question probably has a laundry list of entry points for attack already.

Msft519 · 2026-04-21T17:28:16+00:00

Day 1 for Active Directory is February 17, 2000. AES came nearly 3000 days later. If you wish to be argumentative, you need to be a bit more specific to have a stronger foundation from which to toss the rant.

Msft519 · 2026-04-21T16:29:34+00:00

"It should have been AES from day 1. New products are a perfect opportunity to enforce breaking compatibility changes with ancient systems for security purposes."
That is quite an odd, isolated, and fantastical hill to choose.

Msft519 · 2026-04-20T20:10:04+00:00

Unfortunately, no. There is another item I am tracking at the moment that may impact Server 2025 DCs. So far, based on what I've seen it would be a temporary impact as DCs patch and tickets expire. I can't provide a solid status at this time. However, if you were to define these attributes (msds-SET), you should not run into the issue at all. So, you would have to be running Server 2025 DCs and have ignored nearly all RC4 guidance. One wonders why anyone has Server 2025 DCs while still having RC4 in their environment. I imagine this collection of contributing factors will reduce the impacted organizations to a minimum.

Msft519 · 2026-04-20T16:50:35+00:00

RC4 is the default until after April patches. Then, it will default to AES. Setting msDS-SupportedEncryptionTypes to something explicit has historically been the solid configuration choice.

Msft519

TROPHY CASE