Windows Mai 2022-Updates verursachen AD-Authentifizierungsfehler (Server, Client)

Windows[English]Die Sicherheitsupdates vom 10. Mai 2022 für Windows führen zu diversen Problemen. Eines betrifft die Authentifizierung auf Domain Controllern. Diese scheint für verschiedene Maschinen (Client und Server) wegen Zertifikatsfehlern zu scheitern. Betroffen sind alle Clients, von Windows 7 SP1 (mit ESU) bis hin zu Windows 11 und die betreffenden Server-Pendants. Microsoft hat das Problem inzwischen bestätigt.


Anzeige

Benutzermeldungen im Blog und im Internet

Hier im Blog gibt es diese ausführliche Diskussion zu Problemen mit 802.1x-Zertifikaten nach dem Patchen von Domain Controllern und NPS-Servern. Michael schreibt dazu:

Ja, ich hab hier den NPS mit Computerzertifikaten laufen.

Mit dem Update KB5013941 können keine Authentifizierungen mehr auf Grund von Zertifikaten erfolgen (Error 16, Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.)

Nach Deinstallation des Updates funktioniert der NPS wieder.

Ich hatte kurz im Beitrag Windows, Office: Mai 2022 Patchday-Probleme und Besonderheiten auf dieses Problem hingewiesen. Auf reddit.com findet sich dieser Thread mit der gleichen Fehlerbeschreibung:

My NPS policies (with certificate auth) have been failing to work since the update, stating "Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing account or the password was incorrect.".

