Window: Issues with AllowNtAuthPolicyBypass (CVE-2025-26647)?

[German]In April 2025, an update was released to close the CVE-2025-26647 vulnerability in Kerberos authentication. A blog reader pointed out to me in mid-July 2025 that the registry value AllowNtAuthPolicyBypass had been introduced. However, he encountered problems related to the key.

CVE-2025-26647: Brief summary

On April 8, 2025, Microsoft published a support article entitled Protections for CVE-2025-26647 (Kerberos Authentication), which deals with closing the Kerberos authentication vulnerability CVE-2025-26647 in Windows Server versions that are still supported. In the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

the REG_DWORD value AllowNtAuthPolicyBypass has been newly introduced. The value must be created manually to ensure security. The possible values are listed below:

If the key is not set (default behavior), the domain controller behaves as if the value is set to 1 (audit mode). This means:

• Kerberos logins continue to work
• Event ID 45 "The Key Distribution Center (KDC) encountered a client certificate that was valid but did not chain to a root in the NTAuth store" is logged in the DC's system event log.

This message in the event log serves as an indication of a potential problem that may lead to an error in the future if the mode is changed to 2 (enforcement).

Phases of implementation

Microsoft has planned three phases for implementation, two of which have already been completed:

• April 8, 2025 – Initial Deployment (Audit Mode):logged in the event log
• July 8, 2025 – Enforced by Default:logged in the event log and insecure authentications blocked (but can be switched back to Audit Mode via registry key)
• October 14, – Enforcement Mode:blocked and can no longer be changed back via registry key.

Enforcement mode will therefore come into effect in October 2025, while the first two phases and dates will have passed.

A reader encountered problems

Blog reader Andy M. wrote to me in an email, "I'd like to address an issue that has been preoccupying me for several days now, and I have a slight suspicion that I'm not alone in this." He then described the above situation with the schedule and addressed problems with the Regkey AllowNtAuthPolicyBypass (CVE-2025-26647).

The environment in which the reader encountered the malfunction or problem includes the following machines:

• DCs: 25x Windows Server 2016 (Version 1607 / Build 14393.8148)
• Affected Windows clients: 24H2 (10.0.26100.4061), 23H2 (10.0.22631.5549), 23H2 (10.0.22631.5624)

The reader states that there are approximately 1,500 clients running in the environment, but as of mid-July 2025, only about 40 devices are affected by problems. Andy wrote: "After we checked all DCs for Event ID 45, we were actually sure that we would switch to enforcement mode in advance – i.e., set AllowNtAuthPolicyBypass = 2."

At this point, the domain controllers were at the June 2025 patch level—the July patch was still missing. However, an administrator can switch to enforcement mode using the registry key mentioned above.

A few minutes after switching to enforcement mode, event log entries immediately appeared in the system log of the DCs:

Source: Kerberos-Key-Distribution-Center
EventID: 21
General: The client certificate for the user COMPANY\xxxxxx$ is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they're attempting to use for smartcard logon. The chain status was : A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider.

The following two events can also be seen in the event log on the affected clients:

Source: Security-Kerberos
EventID: 8
General: The domain controller rejected the client certificate of user @@@CN="CN=G11016004", used for smart card logon. The following error was returned from the certificate validation process: Die Zertifizierungskette wurde richtig verarbeitet, doch wird eines der Zertifizierungsstellen-Zertifikate vom Richtlinienanbieter nicht für vertrauenswürdig gehalten.
Source: GroupPolicy
EventID: 1055
General: The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

It is also no longer possible to run "gpupdate /force" on the affected clients. The following message appears:

C:\Users\mxmustermann>gpupdate /force
The policy is being updated ...
The computer policy could not be updated successfully. The following problems have occurred:
Error processing the group policy. The computer name could not be resolved. This can have at least
one of the following causes:
a) Name resolution error with the current domain controller.
b) Active Directory replication latency (an account created on another domain controller has not replicated to the current domain controller).
The user policy could not be updated successfully. The following problems have occurred:
Error processing the group policy. The computer name could not be resolved. This can have at least
one of the following causes:
a) Name resolution error with the current domain controller.
b) Active Directory replication latency (an account created on another domain controller has not replicated to the current domain controller).
Read the event log to diagnose the error, or run the command "GPRESULT /H GPReport.html" to access information about Group Policy results.

