Probleme mit dem Regkey AllowNtAuthPolicyBypass (CVE-2025-26647)

[English]Im April 2025 gab es ein Update um die Schwachstelle CVE-2025-26647 in der Kerberos Authentifizierung zu schließen. Ein Blog-Leser wies mich bereits Mitte Juli 2025 darauf hin, dass  der Registry-Wert AllowNtAuthPolicyBypass eingeführt wurde. Allerdings ist er auf Probleme in Zusammenhang mit dem Schlüssel gestoßen.

CVE-2025-26647: Kurzer Abriss des Sachverhalts

Von Microsoft gibt es seit dem 8. April 2025 den Support-Beitrag Protections for CVE-2025-26647 (Kerberos Authentication), der sich mit dem Schließen der Kerberos Authentifizierungschwachstelle CVE-2025-26647 unter den noch im Support befindlichen Windows Server-Versionen befasst. In folgendem Registrierungsschlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

wurde der REG_DWORD Wert AllowNtAuthPolicyBypass neu eingeführt. Der Wert muss manuell erstellt werden, um sich abzusichern. Nachfolgend werden die möglichen Werte genannt:

Ist der Schlüssel nicht gesetzt (Standardverhalten) verhält sich der Domain Controller so, als ob der Wert auf 1 steht (Audit-Modus). Das bedeutet:

• Kerberos-Anmeldungen funktionieren weiterhin
• 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" wird im System-Ereignisprotokoll des DCs protokolliert.

Diese Meldung im Ereignisprotokoll dient als Hinweis auf ein potenzielles Problem, das in Zukunft zu einem Fehler führen kann, wenn der Modus auf 2 (Enforcement) umgestellt wird.

Phasen der Umsetzung

Microsoft hat für die Umsetzung drei Phasen vorgesehen, von denen zwei bereits verstrichen sind:

• 8. April 2025 – Initial Deployment (Audit-Modus): hier wird im Event-log protokolliert
• 8. Juli 2025 – Enforced by Default: hier wird im Eventlog protokolliert und unsichere Authentifizierungen geblockt (wäre aber via Registry-Key auch wieder zurück auf Audit-Mode umschaltbar)
• 14. Oktober 2025 – Enforcement Mode: hier wird geblockt und kann nicht mehr  per Registry-Key zurück geändert werden.

Zum Oktober 2025 kommt also der Enforcement-Modus zum Tragen, während die beiden ersten Phasen bzw. Termine verstrichen sind.

Ein Leser stieß auf Probleme

Blog-Leser Andy M. schrieb mir in einer E-Mail "ich greife mal ein Thema auf, welches mich nun schon mehrere Tage massiv beschäftigt und ich die leichte Vermutung habe dass ich hiermit nicht alleine sein kann". Dann schilderte er den obigen Sachverhalt mit dem Zeitplan und ging auf Probleme mit dem Regkey AllowNtAuthPolicyBypass (CVE-2025-26647) ein.

Die Umgebung, in der der Leser auf Fehlverhalten bzw. Problem stieß, umfasst folgende Maschinen:

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

Der Leser gibt an, dass in der Umgebung ca. 1.500 Clients laufen, wobei davon jedoch stand Mitte Juli 2025 nur ca. 40 Geräte von Problemen betroffen sind. Andy schrieb dazu: "Nach dem wir alle DCs auf die Events ID 45 geprüft haben, waren wir uns eigentl. sicher dass wir nun schonmal vorab in den Enforcement-Mode umschalten – sprich den AllowNtAuthPolicyBypass = 2 setzen."

Die Domain-Controller waren zu diesem Zeitpunkt auf dem Patchstand von Juni 2025 – der Juli-Patch fehlt noch. Aber ein Administrator kann ja mittels des oben erwähnten Registry-Key schonmal auf den Enforcement-Mode umstellen.

Ein paar Minuten nach der Umstellung auf Enforcement-Mode, sind sofort Eventlog-Einträge im Systemlog der DCs aufgetaucht:

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.

Auch auf den betroffenen Clients sieht man im Eventlog folgende zwei Events:

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).

Ebenfalls ist auf den betroffenen Clients kein "gpupdate /force" mehr möglich. Hierbei kommt folgende Meldung:

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.

"Aktive Beschwerden von Usern haben wir keine. Aber ich gehe davon aus dass gewisse Dinge einfach nicht mehr sauber laufen." schrieb Andy. Das Beantragen von Zertifikate ist  laut seiner Aussage beispielsweise nicht mehr möglich. Beim Beantragen der Zertifikate über die MMC kommt eine RPC-Fehlermeldung.

Der Leser meint, dass das alles ein wenig auf ein Fehlverhalten des Registry-Keys im Zusammenspiel mit den Juni 2025-Patches hindeutet. In den Windows-Release-Health Meldungen werde genau ein solches Verhalten beschrieben, was aber mit dem Juni 2025-Patches erledigt sein soll. In der Umgebung des Lesers ist das jedoch nicht der Fall. Hier mal der Windows release health Auszug:

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.

Der Leser hat seine Erfahrungen bezüglich des obigen Sachverhalts im Zusammenhang mit DCs und Patch-Stand Juni 2025 mit verschiedenen Windows-Clients mit verschiedenen OS-Builds so zusammengefasst:

Nachdem der Key "AllowNtAuthPolicyBypass" aktiv auf "2" gesetzt wird, sind manche Endgeräte fehlerhaft und können nicht sauber mit den DCs kommunizieren. Stellen wir wieder zurück auf "1", ist alles gut.

Der Leser zieht den Schluss, dass dies nach einem Bug ausschaut. Frage an die Leserschaft: Kann jemand das Verhalten bestätigen? Wir haben inzwischen ja bereits die August 2025-Updates verfügbar. Ist dort das Verhalten eventuell behoben? Oder wurde etwas anderes übersehen?