29
Vorsicht bei Windows Update Februar 2021 - Änderung bei AD-Controller Zugriff
Bevor ihr das aktuelle Windows Update installiert, achtet bitte unbedingt auf folgendes:
Um den zerologon Fehler aus dem letzten Jahr zu beheben, wird nach dem Update der Domänen Controller zukünftig der Domain
Controller Enforcement Mode als Standard verwendet!
Info: https://msrc-blog.microsoft.com/2021/01/14/netlogon-domain-controller-en ...
Das hat zur Folge, das alle anderen Zugriff verhindert werden.
Überprüft VORHER ob alle Geräte im Netzwerk den Enforcement Mode unterstützen!!
Weitere Info:
https://msrc-blog.microsoft.com/2021/01/14/netlogon-domain-controller-en ...
https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-n ...
Deutsch:
https://www.borncity.com/blog/2021/02/07/erinnerung-enforcement-mode-ab- ...
https://www.deskmodder.de/blog/2021/01/16/windows-server-domain-controll ...
Zusätzlich kommt im März eine weitere größere Änderung, die dani hier beschreibt Managing deployment of RBCD-Protected User (CVE-2020-16996)
Um den zerologon Fehler aus dem letzten Jahr zu beheben, wird nach dem Update der Domänen Controller zukünftig der Domain
Controller Enforcement Mode als Standard verwendet!
Info: https://msrc-blog.microsoft.com/2021/01/14/netlogon-domain-controller-en ...
Das hat zur Folge, das alle anderen Zugriff verhindert werden.
Überprüft VORHER ob alle Geräte im Netzwerk den Enforcement Mode unterstützen!!
Weitere Info:
https://msrc-blog.microsoft.com/2021/01/14/netlogon-domain-controller-en ...
https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-n ...
Deutsch:
https://www.borncity.com/blog/2021/02/07/erinnerung-enforcement-mode-ab- ...
https://www.deskmodder.de/blog/2021/01/16/windows-server-domain-controll ...
Zusätzlich kommt im März eine weitere größere Änderung, die dani hier beschreibt Managing deployment of RBCD-Protected User (CVE-2020-16996)
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 649654
Url: https://administrator.de/knowledge/vorsicht-bei-windows-update-februar-2021-aenderung-bei-ad-controller-zugriff-649654.html
Ausgedruckt am: 22.12.2024 um 04:12 Uhr
29 Kommentare
Neuester Kommentar
Danke für die Erinnerung im Microsoft 365 Admin Center falle ich gerade über:
*NEU* Um dies aus der Supportanwendung zu ersetzen, geben wir bekannt, dass der neue Microsoft Edge am 13. April 2021 als Teil des kumulativen monatlichen Sicherheitsupdates von Windows 10 verfügbar sein wird, das auch als Update Tuesday (oder "B") bezeichnet wird. Wenn Sie dieses Update anwenden, wird die nicht unterstützte Microsoft Edge Legacy-Desktopanwendung entfernt und die neue Microsoft Edge installiert. Lesen Sie die Ankündigung hier.
Dieser Austausch tritt auch auf, wenn Sie die optionale Windows 10 March Preview (oder "C") Version anwenden.
Dieser Austausch tritt auch auf, wenn Sie die optionale Windows 10 March Preview (oder "C") Version anwenden.
@Deepsys:
Danke für die wertvolle Information.
Von meinem 2008R2Sp1, der hier noch - ohne Gateway-Eintrag und damit ohne Internet sowie ohne jegliche Dateifreigaben in's Netz - für ein paar wenige Aufgaben läuft, kann ich mich dann wohl verabschieden. Ich werd' ihn Inplace auf 2012R2 aktualisieren.
Viele Grüße
von
departure69
Danke für die wertvolle Information.
Von meinem 2008R2Sp1, der hier noch - ohne Gateway-Eintrag und damit ohne Internet sowie ohne jegliche Dateifreigaben in's Netz - für ein paar wenige Aufgaben läuft, kann ich mich dann wohl verabschieden. Ich werd' ihn Inplace auf 2012R2 aktualisieren.
Viele Grüße
von
departure69
MS stellt Zwar ein Skript zur Behebung zur Verfügung, aber dennoch einmal kurz hier:
ich hab ein Skript erstellt, welches die Logs auswertet. Kein großes Ding, aber vielleicht hilft es dem einen oder anderen ja weiter:
Die IDs entsprechen denen von MS angegebenen in den oben genannten Artikel.
ich hab ein Skript erstellt, welches die Logs auswertet. Kein großes Ding, aber vielleicht hilft es dem einen oder anderen ja weiter:
$Auswertung=Get-EventLog -LogName System -ComputerName DC1,DC2
foreach ($value in $Auswertung)
{
if ($value.EventID -in (5827,5828,5830,5831,5829))
{$value}
}Die IDs entsprechen denen von MS angegebenen in den oben genannten Artikel.
1
Servus,
@Deepsys, thanks für die Erinnerung...
Nur, was mache ich in einer Außenstelle mit einem Windows Server 2008 (natürlich ebenfalls ohne Gateway und damit ohne INet-Zugriff), der nur noch als reiner Auskunftsserver dient für "alte" Dateien, die nicht ohne weiteres auf den SQL-Server von MS konvertiert werden können?
Der Windows Server 2008 erhält von MS bekanntermaßen ja seit längerem keine Sicherheitsupdates mehr und wird auch nicht mehr "produktiv" genutzt. Kann der dann noch im Netzwerk genutzt werden?
Edit:
Am DC keine Ereignis-ID/EventID mit 5827 - 5831 gefunden, jetzt bin ich wohl so klug / unwissend wie zuvor?!
Greetz
VGem-e
@Deepsys, thanks für die Erinnerung...
Nur, was mache ich in einer Außenstelle mit einem Windows Server 2008 (natürlich ebenfalls ohne Gateway und damit ohne INet-Zugriff), der nur noch als reiner Auskunftsserver dient für "alte" Dateien, die nicht ohne weiteres auf den SQL-Server von MS konvertiert werden können?
Der Windows Server 2008 erhält von MS bekanntermaßen ja seit längerem keine Sicherheitsupdates mehr und wird auch nicht mehr "produktiv" genutzt. Kann der dann noch im Netzwerk genutzt werden?
Edit:
Am DC keine Ereignis-ID/EventID mit 5827 - 5831 gefunden, jetzt bin ich wohl so klug / unwissend wie zuvor?!
Greetz
VGem-e
Zitat von @VGem-e:
Am DC keine Ereignis-ID/EventID mit 5827 - 5829 gefunden, jetzt bin ich wohl so klug / unwissend wie zuvor?!
Am DC keine Ereignis-ID/EventID mit 5827 - 5829 gefunden, jetzt bin ich wohl so klug / unwissend wie zuvor?!
Im Zweifel gibt es ja noch den Eingriff über die Registry:
Registry value for enforcement mode
Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
The August 11, 2020 updates introduce the following registry setting to enable enforcement mode early. This will be enabled regardless of the registry setting in the Enforcement Phase starting on February 9, 2021:
Registry subkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value
FullSecureChannelProtection
Data type
REG_DWORD
Data
1 – This enables enforcement mode. DCs will deny vulnerable Netlogon secure channel connections unless the account is allowed by the Create Vulnerable Connection list in the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy.
0 – DCs will allow vulnerable Netlogon secure channel connections from non-Windows devices. This option will be deprecated in the enforcement phase release.
Reboot required?
No
Quelle: https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-n ...Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
The August 11, 2020 updates introduce the following registry setting to enable enforcement mode early. This will be enabled regardless of the registry setting in the Enforcement Phase starting on February 9, 2021:
Registry subkey
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value
FullSecureChannelProtection
Data type
REG_DWORD
Data
1 – This enables enforcement mode. DCs will deny vulnerable Netlogon secure channel connections unless the account is allowed by the Create Vulnerable Connection list in the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy.
0 – DCs will allow vulnerable Netlogon secure channel connections from non-Windows devices. This option will be deprecated in the enforcement phase release.
Reboot required?
No
Zudem Punkt 7 beachten:
7. Why isn't Windows Server 2008 SP2 updated to address CVE-2020-1472?
Windows Server 2008 SP2 is not vulnerable to this specific CVE because it does not use AES for Secure RPC.
1
Servus,
@dertowa:
Dies scheint bei uns zuzutreffen, dann sieht es aktuell echt gut mit dieser Fehlerbehebung aus!
Danke nochmals.
Gruß
VGem-e
@dertowa:
Dies scheint bei uns zuzutreffen, dann sieht es aktuell echt gut mit dieser Fehlerbehebung aus!
Danke nochmals.
Gruß
VGem-e
Zitat von @VGem-e:
Am DC keine Ereignis-ID/EventID mit 5827 - 5831 gefunden, jetzt bin ich wohl so klug / unwissend wie zuvor?!
Am DC keine Ereignis-ID/EventID mit 5827 - 5831 gefunden, jetzt bin ich wohl so klug / unwissend wie zuvor?!
Naja wenn du den Link gelesen hast. Da steht:
Ereignis-IDs 5827 und 5828 im Systemereignisprotokoll protokollieren, wenn Verbindungen verweigert werden.
Ereignis-IDs 5830 und 5831 im Systemereignisprotokoll protokollieren, wenn Verbindungen die Zulassung von der Gruppenrichtlinie "Domänencontroller: Zulassen von angreifbaren sicheren Netlogon-Kanalverbindungen“ erhalten.
Ereignis-ID 5829 im Systemereignisprotokoll protokollieren, wenn eine angreifbare sichere Netlogon-Kanalverbindung zugelassen wird. Diese Ereignisse sollten behandelt werden, bevor DC-Erzwingungsmodus konfiguriert ist oder bevor die Erzwingungsphase am 9. Februar 2021 beginnt.
Ereignis-IDs 5830 und 5831 im Systemereignisprotokoll protokollieren, wenn Verbindungen die Zulassung von der Gruppenrichtlinie "Domänencontroller: Zulassen von angreifbaren sicheren Netlogon-Kanalverbindungen“ erhalten.
Ereignis-ID 5829 im Systemereignisprotokoll protokollieren, wenn eine angreifbare sichere Netlogon-Kanalverbindung zugelassen wird. Diese Ereignisse sollten behandelt werden, bevor DC-Erzwingungsmodus konfiguriert ist oder bevor die Erzwingungsphase am 9. Februar 2021 beginnt.
Wenn du die Ereignisse nicht hast, dann werden keine Verbindungen verweigert, lässt du keine Verbindungen via GPO über angreifbare Netlogon-Kanalverbindungen zu und hast du keine Verbindungen, die du behandeln solltest bevor du entsprechendes Update einspielst.
Sprich: Kein Ergebnis = Kein Problem.
@VGem-e:
Hi-De-Ho,
2008 oder 2008R2?
Mit dem nächsten mtl. Update Deiner DCs wird ja der "Domain Controller Enforcement Mode" für sämtliche Logon-Vorgänge erzwungen.
W2K8 und W2K8R2 beherrschen den beide nicht, aber für den W2K8R2 gibt's zumindest ein Update, welches das nachholt, dazu braucht's aber eine ESU-Lizenz, die wir hier nicht haben, deswegen werde ich meinen letzten W2K8R2 nach W2K12R2 inplace aktualisieren.
Für den W2K8R2 gibt's aber auch noch eine Schonfrist, indem man per GPO (https://support.microsoft.com/de-de/topic/verwalten-der-%C3%A4nderungen- ..) die Erzwingung dieses Modus verhindert - es versteht sich aber von selbst, das Microsoft dies nicht empfiehlt.
Eine weitere Möglichkeit bestünde darin, einfach die Februar-kumulativen-Updates nicht zu installieren (und auch alle nachfolgenden nicht
), daß das aber überhaupt nicht empfohlen ist, können wir uns denken .
Somit gibt's also noch 2 Möglichkeiten, den Betrieb eines W2K8R2 zu retten:
- ESU-Update (kostenpflichtig, weil man ESU gekauft/abonniert haben muß)
- GPO zum Verhindern des Erzwingungsmodus (nicht empfohlen)
Zum Vorgänger W2K8 (ohne "R2") wird aber leider gar keine Aussage getroffen, ich fürchte, den kannst Du knicken
. Auch wenn Du vorerst keine verweigerten Verbindungen mit den Ereignis-IDs 5827 und 5828 finden kannst, irgendwann wird das Thema zuschlagen, fürchte ich.
Viele Grüße
von
departure69
Hi-De-Ho,
2008 oder 2008R2?
Mit dem nächsten mtl. Update Deiner DCs wird ja der "Domain Controller Enforcement Mode" für sämtliche Logon-Vorgänge erzwungen.
W2K8 und W2K8R2 beherrschen den beide nicht, aber für den W2K8R2 gibt's zumindest ein Update, welches das nachholt, dazu braucht's aber eine ESU-Lizenz, die wir hier nicht haben, deswegen werde ich meinen letzten W2K8R2 nach W2K12R2 inplace aktualisieren.
Für den W2K8R2 gibt's aber auch noch eine Schonfrist, indem man per GPO (https://support.microsoft.com/de-de/topic/verwalten-der-%C3%A4nderungen- ..) die Erzwingung dieses Modus verhindert - es versteht sich aber von selbst, das Microsoft dies nicht empfiehlt.
Eine weitere Möglichkeit bestünde darin, einfach die Februar-kumulativen-Updates nicht zu installieren (und auch alle nachfolgenden nicht
), daß das aber überhaupt nicht empfohlen ist, können wir uns denken .Somit gibt's also noch 2 Möglichkeiten, den Betrieb eines W2K8R2 zu retten:
- ESU-Update (kostenpflichtig, weil man ESU gekauft/abonniert haben muß)
- GPO zum Verhindern des Erzwingungsmodus (nicht empfohlen)
Zum Vorgänger W2K8 (ohne "R2") wird aber leider gar keine Aussage getroffen, ich fürchte, den kannst Du knicken
. Auch wenn Du vorerst keine verweigerten Verbindungen mit den Ereignis-IDs 5827 und 5828 finden kannst, irgendwann wird das Thema zuschlagen, fürchte ich.Viele Grüße
von
departure69
Servus,
@departure69: Schon ein W2K8 mit SP2.
Eben, wie Ihr Kollegen schon hinweist, wohl im Moment kein Problem! Was die Zukunft bringt: Who knows???
Dann auch diesen Monat hoffentlich keine Installationsprobleme.
Gruß
VGem-e
@departure69: Schon ein W2K8 mit SP2.
Eben, wie Ihr Kollegen schon hinweist, wohl im Moment kein Problem! Was die Zukunft bringt: Who knows???
Dann auch diesen Monat hoffentlich keine Installationsprobleme.
Gruß
VGem-e
Guten Morgen,
wir aktualisieren monatlich recht zeitnah nach erscheinen der Updates unsere Domänencontroller, aktuell ist das Februar-Update installiert.
Wir haben noch zwei Windows Server 2008R2 sowie einen Windows Server 2003 an das AD angebunden, so dass ich entsprechende Events im System-Log der DCs (Netlogon mit IDs 5827, 5828 und 5829) erwarten würde. In den Logs sind jedoch keine derartigen Meldungen vorhanden, hat jemand von euch hierfür eine Erklärung? Für die beiden 2008R2-Server ist kein ESU vorhanden, der jeweils aktuellste Patchstand ist installiert.
Eine entsprechende von Microsoft empfohlene GPO ist nicht gesetzt, selbst wenn würden hierfür ja wiederum andere Events protokolliert werden.
Viele Grüße
RH
wir aktualisieren monatlich recht zeitnah nach erscheinen der Updates unsere Domänencontroller, aktuell ist das Februar-Update installiert.
Wir haben noch zwei Windows Server 2008R2 sowie einen Windows Server 2003 an das AD angebunden, so dass ich entsprechende Events im System-Log der DCs (Netlogon mit IDs 5827, 5828 und 5829) erwarten würde. In den Logs sind jedoch keine derartigen Meldungen vorhanden, hat jemand von euch hierfür eine Erklärung? Für die beiden 2008R2-Server ist kein ESU vorhanden, der jeweils aktuellste Patchstand ist installiert.
Eine entsprechende von Microsoft empfohlene GPO ist nicht gesetzt, selbst wenn würden hierfür ja wiederum andere Events protokolliert werden.
Viele Grüße
RH
2
Moin,
@redhorse: Evtl. gilt ja das gleiche wie von mir angefragt (W2K8) auch für den bei Euch laufenden W2K3-Server?
Gruß
VGem-e
@redhorse: Evtl. gilt ja das gleiche wie von mir angefragt (W2K8) auch für den bei Euch laufenden W2K3-Server?
Gruß
VGem-e
Zitat von @VGem-e:
@redhorse: Evtl. gilt ja das gleiche wie von mir angefragt (W2K8) auch für den bei Euch laufenden W2K3-Server?
@redhorse: Evtl. gilt ja das gleiche wie von mir angefragt (W2K8) auch für den bei Euch laufenden W2K3-Server?
Danke für den Hinweis, das habe ich nicht richtig gelesen. Es scheint so, als wenn wir tatsächlich nicht davon betroffen sind.
Moin,
danke dir für die Info.
Wäre da selbst vermutlich nicht direkt drüber gestolpert...
Ein hoch auf eine (digitale) Community
Grß
em-pie
danke dir für die Info.
Wäre da selbst vermutlich nicht direkt drüber gestolpert...
Ein hoch auf eine (digitale) Community
Grß
em-pie
2
Ich habe auf unseren DCs auf keine Ereignisse gefunden. Mir ist jetzt nur noch nicht klar, ob wir trotzdem ein Problem kriegen können oder nicht?
Und ja, wir haben, ähnlich wie Red-Horse, noch Windows 2008 Server und auch einen 2003er...
Und ja, wir haben, ähnlich wie Red-Horse, noch Windows 2008 Server und auch einen 2003er...
Wenn im Systemprotokoll keine Einträge vorhanden sind, dann sollte es laut MS nicht zu Problemen kommen.
Zitat von @departure69:
@Deepsys:
Danke für die wertvolle Information.
Von meinem 2008R2Sp1, der hier noch - ohne Gateway-Eintrag und damit ohne Internet sowie ohne jegliche Dateifreigaben in's Netz - für ein paar wenige Aufgaben läuft, kann ich mich dann wohl verabschieden. Ich werd' ihn Inplace auf 2012R2 aktualisieren.
Viele Grüße
von
departure69
@Deepsys:
Danke für die wertvolle Information.
Von meinem 2008R2Sp1, der hier noch - ohne Gateway-Eintrag und damit ohne Internet sowie ohne jegliche Dateifreigaben in's Netz - für ein paar wenige Aufgaben läuft, kann ich mich dann wohl verabschieden. Ich werd' ihn Inplace auf 2012R2 aktualisieren.
Viele Grüße
von
departure69
Davon hab ich auch noch mind. einen. Was passiert eig wenn man die DCs normal patched und die alten Kisten laufen lässt ?
@Ex0r2k16:
Hallo.
Hhhm, gute Frage. Der Beschreibung nach dürften sie nicht mehr funktionieren, im Sinne von "keine Anmeldung an der Domäne mehr möglich".
Wenn Du weiter oben mitgelesen hast, haben aber einige die dafür in Frage kommenden Event-IDs (nur bei Vorhandensein dieser Event-IDs kann das Problem nach dem Februar-Patch für den oder die DC(s) überhaupt in Frage kommen/auftreten) kontrolliert und haben festgestellt, daß diese bei ihnen im Eventlog nicht vorkommen und wollten ihre Server W2K8R2 und älter deshalb einfach weiterbetreiben.
Ich hab' die IDs auch kontrolliert (auf dem DC) - auch hier gibt es sie nicht, diese Event-IDs.
Bin trotzdem auf Nummer sicher gegangen und habe meine beiden W2K8R2 (hab' noch einen weiteren - eine VM - entdeckt) Inplace auf W2K12R2 gehoben, was zum Glück problemlos funktionierte. Kostet halt ein Geld - leider.
Auf Nummer sicher deshalb, weil ich befürchte, daß das Problem doch irgendwann wieder vor der Tür steht. Hab' vor 15 Jahren auch nicht glauben wollen, daß der letzte NT4.0-Server, den wir noch hatten, nicht mehr in die W2Kff.-AD-Domäne kann, aber irgendwann war es soweit, daß mit NT4.0 rein gar nichts mehr ging. Und das will ich - in Bezug auf W2K8R2 und älter - nicht abwarten.
Viele Grüße
von
departure69
Hallo.
Was passiert eig wenn man die DCs normal patched und die alten Kisten laufen lässt ?
Hhhm, gute Frage. Der Beschreibung nach dürften sie nicht mehr funktionieren, im Sinne von "keine Anmeldung an der Domäne mehr möglich".
Wenn Du weiter oben mitgelesen hast, haben aber einige die dafür in Frage kommenden Event-IDs (nur bei Vorhandensein dieser Event-IDs kann das Problem nach dem Februar-Patch für den oder die DC(s) überhaupt in Frage kommen/auftreten) kontrolliert und haben festgestellt, daß diese bei ihnen im Eventlog nicht vorkommen und wollten ihre Server W2K8R2 und älter deshalb einfach weiterbetreiben.
Ich hab' die IDs auch kontrolliert (auf dem DC) - auch hier gibt es sie nicht, diese Event-IDs.
Bin trotzdem auf Nummer sicher gegangen und habe meine beiden W2K8R2 (hab' noch einen weiteren - eine VM - entdeckt) Inplace auf W2K12R2 gehoben, was zum Glück problemlos funktionierte. Kostet halt ein Geld - leider
.Auf Nummer sicher deshalb, weil ich befürchte, daß das Problem doch irgendwann wieder vor der Tür steht. Hab' vor 15 Jahren auch nicht glauben wollen, daß der letzte NT4.0-Server, den wir noch hatten, nicht mehr in die W2Kff.-AD-Domäne kann, aber irgendwann war es soweit, daß mit NT4.0 rein gar nichts mehr ging. Und das will ich - in Bezug auf W2K8R2 und älter - nicht abwarten.
Viele Grüße
von
departure69
Zitat von @departure69:
Hab' vor 15 Jahren auch nicht glauben wollen, daß der letzte NT4.0-Server, den wir noch hatten, nicht mehr in die W2Kff.-AD-Domäne kann, aber irgendwann war es soweit, daß mit NT4.0 rein gar nichts mehr ging.
Hab' vor 15 Jahren auch nicht glauben wollen, daß der letzte NT4.0-Server, den wir noch hatten, nicht mehr in die W2Kff.-AD-Domäne kann, aber irgendwann war es soweit, daß mit NT4.0 rein gar nichts mehr ging.
Hmm NT 4.0 Server hab ich vor 3 Jahren noch in ner gekapselten Server 2003 R2 Domain gehabt und die hatte eine Vertrauensstellung mit einer Server 2012 nonR2 Domain. Das war schon ziemlich verquer, was damals unter keinen Umständen mehr wollte war Win 98 in einer Sonderanpassung (konnte man einfach hart abschalten) für Produktionsmaschinen, der Dateizugriff auf Server 2012 war nicht mehr drin. ;)
Um das gerade nur mal zu erwähnen, ich habe auf meinem Zettel für den nächsten Monat noch Managing deployment of RBCD/Protected User changes for CVE-2020-16996 die Vorbereitungen kamen ja im Dezember, ab März wird dann forciert.
Edit, wie ich gerade sehe hat Dani da schon nen passenden Thread parat: klick
@dertowa:
Hallo.
Allein das Stichwort "Produktionsmaschinen" zeigt ja das Dilemma und die immer wieder auftretende Notwendigkeit von Sonderlösungen weit über irgendwelche Supportzyklen hinaus.
Kann mir schon vorstellen, wie das abläuft: Die sauteure Produktionsmaschine kommt mit einem Windows-Betriebssystem XY daher, das 4 Jahre später bei Microsoft keinen Support mehr hat. Der Hersteller sieht zur Maschinensteuerung keine Neuerung bei der PC-Software, die diese Steuerung vornimmt, vor, es wird weiterhin OS XY benötigt. Es wird lediglich empfohlen, das System zu "härten". Zum Glück braucht es kein Internet, dafür aber eine DB-Verbindung zu einem MSSQL/MySQL/Oracle/Firebird/Informix/wasweißich in der Domäne. Und dann kommt Microsoft daher, und sperrt die Domäne zu, obwohl die Maschine und der Steuerungs-PC mit OS XY seit Jahren wunderbar laufen und dies theoretisch noch weitere 100 Jahre könnten.
Da ist dann Erfindungsreichtum seitens der IT-Administration gefragt, den Du scheinbar schon beweisen mußtest, wenn ich lese, was Du noch vor wenigen Jahren mit NT4.0 und W2K3 i. V. m. einer W2K12-Dom. getrieben hast. Hochachtung dafür! Allein die Dokumentation dieses Konstruktes, damit das auch ein anderer irgendwann kapiert, muß ein Alptraum sein.
Weiterhin viel Glück mit solchen Speziallösungen. Ich war bisher davon verschont, ich konnte die Systeme stets problemlos aktualisieren.
Viele Grüße
von
departure69
Hallo.
Allein das Stichwort "Produktionsmaschinen" zeigt ja das Dilemma und die immer wieder auftretende Notwendigkeit von Sonderlösungen weit über irgendwelche Supportzyklen hinaus.
Kann mir schon vorstellen, wie das abläuft: Die sauteure Produktionsmaschine kommt mit einem Windows-Betriebssystem XY daher, das 4 Jahre später bei Microsoft keinen Support mehr hat. Der Hersteller sieht zur Maschinensteuerung keine Neuerung bei der PC-Software, die diese Steuerung vornimmt, vor, es wird weiterhin OS XY benötigt. Es wird lediglich empfohlen, das System zu "härten". Zum Glück braucht es kein Internet, dafür aber eine DB-Verbindung zu einem MSSQL/MySQL/Oracle/Firebird/Informix/wasweißich in der Domäne. Und dann kommt Microsoft daher, und sperrt die Domäne zu, obwohl die Maschine und der Steuerungs-PC mit OS XY seit Jahren wunderbar laufen und dies theoretisch noch weitere 100 Jahre könnten.
Da ist dann Erfindungsreichtum seitens der IT-Administration gefragt, den Du scheinbar schon beweisen mußtest, wenn ich lese, was Du noch vor wenigen Jahren mit NT4.0 und W2K3 i. V. m. einer W2K12-Dom. getrieben hast. Hochachtung dafür! Allein die Dokumentation dieses Konstruktes, damit das auch ein anderer irgendwann kapiert, muß ein Alptraum sein.
Weiterhin viel Glück mit solchen Speziallösungen. Ich war bisher davon verschont, ich konnte die Systeme stets problemlos aktualisieren.
Viele Grüße
von
departure69
C’est la vie, auf dem NT 4.0 lief damals eine Oracle DB mit einem Warenwirtschaftssystem Infor.NT.
Ich muss gestehen dass das mehr oder minder unproblematisch war, denn dem NT 4.0 reichte es
wenn der Client Zugriff auf die Freigabe hatte, das Programm brauchte nur eine Startverknüpfung um zu laufen.
Das ging oh Wunder auch mit Windows 10 noch super, natürlich war SMB 1.0 Pflicht. :D
Hinsichtlich der Maschinen machen die Hersteller dies doch teilweise absichtlich, die Systeme die dort verbaut
werden haben doch kaum eine längere Ersatzteilgarantie als der Microsoftsupport für das OS.
So ein neues Steuerterminal kostet dann schnell mal 5-stellig, allein für die Hardware.
Im Widerspruch steht das Härten der Maschinen dann, wenn es darum geht dass der Hersteller im Zweifel Support
per Fernwartung machen will, da wird es dann ohne Internet eng. ;)
Ich muss gestehen dass das mehr oder minder unproblematisch war, denn dem NT 4.0 reichte es
wenn der Client Zugriff auf die Freigabe hatte, das Programm brauchte nur eine Startverknüpfung um zu laufen.
Das ging oh Wunder auch mit Windows 10 noch super, natürlich war SMB 1.0 Pflicht. :D
Hinsichtlich der Maschinen machen die Hersteller dies doch teilweise absichtlich, die Systeme die dort verbaut
werden haben doch kaum eine längere Ersatzteilgarantie als der Microsoftsupport für das OS.
So ein neues Steuerterminal kostet dann schnell mal 5-stellig, allein für die Hardware.
Im Widerspruch steht das Härten der Maschinen dann, wenn es darum geht dass der Hersteller im Zweifel Support
per Fernwartung machen will, da wird es dann ohne Internet eng. ;)
1
Hey @departure69
ich habe ebenfalls keine Meldungen von Servern im "System" Eventlog. Na supi. Das verunsichert einen nur noch mehr.
ich habe ebenfalls keine Meldungen von Servern im "System" Eventlog. Na supi. Das verunsichert einen nur noch mehr.
Zitat von @Ex0r2k16:
Hey @departure69
ich habe ebenfalls keine Meldungen von Servern im "System" Eventlog. Na supi. Das verunsichert einen nur noch mehr.
Inwiefern? Es steht doch klar und deutlich auf der MS Seite, dass und was man bei entsprechenden Eventlog-Einträgen machen muss. Wenn du die Eventlog-Einträge nicht hast, dann sollte auch kein handeln deinerseits notwendig sein.Hey @departure69
ich habe ebenfalls keine Meldungen von Servern im "System" Eventlog. Na supi. Das verunsichert einen nur noch mehr.
Zitat von @Doskias:
Zitat von @Ex0r2k16:
Hey @departure69
ich habe ebenfalls keine Meldungen von Servern im "System" Eventlog. Na supi. Das verunsichert einen nur noch mehr.
Inwiefern? Es steht doch klar und deutlich auf der MS Seite, dass und was man bei entsprechenden Eventlog-Einträgen machen muss. Wenn du die Eventlog-Einträge nicht hast, dann sollte auch kein handeln deinerseits notwendig sein.Hey @departure69
ich habe ebenfalls keine Meldungen von Servern im "System" Eventlog. Na supi. Das verunsichert einen nur noch mehr.
Aber auch wenn man noch Server 2008R2 im Einsatz hat? Warum warnen die dann davor? Übrigens wurde das Datum verschoben:
„IMPORTANT The date for Enforcement mode as previously noted in this article has changed to March 9, 2021.“
Zitat von @Ex0r2k16:
Übrigens wurde das Datum verschoben:
Übrigens wurde das Datum verschoben:
„IMPORTANT The date for Enforcement mode as previously noted in this article has changed to March 9, 2021.“
Wo stammt das her, denn das hat nichts mit der CVE-2020-16996 zu tun, die kommt erst im nächsten Monat dran.
Zitat von @dertowa:
Um das gerade nur mal zu erwähnen, ich habe auf meinem Zettel für den nächsten Monat noch Managing deployment of RBCD/Protected User changes for CVE-2020-16996 die Vorbereitungen kamen ja im Dezember, ab März wird dann forciert.
Edit, wie ich gerade sehe hat Dani da schon nen passenden Thread parat: klick
Um das gerade nur mal zu erwähnen, ich habe auf meinem Zettel für den nächsten Monat noch Managing deployment of RBCD/Protected User changes for CVE-2020-16996 die Vorbereitungen kamen ja im Dezember, ab März wird dann forciert.
Edit, wie ich gerade sehe hat Dani da schon nen passenden Thread parat: klick
Ja, aber der 9te März ist auch nicht mehr weit hin. Wobei ich mich mal wieder wundere, wieso etwas was im August angekündigt und bekannt ist auf einmal solche Wellen schlägt. MS macht nicht umsonst solche Ansagen. Es war lange genug Zeit sich mit dem Thema auseinander zu setzen.
Nochmal aber ausführlich.
Hast du 5829 nicht, dann hast du keinen verwundbaren Netlogon, der genutzt wirrd.
Weiter heißt es:
Heißt im Klartext: Die sichere Verbindung wird erzwungen, für alle wo nicht separat eine Ausnahme konfiguriert ist. 5829 wird es nicht mehr geben. Die Warnung wird abgeschaltet (du hattest seit August Zeit dich zu kümmern) und wird blockiert und damit zur 5827 oder 5828. Wenn du also keine dieser Nummern hast, dann hast du (a) entweder nur sichere Verbindungen oder (b) das August-Update auf den DCs nicht installiert. Wenn du nur 5830 und 5831 hast, dann ändert sich nichts, weil dies ja weiterhin über Group Policy erlaubte ausnahmen sind. Wenn du nur 5827 und 5828 hast, dann ändert sich auch nichts. Es wird jetzt abgelehnt, es wird später abgelehnt.
Fazit: Wenn du das August-Update auf den DCs installiert hast und keine dieser Nummern hast, dann benutzt du ausschließlich sichere Verbindungen. Das ist kein Fehler sondern der Zielzustand.
Nochmal aber ausführlich.
After the August 11, 2020 updates have been applied to DCs, events can be collected in DC event logs to determine which devices in your environment are using vulnerable Netlogon secure channel connections (referred to as non-compliant devices in this article). Monitor patched DCs for event ID 5829 events. The events will include relevant information for identifying the non-compliant devices.
Hast du 5829 nicht, dann hast du keinen verwundbaren Netlogon, der genutzt wirrd.
Log event IDs 5827 and 5828 in the System event log, if connections are denied.
hast du 5827 und 5828 nicht, dann wird auch jetzt noch keine Verbindung blockiertLog event IDs 5830 and 5831 in the System event log, if connections are allowed by "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy.
hast du 5830 pder 5831, dann benutzt du unsichere Verbindungen und hast aber für diese Verbindungen eine Ausnahme konfiguriert.Weiter heißt es:
Enforces secure RPC usage for machine accounts on non-Windows based devices unless allowed by "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy.
Logging of Event ID 5829 will be removed. Since all vulnerable connections are denied, you will now only see event IDs 5827 and 5828 in the System event log.
Logging of Event ID 5829 will be removed. Since all vulnerable connections are denied, you will now only see event IDs 5827 and 5828 in the System event log.
Heißt im Klartext: Die sichere Verbindung wird erzwungen, für alle wo nicht separat eine Ausnahme konfiguriert ist. 5829 wird es nicht mehr geben. Die Warnung wird abgeschaltet (du hattest seit August Zeit dich zu kümmern) und wird blockiert und damit zur 5827 oder 5828. Wenn du also keine dieser Nummern hast, dann hast du (a) entweder nur sichere Verbindungen oder (b) das August-Update auf den DCs nicht installiert. Wenn du nur 5830 und 5831 hast, dann ändert sich nichts, weil dies ja weiterhin über Group Policy erlaubte ausnahmen sind. Wenn du nur 5827 und 5828 hast, dann ändert sich auch nichts. Es wird jetzt abgelehnt, es wird später abgelehnt.
Fazit: Wenn du das August-Update auf den DCs installiert hast und keine dieser Nummern hast, dann benutzt du ausschließlich sichere Verbindungen. Das ist kein Fehler sondern der Zielzustand.
1Zitat von @Doskias:
[...]
Fazit: Wenn du das August-Update auf den DCs installiert hast und keine dieser Nummern hast, dann benutzt du ausschließlich sichere Verbindungen. Das ist kein Fehler sondern der Zielzustand.
[...]
Fazit: Wenn du das August-Update auf den DCs installiert hast und keine dieser Nummern hast, dann benutzt du ausschließlich sichere Verbindungen. Das ist kein Fehler sondern der Zielzustand.
Alles klar. Danke. Wundert mich aber trotzdem, dass der 2008R2 sich da nicht im Log meldet.
@Ex0r2k16:
Mich auch. Der Logik halber, denn wozu wird in den Microsoft-Artikeln zu dieser neuen, sichereren Verbindungsart ausdrücklich der W2K8R2 für dieses Problem addressiert (?), hätte ich in den Logs eigentlich auch was sehen müssen.
Aber egal, ich bin die beiden W2K8R2, die ich noch hatte, jetzt los. Hab' allerdings nur auf W2K12R2 aktualisiert, d. h., daß das Spiel mit den Inplace-Upgrades spätestens irgendwann in 2023 wieder anfängt. Wollte aber auch nicht gleich zu W2K16 od. W2K19 weiteraktualisieren, einer der beiden war ein Printserver und ich hatte sorgen um die Treiber. Da der Sprung nach W2K12R2 aber zum Glück nicht so groß war, mußte ich keinen einzigen Treiber aktualisieren, alle Freigaben und Warteschlangen sind vollkommen intakt, 1:1 übernommen ohne Probleme.
Viele Grüße
von
departure69
Wundert mich aber trotzdem, dass der 2008R2 sich da nicht im Log meldet.
Mich auch. Der Logik halber, denn wozu wird in den Microsoft-Artikeln zu dieser neuen, sichereren Verbindungsart ausdrücklich der W2K8R2 für dieses Problem addressiert (?), hätte ich in den Logs eigentlich auch was sehen müssen.
Aber egal, ich bin die beiden W2K8R2, die ich noch hatte, jetzt los. Hab' allerdings nur auf W2K12R2 aktualisiert, d. h., daß das Spiel mit den Inplace-Upgrades spätestens irgendwann in 2023 wieder anfängt. Wollte aber auch nicht gleich zu W2K16 od. W2K19 weiteraktualisieren, einer der beiden war ein Printserver und ich hatte sorgen um die Treiber. Da der Sprung nach W2K12R2 aber zum Glück nicht so groß war, mußte ich keinen einzigen Treiber aktualisieren, alle Freigaben und Warteschlangen sind vollkommen intakt, 1:1 übernommen ohne Probleme.
Viele Grüße
von
departure69
Zitat von @departure69:
@Ex0r2k16:
Mich auch. Der Logik halber, denn wozu wird in den Microsoft-Artikeln zu dieser neuen, sichereren Verbindungsart ausdrücklich der W2K8R2 für dieses Problem addressiert (?), hätte ich in den Logs eigentlich auch was sehen müssen.
Aber egal, ich bin die beiden W2K8R2, die ich noch hatte, jetzt los. Hab' allerdings nur auf W2K12R2 aktualisiert, d. h., daß das Spiel mit den Inplace-Upgrades spätestens irgendwann in 2023 wieder anfängt. Wollte aber auch nicht gleich zu W2K16 od. W2K19 weiteraktualisieren, einer der beiden war ein Printserver und ich hatte sorgen um die Treiber. Da der Sprung nach W2K12R2 aber zum Glück nicht so groß war, mußte ich keinen einzigen Treiber aktualisieren, alle Freigaben und Warteschlangen sind vollkommen intakt, 1:1 übernommen ohne Probleme.
Viele Grüße
von
departure69
@Ex0r2k16:
Wundert mich aber trotzdem, dass der 2008R2 sich da nicht im Log meldet.
Mich auch. Der Logik halber, denn wozu wird in den Microsoft-Artikeln zu dieser neuen, sichereren Verbindungsart ausdrücklich der W2K8R2 für dieses Problem addressiert (?), hätte ich in den Logs eigentlich auch was sehen müssen.
Aber egal, ich bin die beiden W2K8R2, die ich noch hatte, jetzt los. Hab' allerdings nur auf W2K12R2 aktualisiert, d. h., daß das Spiel mit den Inplace-Upgrades spätestens irgendwann in 2023 wieder anfängt. Wollte aber auch nicht gleich zu W2K16 od. W2K19 weiteraktualisieren, einer der beiden war ein Printserver und ich hatte sorgen um die Treiber. Da der Sprung nach W2K12R2 aber zum Glück nicht so groß war, mußte ich keinen einzigen Treiber aktualisieren, alle Freigaben und Warteschlangen sind vollkommen intakt, 1:1 übernommen ohne Probleme.
Viele Grüße
von
departure69
Würde ich ja auch gerne machen, aber das ist viel zu riskant in meinem Fall. Da läuft ne Oracle DB und JAVA VMs drauf
Hallo zusammen,
ich muss hier auch nochmals kurz nachhaken, ob ich das richtig
verstanden habe.
Es reicht also, wenn ich das 2020-08 – Sicherheitsqualitätsupdate für Windows Server 2012 für x64-basierte Systeme (KB4571702)
installiere und dann prüfe ob die entsprechenden EventID's auftauchen.
Und gehe ich auch recht in der Annahme, das dieses Update kumulativ ist, und ich alle vorherigen Sicherheitsqualitätsupdates (2020-07, 2020-06 etc.) falls vorhanden nicht benötige.
Grüße
eazy-isi
ich muss hier auch nochmals kurz nachhaken, ob ich das richtig
verstanden habe.
Es reicht also, wenn ich das 2020-08 – Sicherheitsqualitätsupdate für Windows Server 2012 für x64-basierte Systeme (KB4571702)
installiere und dann prüfe ob die entsprechenden EventID's auftauchen.
Und gehe ich auch recht in der Annahme, das dieses Update kumulativ ist, und ich alle vorherigen Sicherheitsqualitätsupdates (2020-07, 2020-06 etc.) falls vorhanden nicht benötige.
Grüße
eazy-isi