"We haven't received any active complaints from users. But I assume that certain things are simply no longer working properly," wrote Andy. According to him, it is no longer possible to apply for certificates, for example. When applying for certificates via the MMC, an RPC error message appears.

The reader believes that this all points to a malfunction of the registry key in conjunction with the June 2025 patches. The Windows Release Health reports describe exactly this type of behavior, which should be resolved with the June 2025 patches. However, this is not the case in the reader's environment. Here is the Windows Release Health entry:

Windows release health – Microsoft 365 admin center

After installing the April Windows monthly security update released April 8, 2025 (KB5055523) or later, Active Directory Domain Controllers (DC) might experience authentication interruptions when processing Kerberos logons or delegations using certificate-based credentials that rely on key trust via the Active Directory msds-KeyCredentialLink field.

Following these updates, the method by which DCs validate certificates used for Kerberos authentication has changed, and will now require that certificates are chained to an issuing certificate authority (CA) in the NTAuth store. This is related to security measures described in KB5057784 – Protections for CVE-2025-26647 (Kerberos Authentication) [link].

As a result, authentication failures might be observed in Windows Hello for Business (WHfB) Key Trust environments or environments that have deployed Device Public Key Authentication (also known as Machine PKINIT). Other products which rely on this feature can also be impacted. Enablement of this validation method can be controlled by the Windows registry value AllowNtAuthPolicyBypass in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Two scenarios can be observed following installation of the April 2025 Windows monthly security update on authenticating DCs:

– When registry value AllowNtAuthPolicyBypass is unconfigured or set to "1", Kerberos-Key-Distribution-Center event ID 45 is repeatedly recorded in the DC system event log, with text similar to "The Key Distribution Center (KDC) encountered a client certificate that was valid but did not chain to an Issuing CA in the NTAuth store". This is a new event, intentionally logged by DCs servicing authentication requests using unsafe certificates.

Although this event may be logged excessively, please note that related logon operations are otherwise successful, and no other change is observed outside of these event log records.

– When registry value AllowNtAuthPolicyBypass is set to "2", self-signed certificate-based authentication fails. Kerberos-Key-Distribution-Center event ID 21 is recorded in the DC system event log. This is a legacy event logged when certificate-based authentication fails, and is intentionally logged when a DC services an authentication request using an unsafe certificate. The event description text for this event may vary.

Note that if the AllowNtAuthPolicyBypass registry key does not exist, the DC will behave as if the value is configured to "1". The key may be created manually, if it does not exist, and configured as per above. Windows Updates released on and after April 8, 2025 incorrectly log Event IDs 45 and 21 when servicing authentication requests using self-signed certificates that will never chain to a CA in the NTAuth store. Self-signed certificates may be used by the AD PKINIT Key Trust feature in the following scenarios:

– Windows Hello for Business (WHfB) Key Trust deployments [link]
– Device Public Key Authentication [link] (also known as Machine PKINIT).
– Other scenarios that rely on the msds-KeyCredentialLink field, such as smart card products, third-party single sign-on (SSO) solutions, and identity management systems.

Resolution: This issue was resolved by Windows updates released June 10, 2025 (KB5061010), and later. We recommend you install the latest security update for your device as it contains important improvements and issue resolutions, including this one.

The reader summarized his experiences regarding the above issue in connection with DCs and the June 2025 patch status with various Windows clients running different OS builds as follows:

After the "AllowNtAuthPolicyBypass" key is actively set to "2," some end devices malfunction and cannot communicate properly with the DCs. If we reset it to "1," everything works fine.

The reader concludes that this looks like a bug. Question for readers: Can anyone confirm this behavior? The August 2025 updates are now available. Has this behavior been fixed? Or has something else been overlooked?