Microsoft’s newest server release is already generating painful operational lessons: administrators who add a Windows Server 2025 domain controller into a mixed Active Directory environment containing older DCs can trigger widespread authentication breakage — machine account password rotations fail, domain logons stall, and remediation can require awkward, high‑risk edits or a full DC upgrade to regain stability. The problem surfaced in community reports and a German technical blog post describing real incidents, and traces back to how Kerberos encryption selection and RC4 handling interact across mixed OS generations.
Active Directory authentication relies heavily on the Kerberos protocol and on a set of machine and service account keys that are rotated on a regular schedule. Historically Windows environments tolerated a degree of implicit negotiation and legacy fallbacks — most notably the RC4-HMAC cipher — when endpoints and domain controllers had mismatched encryption settings. Since late 2022 and into 2024–2025, Microsoft has hardened Kerberos defaults and introduced behavioral changes that make encryption type selection explicit: domain controllers now honor msDS‑SupportedEncryptionTypes and related registry and domain defaults rather than quietly adding RC4 to preserve compatibility. That hardening improves security but reduces implicit fallbacks, which can surface painful interoperability problems in mixed environments. At the same time, Windows Server 2025 includes additional protocol hardenings and default behavior changes intended to reduce legacy cipher use (including a roadmap to phase out RC4). Those changes were rolled into security updates in 2025 and led to several tracked Active Directory and Kerberos‑related incidents — some of which Microsoft fixed via timely updates, and some of which were visible first in real‑world troubleshooting threads and independent blogs.
Source: BornCity Windows Server 2025 as DC: Avoid in mixed environments (RC4 issue) | Born's Tech and Windows World
Background / Overview
Active Directory authentication relies heavily on the Kerberos protocol and on a set of machine and service account keys that are rotated on a regular schedule. Historically Windows environments tolerated a degree of implicit negotiation and legacy fallbacks — most notably the RC4-HMAC cipher — when endpoints and domain controllers had mismatched encryption settings. Since late 2022 and into 2024–2025, Microsoft has hardened Kerberos defaults and introduced behavioral changes that make encryption type selection explicit: domain controllers now honor msDS‑SupportedEncryptionTypes and related registry and domain defaults rather than quietly adding RC4 to preserve compatibility. That hardening improves security but reduces implicit fallbacks, which can surface painful interoperability problems in mixed environments. At the same time, Windows Server 2025 includes additional protocol hardenings and default behavior changes intended to reduce legacy cipher use (including a roadmap to phase out RC4). Those changes were rolled into security updates in 2025 and led to several tracked Active Directory and Kerberos‑related incidents — some of which Microsoft fixed via timely updates, and some of which were visible first in real‑world troubleshooting threads and independent blogs. What administrators are seeing: symptoms and scope
The most consistent symptom set reported by administrators in community threads and in a focused blog post is:- Machine accounts fail to rotate their computer passwords (the scheduled background password changes that keep secure channels valid stop succeeding).
- Domain logins fail intermittently or unpredictably across member servers and endpoints; the failures can be server‑specific and move around the estate.
- Kerberos errors such as Event ID 27 / 21 / 45 / 4771 indicating unsupported encryption types or certificate validation failures are observed in DC system logs.
- The issue frequently surfaces only after a Windows Server 2025 machine has been added as a domain controller into a forest that still has older DCs. Administrators report a “mixed environment” lock‑in: removing 2025 DCs is disruptive, and leaving them in place breaks client authentication unless the entire DC estate is aligned.
The technical root cause (how Kerberos encryption selection breaks mixed DCs)
Two related mechanics explain why adding a 2025 DC to a mixed forest can cause the observed failures:- Explicit encryption settings are now honored — after recent security hardenings Windows no longer silently “add” RC4 when it would help interoperability. If an account or machine has msDS‑SupportedEncryptionTypes set to a value that allows RC4, and a domain controller or GPO effectively removes RC4 on DCs, the Kerberos KDC behavior can become inconsistent across DCs. That leads to KDC responses that clients and machines can’t use, and to failed password rotations because the KDC refuses the selected encryption type. Microsoft has documented this exact class of interoperability fallout in guidance for administrators preparing for Kerberos protocol changes.
- Windows Server 2025 started to tighten default RC4 usage — Microsoft has signalled a plan to disable RC4 by default in new deployments and introduced changes that make enforcement stricter. When a 2025 DC is present, its KDC may act differently from older DCs — and if controllers disagree about which encryptions are allowed (or if a GPO globally disallowed RC4 via msDS‑SupportedEncryptionTypes or DefaultDomainSupportedEncTypes), the KDC may choose an encryption type that the client/machine or other DCs cannot process. That mismatch manifests as machine password reset failures and intermittent logons.
What Microsoft has said and patched so far
Microsoft’s Windows Server Release Health and support documentation confirm several Kerberos‑related problems and the presence of fixes in the 2025 update cadence:- Microsoft documented a Kerberos certificate‑based authentication issue (CVE‑2025‑26647) and provided guidance and mitigations, then resolved the specific event‑logging/authentication behavior in updates released June 10, 2025. Administrators were advised to update DCs to fixes shipped on or after that date.
- A broader set of Kerberos hardenings (dating back to the Nov 2022 Kerberos changes and continued into 2024–2025) changed how encryption negotiation defaults behave. Microsoft’s KB guidance explains that updates released on or after Nov 8, 2022 require administrators to verify that all devices support a common Kerberos encryption type and to explicitly set msDS‑SupportedEncryptionTypes where necessary. These guidance documents also provide the PowerShell queries and values you should use to discover problematic accounts.
Confirmed real‑world workarounds (what actually helped admins)
Field reports and community threads — including the German blog that aggregated the incidents — show several practical approaches that administrators used to stop immediate outages. These are workarounds, not always ideal, and many carry trade‑offs.- Reset the machine account password locally
Logging onto the affected server as a local administrator and running the PowerShell cmdlet to reset the machine account password often restored a working authentication state for that server:
Reset-ComputerMachinePassword -Server <DCname> -Credential (Get-Credential)
This forces the local machine to negotiate a fresh password change with a chosen DC and can restore immediate access. The Reset‑ComputerMachinePassword cmdlet is the documented Microsoft approach for repairing machine‑to‑domain trust problems. However, it treats a symptom and does not resolve the underlying DC‑to‑DC encryption misalignment. - Temporarily allow RC4 again to reestablish service
In reported incidents where a GPO or directory setting had globally disallowed RC4, restoring RC4 allowed older systems and service accounts to authenticate again and stopped the immediate failures. This often required advanced ADSIEdit work to repair GPO or msDS settings. This fix restores compatibility but weakens cryptographic posture and must be treated as a temporary emergency measure only. Community posts and Microsoft Q&A threads show multiple examples where re‑allowing RC4 ended outages at the cost of immediate security regressions. - Upgrade all domain controllers to Windows Server 2025
Several administrators reported that upgrading every DC to the 2025 generation eliminated the inconsistency: once all KDCs were on the same OS and honor the same defaults, the Kerberos behavior stabilized and machine account password rotation resumed. This is a heavy, high‑impact remediation (and in some environments not feasible) but it is an effective way to remove mixed‑version interoperability edges. Community accounts indicate this approach solved the issue where incremental fixes failed.
Recommended action checklist (what every AD admin should do now)
- Do not add a Windows Server 2025 machine as a DC into a production mixed environment without testing. Treat any addition as a major change that requires lab validation against your actual account/service inventory. The BornCity field reports and multiple community threads show this is a high‑risk operation.
- Inventory accounts and services that still rely on RC4 or have explicit msDS‑SupportedEncryptionTypes set. Use Microsoft guidance and PowerShell to find accounts and service principals that may enforce RC4. Example discovery guidance from Microsoft includes the Get‑ADObject filters for msDS‑SupportedEncryptionTypes. Do this before changing GPOs or installing upgrades.
- Example (from Microsoft guidance):
Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18" - Patch domain controllers quickly with Microsoft updates released on or after June 10, 2025 (and earlier relevant fixes). Microsoft fixed known Kerberos certificate‑based authentication issues in the June 10, 2025 update; ensure all DCs have the latest Windows updates to reduce the attack surface and avoid known bugs. Check the Windows Server Release Health page for the most current advisories.
- Avoid globally disabling RC4 at the domain level until you have validated every client, service account, gMSA, and non‑Windows endpoint that interacts with DCs. If you must temporarily enable/disable settings for testing, do so in a staging OU or a blocked test domain. Community threads demonstrate that a global disable can produce catastrophic outages if non‑Windows systems or gMSAs still require RC4.
- If you encounter immediate failures, use Reset‑ComputerMachinePassword as a targeted remediation while you investigate. It’s a documented command that restores machine trust for the local machine by forcing a new password change with a specified DC. Reboot the host after the reset if required.
- Plan a coordinated DC upgrade or consolidation path when feasible. In many cases the long‑term solution is a full rollout to a modern, consistently patched set of DCs that share the same Kerberos negotiation behavior. This reduces future compatibility surprises and is the preferred remediation where time and resources permit.
Practical PowerShell checks and values to use (quick reference)
- Detect accounts explicitly allowing RC4 or using AES-only masks (examples based on Microsoft guidance):
- RC4 bitmask = 4; AES128 = 8; AES256 = 16; AES-only = 24; AES+RC4 = 28. Use these when interpreting msDS flags.
- Example: list service accounts and machines with msDS‑SupportedEncryptionTypes set
Code:Get-ADServiceAccount -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object { $_.'msDS-SupportedEncryptionTypes' -ne $null } | Select-Object Name, msDS-SupportedEncryptionTypes - Example: reset machine password for local recovery
Reset-ComputerMachinePassword -Server "DC01" -Credential (Get-Credential) - Validate KB and patch status on DCs using your patch management tool and consult the Windows Server Release Health page for targeted KB numbers and resolved issues.
Strengths of Microsoft’s approach — and where it traded compatibility for security
- Better security posture. Moving away from RC4 and enforcing explicit encryption type handling reduces the attack surface and helps close long‑standing Kerberos weaknesses. Microsoft’s Kerberos hardening is driven by real CVEs and by the need to remove legacy, weak ciphers. When applied with complete inventory and testing, the hardening meaningfully improves security.
- Clear migration guidance exists. Microsoft has published actionable KBs and guidance describing how to detect at‑risk accounts, the bit flags to use, and the recommended transition steps. Administrators who follow those guides can achieve a safe, planned migration.
- Operational fragility in mixed estates. Environments that are heterogeneous — particularly those that include non‑Windows appliances, appliances running Samba, or legacy Linux services with specific Kerberos settings — are liable to suffer outages if RC4 is disabled prematurely. Real outages and complicated recoveries were reported by administrators in the field.
- Visibility and audit gaps. Many organizations do not know which service accounts, gMSAs, or third‑party appliances carry explicit encryption settings. Without comprehensive discovery, a single GPO change or the addition of a modern DC can have cascading effects.
- Timing & communications. Windows Server 2025 introduced behavior changes that administrators may not expect; the rollout of fixes and advisories can lag the earliest field reports, leaving practitioners to rely on community troubleshooting before official guidance is updated. That gap is where the most damaging outages occur.
Caveats and unverifiable claims
- Several community posts and the blog aggregation cite individual stories involving job losses and dire operational tales. Those human stories are real in the sense that they reflect real consequences, but their particulars (such as employment outcomes) cannot be independently verified here and should be treated as illustrative rather than categorical evidence. The technical symptoms and fixes are widely corroborated; anecdotal narratives about non‑technical fallout are less verifiable.
- The early blog post characterized the Windows Server 2025 behavior as an unacknowledged bug. Microsoft has acknowledged and fixed several Kerberos‑related issues in the 2025 update stream, but that does not eliminate the need for careful planning when introducing a 2025 DC into an environment with older controllers. Where the blog describes an ongoing, unpatched bug at the time it was written, follow up against Microsoft’s Release Health entries and KB articles to validate whether a given fault remains open.
Bottom line for AD administrators
- Short answer: Avoid adding Windows Server 2025 machines as domain controllers into mixed‑version Active Directory forests without a validated, tested migration plan. The combination of Kerberos hardening and RC4 deprecation can break machine password rotation and cause intermittent domain logins in heterogeneous estates.
- Medium‑term plan: Inventory msDS‑SupportedEncryptionTypes across accounts and services, patch all DCs with the June 10, 2025 and later updates (and the latest cumulative fixes), and perform a staged migration or coordinated upgrade of DCs to remove mixed‑version edges. Use the Reset‑ComputerMachinePassword cmdlet for urgent recovery on affected servers while you diagnose the root cause.
- Longer term: Treat Kerberos encryption hardening as a permanent part of AD lifecycle management: include encryption compatibility checks in change control, test new OS releases in a mirrored lab with realistic appliance and service account configurations, and maintain an accurate inventory of service principals and encryption flags.
Source: BornCity Windows Server 2025 as DC: Avoid in mixed environments (RC4 issue) | Born's Tech and Windows World