The server also serves the DC and ADCS role (don't ask, working on severing).

Uninstalling KB5014001 and KB5014011 resolves this but obviously would rather get them patched.

Anyone else seeing this? Running on 2012R2.

Wird auch für andere Server-Versionen (2019 etc.) bestätigt.

Microsoft bestätigt Fehler

Microsoft hat inzwischen das Problem im Windows 11 Health-Dashboard unter den Know Issues im Beitrag You might see authentication failures on the server or client for services zum 11. Mai 2022 angesprochen und bestätigt das Problem:

After installing updates released May 10, 2022 on your domain controllers, you might see authentication failures on the server or client for services such as Network Policy Server (NPS), Routing and Remote access Service (RRAS), Radius, Extensible Authentication Protocol (EAP), and Protected Extensible Authentication Protocol (PEAP). An issue has been found related to how the mapping of certificates to machine accounts is being handled by the domain controller.

Note: Installation of updates released May 10, 2022, on client Windows devices and non-domain controller Windows Servers will not cause this issue. This issue only affects installation of May 10, 2022, updates installed on servers used as domain controllers.

Es wird also genau die Authentifizierungsproblematik mit Domain Controllern (ADs) und ADSC-Rollen bestätigt, die weiter oben angesprochen wurde. Betroffen sind von den Clients folgende Windows-Versionen

  • Windows 11 Version 21H2
  • Windows 10 Version 21H2, 21H1; 20H2
  • Windows 10 Version 1909; Enterprise LTSC 2019
  • Windows 10 Version 1809
  • Windows 10 Version 1607; Enterprise LTSC 2016
  • Windows 10 Enterprise 2015 LTSB
  • Windows 8.1
  • Windows 7 SP1

und von den Servern folgende Varianten:

  • Windows Server 2022
  • Windows Server Version 20H2
  • Windows Server Version 1909; Windows Server 2019
  • Windows Server Version 1809
  • Windows Server 2016
  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2 SP1
  • Windows Server 2008 SP2

Ergänzung: Im Artikel Microsoft fixt (PetitPotam) NTLM Relay-Schwachstelle (CVE-2022-26925) mit Windows Mai 2022-Update habe ich die Mai 2022-Updates aufgelistet. Microsoft untersucht das Problem derzeit und plant, in einer der nächsten Versionen ein Update zur Verfügung zu stellen. Bis dahin schlägt Microsoft folgendes als Workaround vor:

Workaround: The preferred mitigation for this issue is to manually map certificates to a machine account in Active Directory. For instructions, please see Certificate Mapping.

Also die manuelle Zuordnung von Zertifikaten zu einem Maschinenkonto im Active Directory. Die Anweisungen sind die gleichen für die Zuordnung von Zertifikaten zu Benutzer- oder Maschinenkonten in Active Directory. Wenn die bevorzugte Abhilfemaßnahme in Ihrer Umgebung nicht funktioniert, finden sich unter KB5014754—Certificate-based authentication changes on Windows domain controllers weitere mögliche Abhilfemaßnahmen im Abschnitt SChannel-Registrierungsschlüssel. Andere Workarounds wie die Deinstallation des Updates werden von Microsoft, wegen der Sicherheitsproblematik, nicht empfohlen.


Anzeige

Ergänzung 2: Es gibt ein Sonderupdate vom 19. Mai 2022, was das Problem patchen soll – siehe Windows Out-of-Band-Updates (19.5.2022) fixen AD-Authentifizierungsfehler und Store-Installationsfehler.

Ähnliche Artikel:
Microsoft Office Updates (3. Mai 2022)
Microsoft Security Update Summary (10. Mai 2022)
Patchday: Windows 10-Updates (10. Mai 2022)
Patchday: Windows 11/Server 2022-Updates (10. Mai 2022)
Windows 7/Server 2008R2; Windows 8.1/Server 2012R2: Updates (10. Mai 2022)
Patchday: Microsoft Office Updates (10. Mai 2022)

Exchange Server Sicherheitsupdates (10. Mai 2022)

Patchday-Nachlese: Probleme mit April 2022-Updates
Windows Server 2022: März 2022-Update KB5011497 verursacht Probleme mit Remote-Desktop-Rollen/-Verbindungen
Windows Server 2022: Lösung für Remote Desktop-Probleme mit Update KB5011497
Windows Server 2022: Wie ist der Status beim RDS-Bug (RDCB-Rolle), verursacht durch KB5011497?
Windows Update KB5012599: Fix für Installationsfehler 0x8024200B und 0x800F0831 kommt

Windows Mai 2022-Updates verursachen AD-Authentifizierungsfehler (Server, Client)
CISA warnt vor Installation der Mai 2022-Updates auf Windows Domain Controllern
Windows Out-of-Band-Updates (19.5.2022) fixen AD-Authentifizierungsfehler und Store-Installationsfehler


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Störung, Windows, Windows 10, Windows 7, Windows 8.1, Windows Server abgelegt und mit Patchday 5.2022, Störung, Update, Windows verschlagwortet. Setze ein Lesezeichen auf den Permalink.

33 Antworten zu Windows Mai 2022-Updates verursachen AD-Authentifizierungsfehler (Server, Client)

  1. MOM20xx sagt:

    Naive Frage. Wie stellt Microsoft sich das künftig vor? Das haut ja jeden autoenrollment Prozess zusammen, wenn danach der Admin per Script Mappings aktualisieren müsste. Das macht vielleicht einer mit einer handvoll Maschinen, wenn ihm sehr langweilig ist. In großen Unternehmen mit ein paar vielen Tausend Objekten gibts wahrscheinlich "Amokläufe" dann.

    • Stefan sagt:

      Da stimme ich voll zu. Ich finde es darüber hinaus ja auch immer lobenswert wenn treue Mitstreiter workarounds rausbringen in Form von Registryhacks und sonstigem Gefrickel aber Leute, das kanns doch echt nicht sein. Das ist ein Mulltimilliarden Dollar- Unternehmen und jedes verschissenes Monat immer wieder der gleiche Scheiß. Wäre ich Vollzeit MS-Update-Admin… bitte, ich hab aber auch noch andere Dinge zu tun.

  2. Tobi sagt:

    Auf unserem WSUS ist das KB5013941 Update nicht zu finden. Wurde das Update zurückgezogen?

    • MOM20xx sagt:

      brauchst du den überhaupt, das wäre der für Server 2019. hab WSUS bei uns gerade synchronisiert, der ist noch immer da. Da gab es seit DI keine Änderungen. Kein Patch wurde zurückgezogen.

      • Tobi sagt:

        Danke für die Info. SRV19 syncen wir tatsächlich nicht. Ich habe nun KB5014001 and KB5014011 abgelehnt. War etwas irritiert.

  3. tineidae sagt:

    Also wir sehen seit dem Mai Update auf einem 2016 DC massenweise folgende Einträge, das bezieht sich auf User und Maschinen. Interessanterweise ist es auf dem anderem 2012 R2 DC nicht ersichtlich. Können aber aktuell keine Auswirkungen feststellen.

    The client certificate for the user DOMAIN\xxx 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 certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

    • Robert Glöckner sagt:

      ist xxx ein Benutzer- oder ein Rechnername? Es kann natürlich sein, dass das Root-Zertifikat gerade abgelaufen ist und dann ist das Vertrauen auch weg obwohl alles irgendwie weiterfunktioniert. Vielleicht mal im Zertifikatsspeicher nachschauen wie es mit der Gültigkeit aussieht und ggf erneuern.

      • tineidae sagt:

        Hi,

        ich habe beides gesehen. Server sind alle in der Domäne und Clients sind alle AAD. Erst dachte ich das die AAD Zertifikate evtl. mit dem AD ärger machen, aber als ich die ersten Server dort gesehen habe glaub ich das nicht mehr. Die internen CAs sind okay. Da es derzeit scheinbar keine negativen Auswirkungen gibt schau ich mir das alles noch mal in Ruhe an.

        • nk sagt:

          @tineidae
          Diese Meldungen haben wir auch, vermutlich seit Mai 2021 auf den DCs, aber bislang ebenfalls keine negative Auswirkung festellen könne. Eine Lösung habe ich bisher nicht gefunden, konntest du das Problem schon etwas eingrenzen?

  4. Andreas F. sagt:

    Windows 7.1. SP1, habe ich da eine Version verpasst? 😅

  5. Malte sagt:

    Das Update bricht bei uns (Server 2012 R2) DirectAccess mit OTP-Authentifizierung. Ein festes Mapping der bewusst kurzlebigen Zertifikate, die dort ausgestellt werden wird nicht möglich sein: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-otpce/7186a7c7-492d-4d49-a9fc-19a36bfe9db5

    Mit Setzen der Keys für SChannel funktioniert es wieder, aber wie stellt Microsoft sich das ab 02/2023 vor?

  6. Tobias sagt:

    Guten Tag zusammen,
    Hiob wäre stolz auf Microsoft… Verstehe ich das richtig, dass es zu den Störungen mit den Zertifikaten und NPS nur dann kommt, wenn die Updates auf den DCS installiert werden? Bedeutet, ich kann sonst alle anderen Server und Clients patchen? Also auch einen dedizierten NPS?
    Gruß in die Runde!

  7. Frank sagt:

    ja, alle anderen Systeme sind bei uns voll gepatched, auch der NPS-Server
    nur auf den DCs mußte jeweils das passende KB wieder herausgenommen werden (z.B. KB5013941 bei Server2019)

    bei uns betraf es nur WLAN-Zugänge mit Computerzertifikaten, alles andere problemfrei

    Grüsse

    • Tobias sagt:

      Genau das wäre auch bei uns das Thema. Danke für die Rückmeldung!

    • tineidae sagt:

      Oha, wir haben alles gepatcht, also NPS, AD und Clients, WLAN und VPN mit Zertifikaten funktioniert aber zum Glück weiterhin. Mein 2016 wird aber massiv wegen Zertifikatsfehlern zugespammt, aber das hängt evtl. nicht mit der Thematik zusammen auch wenn es erst mit dem Patchday aufgetaucht ist.

  8. Frank sagt:

    @Malte: DirectAccess mit Server2019 lief bei uns übrigens problemfrei als das WLAN schon nicht mehr funktionierte; muß wohl anderes konfiguriert sein als bei dir

  9. pgn sagt:

    Bei uns war es der NPS-Dienst, der auf Windows Server 2012 R2 Datacenter 64-Bit läuft. Der NPS-Server ist auch Domain Controller. Windows Endgeräte konnten sich nicht mehr via Computerzertifikat am 802.1x EAP WLAN anmelden.

    Abhilfe schaffte:
    REG ADD "HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel" /v "CertificateMappingMethods" /t REG_DWORD /d "0x1F" /f

    Dies schaltet lt. o.g. MS Artikel die unsicheren Mappingprüfungen wieder an – genauso wie es vor dem Mai 2022 Update war.

  10. MOM20xx sagt:

    das problem ist wohl, dass auch bei neu augestellten zertifikaten, die nachweislich die sid extension inkludiert haben, diese gleich gar nicht geprüft wird oder nur geprüft wird, wenn vielleicht in UPN auch im SAN steht. zumindest auf Platform 2012 R2.
    Sieht also so aus, als ob Microsoft diese Sicherheitserweiterung nur für User Accounts, aber scheinbar nicht für Computer Accounts getestet hat. Ansonsten würd es ja funktionieren.
    Und wie auch erwähnt, die Doku ist falsch. Die Quellen der Event IDs 39-41 sind nicht Kdcsvc sondern Kerberos-Key-Distribution-Center. Zumindest bei Domain Controllern auf Windows Server 2012 R2

  11. Alte Frau sagt:

    Also ich bin stinksauer. Neuerdings habe ich beim Hochfahren 3 Benutzerkonten und eine ständige Passwortabfrage. Beim Bearbeiten werden nur 2 Benutzer angezeigt. Zudem wird ein falscher Benutzer angesprochen. Ich kann das nirgends ändern und muss nun erst den Benutzer ändern, bevor der Laptop hochfährt. Danke Microsoft. Ich bin ein einfacher Nutzer im fortgeschrittenen Alter, der ganz sicher jetzt nicht anfangen wird, rumzufrickeln, damit alles wieder wie gehabt funktioniert.

  12. Axel sagt:

    Vielen Dank für den Artikel wir nutzen die Zertifkatauthentifizierung um alle Clients im Netz anzumelden. Auch viele macOS Devices. Heute früh ging natürlich nichts mehr. Ihr Artikel hat mich auf die richtige Spur gebracht. Vielen Dank dafür.

    Noch verstehe ich nicht ganz was hier passiert. Soweit sollte doch erst ab 09.05.2023 die Überprüfung erzwungen werden, es sei denn, man aktiviert dies mittels Registry vorher? Warum funktioniert es denn dann überhaupt nicht? Das kann ja dann nur ein Fehlerhaftes Update sein.

    Lösen konnte ich das Problem mit setzen des DWORD Eintrags im Schannel. Eine entsprechende Vorwarnung hätte ich mir gewünscht.

    Invoke-Command -ComputerName dc05 -scriptblock { New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\SecurityProviders\Schannel" -Name "CertificateMappingMethods" -PropertyType "DWORD" -Value "0x1F" }

  13. Tim sagt:

    Gibt es hier eigentlich schon neue Erkenntnisse ob von MS ein Update geplant ist?

  14. Tim sagt:

    Danke. Die Methode CertificateMappingMethods funktioniert.
    Ist dies eigentlich eine neue Sicherheitsfunktion von MS so dass ich etwas an der Umgebung anpassen könnte um den Eintrag nicht mehr zu benötigen?

  15. Feuerpanda sagt:

    Wenn man einen Radius am laufen hat fürs VPN und die Cisco Geräte nur mit einem statischen Schlüssel verbunden sind und die Benutzer die sich nur über ihr Windows Benutzername und Kennwort authentifizieren ist man dann auch von den Problem betroffen oder kann man das dann ignorieren?

  16. Hartmut sagt:

    Da unsere User sich nur mit Benutzernamen und Passwort anmelden, habe ich unseren Win2019Server gepatched und bisher keinerlei Probleme – ich denke es betrifft "nur" die Authentifizierung mit Zertifikaten. Oder hat hier jemand andere Erfahrungen?

    Trotzdem mal wieder typisch Microsoft: da werden so umfangreiche und tiefgreifende Änderungen nicht ausführlich getestet und einfach freigegeben….

  17. Philipp sagt:

    Guten Morgen,

    für das Domain Controller Thema gibt es ein Out of Band Update:

    You might see authentication failures on the server or client for services

    • Günter Born sagt:

      @Phillip: Danke für die Ergänzung – ich hatte die Nacht bereits einen Ergänzungsbeitrag mit Verlinkung aller Updates und des Release-Health-Status veröffentlicht, aber keine Zeit hier zu verlinken (Morpheus hat gerufen). Der Beitrag ist inzwischen am Artikelende verlinkt.

  18. Xronos sagt:

    Also wir haben es wie folgt zum Laufen bekommen.

    OOB Update auf allen CAs, NPS und Domaincontroller installiert.
    Damit gingen schonmal alle Laptops wieder ins WLAN.

    Damit nun auch alle anderen mobilen Endgeräte (iOS usw.) funktionieren, welche die Zertifikate über intune (SCEP) bekommen, mussten wir das noch aktivieren, was eigentlich standardmäßig an sein sollte. Das es noch nicht erzwungen wird.

    Auf allen DCs:
    StrongCertificateBindingEnforcement =1

    1 – Checks if there is a strong certificate mapping. If yes, authentication is allowed. Otherwise, the KDC will check if the certificate has the new SID extension and validate it. If this extension is not present, authentication is allowed if the user account predates the certificate.

    https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_kdcregkey

  19. Tim sagt:

    Wie ist hier der Stand? Gibt es mittlerweile ein Update?

Schreibe einen Kommentar zu Axel Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.