[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:
|
Wert
|
Modus
|
Beschreibung
|
|
0
|
Deaktiviert
|
Die NTAuth-Prüfung wird nicht durchgeführt. Kein Schutz aktiv.
|
|
1
|
Audit-Modus
|
NTAuth-Prüfung wird durchgeführt. Bei Problemen wird nur ein Warn-Event (ID 45) protokolliert. Standardverhalten ab 8. April 2025, wenn der Key nicht gesetzt ist.
|
|
2
|
Enforced-Modus
|
NTAuth-Prüfung wird durchgeführt. Bei Fehlern wird die Anmeldung verweigert. Event-ID 21 wird protokolliert.
|
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\KdcTwo 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?
MVP: 2013 – 2016
Ich habe das ca. seit April bei ca 20 von 1800 Rechnern, die mit Selbstsignierten Zertifikaten beglückt wurden. Die verursachenden Admins haben keine Nebenwirkungen und ich hatte zunächst das Reporting von 45 und 21 für diese Rechnergruppe weggefiltert – das ist jetzt wieder an.
Die Registry-Einstellungen wurden diesbezüglich an den 2019 DCs nicht eingestellt, so dass ich vorsichtshalber mal mit Beeinträchtigungen ab 14. Oktober 2025 rechne.
Falls ich die Tage dazu komme, es mit Einstellung 2 zu provozieren und dabei was erlebe, melde ich mich gerne hier.
Danke für die Warnung.
So wie auch Ralf weiter unten anmerkt, habe ich zwischenzeitlich gelesen, dass das Enforcement bei mir – als jemand der nie einen Key gesetzt hat – seit dem 8. Juli 2025 scharf ist.
Die erwähnten Betroffenen erzeugen zwar an den DCs die Meldungen 45 und 21, haben in deren Selbstbaulösung mit deren mutmaßlich dafür verwendeten eigenen CA scheinbar keine Probleme.
Mehr kann ich dazu hier nicht liefern. Ich klinke mich aus.
Wir erhalten Eventlogmeldungen für selbstsignierte Zertifikate, die im Zertifikatspeicher des DCs liegen, aber für Kerberos Authentifizierung gar nicht relevant sind. Ein Teil der Clients meldet fehlgeschlagene Smartcard-Anmeldungen. (Wir nutzen keine Smartcards.) Die schuldigen selbstsignierten Zertifikate installiert Microsoft offenbar eigenmächtig auf alle Clients mit Entra Hybrid Join. Gemäss den ersten Erfahrungen würde ich persönlich den Key niemals manuell scharf schalten.
Falls keine Zertifikate / SmartCards zur Anmeldung im Spiel sind ggfs. testweise einmal https://gpsearch.azurewebsites.net/#10920 deaktivieren. Dann sollte im Security Log aber auch etwas bzgl. Kerberos (pre) authentication zu finden sein. Ggfs. mit Event-Id 4771.
If an organization had previously issued certificates from a CA not added to NTAuth—or if third-party identity integrations circumvented this store—logons that once succeeded now fail ..
am besten finde ich die letzte Überschrift:
Conclusion: Security Gains Meet Business Reality
https://windowsforum.com/threads/april2025-windows-server-update-causes-authentication-failures-how-to-mitigate-fix.365649/
Die Frage ist, ob in dem AD z.b. noch alte CAs rumliegen, oder die vorhandene nicht eingetragen wurde, da sie nicht "AD integriert" ist.
https://github.com/MicrosoftDocs/SupportArticles-docs/blob/main/support/windows-server/certificates-and-public-key-infrastructure-pki/import-third-party-ca-to-enterprise-ntauth-store.md
War in meiner Umgebung auch betroffen, einziger Workaround den ich bisher gefunden habe, war komplett neu aufsetzen.
lt. DC wird ein Certificate mit Thumbprint erkannt, was ich lokal nicht finden kann…meine Vermutung ist, dass das irgendwie mit TPM und Credential Guard zu tun hat, da liegen die Certs ja nicht im Machine Store und die Funktion aktiviert sich bei Win11 24H2 automatisch.
Äh … Nein. Es ist ein Zertifikat im AD, das dort in der Config PArtition verankert ist. Wahrscheinlich eine alte nicht ordentlich decommisionierte CA.
Nein, ist es 100% nicht da ist kein solches Cert im AD, es geht um Certs die der Client meldet nicht umgekehrt, die Clients sind auch noch nicht so alt (Win11 24H2 LTSC heuer erst installiert) …spannende wilde Spekulation.
Wenn es wirklich eine CA betreffen würde, wären viel mehr Clients betroffen und nicht nur eine handvoll.
Weiß nicht ob ich mir überhaupt die Mühe machen sollte, bei so viel Arroganz mancher hier, aber vielleicht hilft's ja doch Mal jemanden.
https://learn.microsoft.com/en-us/windows-server/security/kerberos/domain-joined-device-public-key-authentication
https://learn.microsoft.com/en-us/windows/release-health/resolved-issues-windows-10-1809-and-windows-server-2019#logon-might-fail-with-windows-hello-in-key-trust-mode-and-log-kerberos-events
Danke, hilft auf jeden Fall den Willigen.
Aus dem 2ten Link:
[…] and will now require that certificates are chained to an issuing certificate authority (CA) in the NTAuth store
Du hast ein Zertifikt, bzw. der Client verwendet ein Zertifikat, das nicht vertrauenswürdig aufgelöst werden kann.
Wenn es "viele" betrifft, dann hat der Client das Zertifikat idR von einer CA erhalten und diese ist nicht im genannten AD Attribut eingetragen.
Ansonsten kann/darf der Fehler nur bei Authentication mit Windows Hello for Business (WHfB) auftreten.
warum wird der erste Link komplett ignoriert? Im zweiten Link steht auch noch ganz klar welche zusätzliche Ursachen sein können, warum hältst du so an deinem narrativ fest ohne meine Umegebungen zu kennen…unglaublich so etwas
"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
Device Public Key Authentication (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."
.. ich halte daran fest, weil der Fehler dann in Verbindung mit WHfB steht, was die wenigsten einsetzen.
der Rest ist Okhams Messer:
am Client gibt es ein Zertifikat, das er erhalten hat, wohl aus einer CA, die nicht mehr trusted ist, aus welchem Grund auch immer. oder der Client hat historisch mehrere Zertifikate aus historisch diversen CAs. alle sind gültig mit Client Authentifizierung, der Login Prozess wählt aber das falsche aus.
Alte CAs im AD, alte Zertifikate am Client und kein cleanup geben ein sehr logisches Bild, das wahrscheinlicher ist, als das jetzt alle auf einmal WHfB nutzen würden oder Yubikey etc
faktisch einfach nur falsch, Device Public Key Authentication hat NICHTS mit WHfB zu tun.
Die 2 anderen Ursachen habe ich ja extra herausgeschrieben, die auch im verlinkten Artikel angeführt sind: Bei mir sind es die Device Public Key Authentication (also known as Machine PKINIT)
wenn es um alte CAs im AD ginge, dann wären alle Clients betroffen. Wären es alte Certs am Client wären es keine neu aufgesetzten Computer von heuer, außerdem wären die fehlerhaften Certs dann im Machine und/oder user store und beides trifft nicht zu.
Beliebte Falle, über die ich mehr als einmal gestolpert bin: In der MMC-Ansicht der Zertifikate unter Ansicht – Optionen den Haken "archivierte Zertifikate" setzen. Defaultmäßig werden Zertifikate, deren Gültigkeitszeitraum abgelaufen ist ausgeblendet.
https://www.normanbauer.com/2022/01/10/unarchive-archived-certificates-with-powershell/
Fritz, ich hatte Hoffnungen in deinen Post gesetzt, aber auch mit der Einblendung der abgelaufenen Zertifikate, wird nichts angezeigt, was auf eine Ursache hindeutet.
Wir haben an einigen Lokationen auch das Problem und es ist kein Muster zu erkennen, dass Gerät A in den Fehler läuft und Gerät B nicht. Es ist zum verrückt werden.
Wir hoffen nicht, dass der einzige gangbare Weg, wie ihn ARC4 beschreibt die Neuinstallation ist.
Nach meinen Erfahrungen gab es da Probleme die aber mit den Windows Updates von 06/2025 gelöst wurden. Die DC (Server 2016) müssen gepatched sein mit KB5061010. Siehe (ich hoffe die Links funktionieren):
https://support.microsoft.com/en-us/topic/protections-for-cve-2025-26647-kerberos-authentication-5f5d753b-4023-4dd3-b7b7-c8b104933d53#bkmk_known_issue
https://learn.microsoft.com/en-us/windows/release-health/resolved-issues-windows-10-1607
https://support.microsoft.com/de-de/topic/june-10-2025-kb5061010-os-build-14393-8148-6766ca26-dc1e-4592-b959-d0c92d6deb6f
Aktuelle Phase: Ohne den Registry Wert "AllowNtAuthPolicyBypass" verhalten sich die DC so, als wäre der Wert auf "2"! Momentan kann man das noch über diesen Wert auf "Audit" (=1) setzen, oder auch deaktivieren "=0"). Ab Oktober wird der Registry Wert dann ignoriert, die Härtugn ist scharf.
Vor den Juni-Updates bewirkte die Scharfschaltung tatsächlich, dass die Clients keine sichere Verbindugn zum DC aufbauen konnten, demzufolge die GPO für den Computer zum Beispiel nicht verarbeitet werden konnte. Das hing wohl mit "PkInit" zusammen. Dies wurde gefixt mit den Juni Updates, steht auch alles sauber in den Artikeln.
es muss nicht zwingend ein Bug sein.
Bei uns ist mir grad das gleiche aufgefallen, nachdem ich den Enforcement Mode auf einem DC aktiviert habe (hatten keine ID 45 Events in den DC Logs).
Direkt danach tauchten ID 21 Events im Log des DC auf und die besagen: ich vertraue einer CA in der Kette nicht. Juli-Updates sind auf den DCs installiert.
Prüft mal die CAs im AD Container NTAuthCertificates (MMC -> Enterprise PKI snap-in -> Rechtsklick auf Enterprise PKI -> Manage AD Containers).
Bei uns taucht da nur die ausstellende Sub-CA auf, nicht die offline root CA. Würde zur Fehlermeldung passen.
Kommando zurück (vorerst). lt unserm Consultant ist das so eigentlich richtig. die offline root CA sollte nicht im NTAuthCertificates Container sein, nur im Certification Authorities Container.
wir versuchen das dennoch mal – melde mich wieder
das hat nichts geändert, die ID 21 Events tauchen nach wie vor im DC Log auf.
Wir sehen aber auch keine Probleme, der Zugriff von unseren AAD-joined Endpoints auf Freigaben etc on-prem funktioniert.
Auch von den paar AD-joined Clients sind mir keine Probleme bekannt, die nutzen aber auch kein Windows Hello for Business.
Zumindest in unserem Fall sieht es so aus, als können wir die Warnungen ignorieren und müssen im Oktober nichts befürchten.
Wie Ralf oben schon angemerkt hat: die strikte Prüfung ist längst standardmäßig aktiv und kann bis Oktober nur per Regkey deaktiviert / auf Audit gesetzt werden
Hallo Leute,
bei uns ist es ähnlich – keine Events , weder 45 noch 21, mit aktiviertem AllowNtAuthPolicyBypass = 1. Sobald der RegistryKey entfernt wird erscheinen 21er Events. Gilt für DC´s Win2016 ,2019 und 2025. Hotfixe sind eingespielt – DC´s sind up to date.
Bekomme auch Event 21 für zahlreiche Computerkonten. Keine Ahnung wieso, device PKINIT müsste doch von dem Check ausgeschlossen sein, da hier self-signed certificates verwendet werden?
Feedback von MS Support: Bekanntes Thema, wird in einem kommenden Update behoben. Man solle für Updates diesen Beitrag hier verfolgen (https://support.microsoft.com/en-us/topic/protections-for-cve-2025-26647-kerberos-authentication-5f5d753b-4023-4dd3-b7b7-c8b104933d53)