Kerberos CVE-2025-26647: Audit-to-Enforce rollout and NTAuth changes

Microsoft’s April 2025 Kerberos protections — delivered to close CVE‑2025‑26647 — introduced a new operational knob, AllowNtAuthPolicyBypass, that was intended to let administrators audit then enforce stricter certificate-based authentication behavior on domain controllers; the rollout fixed a real privilege‑escalation class flaw, but early enforcement settings triggered a rash of authentication failures (smart card logons, 802.1x Wi‑Fi, Group Policy and third‑party SSO), forcing many admins to fall back to audit mode and wait for follow‑up fixes. (support.microsoft.com) (bleepingcomputer.com)

Background / Overview​

Microsoft assigned CVE‑2025‑26647 to an improper input validation vulnerability in the Kerberos certificate‑based authentication (CBA) flow. The vulnerability allowed an attacker who could obtain a certificate containing a target Subject Key Identifier (SKI) to request a Ticket‑Granting Ticket (TGT) that could be mapped to a user or service in ways the KDC would incorrectly accept. That mapping weakness could let an authenticated adversary escalate privileges by getting a Kerberos ticket that grants more rights than intended. The NVD entry classifies the issue as CWE‑20 (improper input validation) and points to Microsoft’s advisory for details. (nvd.nist.gov)
To reduce the blast radius and give administrators a controlled migration path, Microsoft shipped behavioral changes in April 2025 updates and introduced the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\AllowNtAuthPolicyBypass registry value. The new workflow is phased: initial releases put controllers into an audit posture and log Event ID 45 for problematic certificate mappings; later updates default to enforcing the NTAuth‑store check and eventually remove the ability to fully disable the protection. Administrators can set the registry value to 0 (off), 1 (audit/default for initial rollout), or 2 (enforce). (support.microsoft.com)

---

What actually broke (the observed operational problems)​

Shortly after the April deployments, widespread reports surfaced of authentication and connectivity failures when administrators moved domain controllers to enforcement mode (AllowNtAuthPolicyBypass = 2). The symptoms were consistent across environments:

• Smart card / PKINIT logons were rejected with chain validation errors even when the issuing CA appeared to be trusted.
• 802.1x Wi‑Fi connections and other certificate‑based network authentications failed to complete.
• Group Policy processing and some third‑party SSO integrations reported authentication/authorization failures.
• Legacy appliances or management tools that rely on certificates not present in the NTAuth store could no longer authenticate.

Multiple community reports and incident threads described rolling back the registry to audit mode (value 1) as a practical, quick mitigation while waiting for fixes and guidance. Those operational experiences were widely reported and subsequently acknowledged by Microsoft. (yomotherboard.com, bleepingcomputer.com)

Why enforcement triggered failures​

Enforcement (value 2) instructs the KDC to deny Kerberos AS‑REQs that use certificates which do not chain to a CA listed in the domain’s NTAuth store when an altSecID mapping (for example, an SKI mapping) exists. Many enterprise and device certificates are issued by internal or third‑party CAs that are present in the machine or root store but not explicitly present in NTAuth. Because the policy change tightened the mapping rules, certain legitimate authentication flows suddenly failed until the issuing CAs were added to NTAuth or certificate usages were corrected. Microsoft’s advisory explicitly warns that enforcement can cause outages for controllers servicing self‑signed or otherwise non‑NTAuth chained certificates. (support.microsoft.com)

---

Technical deep dive: how CVE‑2025‑26647 ties to certificate mapping and the NTAuth store​

Kerberos certificate‑based authentication (PKINIT / CBA) lets a user or service present an X.509 certificate to the KDC to obtain Kerberos tickets. When certificates are used to represent identities, the Key Distribution Center must be careful about which certificate authorities are trusted to mint identity assertions that map to domain principals.
The attack path for CVE‑2025‑26647 can be summarized:

• An attacker obtains a certificate with a Subject Key Identifier (SKI) that the KDC can match to an altSecID attribute on a domain account or service principal.
• Because the mapping logic did not enforce that the issuing CA be present in the domain NTAuth store, the KDC could accept the certificate as authoritative and issue a TGT for the mapped principal.
• The attacker uses that TGT to impersonate the mapped account, potentially obtaining elevated access.

Microsoft’s fixes alter the KDC behavior so that when altSecID mappings exist the KDC also validates the issuing CA against the NTAuth store; this removes the ability to map arbitrary certificates issued by untrusted CAs, closing the improper input validation vector. The change is a behavior hardening fix rather than a code rewrite; it relies on policy enforcement that can be audited first, then enforced once administrators have remediated certificate chains in their environment. (support.microsoft.com, nvd.nist.gov)

altSecID, SKI and NTAuth: the concrete elements administrators must understand​

• altSecID attributes: Active Directory allows mapping certificates to principals using several certificate attributes (X509SKI, X509IssuerSerialNumber, etc.). These are convenient but rely on the KDC’s trust model to be secure.
• Subject Key Identifier (SKI): A certificate metadata field frequently used as the mapping key for altSecID. If an attacker can obtain or manipulate a cert with the same SKI or engineer a collision scenario, mapping-based attacks become feasible.
• NTAuth store: An AD store of certificate authorities explicitly trusted to mint logon certificates. The new enforcement ensures that certificate chains must root in this store for mappings that use altSecID to be accepted. (support.microsoft.com)

