[English]Noch ein kleiner Nachtrag zum November 2022-Patchday. Microsoft hat mit den Sicherheitsupdates vom 8. November 2022 auch eine stufenweise Änderung am Netlogon- und Kerberos-Protokoll eingeleitet. Das Ganze wird in mehreren Stufen bis Oktober 2023 durchgeführt.
Grund sind drei Schwachstellen (CVE-2022-38023 und CVE-2022-37967) in Windows 8.1 bis Windows 11 und den Server-Pendants. Administratoren müssen entsprechend reagieren, um sicherzustellen, dass diese Änderungen in der Netzwerkkommunikation berücksichtig werden. Blog-Leser Oli hat in diesem Kommentar auf das Thema hingewiesen (danke dafür), welches in diesem heise-Foreneintrag kurz angerissen ist.
Addendum: Microsoft hat ein out-of-band Update zur Korrektur veröffentlicht – siehe Out-of-Band-Updates korrigieren Kerberos Authentifizierungsprobleme auf DCs (17. Nov. 2022).
Schwachstellen in Windows
Mit den Windows-Updates vom 8. November 2022 werden auch Sicherheitslücken in Bezug auf die Umgehung von Sicherheitsvorschriften und die Erhöhung von Berechtigungen durch PAC-Signaturen (Privilege Attribute Certificate) behoben. Die betreffenden Sicherheitsupdates beheben Kerberos-Schwachstellen, bei denen ein Angreifer PAC-Signaturen digital verändern und so seine Berechtigungen erhöhen kann. Betroffen sind folgende Windows-Versionen:
- Windows 8.1
- Windows RT 8.1
- Windows Server 2012
- Windows Server 2012 R2
- Windows 10 Version RTM bis 22H2
- Windows 11 Version 22H1 – 22H2
- Windows Server 2016 – 2022
- Windows Server 2022 Azure Stack HCI Version 22H2
- Windows 11 SE Version 21H2
wobei die obigen CVEs sich teilweise auf Windows Clients und Server, und teilweise nur auf Windows Server beziehen. Microsoft hat dazu verschiedene Support-Beiträge veröffentlicht.
- KB5020805: How to manage Kerberos protocol changes related to CVE-2022-37967
- KB5021130: How to manage the Netlogon protocol changes related to CVE-2022-38023
- KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
Welche Windows-Versionen von welchem CVE genau betroffen sind, lässt sich den oben verlinkten KB-Beiträgen entnehmen.
Vorgehen bei der Installation
Microsoft schreibt, dass die betreffenden Windows-Update auf allen Geräten, einschließlich Windows-Domänencontrollern, zu installieren sind, um Ihre Umgebung zu schützen. Wichtig ist dabei, dass alle Domänencontroller in einer Domäne zuerst aktualisiert werden müssen. Erst danach darf per Update in den Enforced Modus (erzwungenen Modus) umgeschaltet werden. Microsoft schlägt folgende Vorgehensweise vor:
- Aktualisieren Sie die Windows-Domänencontroller mit einem Windows-Update, das am oder nach dem 8. November 2022 veröffentlicht wurde.
- Versetzen Sie den Windows-Domänencontroller in den Audit-Modus, indem Sie die Registrierungseinträge hier verwenden.
- Überwachen Sie die Ereignisse, die im Audit-Modus gespeichert werden, um Ihre Umgebung zu sichern.
- Aktivieren Sie den Durchsetzungsmodus, um CVE-2022-37967 in Ihrer Umgebung zu beheben.
Schritt 1 behebt standardmäßig nicht die Sicherheitsprobleme in CVE-2022-37967 für Windows-Geräte. Um das Sicherheitsproblem für alle Geräte vollständig zu entschärfen, müssen Sie auf allen Windows-Domänencontrollern so bald wie möglich in den Überprüfungsmodus (wie in Schritt 2 beschrieben) und anschließend in den Erzwingungsmodus (wie in Schritt 4 beschrieben) wechseln. In Schritt 2 ist folgender Registrierungsschlüssel:
HKEY_LOCAL_MACHINE\System\currentcontrolset\services\kdc
um den DWORD-Wert KrbtgtFullPacSignature zu ergänzen. Der Wert kann dabei folgende Zustände annehmen:
- 0 – Disabled
- 1 – New signatures are added, but not verified. (Default setting)
- 2 – Audit mode. New signatures are added, and verified if present. If the signature is either missing or invalid, authentication is allowed and audit logs are created.
- 3 – Enforcement mode. New signatures are added, and verified if present. If the signature is either missing or invalid, authentication is denied and audit logs are created.
Ab Juli 2023 wird der Erzwingungsmodus auf allen Windows-Domänencontrollern aktiviert und blockiert anfällige Verbindungen von nicht konformen Geräten. Zu diesem Zeitpunkt können Sie das Update nicht mehr deaktivieren, aber Sie können wieder zur Einstellung des Überprüfungsmodus wechseln. Der Überprüfungsmodus wird im Oktober 2023 entfernt, wie im Abschnitt Zeitplan der Updates zur Behebung der Kerberos-Schwachstelle CVE-2022-37967 beschrieben. Microsoft verwendete eine gestufte Vorgehensweise an, um die Sicherheitsprobleme in CVE-2022-37967 für Windows-Geräte zu entschärfen. Hier die Termine:
- 8. November 2022 – Erste Errichtungsphase
- 13. Dezember 2022 – Zweite Errichtungsphase
- 11. April 2023 – Dritte Einführungsphase
- 11. Juli 2023 – Erste Durchsetzungsphase
- 10. Oktober 2023 – Vollständige Durchsetzungsphase
Details und die Registrierungseinträge sind in den oben verlinkten drei KB-Artikeln zu entnehmen.
Probleme mit gMSA und KDC
Ergänzung: Blog-Leser Marco D. hat mich per Mail auf folgenden Twitter-Beitrag aufmerksam gemacht, wo Probleme angesprochen werden. 
Die Kerberos-Pre-Authentifizierung scheitert, weil Kerberos-DC keine Unterstützung für den Verschlüsselungstyp hat. Das tritt nur auf, wenn die Eigenschaft msDS-SupportedEncryptionTypes gesetzt ist. Die unterstützten Encryption-Type-Flags sind hier dokumentiert. 
Fabian Bader gibt in Folge-Tweet (siehe oben) noch weitere Hinweise, und es gibt eine größere Diskussion. 
Test-Script, um AD-Objekte zu identifizieren
Fabian Bader hat auf Twitter einen Link auf GitHub veröffentlicht. Das dort gepostete PowerShell-Skript kann man verwenden, um jedes möglicherweise vom CVE-2022-37966-Bug betroffene AD-Objekt zu identifizieren.
Get-ADobject -LDAPFilter "(&(!(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=4))(|(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=16)(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=8)))" -Properties msDS-SupportedEncryptionTypes | Select DistinguishedName, msDS-SupportedEncryptionTypes
Er schreibt dazu: Die Einstellung auf 28 (RC4+AES128+AES256) kann eine Abhilfe sein, aber testen Sie dies oder halten Sie sich mit dem Patching zurück. Noch jemand mit diesem Problem?
Ergänzung: Im englischen Blog gibt es einen Kommentar, dass die Abfrage im Script den Wert 16 anstelle von 6 haben sollte. Der Autor des Original-Script hat es inzwischen korrigiert und ich habe dies auch oben berücksichtigt.
Microsoft untersucht das Problem
Inzwischen ist das Problem auch bei Microsoft angekommen. Microsoft Mitarbeiter Steve Syfuhs hat auf Twitter bereits reagiert und schreibt:
Not official guidance, but we’re seeing reports where certain auths are failing when users have their msDS-SupportedEncryptionTypes attribute explicitly being set to AES only (decimal 24, hex 0x18). We have another update to the KB pending, with official guidance and cause of the issue. More to follow.
Aktuell sollten Administratoren im Bereich Domain Controller also mit der Installation der Updates zurückhaltend sein,
Ergänzung: Auf reddit.com gibt es diesen Mega-Thread zu Problemen (danke an 1ST1 für den Link), wo Hinweise auf die Kerberos-Problematik – inklusive Integration von Redhat Linux zu finden sind.
Ergänzung: Microsoft hat das Problem inzwischen bestätigt, siehe Microsoft bestätigt Kerberos Authentifizierungsprobleme nach Nov. 2022 Updates.
Ähnliche Artikel:
Microsoft Office Updates (1. November 2022)
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)
Patchday: Microsoft Office Updates (8. November 2022)
Mir ist ein Fehler passiert und es hat mir zwei Blog-Beiträge zersägt und verbuxelt. Ich habe die Kommentare hier inzwischen hierhin zum korrekten Beitrag verschoben.
Betrifft dies nur die ’normalen‘ DCs, oder auch die RODCs?
Habe da leider nichts gefunden…
alle DCs, Rolle egal.
Wir haben nach den November-Updates heute erhebliche Probleme mit Citrix-Servern, bei denen der Dienst „Citrix Standarddomänendienste“ nicht startet. In Folge kann sich niemand am Terminalserver anmelden. Kann das jemand bestätigen?
Installiert wurden KB5019966 und KB5020615.
Hat es was mit diesem Thema zu tun? November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll
Citrix hat mitlerweile einen KB Artikel veröffentlicht:
DAAS – VDAs not registering with Cloud Connectors after applying Microsoft Update KB5019966
Dort geht es zwar um die VDA zu Cloud Verbindung, aber ich könnte mir gut vorstellen, dass der beschriebene Workaround auch hier hilft.
Ich vermute mal, dies Änderung wird unsere Produktionsmaschinen mit Windows XP und Windows 7 aus der Domäne kicken. Oder habe ich da was falsch verstanden?
Das ist gut möglich!
Ggf, kann man die Absicherung auch nach July 2023 deaktivieren. (Mit Sicherheitsverlust.)
Schau mal hier
KB5021130: How to manage the Netlogon protocol changes related to CVE-2022-38023
Unter Registry steht:
2 – Enforcement mode. All clients are required to use RPC Seal, unless they are added to the „Domain Controller: Allow vulnerable Netlogon secure channel connections” group policy object (GPO).
Noch mehr Infos
Netlogon: Domänen-Controller verweigern Verbindung zu unsicheren Geräten
Das Deaktivieren soll angeblich nur bis Oktober funktionieren.
du hast Produktionsmaschinen in der Domäne? interessant
Darf ich off-topic/interessehalber fragen wie du bei XP Maschinen umgehst die eine SMBv1 Freigabe benötigen – sofern zutreffend?
SMBv1 kann man immer noch einschalten.
Man kann auch ein Linux-System dazwischen schalten, das mountet die SMBv2, SMBv3 Freigabe, und gibt sie wieder als SBMv1 wieder frei, oder als NFS, …!
Also hier ist 1ST1 nicht alleine, auch wir haben noch Produktionsmaschinen im Netzwerk mit WindowsXP, welche immer noch kräftig auf die DCs zugreifen und GPOs anwenden. Das Ersetzen dieser WindowsXP Maschinen ist teilweise nicht möglich. Deshalb wäre es auch für mich interessant welche Auswirkung diese Änderungen auf die Auth/Anmeldung von XP-Clients hat.
Stand jetzt gibt es bei einem Kunden ein Problem, das die Gruppenrichtlinen für die Netzwerklaufwerke nicht verarbeitet werden (Eventlog ID 1053, USERENV, Windows cannot determine the user or computer name. Fehler kann mit gpupdate / force auch erzwungen werden.)
Das richt nach einem Kerberos Problem:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/event-id-1053-gpupdate-force-command
Das manuelle Verbinden des Netzlaufwerks mit net use funktioniert.
Umgebung:
Windows 2012R2 DC mit November Patch, Windows XP SP3. Zugriff auf einen Win 2003 Server.
Registrykeys für die Überwachunng sind jetzt gesetzt. Mal schauen was rauskommt und was passiert, wenn man die GPO „Domain Controller: Allow vulnerable Netlogon secure channel connections“ group policy object (GPO)“ setzt.
Aber eins nach dem anderen.
Wenn man den Rechner in die GPO „Domain Controller: Allow vulnerable Netlogon secure channel connections“ group policy object (GPO)“ setzt. ist die Userenv Meldung weg und die Netzlaufwerke sind verbunden.
Gibt es Informationen wie sich dieser Prozess ggf. auf ältere Betriebssysteme als die im Artikel angegebene auswirken könnte ?
Sieht aus, als ob das November Update (KB5019959) auf Clients Microsoft DirectAccess „kaputt“ patcht:
DirectAccess keeps reconnecting after installing Windows 11 updates
Ja, können wir bestätigen. Bei einem Kunden legt das Update Direct Access komplett lahm. Aktuell hilft nur die Deinstalltion
Ich habe es mal in einen separaten Beitrag rausgezogen.
DirectAccess funktioniert nach November 2022 Windows Updates nicht mehr
Bei uns gibt es wie im Tweet erwähnt mit accounts, die Kerberos AES 128/256 Bit support aktiviert haben [die Probleme]. Das sollte eigentlich kein Problem sein, ist es aber.
Ich gehe davon aus, dass MS hier nachbessern muss und wird.
Benutzer der „Protected User“ Gruppe haben Probleme mit Server <2019, da schlägt die Authentifizierung fehl. Selbst wenn wir RC4 wieder zulassen, wie in dem Twitterbeitrag angemerkt (hatten vorher alles auf AES Only stehen).
Das kann ich nicht bestätigen. Habe auch Protected User, die laufen. DC-Struktur 2019, Member 2016/19/22, RDSH usw., das tut. Aber irgendein Zusammenhang in der Richtung dennoch denkbar.
Dann verschiebe ich mal meinen Kommentar wie folgt:
Gibt es Informationen wie sich dieser Prozess ggf. auf ältere Betriebssysteme als die im Artikel angegebene auswirken könnte ?
Hintergrund ist, das vielen Firmen z.B. Ihre älteren Archiv- und ERP-Systeme gegenüber den (Finanz-)Behörden usw. noch ein paar Jahre am Laufen lassen müssen.
Sowas hat man doch in einer abgetrennten Umgebung oder so?
Scheint so als würde MS mit dem Update RC4 enforcen also genau das Gegenteil wie eigentlich geplant, aber ohne RC4 scheint es nicht mehr zu gehen. Falls man bei krbtgt RC4 geblockt hat, muss man RC4 zuerst enablen und dann das Pw von krbtgt zurücksetzen damit wieder RC4 Kompatbilität besteht.
Scheinbar hat MS nur gegen die Default Settings getestet, aber nicht gegen deren Security Baseline wo ja auch empfohlen wird die Encryption Types auf AES und Future einzuschränken (RC4 und DES fällt raus)
Wenn das Powershell Testscript nichts ausgibt bzw. die Ausgabe leer bleibt, ist also kein AD Objekt betroffen?
Kann dazu vielleicht noch jemand was sagen?
Ja das würde mich auch interessieren.
Muss das am DC ausgeführt werden oder nur an irgendeinem Client in der Domäne?
Besten Dank
So sah es an meinem Client aus:
PS C:\WINDOWS\system32> Get-ADobject -LDAPFilter „(&(!(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=4))(|(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=16)(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=8)))“ -Properties msDS-SupportedEncryptionTypes | Select DistinguishedName, msDS-SupportedEncryptionTypes
PS C:\WINDOWS\system32>
Das PS-Script muss auf dem DC ausgeführt werden. Bei mir wird nichts ausgegeben.
am DC gleiches Bild… es tut kurz was und springt dann zurück in Eingabemodus
Hab mal einen Testuser angelegt und bei „Konto“ die 3 Haken bzgl. Kerberos („nur Kerberos“, 128bit, 256bit) gesetzt und das Script nochmal ausgeführt – jetzt kommt eine Ausgabe
PS C:\Windows\system32> Get-ADobject -LDAPFilter „(&(!(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=4))(|(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=16)(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=8)))“ -Properties msDS-SupportedEncryptionTypes | Select DistinguishedName, msDS-SupportedEncryptionTypes
DistinguishedName msDS-SupportedEncryptionTypes
—————– —————————–
CN=test test,OU=Benutzer,OU=xxx,DC=xxx,DC=local 24
PS C:\Windows\system32>
Ergänzend zu meinem anderen Kommentar:
Wenn also keine Ausgabe aus dem Script erfolgt kann ich den DC normal patchen ohne die Probleme zu bekommen?
Schöne Grüße
Sebastian
Ich habe erstmal nur 1 von 3 DCs aktualisiert
Wir haben noch 2003er Sevrver Produktiv :-(
Alles Client und Server die sich am upgedateten DC anmelden (echo %logonserver%) kommen per DNS nicht mehr auf die alten Server.
Via ip / UNC ging der Zugriff.
Erfolgt die Anmeldung an einem ungepatchten DC geht die Anmeldung.
meinst du mit „alten“ Server die 2003 Server?
hast du das mal ausprobiert:
Microsoft sieht dafür eine neue Einstellung in der Gruppenrichtlinien unter Computerkonfiguration => Richtlinien => Windows-Einstellungen => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen vor. Sie heißt Domain controller: Allow vulnerable Netlogon secure channel connections („Domänen-Controller: Sichere Verbindungen mit verwundbaren Kanäle über den Anmeldedienst (Netlogon) zulassen“).
Nach Aktivieren der Richtlinie weist man ihr die Computer- oder Service-Konten zu, die sich über eine unsichere Verbindung anmelden dürfen. Dabei sollte es sich natürlich um keine dauerhafte Lösung handeln, sondern sie soll nur dazu dienen, um die Zeit bis zur Aktualisierung der betreffenden Geräte zu überbrücken.
Es war bei einem Kunden von uns genau ähnlich. DCs mit November gepatchted und die Verbindungen zu Windows 2003 Server war nicht mehr möglich. Weder via SMB noch SQL (Windows Auth), der auf dem Server läuft. Das CRM 3.0 konnte auch keine Verbindung zum SQL Server der am selber 2003 Server läuft herstellen. Nachdem das Updates von den DCs deinstalliert wurde, war der Zugriff wieder möglich.
Der 2003 Server konnte allerdings immer problemlos auf die Dienste der anderen Services zugreifen.
In der heutigen Zeit mit Server 2003 ist schon happig, aber gut, in einem anderen Beitrag habe ich Server 2000 !!! gelesen….
Man sollte halt den Kunden mal aufklären, was alles passieren kann mit einer so alten Server Version. Als Dienstleister würde ich da graue Haare bekommen. Alternativ liegt das dann komplett in der Verantwortung des Kunden, wenn etwas ausfällt.
Bei uns –>
Physischer DC 2019 – alles in Ordnung
Virtueller DC 2016 – alles in Ordnung
Es handelt sich wohl doch leider (mal wieder) um einen Bug:
https://imgur.com/a/BtEJyyO
Moin,
habt ihr die Regwerte wie z.B. RequireSeal unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters selber angelegt? Auf meinen DCs werden diese nach der PatchInstallation nicht angelegt.
Habe die Patches auf Windows Server 2012R2 DCs installiert.
Gruß
Anton
Auf meinen DCs (Windows Server 2016) finde ich den Wert auch nicht, nur „RequireSignOrSeal“. Ist jetzt die Frage, ob das mit „RequireSeal“ gemeint ist (also quasi Typo von MS) oder ob es sich um zwei verschiedene Werte handelt.
Ich habe die Einträge manuell gesetzt, da mir das Auditing wichtig ist bevor mir ein kommendes Update plötzlich den Riegel vorschiebt.
Das Update allein setzt hier die Einträge aber nicht (Server 2016). Das ist glaube ich auch kein Schreibfehler, sondern der Eintrag wird schlichtweg nicht gesetzt mMn, da der zweite wichtige Eintrag in HKLM\SYSTEM\CurrentControlSet\Services\Kdc
auch nicht gesetzt wurde nach dem Update. Auch diesen habe ich manuell angelegt.
Gruß
Kein einziger der in den verlinkten KB-Artikeln erwähnten Registry-Schlüssel wurde hier durch die Installation erzeugt und mit dem erwähnten Default-Wert belegt. Dass man diese sämtlich manuell erzeugen muss, wird aus den Beschreibungen allerdings überhaupt nicht klar. Wenn in der Beschreibung steht, dass nach der Installation der Updates folgender Schlüssel zur Verfügung steht und weiter unten dann ein Default-Wert aufgeführt wird, dann geht man in der Regel davon aus, dass das durch das Einspielen der Updates automatisch erledigt wird.
Und wie funktioniert dann der nicht mehr abschaltbare Enforcement-Mode, wenn die Schlüssel nicht da sind? Gar nicht?
Wie stellt Microsoft sich das eigentlich genau vor?
Aber so ist das doch immer, das ist doch jetzt nicht wirklich eine Überraschung?
Moin,
gibt es einen offiziellen Link wo die von Microsoft vorgegebene Vorgehensweise bei der Installation beschrieben ist?
Danke und Gruß
Bent
Hat schon jemand erste Erfahrungen, wie sich „Fremdsysteme“ gegen einen gepatchten DC verhalten? Hier sind gemeint:
– Kopier- und Scan-Geräte mit denen Scan2File (Scan2PDF) gemacht wird
z.B. von KonicaMinolta/Toshiba/Kyocera/… und den anderen Verdächtigen
– TrueNAS Systeme, die Shares in der Domäne zur Verfügung stellen.
Wahrscheinlich werden die zunächst alle noch vom DC akzeptiert, aber kann man in den Monitor-Logs erkennen, dass diese Geräte und Systeme eine entsprechende Anpassung benötigen um nicht irgendwann aus der Domäne zu fliegen?
Schnelle soforthilfe für alle, bei denen zum Beispiel keine Dienste mehr mit Domänenanmeldungen ausgeführt werden können, oder aber Laptops keine WLAN Verbindung über ein Zertifikat aufbauen können.
Diese 3 Registryeinträge in alle DCs einfügen:
Das verschaft auf jeden Fall erstmal Zeit.
reg add „HKLMSYSTEMCurrentControlSetserviceskdc“ /v KrbtgtFullPacSignature /t REG_DWORD /d 0 /f
reg add „HKLMSYSTEMCurrentControlSetServicesNetlogonParameters“ /v RequireSeal /t REG_DWORD /d 0 /f
reg add „HKLMSYSTEMCurrentControlSetserviceskdc“ /v ApplyDefaultDomainPolicy /t REG_DWORD /d 0 /f
Quelle: Patch Tuesday Megathread (2022-11-08)
Laut Microsoft soll dieser Key das Problem beheben.
reg add „HKLM\SYSTEM\CurrentControlSet\services\kdc“ /v ApplyDefaultDomainPolicy /t REG_DWORD /d 0 /f
Der Key muss am DC eingespielt werden.
Danke!
Hat sofort funktioniert. Wir kommen damit wieder auf den Server 2003 Fileserver!
Das war auch unsere Rettung.
Danke!
Bei einem Freund funktioniert seit Donnerstag die komplette SAP Struktur nicht mehr, da die Authentifizierung mit Keberos nicht mehr funktioniert.
Naja da frage ich mich wieso der Dienstleister einfach blind die Updates installiert und Jaa…
Ich werde vor dem Patchen des 1. DCs diese Registrykeys setzen, dann sollte ja hoffentlich erstmal nichts passieren, wenn der DC mit dem Patch hochfährt:
KrbtgtFullPacSignature /t REG_DWORD /d 1 /f
RequireSeal /t REG_DWORD /d 0 /f
Inzwischen hat MS das als Problem gelistet:
https://learn.microsoft.com/en-us/windows/release-health/status-windows-10-22H2#2953msgdesc
Besonders spannend ist dieser Text von MS: „Next steps: We are working on a resolution and estimate a solution will be ready in the coming weeks. This known issue will be updated with more information when it is available.“
Die Betonung liegt dabei auf: „will be ready in the coming weeks“
Ich würde ja gerne mal deren Software-Tester kennenlernen… :(
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
Mahlzeit.
Aktuell habe ich so viel gelesen, dass ich nicht mehr mit komme…
Muss man die Reg. Einträge setzen? Ist das nicht eigentlich Aufgabe des Updates?
Die Updates sind bei uns alle durchgelaufen und aktuell haben wir in der normalen Umgebung (Win10,Win11, Server 2012-2019 inkl. RDP Server, SQL,…) keine Probleme.
Alles läuft wie es sollte.
Jetzt haben wir allerdings noch 3 alte Maschinen mit XP im Einsatz. Und dort funktioniert der Zugriff auf die lokalen Freigaben per \\maschine1\Freigabenxyz nicht mehr. Per \\IPAdresse\Freigabexyz funktioniert alles.
Eine Maschine ist Mitglied der Domäne. Das SMB V1 Protokoll ist aktiv.
Unsere TestVD mit aktuell noch „altem Updatestand“ hat auch keinen Zugriff mehr.
Stehe irgendwie auf dem Schlauch. Hängt der DC dort irgendwo zwischen, obwohl es lokale Freigaben sind?
Unsere TestVD hat nun Zugriff auf eine Freigabe, nachdem ich mich als Domänenuser an einem Win7 angemeldet habe. Ist es der lokale User funktioniert die Freigabe nicht mehr.
Korrektur: Nach einmaliger Anmeldung als Domänenuser funktioniert die Freigabe auch, wenn der lokale Úser angemeldet ist.
Hey Frank,
gibt es noch weitere Erfahrung bzw. Workarounds wie du das Thema Windows XP gelöst hast? Wir stehen kurz vorm Update und haben noch etliche WinXP (Produktionsmaschinen) im Einsatz – ich denke wir werden da sicherlich in ein Problem fahren. Deshalb bin ich für jeden Tipp dankbar.
Merci ;)
Leider noch nicht. Aktuell haben wir die entsprechenden Verbindungen auf die IP Adresse umgestellt. Somit funktionieren die Verbindungen zu den Maschinen.
Das wird aber auch keine Dauerlösung sein können.
Hallo Frank,
bist du in dem Thema weitergekommen oder hast etwas neues dazu gelesen?
Hallo,
wir haben hier viele Linux basierte Web-Apps, die SSO per Kerberos machen. Im Firefox und Chrome klappt die Anmeldung, nur im MS Edge nicht.
Kennt den Effekt jemand?
Hat sich erledigt. Wenn der Edge keine Erlaubnis für SSO hat…
Servus,
Wenn ich den PS1-Befehl:
Get-ADobject -LDAPFilter „(&(!(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=4))(|(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=16)(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=8)))“ -Properties msDS-SupportedEncryptionTypes | Select DistinguishedName, msDS-SupportedEncryptionTypes
absetze, kommen bei mir Accounts und ComputerObjekte welche im Attribute „msDS-SupportedEncryptionTypes“ mit 16 (0x10) sowie 24 (0x18) zurück. Ich verstehe die ganzen Artikel leider nicht richtig – kann ich hier nun proaktiv (vor Patch Einspielung) diese Werte anpassen oder passiert bei diesen EncryptionTypes nichts? Es ist ja immer nur die Rede von RC4, dies ist aber hier ja garnicht aktiv. Vielleicht hat ja jemand eine Antwort parat.
Danke.
Hi,
vlt. hilft dir dieser Artikel hier:
https://www.der-windows-papst.de/2021/07/15/kerberoasting-gmsa-accounts/
Hier gibt es auch eine verständliche Tabelle der Dezimalwerte ;-)
Bei beiden Werten wird wohl was passieren, da diese ja KEIN RC4 mehr unterstützen. So habe ich es verstanden. Die Probleme treten dann auf, wenn du wie bei dir der Fall AES only per GPO gesetzt und damit deine Accounts mit dieser Enc erstellt wurden. Siehe hier:
https://twitter.com/fabian_bader/status/1590428401310912512
Ich weiß aber nicht, ob man auch die Passwörter der Accounts ändern muss, wenn man manuell die Keys umschreibt… ich bin auch hin und hergerissen, ob ich mich „trauen“ soll, in meinen beiden INF die Updates zu deployen…
Wenn ich es richtig verstanden habe, betrifft es also nur Netzwerke, in denen per GPO von den default-Werten bei den EncryptionTypes abgwichen wurde – korrekt?
Hallo Robert,
ja genau, so verstehe ich das auch.
Wenn du die MS Hardening Guidelines befolgt, auf AES wert gelegt und DES und RC4 ausgeschlossen hast, dann betrifft es dich, sonst nicht.
Schon strange, wenn man genau darüber nachdenkt…
Man könnte vermuten, dass dort die linke Hand nicht mehr weiß was die rechte Hand macht… und das bei so einer Firma…
Ich blicke hier so langsam nicht mehr durch. Bei uns steht der Registrykey „Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren“ auf „Nicht definiert.“ Kann mir jemand sagen, ob wir hiervon betroffen sind: „Microsoft hat mit den Sicherheitsupdates vom 8. November 2022 auch eine stufenweise Änderung am Netlogon- und Kerberos-Protokoll eingeleitet. Das Ganze wird in mehreren Stufen bis Oktober 2023 durchgeführt. Grund sind drei Schwachstellen (CVE-2022-38023 und CVE-2022-37967) in Windows 8.1 bis Windows 11 und den Server-Pendants. Administratoren müssen entsprechend reagieren, um sicherzustellen, dass diese Änderungen in der Netzwerkkommunikation berücksichtig werden.“
Wenn du die GPO niemals benutzt hast, dann stehen die Werte des msDS-SupportedEncryptionTypes innerhalb deiner Computer / Service / Userkonten auf 28 und damit Default.
Mit dem Defaultwert 28 wird RC4 und AES supported und du solltest safe sein, die Updates zu installieren.
Die böse Überraschung haben nur diejenigen gehabt, die AES only eingestellt hatten, also msDS-SupportedEncryptionTypes Werte von 16 oder 24.
Führe doch das PS Script oben auf deinem DC aus, dann siehst du gleich, ob es Accounts gibt, die andere Werte wie 28 drin stehen haben… ;-)
Vielen Dank für die schnelle Antwort. Das PS-Script wirft nix raus. War mir nur etwas unsicher bei all dem trouble, den MS so in letzter Zeit verursacht.
ich habs so getestet, dass ich ein Computeraccount neu erstellt und dann den Wert auf 24 gesetzt habe. Danach warf das PS genau diesen Client als „impacted“ raus… Nachdem ich den Account dann wieder auf 28 gesetzt hatte, war die Ausgabe auch wieder leer…damit konnte ich prüfen, ob es funzt, oder nicht…
Korrektur: Meine natürlich nicht Registry-Key sondern Sicherheits-Richtlinie.
Hi an alle,
ist es nicht besser mit AES zu bleiben und der Schlussel „reg add „HKLM\SYSTEM\CurrentControlSet\services\kdc“ /v ApplyDefaultDomainPolicy /t REG_DWORD /d 0 /f“ auf DCs zu einfügen, als RC4 zu aktivieren ? Beide Lösungen gehen, aber RC4 zu aktivieren, finde ich schlimmer… Ich habe momentan nur der Schüssel „ApplyDefaultDomainPolicy“ auf die DCs eingefügt, und Kommunikation geht wieder mit AES (RC4 aus).
hi,
in deinem Fall ist es sicher besser, bei AES zu bleiben…natürlich…
Wir hatten bei uns die GPO für AES only nie gesetzt und sind deswegen auf Default… darum hoffe ich auch drauf, dass wenn ich am Freitag die erste INF update, nichts passiert ;-)
Hallo zusammen, was passiert eigentlich, wenn die November-Updates auf allen Clients installiert sind und die DCs die November Updates nicht erhalten?
Können sich die Clients dann nicht mehr anmelden?
hi,
wir haben auf allen Win10/Win11 22H2 Clients und Servern 2k12R2, 2k19 die Updates installiert, außer halt auf den DCs…. bin gespannt, wenn ich am Freitag die Updates auf den DCs installiere, ob es dann immer noch so ist… ich hab ein wenig Angst davor… ohohohho
Es funktioniert in der Konstellation aber alles… es gab keine Probleme…
Es weiß nur niemand, was der Wert: ApplyDefaultDomainPolicy tatsächlich bewirkt oder abschaltet. Von MS kam er offiziell nie raus und das war sicher auch so gedacht. Es gibt aber seit gestern OOB Updates:
https://learn.microsoft.com/en-us/windows/release-health/windows-message-center
Ich würde die OOB Updates installieren und den Wert: ApplyDefaultDomainPolicy wieder löschen.
ich habe gleich gemacht, alles funktionieren jetzt wie die sollten…
Funktionieren, die OOB Updates bei Euch wirklich? Ich habe am Freitag OOB auf Windows 2016 installiert und die den Wert: ApplyDefaultDomainPolicy entfernte. Ich konnte erfolgreich auf den Windows 2003 SMB Share zugreifen. Nach ca. 5 Stunden, war das nicht mehr möglich. Der Wert „ApplyDefaultDomainPolicy“ wurde von mir nachgetragen, veränderte allerdings nicht die Situation. Nach der Deinstallation vom OOB war der Zugriff wieder möglich. Aktuelle Status:
DC1: Windows 2012 R2 – November Update 8.11 + ApplyDefaultDomainPolicy = 0
DC2: Windows 2016 – Oktober Update.
Habe heute bei einem Kunden das OOB Update auf den beiden 2016 DCs eingespielt – kein Zugriff auf die SMB Freigabe vom 2003 Server. Deinstalliere das OOB Update nun wieder.
Auf meinem normalen DC kommt seit Installation von KB5019964 alle paar Tage folgende Meldung betreffend meinen schreibgeschützten DC:
Die Signatur auf dem PAC von [mein schreibgeschützter DC in Außenstelle] konnte vom KDC während der TGS-Verarbeitung nicht verifiziert werden. Dies deutet darauf hin, dass das PAC verändert wurde.
Sollte ich eurer Meinung nach auch das OOB-Update installieren, oder gibt es hierfür noch andere Lösungsansätze?
Meine Internetrecherche ergab folgende Seite, allerdings bezieht sich die nur auf Windows Server2008 R2 und das das normal sei:
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc733969(v=ws.10)?redirectedfrom=MSDN