29 Jun 2026
• RC4
• active directory
What is RC4?
RC4 is a fast but outdated encryption method that is no longer considered secure and is being deprecated. It has known weaknesses and can be broken with modern techniques. Microsoft and others are actively phasing it out
There has been a lot of noise recently around Microsoft’s planned RC4 changes in Active Directory Kerberos. Some of it is useful. Some of it is marketing. And some of it badly misrepresents what Microsoft is actually doing.
The most important point is this: Microsoft is not saying that RC4 suddenly disappears “next month,” and it is not saying that all existing password migration methods immediately stop working. What Microsoft is doing is changing how domain controllers treat RC4 by default, reducing implicit RC4 use and pushing customers toward AES. That is a sensible security move. It is not the same thing as saying "every RC4-dependent workflow instantly dies".
That distinction matters, especially when vendors start making dramatic claims such as:
“Current methods for migrating passwords between Active Directory forests will no longer be effective next month due to the discontinuation of RC4.”
That is not an accurate reading of Microsoft’s guidance.
What Microsoft is actually changing
Microsoft is hardening Kerberos so that domain controllers no longer continue making RC4 available by default. If you set the encryption types via GPO to include RC4 then nothing changes automatically. The goal is to reduce RC4 exposure and make AES the expected standard.
That does not mean RC4 support vanishes overnight. The real change is that RC4 is no longer something organizations should expect to get “for free” through old defaults and assumptions. If you still rely on it, that reliance becomes more explicit, more visible, and increasingly harder to justify.
So, the real message from Microsoft is:
- stop relying on RC4 as the silent fallback,
- identify where it is still in use,
- and move those scenarios to AES wherever possible.
That is very different from “Kerberos breaks next month.”
Why RC4 matters in password migration
RC4 matters in Active Directory because, historically, RC4-HMAC Kerberos is tied to the NT hash. In practical terms, that means legacy password sync and migration methods that work with the NT hash can support RC4-based Kerberos scenarios.
That is why legacy inter-forest password migration has worked the way it has for years.
AES changes that story completely.
AES Kerberos keys are not just the NT hash in another form. They require the actual password material to generate the appropriate modern keys. That means if RC4 is no longer available, synchronizing the NT hash alone is not enough to make pre-existing passwords usable for AES Kerberos.
And that is the point too many vendors are glossing over.
The key limitation customers need to understand
If RC4 is disabled, you lose the ability to use NT-hash-based synchronization as a way of carrying over pre-existing passwords for Kerberos compatibility.
At that point, there is no magic migration trick that can take an old NT hash and somehow recreate proper AES key material for the user’s existing password.
So, what is still possible?
Only two realistic paths remain:
- the user changes their password and that password is captured at change time, or
- the password is reset in the target environment to generate fresh AES keys.
In other words, once RC4 is out of the picture, pre-existing passwords cannot be migrated purely from the NT hash. They can only be synchronized going forward by capturing the password using a filter drive on every Domain Controller when it is changed.
That is the real architectural impact of moving from RC4-era compatibility to AES-first Kerberos.
Why RC4 is a problem in AD
There are good reasons Microsoft wants customers off RC4.
First, the NT hash is deterministic and long-lived. That makes it valuable to attackers and useful well beyond its original purpose.
Second, RC4 use in Kerberos is closely associated with Kerberoasting. Weak or legacy encryption paths make it easier for attackers to request service tickets and attack them offline.
Third, the NT hash is not only useful for RC4-related Kerberos scenarios. It can also be abused directly in pass-the-hash style attacks. So when organisations keep depending on NT-hash-based compatibility models, they are preserving exactly the kind of credential material attackers like most.
So yes, RC4 is bad. Microsoft is right to keep squeezing it out. But that still does not justify pretending Microsoft has announced the instant death of all password migration.
What this means for PowerSyncPro
This is where the distinction between legacy and modern sync matters.
PowerSyncPro legacy password sync supports RC4-based synchronization scenarios built around NT-hash compatibility.
PowerSyncPro modern password sync supports AES-based synchronization by capturing the password at change time, encrypting it and allowing the destination to generate the correct modern Kerberos key material.
That is the honest and technically accurate message:
- RC4-based sync works in legacy scenarios because of the NT-hash model.
- AES-based sync requires password capture at change/reset time.
- If RC4 is disabled, there is no way to migrate pre-existing passwords between AD forests purely from the NT hash.
That is not a product limitation. That is simply how Kerberos key generation works.
A final word on vendor messaging
A slight dig is warranted here.
Some vendors talking loudly about Microsoft’s RC4 changes do not appear to understand either the actual Microsoft roadmap or the cryptographic difference between NT-hash-based RC4 compatibility and true AES-capable password synchronisation.
Saying “RC4 is being reduced and legacy migration approaches have limits” is fair.
Saying “password migration stops working next month because RC4 is being discontinued” is not.
Customers deserve better than that.
Bottom line
Microsoft is hardening Active Directory Kerberos and pushing organisations away from RC4. That is good and overdue.
But the real takeaway is not “RC4 disappears overnight.” The real takeaway is this:
- RC4 is being pushed out as a default and fallback,
- NT-hash-based sync remains a legacy RC4-era mechanism,
- and in an AES-first world, pre-existing passwords cannot be migrated from NT hash alone.
Once RC4 is disabled, only password capture at change or reset time can support ongoing password synchronisation for modern Kerberos.
That is the change customers need to understand. And it is the part some vendors seem determined to blur.
