Ä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
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/knowledge/aenderungen-am-netlogon-und-kerberos-protokoll-durch-nov-2022-updates-es-gibt-probleme-4584506455.html
Ausgedruckt am: 24.12.2024 um 19:12 Uhr
13 Kommentare
Neuester Kommentar
@lcer00
Sind das angepasste WMI-Sensoren? Unsere Standardsensoren laufen nachwievor ohne Probleme.
Gruß
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ß
@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
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ß
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
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
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
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
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
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
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
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
Moin,
siehe OOB update to address an issue with sign in and Kerberos authentication, Kommentar: hier
Gruß,
Dani
siehe OOB update to address an issue with sign in and Kerberos authentication, Kommentar: hier
Gruß,
Dani