Mike Masciulli Managing Director, Migration Products & Services

Picture this.

During a routine Active Directory migration, all seems well. A service account moves cleanly from a source domain to a target. Permissions look right. Group memberships are intact. SID history is preserved.

Then, a week later, the application behind that account starts failing intermittently. By the time someone ties the failures back to the migration, the help desk has 40 open tickets. And nobody can explain it.

What changed? The account had RC4-only Kerberos keys in source. Standard migration tooling copied the NTLM hash. The target domain—fresh, patched, AES-defaults—has no AES keys for that account.

And after April 14, 2026, updated DCs no longer implicitly fall back to RC4 encryption for accounts without explicit RC4 configuration. Authentication just stops.

If you’re running an Active Directory migration, consolidation, or trust-based identity project across the July 2026 RC4 enforcement deadline, this risk may already be sitting in your environment.

In the blog How to Audit Your Environment for RC4 Encryption, my colleagues Guido Grillenmeier and Rich Peckham provide sample queries you can use as templates to audit your environment and locate RC4-dependent accounts.

What you need now is an action plan that helps you prevent those potential account failures.


What you’ll learn in this post

  • Where RC4-related migration failures are most likely
  • The types of failures that can occur—and what to be watching for
  • How to systematically assess your environment and uncover accounts at risk of breakage
  • What free tools can assist you in your discovery
  • Steps to take right now to get ahead of the AES cutover

Why are migration projects uniquely exposed to RC4 changes?

The RC4 deprecation timeline is well-documented.

  • January 2026: Microsoft introduced auditing and the RC4DefaultDisablementPhase registry key.
  • April 2026: Microsoft changed the KDC default to AES-only for accounts that don’t have the msDS-SupportedEncryptionTypes attribute explicitly set.
  • July 2026: Microsoft removes audit mode and stops honoring the RC4DefaultDisablementPhase registry key rollback entirely, leaving only accounts with explicit RC4 exceptions still capable of receiving RC4 tickets.

The Semperis audit-walkthrough post covers the steady-state discovery in detail. What that walkthrough doesn’t cover is the migration scenario, where the risk shows up in three specific ways:

  • Migrations move accounts across security boundaries. An account that authenticates successfully today in source can fail the moment it lands in a target with stricter enforcement, even if the source’s enforcement state is permissive.
  • Migration tools handle credential material asymmetrically. Standard migration tooling copies the NTLM hash but does not copy AES keys. Microsoft’s AD Hardening Series Part 4 puts it directly: If the target domain does not support RC4, you will need to reset the account’s password in the target domain for Kerberos to work. That’s true for every account whose source-side keys are RC4-only.
  • The failures are silent. Steady-state RC4 dependencies announce themselves as KDCSVC events 201–209. Migration-induced failures often don’t. Instead, they show up as application errors with no obvious link to encryption type. The root cause has to be reasoned out, not observed.

Together, these factors make a single PowerShell query insufficient. Migration teams need a structured discovery process.


What accounts are at risk of RC4-related migration failures?

Before going further, a calibration. The April 2026 patches landed without the widespread breakage some industry coverage anticipated—at least from what we observed in the field. In most customer environments, configured Kerberos encryption is preserved and authentication continues normally.

This post is not arguing that the sky is falling.
What it is arguing is that a specific, identifiable failure mode persists—and that migration cutovers are precisely the events most likely to surface it.


Three conditions that put an account at risk

Silent RC4-related migration failures usually show up when all three of the following are true:

  • AES indicated but not delivered. The account’s msDS-SupportedEncryptionTypes attribute is populated with AES bits or is null with the domain default set to AES. The KDC The KDC reads this as “AES is supported” and attempts to issue AES tickets to the account.
  • No AES key material in target. AES keys are generated only when a password is set in a DFL 2008 or higher environment. The highest-risk accounts are old, never-reset accounts and migrated accounts where credential material was copied without regenerating AES keys. The attribute says AES; the keys say RC4 only.
  • Account is actively authenticating via Kerberos. The failure surfaces only when the account requests a Kerberos ticket. At that moment, the KDC attempts AES (per condition 1), finds no AES key (per condition 2), and authentication fails. Dormant accounts and accounts that authenticate only via NTLM stay invisible because the broken state never gets exercised.

