[English]Von Microsoft wurden zum 19. Mai 2022 außerplanmäßiger Updates (out-of-band Updates) für unterstützte Windows Server-Versionen freigegeben, die durch die Sicherheitsupdates vom 10. Mai 2022 verursachte Probleme beheben sollen. Dazu gehört auch die Beseitigung des Active Directory Authentifizierungsproblem auf Domain Controllern. Inzwischen liegen mir aber mehrere Meldungen vor, dass der Fix zumindest in bestimmten Konstellationen mit NPS (Network Policy Server) nicht hilft. Ergänzung: Es gibt einen Hinweis von Susan Bradley, was bei der Reihenfolge zur Vorgehensweise zu beachten ist, den ich im Artikel nachgetragen habe.
Anzeige
Out-of-Band-Updates vom 19. Mai 2022
Mit den Sicherheitsupdates vom 10. Mai 2022 versuchte Microsoft diverse Schwachstellen zu schließen. Allerdings versagten die Sicherheitsupdates auf Windows Server, die als Active Directory Domain Controller fungierten, da dort Authentifizierungsprobleme auftauchten. Ich hatte im Blog-Beitrag Windows Mai 2022-Updates verursachen AD-Authentifizierungsfehler (Server, Client) darüber berichtet. Die Kollateralschäden durch den Mai 2022-Patchday waren so hoch, dass die US-Behörde CISA vor deren Installation warnte (siehe CISA warnt vor Installation der Mai 2022-Updates auf Windows Domain Controllern). Microsoft hat daher nachfolgende außerplanmäßig Updates (out-of-band Updates) veröffentlicht, und im Windows Healt-Statusbereich im Know Issues-Abschnitt in diesem Eintrag aufgelistet:
- KB5015013: Windows Server 2022
- KB5015020: Windows Server Version 20H2
- KB5015018: Windows Server 2019
- KB5015019: Windows Server 2016
sowie die nachfolgenden Standalone-Updates:
- KB5014986: Windows Server 2012 R2
- KB5014991: Windows Server 2012
- KB5014987: Windows Server 2008 R2 SP1
- KB5014990: Windows Server 2008 SP2
Zweck dieser Updates war auch, ein bekanntes Problem zu beheben, das einige Dienste daran hindern kann, Maschinenkonten auf Clients oder Servern zu authentifizieren. Dieses Problem tritt nach der Installation der Sicherheits-Update vom 10. Mai 2022 auf Domänencontrollern auf. Ich hatte das Update und weitere Details im Beitrag Windows Out-of-Band-Updates (19.5.2022) fixen AD-Authentifizierungsfehler und Store-Installationsfehler erwähnt.
Updates helfen bei NPS nicht
Inzwischen haben Betroffene die außerplanmäßigen Updates auf ihren Windows Servern, die als Active Directory Domain Controller fungieren installiert. Dabei ist mir aufgefallen, dass es auffällig oft die Rückmeldung gab, dass die Out-of-Band-Updates am Zertifikatefehler nichts ändern. Blog-Leser Andreas schreibt in diesem Kommentar:
Anzeige
Bei uns hilft es nicht.
Das Mai Update ist drauf und nun auch noch der KB5015018 für Windows Server 2019.
Aber weiterhin kommen die RADIUS Clients nicht am NPS vorbei und damit ins WLAN.Extrem ärgerlich, hier stehen 700 iPads vor dem NPS und wollen rein gelassen werden…
Das neueste SSU Update ist auch installiert.
Nachdem Andreas das beide Updates (KB5013941 und KB5015018) wieder deinstalliert hat, können sich alle Clients erneut mit dem RADIUS WLAN verbinden. Das Problem wird von MOM20xx in diesem Kommentar bestätigt:
Kann ich bestätigen. Notebooks kommen nach einspielen des Patches weiterhin nicht in Netzwerk mit 802.1x. Fehler wie vor dem Update. Dabei wird keiner der erwähnten EventIDs 39-41 gelogged. Wir haben zwar eventid 39 im Logs aber für Mobiles, die bei uns reinkommen, aber eine andere Radius konfiguration haben.
Und auch hier weiterhin die Event Source Kerberos-Key-Distribution-Center und nicht wie unter KB5014754—Certificate-based authentication changes on Windows domain controllers beschrieben kdcsvc
Selbst neue Zertifikate mit der erwähnten Erweiterung, wo die SID vermerkt ist werden nicht akzeptiert. Erst wenn das Zertifikat einen UPN zusätzlich hat, funktioniert 802.1x wieder. Oder sollte man den Patch vielleicht auch am NPS Server einspielen?
- ohne UPN im Zertifikat gibts Auth Failure mit EventID 4768 und Result Code 0x6, was soviel bedeutet wie das Gerät nicht in der KerberosDB gefunden.
Ein weiterer Nutzer bestätigt: In unserer Umgebung (802.1x mit NPS) hat das einspielen von KB5018018 das Problem ebenfalls nicht behoben. NPS denied weiterhin den Zugriff für Computer. Auch im englischsprachigen Blog gibt es diesen Kommentar zum Thema:
I can also confirm that KB5015018 also breaks NPS Radius EAP-TLS device authentication.
Das Update KB5015018 bezieht sich auf Windows Server 2019. Stefan A. fragt hier, ob es jemanden gibt, bei dem das Out-of-Band-Update das Problem mit NPS und Computerzertifikaten überhaupt lösen konnte. Bisher hat sich diesbezüglich noch kein Administrator gemeldet.
Was zu beachten ist und helfen könnte
Ich hatte auf askwoody.com im Forum auf die Probleme hingewiesen. Susan Bradley hat darauf hin diesen Kommentar auf askwoody.com zu meinem Post nachgeschoben (danke dafür) und weist auf bestimmte Schritte hin, die einzuhalten sind, um erfolgreich zu sein.
Wichtig: Diejenigen, die eine PKI (Public Key Infrastruktur) verwenden, müssen zuerst ihre Zertifikate (CAs) aktualisieren. Der Patch fügt einen neuen OID (Objekt-Identifier) zu allen Vorlagen hinzu, die für die Authentifizierung verwendet werden. Dazu schreibt Susan:
Diese OID wird durch die SID des AD-Objekts ergänzt, um das spezifische Gerät im Zertifikat weiter zu identifizieren.
Sobald die Zertifizierungsstellen aktualisiert sind und die OID in Ihrem anfänglichen Testzertifikat für einen PC vorhanden ist, können Administratoren ältere Zertifikate ohne die OID widerrufen und über die automatische Registrierung neue Zertifikate ausstellen.
Sobald diese Schritte abgearbeitet und die Zertifikate erneuert wurden, ist es sicher, die Domain Controller (DCs) zu patchen. Die Authentifizierung wird dann wie gewohnt fortgesetzt, da die DCs nach dem Patching die neue OID als Identifikator verstehen. Inzwischen gibt es auf administrator.de diesen Thread zum Problem. Vielleicht hilft das Betroffenen weiter. Falls jemand das erfolgreich getestet hat, kann er ja eine Rückmeldung hinterlassen – danke.
Ähnliche Artikel:
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)
Microsoft fixt (PetitPotam) NTLM Relay-Schwachstelle (CVE-2022-26925) mit Windows Mai 2022-Update
Windows, Office: Mai 2022 Patchday-Probleme und Besonderheiten
Windows 11: Update KB5013943 erzeugt Fehler 0xc0000135
Windows 11 Update KB5013943 verursacht Probleme mit DATEV (0xc0000135)
Windows Mai 2022-Updates verursachen AD-Authentifizierungsfehler (Server, Client)
CISA warnt vor Installation der Mai 2022-Updates auf Windows Domain Controllern
Active Directory-Admins: Mai 2022-Updates können bei DCs zur Boot-Schleife führen (gesetztes AltSecID-Attribut bei krbtgt)
Windows Out-of-Band-Updates (19.5.2022) fixen AD-Authentifizierungsfehler und Store-Installationsfehler
Anzeige
Mir erschließen sich die Testprozesse von Microsoft nicht.
Alle Unternehmen nutzen 802.1x.
Dafür muss es doch ein Testszenario geben, bevor ein Update veröffentlicht wird.
Nach dem AD Debakel habe ich kein Verständnis mehr dafür.
Ich werde leider immer verwirrter.
Verstehe ich es richtig, dass man also den Server auf dem die interne pki läuft als erstes mit dem OOB Update versehen muss, damit diese OID den Vorlagen hinzugefügt wird und erst danach darf man die DCs aktualisieren?
Bisher ist doch immer nur die Rede von den DCs gewesen…?
Zu NPS mit Zertifikaten:
Hier alles auf 2012R2, alles mit den normalen Updates per WSUS aktualisiert, inklusive eigene interne PKI, NPS und DCs natürlich.
Es gab danach die laut MS zu erwartenden Einträge im Eventlog als Warnung mit ID 39 von kdcsbc bei Authentifizierung im WLAN mit Zertifikaten per 802.1x über NPS/Radius. Beschrieben in "KB5014754—Certificate-based authentication changes on Windows domain controllers"
Wenn man das Zertifikat erneuert sind auch die weg. Also alles so, wie es sein soll – bei 2012R2 wie gesagt. Keinerlei Probleme. Daher wäre es immer wichtig, die OS Version der betroffenen Server zu listen: DCs, CA, NPS.
Mir stellt sich aber die Frage wie ein Client sein Zertifikat erneuern soll, wenn man das auf diesem aktuell vorhandene Zertifikat widerruft? Der Client sollte dann doch wohl keine Chance haben sich per 802.1x mit Zertifikat per NPS zu authentifizieren?
Wohl auch deshalb gilt der Kompatibilitätszeitraum in o. g. Artikel auch 1 Jahr: Die Computerzertifikate haben 1 Jahr Laufzeit u d sind bis dahin automatisch erneuert, bevor der Erzwingungsmodus aktiviert wird, im Mai 2023…
habt ihr im Zertifikat den User Principal Name (UPN) drinnen oder nicht?
Gute Frage!
Vielleicht kann das jemand noch sicher beantworten, ob auf dem CA-Server die Mai-Updates reichen oder ebenfalls das OOB-Update drauf muss.
Gruß Stefan
Danke für die Ergänzungen in dem Artikel!
Ich gebe auf jeden Fall noch Feedback.
Aber was ich dann nicht verstehe ist, warum das hier unter dem Link steht:
*Frequently asked questions*
*Q1* Once the CA is updated, must all client authentication certificates be renewed?
*A1* No, renewal is not required. The CA will ship in Compatibility Mode. If you want a strong mapping using the ObjectSID extension, you will need a new certificate.
https://support.microsoft.com/de-de/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16
Hallo zusammen,
der Hinweis, die Zertifikate zu ändern damit die neue Extension drinnen wäre, verändert nicht viel an der Situation. Das ändert an der Situation für 802.1x nur etwas, wenn das Template der CA zusätzlich den User Principal Name im Subject Alternate Name setzt. Nur ich habe bisher keine Doku gefunden, wo dies zwingend wäre. Bis vor dem Patch funktionierte 802.1x auch ohne UPN im Zertifikat. Wir haben halt jetzt mal den UPN reingegeben. Nur wärs halt hilfreich, wenn es bei Microsoft dann irgendwo eine Aussage gäbe, ob das nun zwingend wäre oder nicht. Sogehen funktioniert dieses Out of Band Update, genauso gut oder schlecht wie der Mai Patch, denn alleine mit dem Patch war 802.1x auch schon funktional, wenn wir den UPN in die Zertifikate mitaufgenommen haben.
Danke für die Rückmeldung.
Hallo MOM20xx!
Ich hätte nochmal eine Rückfrage, was du mit UPN im Zertifikat meinst.
Wir verwenden nur Zertifikate für unsere Computer und nicht für unsere User um unsere Clients im WLAN via NPS / 802.1x zu authentifizieren.
Nach dem Patchen des CA-Servers haben nun auch alle neu ausgestellten Zertifikate zusätzlich diesen Object Identifier (OID) (1.3.6.1.4.1.311.25.2).
Wenn ich mir die Zertifikate an den jeweiligen Clients anschaue, finde ich unter dem Punkt "Alternativer Antragstellername" jeweils den DNS-Namen des Clients.
Also z.B. DNS-Name=NB-XXXXXX.domain.local
Meinst du das mit UPN oder müsste da noch mehr stehen.
Und falls ja, wo muss ich das wie konfigurieren?
Vielen Dank im Voraus
Stefan
Hallo Stefan,
genau beim Punkter Alternativer Antragstellername dann noch der User Principal Name, dann gehts bei uns. Defaultmässig war der nie drinnen. nur im Subjekt der CN des Computers und im SAN eben der DNS des Computers. Wenn wir ein Template im Ad dafür freigeben, dass für den SAN auch noch den UPN aus den AD Daten generiert für den autoenroll Prozess und für 802.1x dann verwendet wird, dann klappt es wie es soll. Mit oder ohne Out Of Band Patch.
Wir verwenden für 802.1x auch nur Computer Zertifikate. aber ein Computer Objekt im AD hat ja fernab der SPN (Service Principal Names) auch einen UPN (Userprinzipalname)
Hier eine Bild was ich meine –> https://www.sysadmins.lv/content/images/pages/7290/3056.6.jpg diesen UPN müsstest du in dsa CA Template für 802.1x mit reinnehmen und dann damit ein Zertifikat enrollen lassen
Hallo MOM20xx!
Danke für die Rückmeldung!
Ich werde das mal mit meinen Kollegen besprechen.
Wir müssten dann ja die Vorlagen anpassen, wenn das geht oder muss man da neue machen?
Aber wie es aussieht, scheint ja der UPN nicht serienmäßig mit in den SAN geschrieben zu werden (vllt. liegt es an alten Templates, die wir immer mit umgezogen haben).
Ich habe davon nur noch nirgends weiter was gelesen.
Auch der Kommentar von Susan Bradley erwähnt ja nichts in die Richtung.
Müsste es dann nicht viel öfters auch bei anderen „knallen"?
Hattest du auch mal ausprobiert was MS unter Troubleshooting aufgeführt hat:
„Add or modify the CertificateMappingMethods registry key value on the domain controller and set it to 0x1F"
@all
Gibt es hier jemand, bei dem der UPN mit in den SAN geschrieben wird, ohne das extra angepasst zu haben?
Viele Grüße
Stefan
Servus,
nein, die Vorlage die man üblicherweise kopiert (Computer) hat es auch nicht, insofern würde es mich wundern wenns bei irgendwem Standard ist
Moin zusammen,
vorab mal wieder vielen Dank an Alle für die rege Diskussion und den Wissensaustausch! Ich verstehe gerade das ursprüngliche Problem nicht und hoffe auf einen Denkanstoß.
Nach Installation der Mai Updates hat MS also das Verfahren zum Mapping eines Zertifikates zum AD-Objekt geändert. Laut MS sollten aber alle Systeme am Anfang automatisch auf "Kompatibilitätsmodus" konfiguriert sein mit der händischen Option, wie in KB5014754 beschrieben, den Erzwingungsmodus vor dem Mai 2023 zu aktivieren. Es sollte also vorerst alles funktionieren, wie bisher auch.
Sollten aktuell Zertifikate für User/Computer zur Authentifizierung ausgestellt werden, die länger als Mai 2023 gültig sind, ist händisches Eingreifen erforderlich, da der Erzwingungsmodus im Mai 2023 aktiviert werden würde und die nötige Zertifikatserweiterung in den bereits ausgestellten, aber weiterhin gültigen, Zertifikaten, fehlt.
Soweit verständlich.
Ist der Bug aus den Mai-Updates + dem OOB-Update nun, dass der Kompatibilitätsmodus nicht aktiviert wurde, oder funktioniert das Mapping der Zertifikate generell nicht mehr, trotz Kompatibilitätseinstellung?
Wir haben in einer Kundenumgebung eine SSTP-basierte Client-VPN-Einwahl mit Authentifizierung via Benutzerzertifikaten und bisher haben wir es gescheut, die Mai Updates auf Grund dieser Probleme einzuspielen. Von einer nicht mehr funktionierenden 802.1x-Authentifizierung im WLAN mal ganz abgesehen, hätten wir bei den VPN-Clients größere Probleme, die wieder in die Firma zu bekommen (Henne-Ei-Problem: Keine neuen Zertifikate ohne VPN-Einwahl, aber keine VPN-Einwahl ohne neue Zertifikate).
In den "VPN-Zertifikaten" haben wir bereits den UPN als SAN-Eintrag im Zertifikat aufgeführt, zusätzlich zur E-Mail Adresse als "RFC822-Name".
Vielen Dank vorab.
Grüße,
Norman.
Sehr interessante Zusammenfassung in diesem Blog hier auch
https://system32.blog/post/adsmapcertificates/
schade nur, dass Microsoft überall den Teil mit dem UPN verschweigt
Also ich muss ganz ehrlich sagen, ich verstehe langsam nur noch Bahnhof und frage mich was MS da macht.
Warum gibt es dafür keine offizielle Anleitung oder Info? Ich muß plötzlich Änderungen durchführen die ich mir mühselig auf unterschiedlichen Seiten zusammensuchen muss. Laut MS muss ich ja vor 2023 gar nichts machen bzw kann das in Ruhe nach dem Mai Update machen.
Ich bin maximal gefrustet und verunsichert. Wir haben die Updates auf den dcs noch nicht eingespielt und werden jetzt mal schauen wie wir es machen.
Der UPN steht auch bei uns in den Vorlagen nicht drin und unsere pki wurde erst vor 1 Jahr auf einem 2019er Server installiert.
Folgende zwei Links haben mir geholfen, um die Gründe warum der Patch überhaupt diese Änderungen durchführt, zu verstehen.
– https://www.gradenegger.eu/?p=18373
-https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
Wir haben nun mal schrittweise unser CA auf den Mai-Patch + anschließend OOB Patch hochgezogen. Neu ausgestellte Zertifikate haben nun auch die OID 1.3.6.1.4.1.311.25.2 (siehe Bild:
Die nächsten Tage werden wir den ersten DC nachziehen und dann mal schauen was passiert ;)
Danke für die Links – sehr interessant.
Hallo ErazerMe!
Danke für die Links!
Wie in dem Artikel von Gradenegger zu lesen ist, wird ja der UPN bei Computerkonten scheinbar im Standard bei niemandem gesetzt.
Hast du dann die Vorlage für Computerkonten (UPN) so wie MOM20xx angepasst oder probierst du es erstmal nur mit dem neuen OID 1.3.6.1.4.1.311.25.2 in den neuen Zertifikaten.
Gruß
Stefan
Hallo Stefan A.,
wir haben die Default-Templates nie benutzt. D.h. wir haben das Computer-Template dupliziert und dieses dann auf unsere Bedürfnisse angepasst. Ebenfalls haben wir schon immer den UPN im Zertifikats-Template angekreuzt gehabt – was jedoch kein Standard ist – wir es aber einfach schon immer gemacht hatten.
Danke Dir. Das ist sehr interessant und frustrierend zugleich :)
Was mir aber immer noch nicht ganz klar ist. Muss jetzt in den Vorlagen der UPN aufgenommen werden oder nicht.
Laut dem Artikel von Uwe Gradenegger, wäre das ja gar nicht notwendig. Oder verstehe ich das jetzt falsch?
Die Lösung von MS ist eher schlecht, aber sollte ja so erstmal funktionieren ohne das man manuell an den Vorlagen etwas anpassen muss.
Ich würde es aber auch so wie jwinc (weiter unten) sehen, man muss das update auch auf dem CA Server installieren. Bei uns läuft die PKI auch nicht auf dem DC.
Also wenn ich die ganzen Artikel richtig verstanden habe, so spielt der UPN bzw. auch DNS-Name später absolut keine Rolle mehr. Nachdem die CA das neue Attribute in den Templates eingetragen hat, bekomme alle neu ausgestellten Zertifikate die S-ID mit eingetragen (konnte ich auch schon nachstellen).
Wenn du den Mai-Patch nun auf deinen DCs installiert hast, so kontrollieren diese DCs die Zertifikate auf das Vorhandensein der S-ID im Zertifikat und vergleichen diese mit dem jeweiligen Computer-Objekt.
– Hat dein Zertifikat keine S-ID eingetragen (weil CA noch nicht gepatch oder kein neues Zertifikat), wird der Zugriff vom DC geblockt.
– Hat dein Zertifikat eine S-ID eingetragen, passt aber mit der S-ID vom Computer-Objekt nicht zusammen (weil du bspw. ein Zertifikat von einem anderen Computer exportiert/importiert hast), wird der Zugriff vom DC geblockt.
– Hat dein Zertifikat eine S-ID eingetragen und diese passt mit deinem Computer überein, Zugriff erlaubt.
So ist zumindest mein Verständnis über das ganze Thema hier.
Und was der OOB nun eigentl. machen sollte: überall wo oben "wird der Zugriff vom DC geblockt" steht, sollte der Zugriff (nach OOB installation) nicht mehr geblockt werden, sondern zugelassen werden UND im Eventlog ein Eintrag notiert werden.
Des "zulassen" funktioniert nur leider nicht richtig / garnicht.
KB5014986
Den Patch auch auf dem SRV mit interner CA installieren, welcher die Zertifikate für die Rechner/Benutzer ausstellt um per WLAN sich zu verbinden. Ich denke, dass MS hier denkt, dass auf SRV mit DC Rolle auch die CA Rolle mit installiert ist. Das stimmt so wohl nicht bei vielen von uns ;-) Gruss
OS 2012R2 2x DC und 1x CA
Danke für die Info – ich werde diese Info und das von ErazerMe gepostete auch im englischsprachigen Blog-Beitrag nachtragen.
Hallo zusammen,
ich frage mich gerade ernsthaft, wie MS sich das Ganze prozedere mit dem UPN, den neuen Zertifikaten und der "Reihenfolge" der Updates gedacht hat…??!?
Wir haben genau EINEN Windows 2019 Server je Standort. Dieser eine Server ist gleichzeitig DC und CA. Wie soll ich da vorher nun die CA updaten und dann hergehen und später den DC nachziehen.
Vor allem holen sich unsere hunderte iPads die neuen Zertifikate nicht selbst, die muss ich denen per MDM zuweisen. Wenn die aber nicht mehr ins WLAN kommen (alle iPads sind wifi only Geräte) dann bekommen die auch die neuen Zertifikate nicht. Ich hab hier also gleich zwei henne-Ei Probleme, die ich so im Moment ohne genaue Anleitung von irgend jemandem nicht gelöst bekomm. Oder aber ich blick vor lauter Wald nun einfach nicht mehr durch … ;-)
Gruß Andreas
Moin,
wir haben das Problem auch noch vor uns – könnten Sie mir bitte schreiben, wie es aktuell aussieht?
Funktionieren die OOB Updates mittelweile?
Wie ist die Einspielreihenfolge:
Erstmal das Mai Update, dann das OOB Update?
Wir haben einen CA Server, zwei RADIUS Server und dann 7 Standorte mit jeweils drei DCs (eine übergeordnete und sechs untergeordnete AD) – sollen die Updates auch in dieser Reihenfolge eingespielt werden?
Ich danke Ihnen im Voraus für Ihre Antworten mit den Tipps!
Viele Grüße,
Alex
Direkte Antworten per Mail kann ich keine liefern. Möglicherweise kann ein Admin aus dem betreffenden Umfeld was zu sagen – mein aktueller Wissensstand: Automatisch OOB-Update ausrollen und alles ist gut, scheint nicht zuzutreffen. Einige sind glücklich, andere müssen nacharbeiten oder scheitern. Lasse mich aber gerne von Betroffenen korrigieren.
Hallo,
es gab noch eine Änderung am Microsoft Artikel bzgl. der Problematik:
2022-05-27 14:07 PT
https://docs.microsoft.com/en-us/windows/release-health/status-windows-10-21h2#known-issues
Kann jemand nachvollziehen was hier angepasst wurde? Gab es ggf. nochmal Anpassungen bzgl. der NPS Probleme?
Interessanterweise habe ich das jetzt zum ersten Mal so verstanden, dass das OOB-Update nicht nur auf die DCs soll, sondern auch auf den NPS oder CA Server.
Oder wie versteht ihr das?
Resolution: This issue was resolved in out-of-band updates released May 19, 2022 for installation on all Domain Controllers in your environment, as well as all intermediary application servers such as Network Policy Servers (NPS), RADIUS, Certification Authority (CA), or web servers which passes the authentication certificate from the client being authenticated to the authenticating DC. If you used any workaround or mitigations for this issue, they are no longer needed, and we recommend you remove them. This includes the removal of the registry key (CertificateMappingMethods = 0x1F) documented in the SChannel registry key section of KB5014754. There is no action needed on the client side to resolve this authentication issue.
https://docs.microsoft.com/en-us/windows/release-health/status-windows-10-21h2#known-issues
Gruß
Stefan
Hallo Stefan,
genau das ist aktuell auch meine Interpretation und die einiger Leute im Sysadmin Reddit:
was geändert wurde? vor 27.5. hiess es wohl nur auf DCs installieren. Jetzt kannst den out of band patch eigentlich auf jedem member server installieren, der irgendwas mit certificaten authentifizieren soll. im prinzip kannst das gleich in den wsus rein hauen für alle server os und verteilen auf jedem server.
Update:
OOB auf NPS, CA DCs und allen Member Servern mal installiert.
Ergebnis: 802.1x funktioniert auf Clients mit Computer Zertifikaten ohne UPN im Zert wieder.
Wir hatten den OOB Patch auf einem DC installiert und dann alle System welche Client-Authentifzierung durchführen explizit auf diesen einen DC umgestellt. Konnten keinerlei Probleme feststellen.
Die Anmeldung von DomainAdmins findet bei uns via SmartCard (YubiKey) statt – bei der Anmeldung von Domain Admins mit einem (vor dem Patch) ausgerollten Zertifikat läuft die Anmeldung durch, es wird aber zusätzlich eine Warning in das Eventlog geschrieben. Anmeldungen mit neuen Zertifikaten werden ohne Warning im Eventlog akzeptiert.
Die nächsten Tage wird der Patch nun auf allen Windows-Servern bei uns ausgerollt.
Nachdem ich angebotenen Updates KB5014022 & KB 5014090 auf dem DC installiert habe, kann das Update KB5015018 nicht mehr installiert werden.
Wird es jetzt nicht mehr benötigt oder soll ich die beiden Updates deinstallieren und das OOB-Update zuerst installieren?
Ich blicke echt nicht mehr durch!
Die Windows Updates sind seit Server 2016 kumulativ.
Das bedeutet, ein neueres Update beinhaltet auch die Anpassungen der Updates davor.
Wobei ich mit Vorschau-Updates auf Servern immer vorsichtig bin.
Du siehst es auch auch an den folgenden Build Nummern:
24. Mai 2022 – KB5014022 (Betriebssystembuild 17763.2989) Vorschau
19. Mai 2022 – KB5015018 (Betriebssystembuild 17763.2931) Out-of-Band
Check das einfach mal mit dem Befehl „winver" auf welchem Build dein Server aktuell ist.
Daher kannst du das OOB nicht mehr installieren, weil du ja schon auf einem höheren Build bist und was dadurch auch nicht mehr nötig ist.
Verbessert mich gerne, falls ich mich täusche.
Gruß
Stefan
Alles klar, thx für die Erklärung. Beide DC sind jetzt up2date.
Bis jetzt hatte ich mit den Vorschau-Updates noch keine Probleme, wobei ich allerdings im Normalfall bisher immer 1-2 Wochen abwarte, bevor ich Updates einspiele.
Zuvor schaue ich immer hier vorbei….. ;)
Ich wollte jetzt auch mal Feedback geben:
Wir haben nun seit einigen Tagen ebenfalls unsere DCs aktualisiert und unsere WLAN-Authentifizierung via NPS und 802.1x funktioniert weiterhin!
Wir haben keine Zertifikatsvorlagen anpassen müssen.
Wir haben nun das erwartete Verhalten, dass Zertifikate, die noch nicht den neuen OID 1.3.6.1.4.1.311.25.2 enthalten, dazu führen, dass ein Event 39 protokolliert wird.
Wir haben zuerst unseren CA-Server und dann den NPS-Server mit dem OOB-Update versorgt und dann nach einigen Tagen unsere DCs mit dem OOB-Update versorgt.
Bisher ist noch nichts Negatives aufgefallen und ich hoffe das bleibt auch so!
Grüße
Stefan
Bei uns läuft auch alles nach installation der OOB-Updates.
DCs aktualisiert (einer der DCs ist auch CA).
WLAN Anmeldung per PEAP und machine cert. funktioniert (das Mai-Update hatte hier alles zerschossen) weiterhin.
Auch wenn das machine cert. noch nicht erneuert wurde und somit auch noch nicht die neue OID hat. Alles läuft.
Infrastruktur:
DC1 – OOB installed
DC2 – OOB installed
DC3 – OOB installed
NPS1 – May update installed
NPS2 – May update installed
Ich verstehe es gerade nicht, wir haben unser Template unter anderem mit dem UPN angepasst, wir haben die auto aktualisierung an aber die clients mit zertifikat aktualisieren ihr Zertifikat nicht. Wie kann man das sonst triggern? Ja gültigkeit ist da und es ist <80% seiner Gültigkeitsdauer aber ich dachte wenn sich das Template aktualisiert (also eine neue Revision bekommt) ziehen sich die Clients das Zertifikat trotzdem neu?
Hast du mal die Funktion per Rechtsklick auf den Templatenamen versucht und "Reenroll all certificate holders" getriggert?
Ansonsten Vorlage mal neu auf der CA publizieren auch.
Hallo werte Kollegen und Leidensgenossen. Ich habe eine Lösung entwickelt für das Problem, dass die neue SID-Zertifkaterweiterung nur bei Zertifikatvorlagen eingetragen wird, die für AD-(Auto)Enrollment konfiguriert sind. Microsoft hat laut ihrem KB ja vor, das "Full Enforcement" am 09. Mai 2023 hart zu erzwingen, was meiner Ansicht nach alle MDM (Intune, Airwatch und Co.) verwalteten Endgeräte aus dem 802.1x rauswerfen wird wenn das Unternehmen den Network Policy Server einsetzt.
Die Lösung ist ein sog. Policy Modul für die Zertifizierungsstelle. Es kann eingehende Zertifikatanforderungen analysieren, die beantragte Identität ermitteln und auf das zugehörige AD Objekt mappen. So kann es die SID für das entsprechende Konto ermitteln und in das ausgestellte Zertifikat eintragen. Das funktioniert mit allen von der Microsoft CA zur Verfügung gestellten Protokollen, Clients und allen MDM Systemen.
Hier findet ihr das Modul: https://github.com/Sleepw4lker/TameMyCerts
Es ist Open Source, kann also kostenlos eingesetzt werden. Unter "releases" liegt eine fertig kompilierte digital signierte Version davon. Ich hoffe, dass es euch einen Nutzen stiften kann. Meldet euch wenn ihr Schwierigkeiten beim Einsatz oder andere Fragen haben solltet. Mitarbeit am Projekt ist ebenfalls herzlich willkommen.
Cheers
Hallo Uwe,
erstmal wollte ich dir mein sehr großen Respekt vor deiner Leistung, solch ein Modul zu programmieren, aussprechen. Solch ein Teil zu coden für eine CA, bei dem jeder Fehler zum Desaster führen kann, einfach nur spitzenklasse. :-)
Ich stehe vor dem Problem, unseren MACs per Jamf Pro und deren ADCS Connector eine funktionierende und automatisierte 802.1x Comp Cert Auth beizubringen.
Leider habe ich wie alle anderen auch das OID Problem, da wir ebenfalls den Windows NPS einsetzen.
Auch sind wir immer noch auf Server 2012R2 mit den meisten unserer VMs, d.h. eine Migration
auf Server 2019 steht ebenfalls noch an…
Glücklick war ich, als ich gelesen habe, dass MS die Grandenfrist des Forced Mode auf November 2023 verlängert hat. :-)
https://support.microsoft.com/de-de/topic/kb5014754-%C3%A4nderungen-an-der-zertifikatbasierten-authentifizierung-auf-windows-dom%C3%A4nencontrollern-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap
Doch trotzdem muss das Problem zeitnah angegangen werden… ich würde mich mal per PM bei dir melden…
Ich hätte da so ein paar Fragen… ;-)
VG
Rene´