---

Timeline and Microsoft’s phased rollout​

Microsoft published the initial protections in updates released on or after April 8, 2025. That initial phase sets the default to Audit (AllowNtAuthPolicyBypass = 1) in updated controllers, logging Event ID 45 when the KDC sees a potentially unsafe certificate mapping. Administrators are instructed to monitor Event ID 45, remediate certificate chains, and only set the registry to enforcement (2) after confirming all legitimate CAs are present in NTAuth. (support.microsoft.com)
Key milestones documented by Microsoft and independent trackers:

• April 8, 2025 — Initial deployment: Audit mode, eventing (Event ID 45) enabled. (support.microsoft.com)
• Early May 2025 — Operational reports of authentication problems surfaced; admins used audit mode and temporary workarounds. (yomotherboard.com, bleepingcomputer.com)
• July 2025 — Microsoft’s “enforced by default” phase began for updates released on or after early July; the registry still allowed movement back to audit but the default behavior tightened. (m365admin.handsontek.net, support.microsoft.com)
• July–October 2025 — Microsoft published follow‑up cumulative updates to address compatibility problems and published KB articles and health advisories (for example, KB5057784 and later cumulative fixes). Administrators were urged to patch and follow the audit→enforce workflow. (west.jcteams.info, bleepingcomputer.com)

---

Real‑world impact and ecosystem ripple effects​

The change did what it intended to do — close a privilege‑escalation vector tied to certificate mapping — but enforcement revealed how brittle some production environments are around certificate trust configuration.

• Enterprise risk: Organizations with heterogeneous PKI deployment models (internal PKI plus vendor devices with embedded certs, appliance CAs, or cloud‑issued certificates) were most likely to see disruption. Devices that rely on local trust chains not present in NTAuth suddenly stopped functioning.
• Identity stacks and SSO: Federated SSO products, VPNs using certificate authentication, and NIC/802.1x flows were at risk if their issuing CAs hadn’t been recorded in NTAuth.
• Operational overhead: Many shops lacked a clean inventory of authoritative issuing CAs associated with logon certificates, making the audit window crucial — but also time‑consuming to parse and remediate.

Independent industry reporting and vendor advisories captured the operational fallout. Security and operations teams that flipped enforcement prematurely found themselves chasing registration of multiple CAs into NTAuth or rewriting certificate issuance flows — both time‑consuming processes in large estates. (bleepingcomputer.com)

---

What Microsoft recommended — and what admins actually did​

Microsoft’s recommended sequence is straightforward:

• Update all domain controllers with the Windows update released on or after April 8, 2025.
• Monitor Event ID 45 on DCs to identify certificates and CAs that will fail under enforcement.
• Fix those certificate chains (add the issuing CA to NTAuth or reissue certificates from an NTAuth‑chained CA).
• Once Event ID 45 entries are cleared and certificate paths are fixed, set AllowNtAuthPolicyBypass to 2 to enable enforcement. (support.microsoft.com)

Operational reality pushed many administrators into a more pragmatic short‑term approach:

• Keep AllowNtAuthPolicyBypass at 1 (audit) after installing the update until a thorough certificate inventory and remediation is completed.
• Use temporary compensating controls — isolate devices that can’t be remediated immediately, or limit network exposure of services that require the old mappings.
• Deploy the Microsoft follow‑up cumulative updates that resolved some of the compatibility problems affecting smart card and key‑trust scenarios. Microsoft later published specific KBs that remedied several of the reported outages. (bleepingcomputer.com, west.jcteams.info)

BleepingComputer and other trade outlets documented both the admin guidance and the reality that many organizations needed the “audit window” to avoid service disruption. Those industry writeups documented the rollback strategy (set the key to 1) that administrators used when enforcement prevented legitimate logons. (bleepingcomputer.com)

---

Step‑by‑step remediation checklist for administrators​

• Inventory: Collect a complete list of certificate‑based authentication usage in your environment (smart cards, device authentication, VPNs, RADIUS/802.1x, application service certs).
• Patch: Ensure all domain controllers are updated with the April (or later) updates that include CVE‑2025‑26647 protections. The change only takes effect on patched KDCs. (support.microsoft.com)
• Audit: Leave AllowNtAuthPolicyBypass at 1 (audit) and monitor Event ID 45 on DCs for at least 1–2 weeks to capture production flows.
• Remediate:
• Add the issuing CA to the NTAuth store for any legitimate CA identified in audit events, OR
• Reissue client/device certificates from an issuing CA already present in NTAuth.
• Test: Confirm all authentication flows under a test enforcement configuration before moving to production enforcement.
• Enforce: When the audit log shows no remaining problematic certificates, set AllowNtAuthPolicyBypass to 2 to block unsafe certs and harden the environment.
• If urgent outages occur: set the key to 1 and apply the latest cumulative updates that address known compatibility issues; coordinate with Microsoft support if necessary. (support.microsoft.com, bleepingcomputer.com)