What account types are most at risk?

In most enterprises, the at-risk account population is not random. It tends to cluster in five account types—the categories worth asking about in any pre-migration scoping conversation.

  • Legacy service accounts from initial AD deployment, created in the 2000–2010 era and never rotated. These are the single highest-frequency entry in the at-risk population.
  • Accounts with PASSWD_CANT_CHANGE or DONT_EXPIRE_PASSWORD UAC flags set. The flags correlate strongly with passwords set once at provisioning and never rotated.
  • Non-Windows systems with locally stored Kerberos credentials—Linux hosts with keytab files, Java application servers with hardcoded krb5.conf, NAS appliances joined to the domain, network devices with cached credentials.
  • Service accounts owned by departed administrators, where credential material exists but the institutional knowledge of what depends on the account has been lost.
  • Computer accounts where automatic password rotation has broken—long-offline machines, orphaned accounts, accounts with PasswordNeverExpires set inappropriately.

How many accounts may be affected by RC4 during AD migration, on average?

Based on field experience across migration engagements, the at-risk account population in a given environment typically falls within these ranges.

Environment TypeAverage At-Risk Population
Greenfield environments built after 2010 with strong identity governance0–10 accounts
Typical mid-to-large enterprise with a decade or more of AD history20–200 accounts
Environments built through M&A without subsequent identity consolidationSeveral hundred to low thousands
Acquired environments where the acquiring organization has not yet completed identity rationalizationHighly variable, sometimes exceeding the M&A range

NOTE: These are starting points for scoping conversations, not measurements. The actual population can be confirmed only through the discovery work we’ll walk through.


Why AD migration cutover concentrates the risk

These RC4-dependent accounts can persist in production for years without failing. Their Kerberos authentication relies on cached tickets and infrequent re-authentication, which keeps the missing AES keys invisible during normal operations.

Migration cutover changes that. It invalidates cached credentials across the population simultaneously, forces fresh AS-REQs and TGS-REQs in a short window, and surfaces the failure mode at exactly the moment when owner knowledge has aged out and root-cause analysis is hardest.


The two failure modes you’re hunting for

Before getting into the discovery methodology, it helps to name the two distinct categories of break risk that you’re trying to surface.

  • Latent configuration drift. Accounts that appear fine today but will fail under enforcement—the at-risk population defined above. The AD attributes say one thing; the actual key material says another. You can’t see this by querying AD attributes alone.
  • Migration-mechanism risk. Failures that emerge specifically from the way that the migration moves identity material. These don’t appear in steady-state telemetry on either side and include:
    • SID history dependencies
    • Dual-running scenarios where the same logical identity authenticates from both realms
    • Target DFL lower than 2008 (silently breaks every post-migration password reset)
    • Trust attribute mismatches.

Both categories require evidence to find. Neither is reliably surfaced by tools that only look at one signal source.


How to prepare for the RC4-to-AES cutover: A six-phase migration discovery methodology

Understanding the context that your RC4-dependent accounts operate in—and the potential failure types you may encounter—gives you a framework to work from as you move through the process of locating those accounts and configuring them for AES.

This is the field-tested sequence we use with customers on migration engagements. Each phase produces evidence that feeds the final break-scenario matrix.


Phase 0: Establish the playing field

Before looking for problems, document both the source and target environments. Asymmetry between the two is itself a primary risk surface.

For each domain, capture:

  • Forest and domain functional level
  • OS version of every DC
  • Latest cumulative update
  • The value of RC4DefaultDisablementPhase on each domain controller (DC)

Some DCs may not have RC4DefaultDisablementPhase or DefaultDomainSupportedEncTypes set at all. That usually means the setting is not explicitly configured and the DC is following its current default behavior for its OS and patch level.

