[English]Microsoft hat zum 13. November 2022 ein weiteres Problem mit der Kerberos Authentifizierung unter Windows in Verbindung mit den November 2022-Updates bestätigt. Ich hatte ja bereits berichtet, dass die Sicherheitsupdates vom 8. November 2022 zu diesen führen können. Nun hat Microsoft noch einige Details zum Sachverhalt offen gelegt.
Anzeige
Ich hatte ja bereits am 10. November 2022 im Blog-Beitrag November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll über die aufgetretenen Probleme berichtet. Die Aussagen basierten aber auf Fragmenten von Aussagen, die auf Twitter diskutiert wurden. Nun erfolgte eine offizielle Bestätigung durch Microsoft zum 13. November 2022 auf der Windows Release Health Status-Seite von Windows 11 22H2 sowie auf den entsprechenden Seiten von Windows 10.
Details und betroffene Windows-Versionen
Das Problem betrifft nur Windows-Systeme, die mit Domain-Controllern kommunizieren und sich über Kerberos authentifizieren. Windows-Geräte, die von Privatpersonen zu Hause verwendet werden, oder Geräte, die nicht Teil einer Domäne vor Ort sind, sind von diesem Problem nicht betroffen. Azure Active Directory-Umgebungen, die nicht hybrid sind und keine Active Directory-Server vor Ort haben, sind nicht betroffen. Im Hinblick auf die betroffenen Systeme heißt es im Beitrag Sign in failures and other issues related to Kerberos authentication vom 13. November 2022 dazu:
Nach der Installation von Updates, die am 8. November 2022 oder später auf Windows-Servern mit der Rolle Domänencontroller veröffentlicht wurden, können Probleme mit der Kerberos-Authentifizierung auftreten. Dieses Problem kann sich auf jede Kerberos-Authentifizierung in Ihrer Umgebung auswirken. Einige Szenarien, die betroffen sein können:
- Die Anmeldung von Domänenbenutzern kann fehlschlagen. Dies kann auch die Active Directory Federation Services (AD FS)-Authentifizierung beeinträchtigen.
- Gruppenverwaltete Dienstkonten (gMSA), die für Dienste wie Internet Information Services (IIS Web Server) verwendet werden, können möglicherweise nicht authentifiziert werden.
- Remote Desktop-Verbindungen mit Domänenbenutzern können möglicherweise nicht hergestellt werden.
- Sie können möglicherweise nicht auf freigegebene Ordner auf Workstations und Dateifreigaben auf Servern zugreifen.
- Druckvorgänge, die eine Domänenbenutzer-Authentifizierung erfordern, schlagen möglicherweise fehl.
Wenn dieses Problem auftritt, tritt möglicherweise ein Microsoft-Windows-Kerberos-Key-Distribution-Center-Fehlerereignis mit der Ereignis-ID 14 im Abschnitt "System" des Ereignisprotokolls auf dem Domänencontroller auf. Das Fehlerereignis enthält den unten stehenden Text.
While processing an AS request for target service <service>,
the account <account name> did not have a suitable key for generating
a Kerberos ticket (the missing key has an ID of 1). The requested
etypes : 18 3. The accounts available etypes : 23 18 17.
Changing or resetting the password of <account name> will generate
a proper key.Hinweis: Die betroffenen Ereignisse haben den Text "Der fehlende Schlüssel hat eine ID von 1".
Microsoft schreibt, dass dieses Problem voraussichtlich nichts mit der Sicherheitshärtung für Netlogon und Kerberos im Rahmen der November 2022-Updates zu tun habe. Die Entwickler von Microsoft arbeiten an einer Lösung und gehen davon aus, dass diese in den nächsten Wochen zur Verfügung stehen wird. Dieses bekannte Problem wird mit weiteren Informationen aktualisiert, sobald diese verfügbar sind. Betroffen von diesem Bug sind folgende Windows-Plattformen:
Anzeige
Clients:
Windows 11 Version 22H2;
Windows 11, Version 21H2;
Windows 10, Version 22H2;
Windows 10, Version 21H2;
Windows 10, Version 21H1;
Windows 10, Version 20H2;
Windows 10 Enterprise LTSC 2019;
Windows 10 Enterprise LTSC 2016;
Windows 10 Enterprise 2015 LTSB;
Windows 8.1;
Windows 7 SP1
Server:
Windows Server 2022;
Windows Server 2019;
Windows Server 2016;
Windows Server 2012 R2;
Windows Server 2012;
Windows Server 2008 R2 SP1;
Windows Server 2008 SP2
Im Blog-Beitrag November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll werden von betroffenen Nutzern verschiedene Strategien diskutiert, um diese Authentifizierungsprobleme zu beheben. Zudem findet sich im Artikel ein Hinweis auf ein PowerShell Script, um betroffene Maschinen zu identifizieren.
Ähnliche Artikel:
Microsoft Security Update Summary (8. November 2022)
Patchday: Windows 10-Updates (8. November 2022)
Patchday: Windows 11/Server 2022-Updates (8. November 2022)
Windows 7/Server 2008 R2; Windows 8.1/Server 2012 R2: Updates (8. November 2022)
Windows 10 20H2-22H2 Preview Update KB5018482 (25.10.2022)
Windows 11 22H2: Preview-Update KB5018496 (25.10.2022)
Windows 11 21H2: Preview-Update KB5018483 (25.10.2022)
Windows Server 2022 Preview Update KB5018485 (25.10.2022)
November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll
Microsoft bestätigt Direct Access-Probleme nach Nov. 2022 Updates
Anzeige
Gibt es einen Workaround, ausser das Update zu deinstallieren?
Falls wer keine Registry Änderungen am DC vornehmen will/kann. Es gibt auch einen Workaround den man auf den betroffenen Member Server/Clients einstellen kann…
z.b. damit:
reg.exe ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\kerberos\parameters" /v "supportedencryptiontypes" /f /t "REG_DWORD" /d "0x7fffffff"
Restart-Service -Force Netlogon
gpupdate /force
Mit dem Regkey werden alle Verschlüsselungsmethoden aktiviert. Wo vorher z.b. AES Only war ist mit dem Reg key nun auch DES und RC4 erlaubt.
Wenn ihr das wieder Rückgäng machen wollt einfach: 0x7ffffff0
Hallo zusammen,
vermutlich/hoffentlich haben die meisten Admins schon eine Lösung.
Ich möchte kurz auf meine eingehen:
Bin auf Reddit auf folgende Post gestoßen -> https://www.reddit.com/r/sysadmin/comments/ypbpju/comment/iw91ivt/?utm_source=reddit&utm_medium=web2x&context=3
Habe in meiner Domain dann für die Workstation RC4 zusätzlich ergänzt und bei den Useraccounts via ADSI-Editor den Attribut "SupportedEncryptionTypes" auf den Wert 20 gesetzt.
Danach lief wieder soweit alles.
MS schreibt immer nur 'kann fehlschlagen' und 'können möglicherweise nicht authentifiziert werden'. Sind die nicht in der Lage zu sagen, unter welchen Bedingungen/Voraussetzungen es Probleme gibt?
… schöne Grüße aus der Rechtsabteilung. Da entstehen meistens solche Formulierung bzw. in den Schulungen. Ist bei meinem AG genau so, wenn es um Stellungnahmen für Unternehmen, Partner und Kunden geht.
Unabhängig davon wird Microsoft selbst noch nicht überlicken, welche Bedingungen und Rahmenbedingungen reinspielen. Ich finde es nach wie erstaunlich, wie bei der aktuellen Komplexität und Verzahnung der verschiedenen Produkte überhaupt noch jemand einen Überblick hat und vorallem weitestgehend funktioniert.
Was für Dauer-Looser bei M$
Man muß froh sein, daß M$ keine Autos oder Atomkraftwerke baut. Ich hoffe mal, daß niemand AKWs etc. mit M$ Produkten steuert.
Doch sicher wird das dort laufen. Win Embedded oder Win CE auf Maschinen ist durchaus üblich. Hat aber mit der Domänenproblematik hier ncihts zu tun.
Das S auf deiner Tastatur ist wohl auch defekt..
Die Hoffnung darf sterben:
https://www.csoonline.com/article/2905402/inside-the-rickety-vulnerable-systems-that-run-just-about-every-power-plant.html
Ist hallt immer noch eines der meist verwendeten Systeme überhaupt…bin zwar auch nicht glücklich mit deren QA, aber Looser sind sie wohl nicht.
Weiteres Problem mit November Update hier: Server 2019 mit einer GPO mit automatischem Install/Restart an einem bestimmten Tag, haben sofort am Tag des WSUS-Approvals installiert.
Server mit einer GPO ohne automatischem Install/Restart haben bisher nicht neu gestartet.
Dazu gibt es einen Eventlogeintrag mit "Reason: Service Pack", der bisher nie aufgetreten ist:
System Eventlog ID 1074
The process C:\Windows\system32\svchost.exe (Serv001) has initiated the restart of computer Serv001 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Service pack (Planned)
Reason Code: 0x80020010
Shutdown Type: restart
Wir hatten nach dem Update des Druckservers auf CU-2022-11 Probleme mit der Druckerzuweisung im Citrix über WEM. (Citrix 7 LTSR 1912 CU4, WEM 2109).
Die Citrix-Server waren zu diesem Zeitpunkt alle noch auf CU 2022-09.
Nach dem auch die Citrix Server aktualisiert wurden, war das Problem weg.
Jetzt sind alle Server (2016) auf 2022-11 und es sind, bis jetzt, keine weiteren Probleme aufgetreten.
Hi,
laut Microsoft sind nur Domain-Controller betroffen:
After installing updates released on November 8, 2022 or later on Windows Servers with the Domain Controller role, you might have issues with Kerberos authentication.
Lauf Beitragstext:
"Das Problem betrifft nur Windows-Systeme, die mit Domain-Controllern kommunizieren und sich über Kerberos authentifizieren."
Kann man also getrost alles bis auf die DCs Updaten?
japp.
Das Problem tauch auch bei Linux auf mit SSSD und AD Join. Workaround muss ich mal morgen schauen… hatte heute keine Lust mehr ;)
Lösung: in dem Computer Konto der AD muss in dem Attribute Editor unter msDS-SupportedEncryptionTypes von 24 auf 28 geändert werden.
Damit ist der Spuk vorbei und man kann sich wieder via AD an der Linuxmaschiene anmelden.
mfg
Olaf
Ist bei mir schon auf 28, klappt leider trotzdem nicht, sonst ne Idee was da Ubuntu mit SSSD fürs AD brauchen könnt?
Bei meinem DELL Latitude funktioniert das WLAN seit dem November 2022 Update nicht mehr. WLAN wird verbunden, das Notebook bekommt aber keine IP Adresse per DHCP. Deinstallation aller November 2022 Updates hat leider nichts geholfen………. :-(
betroffene KBs:
KB5019081 – Server 2022
KB5019966 – Server 2019
KB5019964 – Server 2016
KB5020023 – Server 2012 R2
Wäre mal interessant, bei welchen Szenarios es bei euch zu Fehlern kommt? "normales" Einloggen mit AD-Benutzer? RDP-Connect per AD-Benutzer? usw
Folgende Zeilen, ausgeführt als Administrator in der "PowerShell (Administrator)" hat mir bei den Kerberos- und ANmelde-Fehlern geholfen. Dieser Task sollte bestenfalls vor dem Update durchgeführt werden, funktionierte aber auch nach dem Update.
# Create KDC REG Key
New-ItemProperty -path "HKLM:\System\CurrentControlSet\services\KDC" -name ApplyDefaultDomainPolicy1 -PropertyType DWORD -value "00000000"
#Restart KDC Service
Restart-Service KDC -Force
Die Probleme dürften meiner Meinung nach nur auftreten, wenn unter "Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren" RC4 ausgenommen wurde.
Wir haben den Wert nicht gesetzt und auch keine oben genannten Probleme identifizieren können.
Kann jemand bestätigen, dass die Fehler mit der Ausnahme von RC4 direkt zusammenhängt?
Denke eher, dass hier NTLM-Fallback greift…
So zumindest meine Tests. Mein Admin-Konto war fix auf AES128/256 eingestellt, sprich MS-DSSupportedencryptiontypes = 24.
Konnte mich damit auch anmelden aber alle Kerberos-Only-Dienste schlugen fehl und ein Wireshark-Capture zeigte, dass bspw. bei Zugriffen auf Fileserver NTLM statt Kerberos verwendet wurde… klist zeigte auch keine Service-Tickets an…
Erst nachdem ich AES im DSA wieder deaktiviert habe, lief es wieder via Kerberos-Auth
Abhilfe ist da in Form von Out-Of-Band-Updates:
Server 2019: https://support.microsoft.com/en-us/topic/november-17-2022-kb5021655-os-build-17763-3653-out-of-band-8e0c94f1-0a7d-4602-a47b-1f086434bb16
Server 2016: https://support.microsoft.com/en-us/topic/november-17-2022-kb5021654-os-build-14393-5502-out-of-band-3bccb4df-bfa1-4c70-9ce3-d5842e3af467
Server 2012R2: https://www.catalog.update.microsoft.com/Search.aspx?q=KB5021653
Muss man nur auf den DCs installieren.