---

Advantages of Microsoft’s phased approach — and the trade‑offs​

Why the change is ultimately a win:

• It closes a practical mapping‑based escalation vector that attackers could exploit to gain elevated Kerberos privileges.
• The NTAuth check restores an explicit trust requirement (the issuing CA must be present in the domain NTAuth store) for sensitive altSecID mappings.
• Audit mode gives administrators a chance to evaluate impact before enforcement.

Why it caused pain:

• The NTAuth store is not always a complete reflection of organizations’ CA ecosystems — operational inertia, mixed PKI management and vendor device CAs mean many legitimate use cases were initially overlooked.
• Tight timing between the April deployment and administrators’ readiness led to premature enforcement attempts and outages.
• The registry flag delegated significant operational responsibility to admins, who had to correctly interpret event logs and fix a variety of certificate chains across diverse systems.

These trade‑offs are common when hardening a long‑standing authentication surface: the security gain is real, but the migration path requires inventory, testing, and careful communication between identity, networking and application teams. (support.microsoft.com, nvd.nist.gov)

---

Known fixes and follow‑up patches​

Microsoft subsequently published cumulative updates and guidance to address the most pressing compatibility problems. Administrators were explicitly told to install the later cumulative updates (examples: KB5060842, KB5060526, KB5060531 and KB5061010 for various Server SKUs) that corrected the immediate auth breakages in many reported scenarios. After the fixes, the recommended posture remained: patch DCs, audit, remediate certs, then enforce. (bleepingcomputer.com, west.jcteams.info)
Industry trackers and community forums reported that the fixes resolved many, but not all, edge cases — particularly where appliances or third‑party products embedded certificates with unusual chain configurations. Where vendors did not publish evidence that their certs would chain to NTAuth, organizations were advised to treat those devices as remediation projects and isolate them until certificates were corrected. (yomotherboard.com, bleepingcomputer.com)

---

Risks and residual caveats — what to watch for​

• Incomplete visibility: If an organization cannot inventory all certificates used for authentication (for example, vendor appliances, IoT devices, or third‑party hosted services), enforcement will likely produce surprises. The audit phase is mandatory for those environments.
• Temporal mismatch: Some Microsoft guidance recommended delaying enforcement until after applying updates released after May 2025 for controllers servicing self‑signed certificate authentication scenarios (notably Windows Hello for Business Key Trust and device public key authentication). Admins who enforced too early saw service disruption. (support.microsoft.com)
• Vendor coordination: Some third‑party vendors were slow to acknowledge or publish guidance, leaving customers to either upgrade or reissue certs themselves.
• Unverifiable anecdotal reports: Community posts and Q&A threads provided useful telemetry about failures, but they are not authoritative; follow Microsoft’s KBs and apply supported cumulative updates rather than ad‑hoc fixes alone. Industry posts are valuable for patterns — but treat them as signals, not official remedies. (yomotherboard.com)

---

Practical recommendations for Windows‑focused operations teams​

• Treat this as a high‑priority identity project following any large‑scale identity hardening change: patch, audit, inventory, remediate, test, enforce.
• Build a certificate inventory and a single source of truth for which issuing CAs are authoritative for logon certificates; script checks for presence in NTAuth where possible.
• Use a staged rollout for enforcement: pilot with a limited set of DCs and selected user/device groups before changing the global posture.
• Communicate widely with application owners and network teams; many problems surfaced because nobody informed downstream teams that certificate validation would become stricter.
• If you operate mixed estates or appliances controlled by vendors, contact those vendors early and demand clear guidance for NTAuth compatibility. If a vendor cannot accommodate NTAuth, plan compensatory isolation. (support.microsoft.com, bleepingcomputer.com)

---

Conclusion​

CVE‑2025‑26647 was a legitimate Kerberos authentication vulnerability that warranted intervention. Microsoft’s behavioral hardening — introducing the AllowNtAuthPolicyBypass audit→enforce workflow and requiring NTAuth‑store rooted certificate chains for altSecID mappings — closes a significant mapping‑based escalation vector. At the same time, the change exposed how many production environments lack disciplined certificate inventory and NTAuth hygiene, which led to real authentication outages during the enforcement phase. The correct operational path is clear: install the updates, remain in audit mode while you inventory and remediate certificate chains, and only move to enforcement after testing and verification. The fixes Microsoft published and the cumulative updates that followed resolved many compatibility problems, but the episode reinforces a perennial lesson: identity hardening is essential, but it demands a careful, collaborative migration plan to avoid breaking critical services. (support.microsoft.com, bleepingcomputer.com, nvd.nist.gov)

---

Additional community context and a reminder: community reports and forum threads chronicled the outage patterns and rollback tactics used by administrators during the April/May 2025 window. Those accounts are valuable for operational color but should be cross‑checked against Microsoft’s KB guidance and the cumulative update notes before making permanent configuration decisions.

---

Source: BornCity Window: Issues with AllowNtAuthPolicyBypass (CVE-2025-26647)? | Born's Tech and Windows World