What matters next is whether that effective behavior is consistent across the domain and between source and target.

      $path = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\' +
    'Policies\System\Kerberos\Parameters'
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName -ScriptBlock {
    Get-ItemProperty -Path $using:path -ErrorAction SilentlyContinue |
        Select-Object PSComputerName, RC4DefaultDisablementPhase,
                               DefaultDomainSupportedEncTypes
}

Look for asymmetry: A source domain at DFL 2003 with phase unset and paired with a target at DFL 2016 already at phase 2 means every migrated account that lacks AES keys breaks at cutover.

Note any DC running Server 2012 or 2012 R2 with expired ESU: Those will not get the July 2026 patches and are immovable RC4 sources.

If the registry keys are missing: Check the DC’s OS version, patch level, and whether other DCs in the same domain show explicit values. The red flag is not the absence of the key itself, but a mixed estate where some DCs are effectively in one behavior state and others are in another.

Treat source/target mismatch as a risk signal: Missing keys in source plus explicit phase settings in target, or null defaults on one side and explicit RC4 exceptions on the other, are exactly the combinations that hide migration break scenarios until cutover.

Document the migration trust: A trust with msDS-SupportedEncryptionTypes set to 0x4 (RC4-only) is a guaranteed break point at July 2026. A trust with the attribute null follows the newer AES-default behavior and is far less likely to be the break point than a trust explicitly pinned to RC4.


Phase 1: Confirm both domains can see RC4 traffic

You can’t find what you don’t log. Verify Kerberos auditing on every DC in both domains:

      auditpol /get /subcategory:"Kerberos Authentication Service"
auditpol /get /subcategory:"Kerberos Service Ticket Operations"

Both should report Success and Failure. If they don’t, push the standard Kerberos auditing Group Policy Object (GPO) on the Domain Controller’s OU before going further.

On DCs patched to January 2026 or later, the System log should also be capturing Provider KDCSVC events 201–209. A complete absence of these in an environment with known legacy applications usually means a logging gap rather than a clean environment, so validate patching and collection before assuming you have no RC4 exposure.

Also watch for partial visibility: auditing enabled on some DCs but not others, forwarded events from only part of the estate, or retention windows too short to catch low-frequency service accounts.


Phase 2: Configuration-layer discovery

This phase identifies break scenarios visible in AD attributes alone. The fastest path is the open-source RC4-ADAssessment PowerShell module, run against both domains:

      Install-Module -Name RC4-ADAssessment
Import-Module RC4-ADAssessment

Invoke-RC4Assessment -Domain source.contoso.com -ExportResults
Invoke-RC4Assessment -Domain target.contoso.com -ExportResults

This module captures:

  • DC encryption configuration
  • Trust encryption
  • KRBTGT password age
  • Every service account flagged as RC4-only or DES-enabled
  • Accounts with the USE_DES_KEY_ONLY UAC flag
  • Accounts with explicit RC4 exceptions
  • Accounts with stale passwords

Each finding is exported with copy-paste remediation commands inline. Treat the output as a prioritized candidate list rather than final proof. Phase 2 tells you where to investigate, but event data and application context are what confirm an actual migration break scenario.

Pay special attention to service accounts whose PasswordLastSet predates the source domain’s DFL upgrade to 2008. These are high-priority candidates for the at-risk population defined above and should be validated against event data and migration history.


Phase 3: Behavioral discovery

Configuration tells you what’s allowed. Events tell you what’s actually happening. They routinely disagree.

