Most AD migrations involve some period of password synchronization between the source and...

Most AD migrations involve some period of password synchronization between the source and target domain. That works fine until someone disables RC4 encryption on the domain controllers, and then it breaks quietly in ways that are easy to miss until users start calling the help desk. Microsoft published a post titled "What Changed in RC4 with the January 2026 Windows Update and Why It Is Important" on the Tech Community Core Infrastructure and Security Blog that is worth reading before your next migration planning session. The short version is that RC4 is being disabled by default, a temporary workaround exists right now to re-enable it, and that workaround has a shelf life. If your migration is in flight or planned for later this year, this is not a future problem. Here is what actually happens when RC4 drops out. Kerberos in older migration tooling defaults to RC4 for certain ticket operations. When it is disabled, those authentication requests fail. Password sync stops. Users in the middle of a cutover window suddenly have credentials that do not match between domains, and the migration team is debugging Kerberos errors instead of finishing the cutover. The real answer is confirming your tooling supports AES128 and AES256 exclusively, and that your service accounts and target objects have the msDS-SupportedEncryptionTypes attribute set correctly before you start. Tools like Quest Password Propagation Utility, and similar products from other vendors, exist specifically to keep credential state consistent across domains during a migration. If RC4 drops out mid-migration and passwords diverge, those tools are what close the gap without forcing a mass password reset on users who are already mid-transition. Has anyone in your migration plan actually tested password sync with RC4 disabled in the lab, or is the team still assuming the default config works?