If your organization runs on-premises Active Directory (and most rural health care organizations still do), there is a change coming in April 2026 that could break authentication across your environment if you have not prepared for it. Microsoft is retiring RC4 as the default fallback encryption for Kerberos ticket issuance on domain controllers. For environments that have been quietly relying on this decades-old fallback without realizing it, the April cumulative update will disable it by default.
This is not a distant planning item. April is days away. If you have not audited your environment for RC4 dependencies, this article will walk you through how to find out if you are affected, what to do about it, and why it matters for health care IT specifically. For a comprehensive technical deep dive into the full scope of this change, Health Tech Authority has published an excellent breakdown in their article Microsoft Is Killing RC4 in Kerberos. If You Have Not Acted, Here Is What You Need To Do Now. Our focus here is on what this means practically for the solo IT admin or small team at a rural health care organization.
Does This Even Apply to Us?
Before anything else, let us cut through the noise and help you figure out whether you need to act on this.
First question: do you run on-premises Active Directory? If your environment is entirely cloud-based with no on-premises domain controllers (pure Entra ID / Azure AD), this change does not affect you. You can stop reading here.
If you do run on-premises AD (and most rural health care organizations still do), keep going.
Second question: how old is your domain, and have your service account passwords been reset recently? This is where the actual risk lives. The change affects accounts that only have RC4 encryption keys. Whether an account has AES keys or not depends on one thing: which domain controller processed the account's last password change.
- Server 2003 was the last version that did not generate AES keys for Kerberos. Server 2003 DCs only created DES and RC4 keys when processing a password change.
- Server 2008 was the first version to generate AES keys automatically whenever it processed a password set or reset.
So the question is not "when was my domain created?" The question is "when was each account's password last set, and was a Server 2008 or later DC handling that change?"
If your domain has always run on Server 2008 or later DCs, and all account passwords have been set or reset on those modern DCs, AES keys already exist for those accounts. You are in good shape for the majority of your accounts, even if the msDS-SupportedEncryptionTypes attribute shows as null (blank). A null attribute does not mean "this account only has RC4 keys." It just means no explicit encryption type preference is configured. The actual keys were generated by the DC at the time of the last password change.
However, even on a brand-new modern domain, you are not off the hook entirely. Certain accounts can still be affected regardless of how new your environment is. Service accounts with SPNs registered may have null msDS-SupportedEncryptionTypes and passwords that have never been reset. The AZUREADSSOACC account (if you use Seamless SSO) is created with RC4 by default regardless of your DC version. You should still run the audit queries in this article to confirm.
If your domain started on Server 2003 and has been upgraded over the years (through 2008, 2012, 2016, 2019, 2022), the risk depends on the account type:
- Computer accounts: generally fine. Domain-joined computers automatically rotate their machine account passwords every 30 days by default. This rotation is handled by the Netlogon service and happens silently in the background. Any machine that has been online and communicating with a modern DC would have cycled through AES key generation long ago. The only exceptions are machines that have been offline or disconnected from the domain for extended periods, machines where the rotation was explicitly disabled via Group Policy (the "Domain member: Maximum machine account password age" policy set to 0), or stale computer objects in AD for machines that no longer exist but were never cleaned up.
- Regular user accounts: generally fine. If your organization enforces password expiration policies, users have reset their passwords on a modern DC at some point, which means AES keys were generated.
- Service accounts: this is where the real risk lives. Service account passwords are manually managed. Nobody resets them unless there is a specific reason to. In an environment that has been upgraded over the years, it is entirely possible that a service account's password has not been reset since the days when a Server 2003 DC was processing password changes. If that is the case, that account may only have RC4 keys, and it will break after April enforcement.
- User accounts with "password never expires" set before 2008 DCs were in place: A less common edge case, but if you have user accounts whose passwords were set when a pre-2008 DC was processing the change and have never been reset since, those could be affected too.
Third question: do you use Azure AD Seamless SSO? If your domain has a computer account named AZUREADSSOACC, that account was historically created with RC4 encryption by default and needs specific attention. We cover this in the remediation section below.
For most rural health care organizations we work with, on-premises Active Directory is the backbone of the network. If that describes your environment, keep reading.
What Is Changing and Why
The change is tied to CVE-2026-20833, an information disclosure vulnerability in Windows Kerberos. The short version: RC4-HMAC encryption in Kerberos service tickets is cryptographically weak enough that attackers can request tickets encrypted with RC4 and then crack service account passwords offline. This technique, known as Kerberoasting, has been used in real-world attacks for years.
Microsoft's fix is a phased rollout that changes how the Key Distribution Center (KDC) on your domain controllers handles accounts that do not have an explicit encryption type set.
Here is the timeline:
January 13, 2026 (Audit Phase): New audit events (Event IDs 201 through 209) are introduced in the System event log on domain controllers. A temporary registry key (RC4DefaultDisablementPhase) is available for testing. No breaking changes at this point.
April 2026 (Enforcement with Rollback Option): The default value for DefaultDomainSupportedEncTypes on domain controllers changes to 0x18 (AES-SHA1 only). Accounts without an explicit msDS-SupportedEncryptionTypes value will no longer fall back to RC4. You can temporarily revert to audit mode via registry if needed, but enforcement is on by default.
July 2026 (Full Enforcement): The registry rollback key is retired. Enforcement mode becomes the only operational state. RC4 fallback from the KDC path is permanently gone unless you have explicitly configured it on specific accounts.
The key point: if you have already set msDS-SupportedEncryptionTypes on your accounts, or if you have manually defined DefaultDomainSupportedEncTypes on your domain controllers, your behavior will not change. The risk is with accounts where nobody ever set the encryption type attribute. It was left blank, the KDC fell back to RC4 when needed, and that fallback is what is going away.
A quick note on "AES-SHA1" terminology. If you are reading Microsoft's documentation on this change and wondering why it says "AES-SHA1" when SHA1 has been deprecated for other uses, the naming can be misleading. The full Kerberos encryption type names are AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96. The encryption itself is AES (128-bit or 256-bit), which is strong. The SHA1 component is used only for the HMAC integrity check, not for encryption or digital signatures. The SHA1 vulnerabilities that led to certificate deprecation are collision attacks, which do not apply to HMAC constructions. HMAC-SHA1 remains cryptographically sound for this purpose, and NIST still considers it acceptable. There are newer Kerberos encryption types using SHA-256 and SHA-384 (introduced in RFC 8009), but those require the newest Windows versions (Server 2025, Windows 11 24H2) and are not what this enforcement is about.
(Microsoft Support: KB5073381)
Why This Matters in Health Care IT
Rural health care environments carry some specific risks with this change that are worth calling out.
Remote Desktop and profile environments. If your organization uses FSLogix for profile containers on SMB file shares (common in Azure Virtual Desktop or Remote Desktop Services setups for clinical workstation access), this change can break profile mounting at logon. FSLogix authenticates to the file server using Kerberos when loading user profiles. If the file server's computer account does not support AES, that authentication will fail after the April update. The result is temporary profiles or failed logins entirely. In a clinical environment where nurses and providers depend on roaming profiles to access their EMR sessions, that is a patient care impact, not just an IT inconvenience.
File shares carrying ePHI. Departmental shares, scanned documents, clinical data exports, reporting databases that write to file shares; all of these authenticate through Kerberos when accessed from domain-joined workstations. If the computer accounts or service accounts involved still rely on RC4 fallback, access will break.
Legacy systems and medical devices. Health care environments are known for running systems well past their intended lifespan. That Windows Server 2008 R2 box running a specialty clinical application, the interface engine on an older OS, the lab system that has not been touched in years. These are all candidates for RC4-only Kerberos configurations. If their computer account passwords have never been reset on a domain controller that supports AES, they will not have AES keys and will fail to authenticate after enforcement.
The compliance angle. The HIPAA Security Rule requires covered entities to implement technical safeguards for ePHI. The person or entity authentication standard under 45 CFR 164.312(d) is a Required implementation specification, meaning you must verify that a person or entity seeking access to ePHI is who they claim to be. Running authentication protocols that rely on a cryptographically broken algorithm is not a strong position during a compliance review.
This does not mean that using RC4 is itself a HIPAA violation. But moving to AES strengthens the authentication mechanisms protecting your ePHI, and Microsoft's enforcement is doing the work for you here. The goal is to make sure the transition is clean, not chaotic. For more on how software patching ties into HIPAA compliance obligations, we have covered that topic in detail.
How to Find Out If You Are Affected
If you have not specifically audited for this, you probably have at least some accounts that are affected. RC4 has been the silent fallback for so long that many organizations do not realize they are relying on it.
Check Your Domain Controller Event Logs
If your domain controllers have the January 2026 cumulative update installed (and they should by now), check the System event log for the new KDCSVC events. The ones to look for:
- Event ID 201: RC4 usage detected because the client advertises only RC4 and the service account does not have msDS-SupportedEncryptionTypes defined.
- Event ID 202: RC4 usage detected for a service account that is at risk.
- Event ID 205: Insecure configuration of DefaultDomainSupportedEncTypes detected.
- Event ID 206 and 207: Additional warnings about at-risk configurations.
If you see Event IDs 201, 202, 206, or 207 in the System event log on your domain controllers, you are at risk for breaking changes when enforcement mode is enabled.
Important note: the absence of these events does not guarantee you are safe. It means the KDC has not encountered the specific conditions that trigger them yet. You still need to proactively audit.
Query Active Directory Directly (But Use the Right Queries)
Your first instinct might be to query AD for every account with a null or zero msDS-SupportedEncryptionTypes attribute. You can do that:
Get-ADObject -Filter {(objectClass -eq "user" -or objectClass -eq "computer")} -Properties msDS-SupportedEncryptionTypes |
Where-Object { $_."msDS-SupportedEncryptionTypes" -eq $null -or $_."msDS-SupportedEncryptionTypes" -eq 0 } |
Select-Object Name, ObjectClass, DistinguishedName, msDS-SupportedEncryptionTypes
But do not panic when that query returns what looks like every account in your domain. It probably will. As we explained above, a null msDS-SupportedEncryptionTypes attribute on regular user accounts is completely normal and does not mean those accounts only have RC4 keys. If the password was set on a Server 2008 or later DC, AES keys exist for that account regardless of what the attribute says.
The accounts you actually need to focus on are more specific. Run these targeted queries instead.
Service accounts with SPNs registered (these are your Kerberoasting targets and the accounts most at risk):
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
Select-Object Name, ServicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet
Computer accounts, sorted by password age so you can see the oldest (and riskiest) first:
Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes, PasswordLastSet, OperatingSystem |
Where-Object { $_."msDS-SupportedEncryptionTypes" -eq $null -or $_."msDS-SupportedEncryptionTypes" -eq 0 } |
Select-Object Name, OperatingSystem, PasswordLastSet, msDS-SupportedEncryptionTypes |
Sort-Object PasswordLastSet
The red flags in those results are service accounts with SPNs whose passwords have not been reset in years, and computer accounts running older operating systems with old PasswordLastSet dates.
Accounts That Deserve Special Attention
Beyond the general queries, there are a few specific accounts that commonly show up in health care AD environments and need individual attention.
AZUREADSSOACC (Azure AD Seamless SSO). If your organization uses Azure AD Seamless Single Sign-On (where domain-joined users automatically sign into Microsoft 365 without a password prompt), your domain has a computer account named AZUREADSSOACC. Historically, this account was created with RC4 encryption by design, and it is actively issuing Kerberos tickets. If it is still RC4-only, it will break after the April enforcement, and your users will start getting password prompts for Microsoft 365 where they previously had none.
Check it:
Get-ADComputer -Identity "AZUREADSSOACC" -Properties msDS-SupportedEncryptionTypes, PasswordLastSet |
Select-Object Name, msDS-SupportedEncryptionTypes, PasswordLastSet
If msDS-SupportedEncryptionTypes is null or 0 and PasswordLastSet is old, you need to roll this key over. This is not a simple password reset because the key has to be coordinated between your on-premises AD and Entra ID. Microsoft has a documented process for this through the Entra Connect (formerly Azure AD Connect) wizard or via PowerShell. Search for Microsoft's documentation on rotating the Seamless SSO decryption key and follow that procedure specifically.
krbtgt. The built-in Kerberos Ticket Granting Ticket account will always show up in your queries with null or zero for msDS-SupportedEncryptionTypes. That is normal and not a concern for the RC4 enforcement change specifically, since the KDC handles krbtgt specially. However, while you are looking at it, check when it was last reset:
Get-ADUser -Identity "krbtgt" -Properties PasswordLastSet |
Select-Object Name, PasswordLastSet
Microsoft recommends rotating the krbtgt password every 180 days as general security hygiene. Most organizations do not do this, and many AD administrators are not aware of the recommendation. If your PasswordLastSet date is more than a year old, it is worth scheduling a rotation. The process requires care because krbtgt is the account the KDC uses to encrypt and sign every Kerberos ticket in your domain. We will be publishing a dedicated article walking through the safe rotation process for health care environments in the near future.
SQL Server service accounts. If you run SQL Server (for your EMR database, for Configuration Manager, for reporting, etc.) under a domain service account rather than a managed service account, those accounts commonly have SPNs registered and their passwords may not have been reset in a very long time. These are prime candidates for both the RC4 enforcement break and Kerberoasting attacks.
Application service accounts. EMR systems, interface engines, print services, backup services. Any domain account running a service with an SPN registered is worth checking.
Check Group Policy
Look at your domain-wide Kerberos encryption configuration:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos
If this policy is configured and set to only allow AES128 and AES256, you are already in better shape than most. If it includes RC4_HMAC_MD5, or if it is not configured at all, you need to look deeper.
Also check the domain controller registry directly:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC\DefaultDomainSupportedEncTypes
If this value exists and is set to 0x18 (decimal 24), your domain controllers are already defaulting to AES-SHA1 only and the April update will not change your behavior.
Use Microsoft's Detection Scripts
Microsoft has published PowerShell scripts in the Kerberos-Crypto GitHub repository specifically for this purpose:
- List-AccountKeys.ps1 queries the Security event log on your domain controllers to enumerate the encryption keys available for each account.
- Get-KerbEncryptionUsage.ps1 identifies the Kerberos encryption types actually being used. Run it with the -Encryption RC4 parameter to find all requests currently using RC4.
What to Do If You Are Affected
The good news is that remediation for most accounts is straightforward. The not-so-good news is that a few of these need a specific process, especially in health care environments where downtime directly affects patient care.
Reset Account Passwords
For most accounts, the fix is a password reset. When you reset a password on a domain controller that supports AES (anything Windows Server 2008 or later), the KDC generates AES keys for that account automatically.
For computer accounts, run this on the affected machine:
Reset-ComputerMachinePassword -Server "YourDC.domain.local"
For service accounts, reset the password and update it everywhere the account is used. This means you need to know every place that service account password is configured, which is why service account management should never be left to tribal knowledge.
Explicitly Set Encryption Types
If you want to explicitly set the encryption type for an account to AES-SHA1 only:
Set-ADUser -Identity "ServiceAccountName" -Replace @{"msDS-SupportedEncryptionTypes"=24}
The value of 24 (0x18 in hex) corresponds to AES128 + AES256. For computer accounts, use Set-ADComputer with the same attribute update.
For service accounts, the recommended approach is to set the encryption type first, then reset the password. Setting the attribute tells the KDC what encryption types to use; resetting the password generates the actual keys.
Updating SQL Server Service Account Passwords the Right Way
If your SQL Server service accounts show up in your audit (and they probably will), there is a specific process for updating the password. Do not use the Windows Services console (services.msc) for this. It will update the logon credentials, but it will not update the ACLs and permissions that SQL Server manages internally for that account.
Use SQL Server Configuration Manager instead. This is the official supported method.
- Open SQL Server Configuration Manager on the SQL Server. (On newer versions, search for "SQLServerManager" or find the MMC snap-in directly. The snap-in name varies by SQL version: SQLServerManager16.msc for SQL 2022, SQLServerManager15.msc for SQL 2019, and so on.)
- Click on SQL Server Services in the left pane.
- Right-click the SQL Server service instance, click Properties.
- Go to the Log On tab.
- Enter the new password in both the Password and Confirm password fields. Do not change the account name, just the password.
- Click OK. SQL Server Configuration Manager will update the service credentials and restart the service.
The reason this matters: SQL Server Configuration Manager also handles updating the service SID, the registry entries SQL uses internally, and the permissions on SQL-specific resources like certificate private keys and the error log directory. Using services.msc skips all of that, and you can end up with subtle permissions mismatches that surface later as random failures in things like encrypted connections, backups, or transparent data encryption.
If you also have SQL Server Agent running under the same service account, it will appear as a separate entry in the SQL Server Configuration Manager services list. Update it the same way at the same time.
Do this during a maintenance window. If SQL Server is the backend database for your EMR, your Configuration Manager site, or your reporting systems, the service restart will briefly take those systems offline. After the service comes back up, verify that your dependent applications are functioning before walking away.
A Note on krbtgt Password Rotation
As mentioned earlier, this is not an April enforcement risk, but if your audit revealed an old krbtgt PasswordLastSet date, put it on your list. The rotation process is straightforward but requires patience. It involves two resets with a replication wait and a TGT cycle window between them. Done carefully, the impact to users is minimal to none. Done hastily (both resets back to back), it will invalidate every outstanding Kerberos ticket in the domain simultaneously. In a clinical environment with active EMR sessions, that would be a very bad day. Health Tech Authority has an in-depth article on krbtgt password rotation, you can find it here.
Check Your File Servers Specifically
If you run FSLogix, identify every computer account and service account involved in your FSLogix SMB share authentication path. Verify that every one of them has AES keys and an explicit msDS-SupportedEncryptionTypes value. Do the same for any file server hosting ePHI or critical departmental data.
Handle Legacy Exceptions
If you have systems that genuinely cannot support AES (and in health care, these do exist), you can explicitly set msDS-SupportedEncryptionTypes on the affected account to include RC4 with AES session keys. Microsoft's recommended value for this scenario is 0x24 (decimal 36), which allows RC4 for ticket encryption while still requiring AES for session keys.
This is a security exception and should be treated as one: documented, time-limited, and tracked for remediation. This configuration still leaves the account vulnerable to CVE-2026-20833, and the long-term recommendation is to migrate to AES entirely.
Microsoft has also set up a contact channel at stillneedrc4@microsoft.com for organizations with persistent RC4 dependencies.
(Microsoft TechCommunity: AskDS)
Test Before April Forces It
You can proactively enable enforcement mode using the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
Set RC4DefaultDisablementPhase to 2 (enforce). Do this in a test environment or on a single DC in a controlled manner to validate that everything still works before April makes it the default everywhere.
A Quick Checklist
For the solo IT admin or small team at a rural health care organization who needs to work through this efficiently, here is the sequence:
- Confirm your domain controllers have the January 2026 cumulative update installed.
- Check the System event log on your DCs for Event IDs 201, 202, 206, and 207.
- Run the targeted PowerShell queries to find service accounts with SPNs and computer accounts with old passwords. Do not panic when the broad query returns all your regular users; that is expected.
- Check the AZUREADSSOACC account specifically if you use Azure AD Seamless SSO.
- Check your krbtgt PasswordLastSet date and schedule a rotation if it has been more than 180 days.
- For affected service accounts, set msDS-SupportedEncryptionTypes to 24, then reset the password and update it in the application. For SQL Server service accounts, use SQL Server Configuration Manager to update the password, not the Windows Services console.
- Reset passwords on affected computer accounts.
- Pay special attention to file servers, especially those hosting ePHI or FSLogix profile stores.
- Document any legacy exceptions where RC4 must remain (set to 0x24 and track for future remediation).
- Consider testing enforcement mode on a single DC before April.
Do Not Wait on This
This is not a change where you can take a "wait and see" approach. The April update will enable enforcement mode by default on all Windows domain controllers. If you have accounts that depend on RC4 fallback and you have not remediated them, authentication will break.
In a health care environment, that could mean clinicians cannot log in, profiles fail to load, EMR sessions do not launch, and file shares carrying patient data become inaccessible. The fix is well-documented, the tools are freely available, and the remediation for most accounts is a password reset. But the runway is short.
If you are a rural health care organization and this feels overwhelming on top of everything else your IT team is juggling, you are not alone. This is exactly the kind of infrastructure work where having a partner who understands both Active Directory and the operational realities of small hospital IT makes a difference. visuaFUSION Systems Solutions works exclusively with rural health care organizations, and our HealthNet managed services model is built around keeping environments like yours current and secure through a cost-sharing approach that does not require a full in-house team.
If you have questions about how this change affects your environment, reach out to us at info@visuafusion.com or (308) 708-7490.
Leveling the IT Playing Field for Rural Health Care Organizations.
Reviewed by visuaFUSION health care IT professionals with experience supporting Critical Access Hospitals and Rural Health Clinics.
This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.
Sources
- Microsoft Support: How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 (KB5073381)
- Microsoft TechCommunity AskDS: What is going on with RC4 in Kerberos?
- Microsoft TechCommunity: What Changed in RC4 with the January 2026 Windows Update and Why it is Important
- Microsoft Learn: Detect and remediate RC4 usage in Kerberos
- Microsoft GitHub: Kerberos-Crypto Repository
- HIPAA Security Rule: 45 CFR 164.312 - Technical Safeguards
- CVE-2026-20833: Microsoft Security Response Center
- Health Tech Authority: Microsoft Is Killing RC4 in Kerberos. If You Have Not Acted, Here Is What You Need To Do Now.
- Log in to post comments