Run the assessment with event-log analysis enabled or query Sentinel or Splunk directly:

      Invoke-RC4Assessment -Domain source.contoso.com `
-AnalyzeEventLogs -EventLogHours 168 -ExportResults

The high-value output is the AES-configured-but-RC4-used correlation: accounts where AD says “I support AES” but event logs show RC4 tickets being issued. That gap is the exact failure mode that will surface during migration.

For migration engagements specifically, also pull cross-realm TGS requests. In 4769 events, look for service tickets where ServiceName is in the other realm and TicketEncryptionType is 0x17. Cross-realm RC4 traffic is the canary for migration trust path failures under enforcement, and even low-volume findings deserve direct investigation because the affected application may be business critical.

Also watch for service accounts that authenticate only during batch windows, month-end processing, or scheduled jobs; they are easy to miss in short collection windows and often make up the most painful cutover surprises.


Phase 4: Application-layer discovery

This is where most migrations actually break, and where AD-aware tooling provides the least visibility.

Walk every Linux, Java, and network appliance host that uses AD-based Kerberos.

Inventory keytab files; anything containing only arcfour-hmac entries is RC4-pinned. Expect to find at least a few non-Windows systems still using keytabs generated years ago.

Check /etc/krb5.conf for hardcoded default_tkt_enctypes or permitted_enctypes listing only RC4. Both will break post-July 2026 regardless of what AD does—and re-keying the keytab against the target realm requires the migrated account to have AES keys, which loops back to Phase 2 findings.

For each application that uses Kerberos authentication, walk the owner through:

  • The service account currently in use and its msDS-SupportedEncryptionTypes value
  • Where the application is hosted
  • Whether a keytab is in use and when it was generated
  • Whether vendor docs specify required Kerberos encryption types
  • Whether pre-authentication is RC4-pinned

Expect documentation gaps. Many owners will not know when the keytab was generated or whether the vendor supports AES cleanly, and that uncertainty is itself a useful risk indicator.

Also scan for hardcoded encryption configurations in places AD-attribute discovery doesn’t reach the network security:

  • The Network security: Configure encryption types allowed for Kerberos GPO setting
  • SQL Server linked servers
  • IIS application pool identities with stale passwords
  • Java apps with -Dsun.security.krb5.permitted_enctypes JVM flags

Phase 5: Migration-specific risks

The break scenarios we’ll uncover in this phase manifest only during the migration cutover. They’re properties of the migration mechanism rather than of either domain in steady state.

Map your migration tool’s password handling. If the tool copies passwords, it copies whatever credential material exists. An account with only RC4 keys in source arrives in target with only RC4 keys. The standard mitigation—forced password reset post-migration—can break dependent services if the application is running.

Each service account needs a documented after-migration reset plan with a maintenance window.

Evaluate password-synchronization approaches honestly. Some migration tools offer password-sync filters that capture changes on source DCs and replay to target. These do solve the AES key generation problem at the target—but they:

  • Install a privileged code path on source DCs
  • Expose plaintext transiently in memory
  • Fire only on password change events (missing dormant accounts and non-rotating service accounts entirely)
  • Carry operational risk if the filter fails silently

Using such tools is legitimate for bounded coexistence windows where the tradeoffs are documented and accepted—but not a substitute for the discovery work above.

Catalog dual-running scenarios. During the migration window, users and services may exist in both source and target. Identify cases where the same logical identity authenticates from both sides—typically across cross-realm trusts, federation, or a synced Entra ID tenant.

Each one is a potential break point because encryption negotiation differs by side.

Inventory SID history dependencies. SID history preserves resource access; however, encryption keys are independent. An app authorizing via SID history but issuing tickets via the target account’s keys can fail if those keys are RC4-only.

Confirm target DFL is at least 2008. On consolidations involving acquired environments, the target sometimes ends up at a lower domain functional level (DFL) than expected. Below DFL 2008, password resets do not generate AES keys, so the entire post-migration reset plan silently fails. Verify before cutover. Not during.

The real risk in this phase is combinations, not isolated facts. For example:

  • Password-copy migrations with no documented reset window
  • Dual-running identities with no path-by-path testing
  • SID history treated as an authentication fix
  • A target DFL problem discovered only after pilot cutover

These are the migration-specific patterns that turn manageable findings into outage scenarios.


Phase 6: Build the break-scenario matrix

The output from the first five phases is not a generic risk list. It is a break-scenario matrix: one row for each identifiable way the migration can fail. Keep it compact. For each row, capture the scenario, what triggers it, how it will present, and the action needed before cutover.

Phase 2, 3, and 4 findings usually generate the first rows.

Phase 5 adds the migration-only scenarios that don’t appear in steady-state discovery.

Once populated, this matrix becomes the cutover tracker and the basis for the go/no-go decision.

ScenarioTrigger How it shows upAction before cutover
Service account migrated with AES configured but no AES keysCutover or first fresh Kerberos requestApp authentication fails after migration; scheduled jobs or services start failing once cached tickets expireReset the password in target, validate AES key generation, retest the app, and schedule the change in a maintenance window
Linux or Unix host with an RC4-only keytabJuly 2026 enforcement or target-realm cutoverKerberos auth fails from the non-Windows host; the service falls back or stopsRegenerate the keytab with AES-capable credentials after confirming the migrated account has AES keys
Cross-realm trust explicitly pinned to RC4July 2026 enforcementCross-realm ticket requests fail during coexistence or staged accessRemove the RC4-only trust setting and validate trust behavior with direct test traffic before cutover
Target domain below DFL 2008Post-migration reset plan Password resets appear to succeed, but AES keys are never generated and the app still fails Raise the target DFL before migration, or redesign the remediation path before the first pilot
Java, appliance, or local Kerberos config hardcoded to RC4Cutover, enforcement, or first fresh ticket request One app tier fails even though AD-side settings look healthyRemove RC4 pinning, validate vendor support for AES, and test the exact app path before production
Dual-running identity authenticating differently across source and targetCoexistence window or staged migration waveAccess behavior varies by realm, host, or path, creating inconsistent user impact Document the path-by-path behavior, reduce overlap where possible, and test the coexistence path explicitly

What you’ll actually find

Across migration engagements, the highest-yield findings usually fall into four categories:

  • Service accounts with AES configured but no AES keys. These are often old, never-reset accounts or migrated accounts where credential material was copied without regenerating AES keys. The AD attribute lies. Phase 3’s event-log correlation is the only reliable way to find them. They are also the easiest to remediate. A password reset in a DFL 2008 or higher environment generates the AES keys. Two sequential resets with a delay between them are sometimes recommended as a replication-safety measure.
  • Linux hosts with RC4-only keytabs. SSSD, Samba, Apache mod_auth_kerb, PostgreSQL with GSSAPI—all common, all generate keytabs against whatever encryption types existed at generation time. Re-keying against the target realm post-migration is the fix but requires the migrated account to have AES keys first.
  • Acquired-environment DFL surprises. When the target was the smaller acquired entity, or when consolidations happened in the wrong direction, the DFL ends up below 2008 and nobody notices until cutover. Verify in Phase 0; verify again before each migration wave.
  • Trusts with explicit RC4 attributes. Less common than the others but high impact when present. A trust with msDS-SupportedEncryptionTypes = 0x4 will fail the migration mechanism itself, not just specific accounts.

If engagement time is constrained, prioritize Phase 3’s AES-configured-but-RC4-used correlation and Phase 4’s keytab inventory. Together they typically produce 60–80% of the actual break list.


Tools and resources

The discovery work above can be assembled from open-source tooling and native AD commands. Here are some trusted resources for detection and mitigation of RC4-dependent accounts; all of these are freely available.

For organizations running this assessment as part of an active migration project, Semperis Professional Services regularly runs this methodology as a pre-migration engagement. The migration community is also actively working on approaches that reduce the user-disruption cost of post-migration password resets — a follow-up post will cover those approaches as they mature.


Where to start this week

If you have a migration project crossing July 2026 and haven’t started this work yet, start with these four steps:

  • Run Phase 0 today. It’s a 30-minute exercise per domain and surfaces the DFL-and-patch-state asymmetries that determine everything else.
  • Verify auditing in both domains (Phase 1). If it’s not on, fix that this week. Every day of missing telemetry is a day of break risk you can’t see.
  • Run RC4-ADAssessment with -AnalyzeEventLogs against both domains (Phases 2 and 3 combined). The AES-configured-but-RC4-used finding category is your single highest-value output.
  • Schedule the Phase 4 application-owner walks. This is the long pole. Start it now and run it in parallel with everything else.

The migration cutover and the July 2026 enforcement deadline are different events. The discovery work that prepares you for one prepares you for the other.

Start now and the matrix you build becomes the operating tracker for both.

Have questions about this methodology or about how Semperis can help with an active migration project? Get in touch—we’re here to help.