Änderungen am Netlogon- und Kerberos-Protokoll durch Nov. 2022 Updates, es gibt Probleme

Mit den November 2022 Sicherheitsupdates startet Microsoft mit dem stufenweisen Rollout von Änderungen am Netlogon- und Kerberos-Protokoll. Administratoren müssen in DC-Umgebungen bestimmte Schritte unternehmen und Sachen berücksichtigen. Bis Oktober 2023 soll das Ganze über die Bühne sein (dann wird der Enforement Mode aktiviert und ist nicht mehr abschaltbar).

So weit die Theorie. In der Praxis sieht es so aus, dass durch die Windows-Sicherheitsupdates vom 8. November 2022 die Kerberos-Verbindungen zum DC in bestimmten Konstellationen in Fehler laufen. Microsoft untersucht bereits. Ich habe den aktuellen Stand in folgendem Beitrag zusammen gefasst (das Problem hat einige DC-Administratoren erwischt).

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

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4584506455

Url: https://administrator.de/contentid/4584506455

Ausgedruckt am: 23.11.2024 um 08:11 Uhr

13 Kommentare

Neuester Kommentar

Hallo,

Da scheint etwas dran zu sein. Bei mir hat es unmittelbar nach dem Reboot der DCs nach KB5019966 und KB5020627 die WMI-Abfragen unseres PRTG-Servers entschärft. Bin aber noch an der Fehlersuche.

Grüße

lcer

@lcer00
Sind das angepasste WMI-Sensoren? Unsere Standardsensoren laufen nachwievor ohne Probleme.

Gruß

Zitat von @Coreknabe:

@lcer00
Sind das angepasste WMI-Sensoren? Unsere Standardsensoren laufen nachwievor ohne Probleme.

Gruß

Die Sensoren sind Original. Ich hatte aber die WinRM-Configuration angepasst.

PS C:\Windows\system32> winrm g winrm/config
Config
    MaxEnvelopeSizekb = 500
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false [Source="GPO"]  
        Auth
            Basic = false [Source="GPO"]  
            Digest = false [Source="GPO"]  
            Kerberos = true [Source="GPO"]  
            Negotiate = true [Source="GPO"]  
            Certificate = true
            CredSSP = false [Source="GPO"]  
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts = 192.168.200.39 [Source="GPO"]  
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 1500
        EnumerationTimeoutms = 240000
        MaxConnections = 300
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false [Source="GPO"]  
        Auth
            Basic = false [Source="GPO"]  
            Kerberos = true [Source="GPO"]  
            Negotiate = true [Source="GPO"]  
            Certificate = true
            CredSSP = false [Source="GPO"]  
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = 192.168.0.1-192.168.0.255,192.168.5.1-192.168.5.255,192.168.1.1-192.168.1.255,192.168.200.1-192.168.200.255,192.168.15.2-192.168.15.199,192.168.95.2-192.168.95.255,192.168.50.100-192.168.50.199 [Source="GPO"]  
        IPv6Filter [Source="GPO"]  
        EnableCompatibilityHttpListener = false [Source="GPO"]  
        EnableCompatibilityHttpsListener = false [Source="GPO"]  
        CertificateThumbprint = e4......... ae bb
        AllowRemoteAccess = true [Source="GPO"]  
    Winrs
        AllowRemoteShellAccess = true [Source="GPO"]  
        IdleTimeout = 7200000
        MaxConcurrentUsers = 2147483647
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 2147483647
        MaxMemoryPerShellMB = 2147483647
        MaxShellsPerUser = 2147483647

PS C:\Windows\system32> winrm e winrm/config/listener
Listener [Source="GPO"]  
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 192.168.0.153

Listener
    Address = *
    Transport = HTTPS
    Port = 5986
    Hostname = host......
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint = e4 ..... bb
    ListeningOn = 192.168.0.153

Außerdem sind die Abfragebenutzer, die PRTG verwendet, Mitglied der Gruppe "Protected Users".

Bin am suchen ...

Grüße

lcer

Edit: PRTG kann glaube ich kein Kerberos. Die Absicherung der Verbindungen habe ich über die Windows Firewall über Verbindungssicherheitsregeln gemacht.

Sieht so aus, als hättest Du Recht:
https://kb.paessler.com/en/topic/88643-kerberos-authentication

