{"id":314639,"date":"2025-08-16T00:01:30","date_gmt":"2025-08-15T22:01:30","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=314639"},"modified":"2025-08-29T06:11:30","modified_gmt":"2025-08-29T04:11:30","slug":"probleme-mit-dem-regkey-allowntauthpolicybypass-cve-2025-26647","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2025\/08\/16\/probleme-mit-dem-regkey-allowntauthpolicybypass-cve-2025-26647\/","title":{"rendered":"Probleme mit dem Regkey AllowNtAuthPolicyBypass (CVE-2025-26647)"},"content":{"rendered":"<p><img decoding=\"async\" style=\"margin: 0px 10px 0px 0px; display: inline; float: left;\" title=\"Windows\" src=\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2021\/04\/Windows-klein.jpg\" alt=\"Windows\" width=\"200\" align=\"left\" \/>[<a href=\"https:\/\/borncity.com\/win\/2025\/08\/29\/window-issues-with-allowntauthpolicybypass-cve-2025-26647\/\" target=\"_blank\" rel=\"noopener\">English<\/a>]Im April 2025 gab es ein Update um die Schwachstelle CVE-2025-26647 in der Kerberos Authentifizierung zu schlie\u00dfen. Ein Blog-Leser wies mich bereits Mitte Juli 2025 darauf hin, dass\u00a0 der Registry-Wert <em>AllowNtAuthPolicyBypass<\/em> eingef\u00fchrt wurde. Allerdings ist er auf Probleme in Zusammenhang mit dem Schl\u00fcssel gesto\u00dfen.<\/p>\n<p><!--more--><\/p>\n<h2>CVE-2025-26647: Kurzer Abriss des Sachverhalts<\/h2>\n<p><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/vg04.met.vgwort.de\/na\/225ef3a69ef74120a5746202fa06db98\" alt=\"\" width=\"1\" height=\"1\" \/>Von Microsoft gibt es seit dem 8. April 2025 den Support-Beitrag\u00a0<a href=\"https:\/\/support.microsoft.com\/en-us\/topic\/protections-for-cve-2025-26647-kerberos-authentication-5f5d753b-4023-4dd3-b7b7-c8b104933d53\" target=\"_blank\" rel=\"noopener\">Protections for CVE-2025-26647 (Kerberos Authentication)<\/a>, der sich mit dem Schlie\u00dfen der Kerberos Authentifizierungschwachstelle CVE-2025-26647 unter den noch im Support befindlichen Windows Server-Versionen befasst. In folgendem Registrierungsschl\u00fcssel:<\/p>\n<pre>HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Kdc<\/pre>\n<p>wurde der REG_DWORD Wert <em>AllowNtAuthPolicyBypass<\/em> neu eingef\u00fchrt. Der Wert muss manuell erstellt werden, um sich abzusichern. Nachfolgend werden die m\u00f6glichen Werte genannt:<\/p>\n<table>\n<tbody>\n<tr>\n<td>\n<div>\n<div>Wert<\/div>\n<\/div>\n<\/td>\n<td>\n<div>\n<div>Modus<\/div>\n<\/div>\n<\/td>\n<td>\n<div>\n<div>Beschreibung<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<div>\n<div>0<\/div>\n<\/div>\n<\/td>\n<td>\n<div>\n<div><b>Deaktiviert<\/b><\/div>\n<\/div>\n<\/td>\n<td>\n<div>\n<div>Die\u00a0NTAuth-Pr\u00fcfung\u00a0wird <b>nicht\u00a0durchgef\u00fchrt<\/b>. Kein Schutz\u00a0aktiv.<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<div>\n<div>1<\/div>\n<\/div>\n<\/td>\n<td>\n<div>\n<div><b>Audit-Modus<\/b><\/div>\n<\/div>\n<\/td>\n<td>\n<div>\n<div>NTAuth-Pr\u00fcfung\u00a0wird\u00a0durchgef\u00fchrt. Bei\u00a0Problemen\u00a0wird <b>nur\u00a0ein\u00a0Warn-Event (ID 45)<\/b>\u00a0protokolliert. <b>Standardverhalten\u00a0ab 8. April 2025<\/b>,\u00a0wenn\u00a0der Key <b>nicht\u00a0gesetzt<\/b>\u00a0ist.<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<tr>\n<td>\n<div>\n<div>2<\/div>\n<\/div>\n<\/td>\n<td>\n<div>\n<div><b>Enforced-Modus<\/b><\/div>\n<\/div>\n<\/td>\n<td>\n<div>\n<div>NTAuth-Pr\u00fcfung\u00a0wird\u00a0durchgef\u00fchrt. Bei\u00a0Fehlern\u00a0wird\u00a0die\u00a0Anmeldung <b>verweigert<\/b>. Event-ID 21\u00a0wird\u00a0protokolliert.<\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Ist der Schl\u00fcssel nicht gesetzt (Standardverhalten) verh\u00e4lt sich der Domain Controller so, als ob der Wert auf 1 steht (Audit-Modus). Das bedeutet:<\/p>\n<ul>\n<li>Kerberos-Anmeldungen\u00a0funktionieren\u00a0weiterhin<\/li>\n<li>Event-ID 45 \"<em>The Key Distribution Center (KDC) encountered a client certificate that was valid but did not chain to a root in the NTAuth store<\/em>\" wird im System-Ereignisprotokoll des DCs protokolliert.<\/li>\n<\/ul>\n<p>Diese Meldung im Ereignisprotokoll dient als Hinweis auf ein potenzielles Problem, das in Zukunft zu einem Fehler f\u00fchren kann, wenn der Modus auf 2 (Enforcement) umgestellt wird.<\/p>\n<h2>Phasen\u00a0der\u00a0Umsetzung<\/h2>\n<p>Microsoft hat f\u00fcr die Umsetzung drei Phasen vorgesehen, von denen zwei bereits verstrichen sind:<\/p>\n<ul>\n<li><b>8. April 2025 \u2013 Initial Deployment (Audit-Modus): <\/b>hier wird im Event-log protokolliert<\/li>\n<li><b>8. Juli 2025 \u2013 Enforced by Default:\u00a0<\/b>hier wird im Eventlog protokolliert und unsichere Authentifizierungen geblockt (w\u00e4re aber via Registry-Key auch wieder zur\u00fcck auf Audit-Mode umschaltbar)<\/li>\n<li><b>14. Oktober 2025 \u2013 Enforcement Mode: <\/b>hier wird geblockt und kann nicht mehr\u00a0 per Registry-Key zur\u00fcck ge\u00e4ndert werden.<\/li>\n<\/ul>\n<p>Zum Oktober 2025 kommt also der Enforcement-Modus zum Tragen, w\u00e4hrend die beiden ersten Phasen bzw. Termine verstrichen sind.<\/p>\n<h2>Ein Leser stie\u00df auf Probleme<\/h2>\n<p>Blog-Leser Andy M. schrieb mir in einer E-Mail \"<em>ich greife mal ein Thema auf, welches mich nun schon mehrere Tage massiv besch\u00e4ftigt und ich die leichte Vermutung habe dass ich hiermit nicht alleine sein kann<\/em>\". Dann schilderte er den obigen Sachverhalt mit dem Zeitplan und ging auf Probleme mit dem Regkey AllowNtAuthPolicyBypass (CVE-2025-26647) ein.<\/p>\n<p>Die Umgebung, in der der Leser auf Fehlverhalten bzw. Problem stie\u00df, umfasst folgende Maschinen:<\/p>\n<ul>\n<li>DCs: 25x Windows Server 2016 (Version 1607 \/ Build 14393.8148)<\/li>\n<li>Betroffene Windows-Clients: 24H2 (10.0.26100.4061), 23H2 (10.0.22631.5549), 23H2 (10.0.22631.5624)<\/li>\n<\/ul>\n<p>Der Leser gibt an, dass in der Umgebung ca. 1.500 Clients laufen, wobei davon jedoch stand Mitte Juli 2025 nur ca. 40 Ger\u00e4te von Problemen betroffen sind. Andy schrieb dazu: \"<em>Nach dem wir alle DCs auf die Events ID 45 gepr\u00fcft haben, waren wir uns eigentl. sicher dass wir nun schonmal vorab in den Enforcement-Mode umschalten &#8211; sprich den AllowNtAuthPolicyBypass = 2 setzen<\/em>.\"<\/p>\n<p>Die Domain-Controller waren zu diesem Zeitpunkt auf dem Patchstand von Juni 2025 &#8211; der Juli-Patch fehlt noch. Aber ein Administrator kann ja mittels des oben erw\u00e4hnten Registry-Key schonmal auf den Enforcement-Mode umstellen.<\/p>\n<p>Ein paar Minuten nach der Umstellung auf Enforcement-Mode, sind sofort Eventlog-Eintr\u00e4ge im Systemlog der DCs aufgetaucht:<\/p>\n<p><code>Source: Kerberos-Key-Distribution-Center<br \/>\nEventID: 21<br \/>\nGeneral: 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.<\/code><\/p>\n<p>Auch auf den betroffenen Clients sieht man im Eventlog folgende zwei Events:<\/p>\n<p><code>Source: Security-Kerberos<br \/>\nEventID: 8<br \/>\nGeneral: 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\u00fcr vertrauensw\u00fcrdig gehalten.<\/code><br \/>\n<code>Source: GroupPolicy<br \/>\nEventID: 1055<br \/>\nGeneral: The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following:<br \/>\na) Name Resolution failure on the current domain controller.<br \/>\nb) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).<\/code><\/p>\n<p>Ebenfalls ist auf den betroffenen Clients kein \"gpupdate \/force\" mehr m\u00f6glich. Hierbei kommt folgende Meldung:<\/p>\n<p><code>C:\\Users\\mxmustermann&gt;gpupdate \/force<br \/>\nThe policy is being updated ...<br \/>\nThe computer policy could not be updated successfully. The following problems have occurred:<br \/>\nError processing the group policy. The computer name could not be resolved. This can have at least<br \/>\none of the following causes:<br \/>\na) Name resolution error with the current domain controller.<br \/>\nb) Active Directory replication latency (an account created on another domain controller has not replicated to the current domain controller).<br \/>\nThe user policy could not be updated successfully. The following problems have occurred:<br \/>\nError processing the group policy. The computer name could not be resolved. This can have at least<br \/>\none of the following causes:<br \/>\na) Name resolution error with the current domain controller.<br \/>\nb) Active Directory replication latency (an account created on another domain controller has not replicated to the current domain controller).<br \/>\nRead the event log to diagnose the error, or run the command \"GPRESULT \/H GPReport.html\" to access information about Group Policy results.<\/code><\/p>\n<p>\"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\u00a0 laut seiner Aussage beispielsweise nicht mehr m\u00f6glich. Beim Beantragen der Zertifikate \u00fcber die MMC kommt eine RPC-Fehlermeldung.<\/p>\n<p>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:<\/p>\n<blockquote><p><a id=\"LPlnkOWA8bfc5b49-79aa-155a-ed61-efe0c6c9a7d1\" class=\"OWAAutoLink\" href=\"https:\/\/admin.cloud.microsoft\/?source=applauncher#\/windowsreleasehealth\/history\/:\/issue\/WI1068856\" target=\"_blank\" rel=\"noopener\">Windows release health &#8211; Microsoft 365 admin center<\/a><\/p>\n<p>After installing the April Windows monthly security update released April 8, 2025 (<a href=\"https:\/\/support.microsoft.com\/help\/5055523\" target=\"_blank\" rel=\"noopener\">KB5055523<\/a>) 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.<\/p>\n<p>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 &#8211; Protections for CVE-2025-26647 (Kerberos Authentication) [<a href=\"https:\/\/support.microsoft.com\/help\/5057784\" target=\"_blank\" rel=\"noopener\">link<\/a>].<\/p>\n<p>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\u00a0AllowNtAuthPolicyBypass in<\/p>\n<pre>HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Kdc<\/pre>\n<p>Two scenarios can be observed following installation of the April 2025 Windows monthly security update on authenticating DCs:<\/p>\n<p>&#8211; 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.<\/p>\n<p>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.<\/p>\n<p>&#8211; 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.<\/p>\n<p>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:<\/p>\n<p>&#8211; Windows Hello for Business (WHfB) Key Trust deployments [<a href=\"https:\/\/learn.microsoft.com\/windows\/security\/identity-protection\/hello-for-business\/deploy\/hybrid-key-trust\" target=\"_blank\" rel=\"noopener\">link<\/a>]<br \/>\n&#8211; Device Public Key Authentication [<a href=\"https:\/\/learn.microsoft.com\/windows-server\/security\/kerberos\/domain-joined-device-public-key-authentication\">link<\/a>] (also known as Machine PKINIT).<br \/>\n&#8211; 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.<\/p>\n<p>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.<\/p><\/blockquote>\n<p>Der Leser hat seine Erfahrungen bez\u00fcglich des obigen Sachverhalts im Zusammenhang mit DCs und Patch-Stand Juni 2025 mit verschiedenen Windows-Clients mit verschiedenen OS-Builds\u00a0so zusammengefasst:<\/p>\n<blockquote><p>Nachdem der Key \"AllowNtAuthPolicyBypass\" aktiv auf \"2\" gesetzt wird, sind manche Endger\u00e4te fehlerhaft und k\u00f6nnen nicht sauber mit den DCs kommunizieren. Stellen wir wieder zur\u00fcck auf \"1\", ist alles gut.<\/p><\/blockquote>\n<p>Der Leser zieht den Schluss, dass dies nach einem Bug ausschaut. Frage an die Leserschaft: Kann jemand das Verhalten best\u00e4tigen? Wir haben inzwischen ja bereits die August 2025-Updates verf\u00fcgbar. Ist dort das Verhalten eventuell behoben? Oder wurde etwas anderes \u00fcbersehen?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>[English]Im April 2025 gab es ein Update um die Schwachstelle CVE-2025-26647 in der Kerberos Authentifizierung zu schlie\u00dfen. Ein Blog-Leser wies mich bereits Mitte Juli 2025 darauf hin, dass\u00a0 der Registry-Wert AllowNtAuthPolicyBypass eingef\u00fchrt wurde. Allerdings ist er auf Probleme in Zusammenhang &hellip; <a href=\"https:\/\/borncity.com\/blog\/2025\/08\/16\/probleme-mit-dem-regkey-allowntauthpolicybypass-cve-2025-26647\/\">Weiterlesen <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8537,426,2557],"tags":[24,4328,4364],"class_list":["post-314639","post","type-post","status-publish","format-standard","hentry","category-problem","category-sicherheit","category-windows-server","tag-problem","tag-sicherheit","tag-windows-server"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/314639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=314639"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/314639\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=314639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=314639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=314639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}