RC4 Disabled Since April Patches: Temporary RC4 Allowance for NT Hash Migration
Microsoft is phasing out RC4 usage in Kerberos, and many Active Directory environments are now moving toward AES-only authentication. This is a positive security improvement, but it can expose a specific compatibility issue during password or account migration projects.
When only the NT hash of a user password is migrated, the target account has the credential material needed for RC4-compatible Kerberos authentication and NTLM authentication. However, AES Kerberos keys are salted and derived from the plaintext password. They cannot be recreated from the NT hash alone.
For that reason, environments that disable RC4 may encounter authentication problems for migrated users if the migration relies on NT hash migration only. In this specific scenario, a temporary and targeted RC4 allowance may be required for the affected migrated user accounts until their passwords are changed or synchronized in a way that creates valid AES keys in the target domain.
NT hashes are sensitive credential material. The guidance below is intended only for controlled migration compatibility cases where NT hash migration is genuinely required. It is not a general security recommendation, not a broad rollback of RC4 restrictions, and not intended for AES-only migration paths that use password synchronization instead of NT hash migration. If your migration scenario requires an AES-only migration path, please refer to the "Migrate Active Directory Passwords with RC4 Disabled (Kerberos AES)" blog posting instead.
If your migration plan requires NT hash migration, you can set the destination user's supported Kerberos encryption types in a user transformation script:
Destination("msDS-SupportedEncryptionTypes")=60
Decimal 60 is hexadecimal 0x3C. This value includes RC4-HMAC, AES128, AES256, and AES session-key support. In practical terms, it allows the migrated account to continue working in the temporary NT-hash compatibility scenario while avoiding an RC4-only configuration. You can use this handy Encryption Type Calculator to visualize the encryption-type bitmask and see which options are enabled.
Use this setting only as a targeted migration aid. Apply it only to users or migration waves that actually require NT hash migration, and document why the exception was added.
This setting does not create AES keys for the account. A password change, password reset, or password synchronization event is still required to move the account forward so that the target domain has current password-derived Kerberos keys.
After the compatibility period is complete, remove the temporary RC4 allowance or restore the account to your organization's normal Kerberos encryption baseline. A password change alone does not clear the msDS-SupportedEncryptionTypes attribute and does not remove the RC4 bit if it was explicitly configured.
A practical operating model is:
- Identify the users or migration waves that genuinely require NT hash migration.
- Apply the transformation-script setting only to those users.
- Complete the migration.
- Ensure affected users receive a password change, password reset, or password synchronization event that creates current keys in the target domain.
- Remove the temporary RC4 allowance or restore the normal encryption-type baseline.
- Document the exception and cleanup so the compatibility setting does not remain in place longer than required.
This keeps the migration path available without turning a narrow compatibility requirement into a long-term security exception.
For product-specific migration details, review the Password Synchronization & Migration Add-On Administrator Guide. If you are unsure whether your environment requires this setting, contact Sys-Manage support before changing your migration plan. We can help determine whether the issue is related to RC4 being disabled for affected Active Directory/Kerberos accounts, whether NT hash migration is actually needed, whether password synchronization is the better approach, and what post-migration cleanup should be planned.