https://kb.paessler.com/en/topic/89790-open:-feature-request:-support-kerberos-authentication-for-wmi-sensors

PRTG hinkt da teils leider sehr hinterher. Anderes Beispiel: Wenn ich an unseren Synology die Verbindungseinstellungen TLS- / SSL-Profilebene auf "Moderne Kompatibilität" setze, klappt das Monitoring der HTTPS-Verbindung / Zertifikat seitens PRTG auch nicht mehr. Aussage Support: Wird noch nicht unterstützt. Na denn...

Gruß

Hallo,

Microsoft hat Probleme mit der Kerberos-Authentifizierung bestätigt: https://learn.microsoft.com/de-de/windows/release-health/status-windows- ... Ob das auch mein Problem ist, weiss ich allerdings noch nicht.

Grüße

lcer

Hallo Icer00

Wir hatten auch Probleme nach den Updates. Diese konnten entweder mit dem Attribut msDS-SupportedEncryptionTypes auf dem Computerobjekt oder des Service Benutzers gelöst werden (Wert=28, siehe Printscreen).

Im PRTG hatte ich aber noch einen speziellen Fall.. ein altes unsupportetes Betriebssystem... darf gar nicht schreiben was das war. Die Lösung war ein lokaler Benutzer auf dem System zu erstellen und mit diesem zu verbinden... Monitoring läuft wieder.

Gruess
Luke

Moin,
Out-of-Band-Updates korrigieren Kerberos Authentifizierungsprobleme auf DCs (17. Nov. 2022)

Gruß,
Dani

Hallo,

die Updates haben meine WMI-Sensoren wieder zum laufen gebracht. Es hing dann tatsächlich dem msDS-SupportedEncryptionTypes Attribut zusammen. Dieses wurde offenbar durch die Häkchen bei „Dieses Konto unterstützt Kerberos-AES-128-Bit-Verschlüsselung“ und bei „Dieses Konto unterstützt Kerberos-AES-256-Bit-Verschlüsselung“ gesetzt. Ich musste das Attribut allerdings nicht manuell ändern. Nach dem Update KB5021655 auf dem DC ging alles wieder.

Grüße

lcer

Hallo zusammen,

erstmal danke für die Aufnahme

Wir haben auch seit Donnerstag nach dem Update und Notfall-Patch riesen Probleme mit der Authetifizierung.
Wir nutzen Windows Server 2012 R2 als DC und 2008 R2 mit Exchange 2010.

Das Problem ist weitreichend, wie z.B.:
- Outlokk, dass immer wieder zur Eingabe des Passwortes auffordert und es dann nicht behält.
- Anmeldungen an Terminalserver die mal funktionieren und mal nicht.
- Laufwerkszugriffe die auch sporadisch nicht greifen und dann plötzlich wieder.

Ich bin mit meinem Latein echt am Ende und weiß nicht wo ich noch anstzen soll.
Zur Zeit wirft mir der Exchange den Fehler:
Security-Kerberos ID 7
-Das digital signierte Privilege Attribute Certificate (PAC), das die Berechtigungsinformationen für Client "Server" in Bereich "Domain" enthält, konnte nicht überprüft werden.

Hat denn jemand das gleiche Problem oder vielleicht sogar eine Lösung?

Ich danke euch für ein Feedback.

Grüße Marco

reg add "HKLM\SYSTEM\CurrentControlSet\services\kdc" /v ApplyDefaultDomainPolicy /t REG_DWORD /d 0 /f  

https://www.borncity.com/blog/2022/11/10/november-2022-updates-fr-window ...

und eventuell

reg add "HKLM\SYSTEM\CurrentControlSet\services\kdc" /v KrbtgtFullPacSignature /t REG_DWORD /d 0 /f  

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" /v RequireSeal /t REG_DWORD /d 0 /f  

Alles auf den DCs

Eigentlich sollten die Probleme durch das Update vom 17.11. ausgebessert sein.
BornCity

Hallo chaot1coz,

ich habe den Notfallpatch auch eingespielt aber anscheinend hat das nicht so ganz geholfen.
Ich habe die 3 Befehle nun eingegeben und es scheint zumindest auf dem Terminalserver ohne erneute Passwortabfrage wieder zu laufen.
Ich bin noch am testen und hoffen, dass es das nun war.
Vielen Dank erstmal für die schnelle Hilfe