November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll

Windows[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.


Anzeige

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.

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:

  1. Aktualisieren Sie die Windows-Domänencontroller mit einem Windows-Update, das am oder nach dem 8. November 2022 veröffentlicht wurde.
  2. Versetzen Sie den Windows-Domänencontroller in den Audit-Modus, indem Sie die Registrierungseinträge hier verwenden.
  3. Überwachen Sie die Ereignisse, die im Audit-Modus gespeichert werden, um Ihre Umgebung zu sichern.
  4. 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:


Anzeige

  • 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. Kerberos Issues after Nov. 2022 updates 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. Kerberos Issues after Nov. 2022 updates Fabian Bader gibt in Folge-Tweet (siehe oben) noch weitere Hinweise, und es gibt eine größere Diskussion. Kerberos Issues after Nov. 2022 updates

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)


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Netzwerk, Sicherheit, Störung, Update, Windows, Windows Server abgelegt und mit , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

78 Antworten zu November 2022-Updates für Windows: Änderungen am Netlogon- und Kerberos-Protokoll

  1. Günter Born sagt:

    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.

  2. Robert sagt:

    Betrifft dies nur die 'normalen' DCs, oder auch die RODCs?

    Habe da leider nichts gefunden…

  3. Mario sagt:

    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.

  4. ReFe sagt:

    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?

  5. RalphAndreas sagt:

    Gibt es Informationen wie sich dieser Prozess ggf. auf ältere Betriebssysteme als die im Artikel angegebene auswirken könnte ?

  6. Bembel sagt:

    Sieht aus, als ob das November Update (KB5019959) auf Clients Microsoft DirectAccess "kaputt" patcht:

    DirectAccess keeps reconnecting after installing Windows 11 updates

  7. Markus K. sagt:

    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.

  8. Jörg sagt:

    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).

    • MJ sagt:

      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.

  9. RalphAndreas sagt:

    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.

  10. Michael sagt:

    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)

  11. techee sagt:

    Wenn das Powershell Testscript nichts ausgibt bzw. die Ausgabe leer bleibt, ist also kein AD Objekt betroffen?

    • Günni sagt:

      Kann dazu vielleicht noch jemand was sagen?

      • Sebastian sagt:

        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>

        • smily5 sagt:

          Das PS-Script muss auf dem DC ausgeführt werden. Bei mir wird nichts ausgegeben.

          • Sebastian sagt:

            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>

          • Sebastian sagt:

            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

  12. Daniel Hochfeld sagt:

    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.

    • Dominik sagt:

      meinst du mit "alten" Server die 2003 Server?

    • jup sagt:

      hast du das mal ausprobiert:
      Microsoft sieht dafür eine neue Einstellung in der Gruppenrichtlinien unter Computer­konfiguration => Richt­linien => Windows-Einstellungen => Sicherheits­einstellungen => Lokale Richtlinien => Sicherheits­optionen 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.

  13. Moto sagt:

    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.

    • Dominik sagt:

      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

  14. Michael R. sagt:

    Es handelt sich wohl doch leider (mal wieder) um einen Bug:

    https://imgur.com/a/BtEJyyO

  15. Anton sagt:

    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

    • Anonymous sagt:

      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.

      • Carsten sagt:

        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ß

    • M.D. sagt:

      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?

  16. Bent sagt:

    Moin,

    gibt es einen offiziellen Link wo die von Microsoft vorgegebene Vorgehensweise bei der Installation beschrieben ist?

    Danke und Gruß
    Bent

  17. M.D. sagt:

    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?

  18. Frank sagt:

    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)

  19. Lauer Thomas sagt:

    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.

  20. Dominik sagt:

    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…

  21. MG sagt:

    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

  22. Robert sagt:

    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… :(

  23. SCCM-Uwe sagt:

    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

  24. Frank sagt:

    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?

    • Frank sagt:

      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.

    • ErazerMe sagt:

      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 ;)

  25. Klaus sagt:

    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?

  26. Erazerme sagt:

    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.

    • Rene sagt:

      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…

      • Robert sagt:

        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?

        • Rene sagt:

          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…

  27. smily5 sagt:

    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."

    • Rene sagt:

      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… ;-)

      • smily5 sagt:

        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.

        • Rene sagt:

          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…

  28. smily5 sagt:

    Korrektur: Meine natürlich nicht Registry-Key sondern Sicherheits-Richtlinie.

  29. Octavian sagt:

    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).

    • Rene sagt:

      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 ;-)

  30. Stas sagt:

    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?

    • Rene sagt:

      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…

  31. IXSOL sagt:

    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.

    • Octavian sagt:

      ich habe gleich gemacht, alles funktionieren jetzt wie die sollten…

    • Moto sagt:

      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.

      • Fk sagt:

        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.

  32. Andreas Wass sagt:

    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

Schreibe einen Kommentar zu Robert Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

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.