Weingeist

Yep... Habe mittlerweile auch gelesen. Habe ich vermutlich wieder vergessen. Shame on me. Schiebe schon sehr lange alle "normalen" User da rein. Oder die User setzen wirklich immer brav das sperren/entsperren um in Kaffeepausen und abmelden am Abend und die jahrelangen Mühen tragen Früchte... auch wenn schwer vorstellbar ist in allen Umbgebungen. Wobei ich auch nicht so besonders die NTLM-Logs von den Clients prüfe wenn niemand reklamiert das etwas nicht geht... hmmm.... Dafür habe ich noch ein Problem gefunden. Meine CA's mögen kein Kerberos für das ausstellen von Zertifikaten obwohl durchgängig aktiviert. Fällt mir wohl auch bald irgendwo auf die Füsse. Hach wäre das doch schon überall komplett durch. Wobei eigentlich hätte man ja fast 20 Jahre Zeit gehabt, muss man jetzt nicht rumjammern (Wobei stimmt nicht ganz, manche Services von MS waren ja auch nicht Kerberos tauglich) ;)

Born hat jetzt was seit ein paar Tagen für den aktuellen Kram. Vielleicht pflegt er es ja auch. Habe ich aber auch erst später gesehen mit ältere Beiträge. =) --> https://www.borncity.com/blog/2023/05/02/windows-hrtung-termine-2023/ Und MS hat jetzt auch einen Dienst für Admins wenn man sich online anmeldet. Da bekommt man dann die Bug und wohl auch Sicherheits-Bulletins zugemailt. Vor kurzem gelesen.

Die neueren Epyc sind sehr ordentlich. Gerade wenn man NVMe einsetzt sind die Menge verfügbarer Lanes pro CPU sehr cool. Muss man sich nie Gedanken machen. Da Add-On Karten fast durchgängig x16 haben und trotzdem noch viele NVMe Ports verfügbar sind, ist man hochflexibel in der Bestückung. Heisst man kann auch den gleichen Hosttyp für mehrere Aufgaben brauchen. (Reservemaschine am Lager). Allerdings würde ich für Server nur die Big Four kaufen (HP, Dell, Fujitsu-Siemens, Supermicro. Hat man schonmal viel potentiellen Ärger nicht. Bei AMD-Systemen erst recht wo die Stückzahl halt deutlich tiefer ist. Für den TO: Nun, das April-Update hat ein paaar Dinge punkto Sicherheit geändert. Wie auch schon das November-Update. Möglicherweise wurden bei HyperV ein paar Dinge erzwungen die sonst noch nicht erzwungend wurden aber bis Ende Jahr werden. Alles auf Kerberos umgestellt? =) Lesenswerter Link zum Thema: https://www.borncity.com/blog/2023/05/02/windows-hrtung-termine-2023/

Da gibts eigentlich nur eins, Maus oder Tastatur auf Trapp halten. Von Freeware die das erledigt würde ich abstand halten! Die Leute sollen selber schubsen (alle 15min halte ich für 'erträglich', das lernt man, kurz aufstehen tut jedem gut, mit Funkmaus nichtmal nötig). Wenn auf den Kisten Präsenationen eher die Regel als die Ausnahme sind, eine andere GPO mit längerer Laufzeit Selber etwas proggen. Allzu schwer ist das nicht, ein paar Api-Befehle sollten genügen. Die GPO durch eine lokale Policy ersetzen. Deren Einstellung z.B. mit Tasks setzen/rücksetzen welcher der User anstossen kann. Dann je nach dem wieder automatisch setzen. Für sowas gilt immer: Möglich ist vieles. Die Frage ist nur, wieviel Aufwand ist einem das tatsächlich wert? Wieviel Leute sind wie oft betroffen? Wieviel allfälligen Ärger nimmt man im Unterhalt in Kauf? Wieviel Sicherheit geht allenfalls flöten. Meist gehen schnell ein paar Stunden drauf um spezial-Lösungen zu testen. In 90-95% der Fälle ist es meiner Meinung nach zumutbar, dass die Leute die Maus selber ab und wann schubsen. Die anderen müssen sich fügen und damit leben oder man findet eben eine Lösung. Man kann im Leben selten alle glücklich machen. Am schicksten wäre eine Zugangskarte. Solange die drinn ist, ist PC entsperrt und Screensaver kommt nicht. Ist sie draussen, kommt er. Der Aufwand dafür ist aber nicht ganz ohne. Würde aber manche Dinge erleichtern. Industriecomputer von Maschinen ist ultranervig wenn die Passwortfrage ständig kommt. Gleichzeitig doof wenn Screen nicht gesperrt ist wenn User weg. Da wäre eine Karte mit NFC-Chip viel schicker.

Die hoch getakteten F16er von AMD sind erste Sahne! Vorteile dürften gut bekannt sein (PCI-Lanes usw.) Die grössten Nachteile von AMD sind - Verfügbarkeit - teilweise lausige Auswahl an hochwertigen Servern Als ich die ersten EPYC Server bestellt habe, musste ich fast 6 Monate drauf warten während Intel einfach so ab Lager lieferbar gewesen wäre. Hat sich aber heute verbessert. Sowohl Auswahl als auch Verfügbarkeit. VM's kann man schon mit ungerader Core-Zahl erstellen. Host verschenkt man Lizenzkosten. Wichtig ist, dass die VM innerhalb des gleichen Sockels bleibt und auf den "eigenen" RAM zugegriffen wird. Aber das weisst Du vermutlich auch. Negative Auswirkung gibts bei 1 Core und modernem Windows. Insbesondere wenn die Telemetrie läuft. HT: Bei der Deaktivierung gab es bei hoher Auslastung in der einzelnen VM gewisse Vorteile. Der Effekt war sichtbar bei der Übertragungsrate der virtuellen Netzwerkkarte/Zip. Das war etwas schneller ohne HT. Wie es bei Vollauslastung eines Hosts/starkes Overcommitment aussieht, kann ich nichts beitragen. Auch sind meine Tests ein paar Jahre zurück! Dank 16 Kerne pro Sockel bin ich bei meinen Umgebungen heute in der bequemen Lage, HT gar nicht wirklich zu benötigen. Die Kerne werde meist genügend schnell wieder frei. Sprich ein theoretisches Risiko weniger (Sicherheit). Energieeinstellungen: In der Vergangenheit waren all diese Optimierungen egal welcher Art (Stromsparen, Leistungsverteilung usw.) eher problematisch als hilfreich. Unerklärliche Probleme konnten oft mit dem Wechsel auf die Einstellung Höchstleistung gelöst werden. ABER: Wir schreiben das Jahr 2023 und somit über 10 Jahre nach Einführung. Es gab diesbezüglich enorme Verbesserungen. Bei Business-Notebooks funktionierts es seit ein paar Jahren, gut möglich, dass es mittlerweile auch im Serverbereich angekommen ist. Freiwillige vor. Aber ganz ehrlich, mir ist egal ob der Takt bei 3.5-4GHZ rund 200MHZ höher ist oder nicht. Bei 1GHZ fange ich dann an zu überlegen/testen. =) RAM: Keine Ahnung wozu das Overcommitment ausserhalb von Testumgebungen gut sein soll. Sobald man es bräuchte wird die Performance unterirdisch. Den Trend zu mehr Cores statt MHZ habe ich ebenfalls nie wirklich verstanden und bin nie auf den Zug aufgesprungen. - nur wenige Tasks profitieren energetisch tatsächlich bei gleicher Performance (heterogene Umgebungen profitieren also eher nicht) - sehr viele Tasks brauchen die Ergebnisse von vorherigen Berechnungen, also Multicore schwierig - sehr viele Anwendungen die vielleicht profitieren würden, sind nicht so programmiert - Overhead ist mit der steigenden anz. Cores im VM-Bereich deutlich höher. Deutlich lieber zwei hohe als vier tief getaktete cores. Je schneller desto schneller fertig/frei. - Für VDI/Terminal-Server ist es eh diskussionslos wenn man die Anwender fragt, aber die werden ja selten gefragt =) Zum Glück waren die 16xx E5 von Intel so lange verfügbar. Waren halt Single CPU und dafür gabs fast nur von Supermicro schlaues Zeug. Mit den Scalable war dann Ende Gelände, hohe Taktrate völlig unbezahlbar oder CPU's gar nicht verfügbar oder nur in Workstations. Glücklicherweise sprang dann recht bald AMD in die Bresche und Intel musste wohl oder übel nachziehen und massiv an der Preisschraube drehen. Aktuell bin ich dennoch bei AMD geblieben.

Hmm dann wäre das wieder "neu" seit November. Eigentlich hat MS diesbezüglich mal ne Rolle rückwärts gemacht. Ist mir auf alle Fälle nicht aufgefallen weil ich die Updates auf Servern mit Powershell ziehe/installiere. Passt aber hervorragend in das Update-Ghetto welches sie fabriziert haben. ;) Möglicherweise reagiert auch die Core Version anders als jene mit Desktop weil SystemSettings.exe fehlt und die ist massgeblich für die "Umgehung" der GPO-Einstellungen verantwortlich. Sprich sobald man in den Einstellungen die Updates öffnet, werden sofort Updates gezogen und installiert. Gerne auch vom Internet. Die GPO-Einstellungen zielen eher auf den eigentlichen, älteren Update-Client welcher sie auch respektiert. Wenn man der Übermittlungsoptimierung und SystemSettings das Verbinden auf externe Adressen blockiert, dann ziehen sie auch keine Udpates mehr vom Internet. Egal was MS am Updatedienst dreht. Sie ziehen also nur Updates die man in WSUS freigibt. Was man da wem zu welchem Zeitpunkt freigibt hat man ja selbst in der Hand. Sprich sobald man installieren möchte, gibt man frei. Am besten gestuft beginnend mit weniger heiklen Rechnern/Testrechner um Probleme zu erkennen und notfalls Update-Prozeder zu stoppen. Die "Umgehung" von Windows-Einstellungen kommst auch mit einer anderen Lösung nicht bei ohne bestimmt Massnahmen zu treffen. Oder die Lösung trifft die Massnahmen selbst. Windows ist hier ziemlich "selbständig". Auch Firmenübergreifend bekommt man technisch hin. Lizenztechnisch ist es etwas "spezieller". Früher war das mit einer Web-Version ohne Diskussion möglich. Diese Problematik bleibt aber mit jeder Lösung identisch problematisch/unproblematisch wie mit WSUS.

Ja da hast Du auch wieder recht, auch wenn es eigentlich eine schlechte Aussage ist. Die paar RPC-Protokolle welche für die aktuellen "Schmerzen" punkto NTLM sorgen, kann man ja bis auf wenige Ausnahmen schmerzfrei einfach deaktivieren. Insbesondere wenn man NTLM noch nicht deaktivieren kann. Die paar wenigen Ausnahmen wie die DC-Replikation müssen wohl nur an eine AD-Gruppe gebunden werden. Ist im Unterhalt ja eigentlich trivial, einfach in die entsprechende Gruppe schieben. Muss ja nicht extremst granular sein. Aber ist wohl schon so, je grösser die Umgebung, desto mehr kann ein deaktivieren Schmerzen bereiten, weil mehr Tasks Remote erledigt werden und nicht auf der Maschine selbst. Allerdings hat man ja schon heute Admin-Benutzergruppen denen man verschiedenste Rechte wie das lokale Anmelden verweigert oder zulässt. Diese Gruppe (oder eigene) könnte man an die RPC-Filter hängen mit welchen man heikle Remote-RPC-Protokolle benutzen darf. Die BFE lässt einem gar nicht mit den anfälligen oder heiklen Diensten sprechen, welche als Relay oder sonstiges missbraucht werden könnten. Die nächsten Wochen/Monate werden zeigen wie praxistauglich die Umsetzung ist und welchen Ärger sie produzieren. Bis jetzt habe ich nur geblockt und nicht Zugriffe zugelassen und schon gar kein Whitelisting betrieben (ist mir der Aufwand vermutlich auch zu hoch). Bezüglich NTLM: Zum Glück hat man ja noch laaaaaange Zeit *hust*: Günther Born hat wie ich heute gesehen habe, übrigens seit ein paar Tagen ne Timeline für die aktuellen Dinge wann sie scharf geschaltet werden: https://www.borncity.com/blog/2023/05/02/windows-hrtung-termine-2023/ Eigentlich ist es ja krass, dass erst 20 Jahre nach der Einführung das Messer an den Hals gesetzt wird. Wobei auch krass ist, dass das Standardverhaten für neue Umgebungen seit 20 Jahren nie geändert wurde. =) Ich meine ja in Windows selbst, nicht auf Stufe Netzwerk. Bei Windows muss man sich ja gar nicht darum kümmern. Macht Windows selbst. Entweder antwortet kein Dienst, da abgeschaltet oder es kommt nichts bis zum Dienst, da der Fragende via dem RPC-Protokoll-Filter der BFE geblockt wird. Der Overhead der BFE ist zudem vergleichsweise minimal, da sie die benötigten Infos hat/bekommt und nicht grossartig analysieren und berechnen muss.

Mittlerweile habe ich auch rausgefunden, dass die versuchten NTLM-authentifizierungen und deren Logs definitiv daher kommen, dass das Kerberos-Ticket abgelaufen ist. Es wird dann permanet versucht die bestehenden Verbindungen von Netzlaufwerken, GroupPolicy-Abfragen, Printerverbindungen etc. via NTLM zu authentifizieren. Was natürlich fehlschlägt. Führt aber zu sehr vielen Einträgen. Das Kerberos Ticket wird auch nicht selbst wieder erstellt wie ursprünglich angenommen, man muss effektiv den Arbeitsplatz sperren/entsperren. Trifft insbesondere für User der Gruppe "Protected Users" zu wo der Spass nach 3h oder so abläuft. Wir noch ein paar Kopfschmerzen bereiten bis alles kompatibel ist. Und noch mehr, wenn NTLM für Lokale Accounts auch unwiederbringlich abgeschaltet wird...

Danach haben leider auch die Spielereien von MS an den Updatediensten angefangen. Server 2016 ist ja ein LTSC (damals noch LTSB) Build, der blieb soweit ich mich erinnere bei seinem Verhalten (kann es nicht mehr genau sagen, da ich produktiv bis zum erscheinen von 2022 nur 2012/2012R2 verwendet habe und bei W8.1 geblieben bin und dann auf die LTSC Builds gewechselt habe. Den Update-Ärger haben dann die W10 der Maschinensteuerungen verursacht (meist Pro). Ansonsten bin ich bei Sunny. WSUS schafft einige Probleme Hals. Das heisst aber nicht, dass die modernen Clients dann auch wirklich nur von ihm Updates beziehen. Auch wenn mans verbietet. Das verhindert manchmal nur die Windows Firewall. ;)

Einen hätte ich auch noch: Vergleiche mal die Firewall-Regeln, insbesondere die Static in der Registry zwischen einem funktionierenden und dem nichtfunktionierenden Client. DHCP hat da ein paar Regeln. Wenn die geschrottet sind, funktioniert DHCP nicht mehr zuverlässig oder gar nicht mehr. Das gleiche gilt für die "normalen" Rules die man auch in der GUI sieht. Passiert aber eigentlich eher wenn man selber dran rumspielt =) Edit: Pfad: HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System

Vor Jahren hatte ich das mal (ist aber wirklich schon ewig her), aber nur die abgeschnittenen Bilder, nicht gemischte Farben. Damals war es aber ausschliesslich auf einen Client bezogen und der hatte nicht den gleichen Patchstand/Windows. Sprich ein paar Bibliotheken waren veraltet oder neuer oder anders als bei den anderen (ganz genau wie rum weiss ich nicht mehr). Dateien von A machten Probleme auf B nicht jedoch anders rum. Habe damals die dafür zuständigen DLL's ausgetausch und es war wieder i.O. Wurden soweit ich mich erinnere durch ein spezielles Programm überschrieben mit einer alten Version. Ob es die Datei oder aber der Client selbst ist, kannst relativ einfach mit einer Prüfsumme abgleichen. Also Prüfsumme der lokalen sowie der kopierten Datei vergleichen. Ist sie identisch, ist das File zu 99.9999% identisch und es liegt am Client. Sprich es wurde entweder von A so gespeichert weil veraltet, dass es nur A lesen kann oder B ist veraltet und kann es deshalb nicht lesen. MIST sorry, erst jetzt gesehen das es schon ne Weile her war....

Klar, Deine Netze sind eine "etwas" andere Dimension. Aber das einzelne Subnet für sich ist ja auch nicht gigantisch gross. ;) Ein RPC-Filter seitens Windows ist relativ trivial. Der Filter greift auf eine der untersten Eben der BFE. Um die random Ports muss man sich nicht kümmern. Windows weiss, welches Protokoll aktuell an welche RPC-Ports gebunden ist. Die Firewall müsste ja gar nicht so viele und aufwendige Rules haben, da man die "Freigabe" oder Blocks auch an AD-Gruppen binden kann. Ich sehe es in etwa so: Wenn z.B. auf den DC's Printservice und andere Dienste abschaltet werden weil es dafür bestehende Exploits gibt und sie nicht gebraucht werden, wieso verhindert man auf den Servern nicht auch einfach alles ein einkommenden RPC-Verkehr der nicht notwendig ist oder beschränkt ihn - sofern sinnvoll möglich auf gewisse Partner? Ist ja jetzt nicht so eine Weltmeisterübung wenn man mal weiss was überhaupt benötigt wird. Die meisten sind z.B. der Meinung, EFS sei kaum sinnvoll zu verwalten, wozu dann seine Remote-Anlaufstelle offen lassen wenn genau dafür Exploits existieren (Auch wenn dafür der Dienst laufen muss). Wenn gewisse Protokolle nur für den Austausch unter DC's/CA/DFS's/Admin-WS zuständig sind und für "normale" Clients irrelevant sind, könnte man die erlaubte Kommunikation für bestimmte Protokolle an bestimmte AD-Gruppen hängen. Der Aufwand wäre überschaubar und das Problem doch eigentlich an der Wurzel gepackt, eine Kommmunikation wird zum vornherein verhindert. Ein allfälliger Explit ist zahnlos. Die Logeinträge für untypische Kommunikationsaufnahmen hätte man ja auch grad gratis dazu. Muss ja nicht gleich Whitelisting für alles sein. Die ganzen PetitPotam wären - zumindest wenn ich die Artikel richtig interpretiere - eher nicht so erfolgreich gewesen mit einer handvoll RPC-Filtern, deren "Anlaufstelle" auf DC's/CA sowieso nicht gebraucht wird.

keep it simple versuche ich auch wenn irgendwie möglich durchzusetzen. Auch das mit den Berechtigungen sehe ich genau so, auch wenn es nicht immer ganz einfach durchzublicken ist, wo und wie man genau das Standardverhalten ändern muss. Das erstellen von Benutzern/Admin Workstations welche nur in ihrem möglichst kleinen Teil und möglichst nur dann wenn notwendig Zugriff haben/anmelden können, ist noch der einfachste/offensichtlichste Teil. Für die verlinkten RPC-Protokollle gibt es aber aktive Exploits und soweit ich das richtig verstanden habe, sind die Updates von MS nur die halbe Miete und die Wahrscheinlichkeit das ähnliche Exploits auftauchen relativ hoch. Macht es da nicht doch Sinn, die problematischen Protokolle ebenfalls auf die Admin-WS zu begrenzen oder gänzlich zu blockieren wenn sie nicht benötigt werden (z.B. Remote EFS)? Gerade was via RPC läuft ist durch die variablen Ports/maskierten Services doch einigermassen schwierig via FW auf einen bestimmten Port/Endgerät zu begrenzen. Ausser man biegt es von Variabel auf fix um, was dann auch nicht mehr Standardverhalten wäre. RPC selbst kann man ja lediglich zwischen den Clients verhindern ohne Ärger zu bekommen.

@Userle Also die verschachtelte Freigabe sollte nichts ausmachen. Habe ich (mühsamerweise) aus historischen Gründen ein paar wenige solcher Konstrukte in der Pflege. Da werden jeweils auch zwei Laufwerke verbunden. Diesbezüglich noch keine Probleme gehabt. Das genannte Problem mit Random-mässig nicht erreichbaren Netzlaufwerken kenne ich vor allem aus folgender Situation: - Netzwlauferk verbunden, aber nicht erreichbar - USB Stick eingesteckt und es hat den Buchstaben des Netzwlaufwerkes erhalten - wie auch immer das geht - Das hat dann auch die lustigsten, nicht reproduzierbaren Fehlerbilder verursacht weil es einmal so und einmal so funktioniert hat. Lösung war dann allerlei Reg-Hives zu killen (Suche nach dem Laufwerksbuchstaben). Aber eben, hat eigentlich nix mit an- und abmelden von anderen Usern zu tun, daher auch der erste Lösungsvorschlag mit dem expliziten trennen der Verbindung/sauberem rauslöschen allfälliger Überrest von systemweiten Verbindungen. Bei Netzdruckern ist der Ärger vergleichbar wenn die Verbindungen nicht auf Benutzerebene geschehen und deren Verbindungen werden ja recht ähnlich aufgebaut wie Netzlaufwerke. Das fiese ist aber, nicht immer gibt es Ärger. Manchmal tuts auch einfach. Einigermassen schwierig zu reproduzieren. Was mir grad noch einfällt, das Verhalten gibt es auch bei abgelaufenen Kerberos-Tickets und aktivierten aktuellen Sicherheitseinstellungen für SMB (kerberos statt NTLM). Sobald man Desktop kurz sperrt und sich wieder anmeldet, sind die Netzlauwerke wieder erreichbar. Das trifft dann insbesondere auch auf die User-Accounts zu, die man in die "Protected-Users" gelegt hat. Das ist dann aber zeitlich nachvollziehbar und auch nicht durch Prozesse von an- und abmelden von anderen User beeinflusst.

Wie gesagt GPO "Automatisch herunterladen und gemäss Zeitplan installieren." setzen und nicht nur den Zeitplan selbst. Wenn das nicht zieht, die GPO's tatsächlich auch ausgeführt werden bleibt Dir nur der beschwerliche Weg den ich beschrieben habe wenn Du das wirklich steuern möchtest. Testen musst Du es mit den aktuellen Versionen die Du einsetzt mit +- aktuellem Patchstand. z.B. manuelles installieren von März-Rollups sowie vorher .Net vom Februar aus dem Updatekatalog, dann einbinden in die Domäne und schauen ob und wie er die restlichen Updates zieht/installiert.

Kriegt man nicht so easy weg. Soweit ich das beurteilen kann, ist das auch ein Verhalten das bewusst so geschaffen wurde um ein Umdenken zu erzwingen. Ist das Oberchaos und sogar zwischen Builds und manchmal sogar Update-Rollups anders. Sprich jede Build bräuchte seine eigenen, spezifischen GPO's auf die es normal auch richtig reagiert. Generell kann man sagen, dass die Einstellungen mit den Verzögerungen nur ziehen - wenn sie denn ziehen -, wenn man ebenfalls folgendes konfiguriert: "Automatisch herunterladen und gemäss Zeitplan installieren." Auch "keine Verbindung mit Windows-Internetadressen herstellen" sollte man aktivieren, sonst kann die Übermittlungsoptimierung das auch umgehen. Gibt aber auch Builds, die dann auch vom WSUS nichts mehr holen (hat ja auch eine https-Adresse). Wie gesagt, das totale Desaster um den Admins wohl den Verleider anzuhängen, das konfigurieren zu wollen. Auf Server OS - sicher in 2022 - funktioniert mittlerweile das "nur Herunterladen aber manuell installieren" wieder. Wurde wohl aufgrund zu grossem Druck wieder geändert. Ansonsten kann bei einem Client OS gesagt werden: Irgendwie kriegt Windows die Updates immer und wenn es via der Fernwartung ist weil die Maschine durch den Hersteller eine Internetverbindung bekommen hat. 100% Gewissheit hat man nur bei abschalten von Windos Medical Service und fast noch wichtiger, dem entsprechenden Task im Taskplaner und die Deaktivierung der Übermittlungsoptimierung. UpdateDienst kann normal anbleiben. Dann z.Bsp. per Task den Service aktivieren wenn man installieren möchte. Dumm nur, das das Zeugs teilweise TI-Rights braucht die man nicht so ohne weiteres bekommt. --> Auf Industriemaschinen biege ich daher die relevanten Services auf eine eigene svchost.exe um (Hardlink) und aktiviere/Deaktiviere Updates via einer Firewallrule indem ich die Diensteigene svchost erlaube oder blockiere. Auf normalen Clients limtitiere ich die Verbindung auf den WSUS, somit kann er nicht ins Internet. Funktioniert 1A. Mit Firewall-Rules kann man auch mit minimalem Aufwand das Update zum gewünschtem Zeitpunkt angestossen werden ohne gross Services an und abzuschalten. Nur der Task des Medicalservices muss ausbleiben, der korrigiert sonst die svchost.exe wieder auf das original. Auf Servern/Industriemaschinen deaktiviere ich die Übermittlungsoptimierung vollständig und ziehe die Updates mit dem Powershell-Script rein (Get-WindowsUpdate) Lässt sich mit Tasks auch recht Dirty automatisieren ;)

Hallo zusammen, Habe mich mal etwas mit den RPC-Filter der Windows Firewall befasst. Habe zwar die Empfehlung für die Blockierung von Remote-EFS damals blind umgesetzt, aber eingehend damit beschäftigt bis anhin nicht. So wie es aussieht sind RPC-Angriffe einigermassen beliebt und effizient. Vielleicht auch weil es selten konfiguriert wird? 1. Frage: Hat sich jemand schonmal mit einem Whitelisting beschäftigt? Sprich alles an RPC zu blocken und nur das gewünschte zu gewünschten Empfängern zuzulassen? Oder einem Black-Listing? Also quasi je nach Client oder Servertyp? Gibt es Empfehlungen dazu? Habe zwar etwas recherchiert aber nix sinnvolles gefunden. Da es doch ein paar Protokolle gibt, wäre der Aufwand nicht ganz unerheblich. 2. Frage: Wie rollt man das am einfachsten aus? Per Start-Script oder geht das eleganter? "Rumpfuschen" in der Registry mit GPP braucht bei Firewall-Rules normal nen neustart. 3. Frage: Wie hoch ist der tatsächliche Nutzen? Bei PetitPotam scheint es ja jedenfalls die Attacke zu verhindern. Grüsse und Danke Dann noch etwas Lektüre zum Thema für die die es interessiert: Interessanter Beschrieb: https://www.akamai.com/blog/security/guide-rpc-filter#why Die technische Doku bei MS zu den Protokollen (für die GUIDs): https://learn.microsoft.com/en-us/openspecs/windows_protocols/MS-WINPROTLP/e36c976a-6263-42a8-b119-7a3cc41ddd2a Ein paar bekannte Attacken und wie man sie blockt/filtert: https://github.com/jsecurity101/MSRPC-to-ATTACK (Leider schon etwas älter? Keine Ahnung ob obsolet oder nicht) Etwas mehr Details: https://www.tiraniddo.dev/2021/08/how-windows-firewall-rpc-filter-works.html

*Hmpf* auch ein Artikel den ich übersehen habe. Irgendwie bin ich zu doof immer alles auf dem Radar zu haben. Gibts eigentlich irgendwo eine Auflistung über alle Massnahmen die von MS gepflegt wird inkl. aktuellem Status sowie die Umsetzungsphasen etc? Würde manches vereinfachen :-/ Generell kann man sagen: Je früher man aktiviert desto besser. Ich aktiviere meist nach dem TryAndError Prinzip. Schauen was allenfalls nicht mehr geht und darauf reagieren. Oder erst Audit, beheben und dann aktivieren. Grund: Wenn MS das ganze propagiert, mit Timelines versieht etc. ist der Exploit entweder gut bekannt und wird bereits ausgenutzt oder er ist es spätestens wenn MS so granulare Infos bereitstellt. Da wird dann das Verhalten von Windows entsprechend analysiert und darauf reagiert. Bezüglich diesem spezifisch dSHeuristics: Gibt es einen empfohlenen, möglichst "sicher" Wert den man eintragen sollte? Sobald ja der Wert vorhanden ist, müssen alle Flags gesetzt werden, zumindest bis zu dem Flag, den man braucht. Ist irgendwie nicht alles so trivial beschrieben bei MS was nun genau empfohlen wird. =)

Kommt auch etwas aufs interne KnowHow drauf an. Teamviewer ist halt sehr trivial im Management. Aus technischer Sicht gefällt mir nicht, dass die Applikation mittlerweile brutal aufgeblasen ist und somit auch sicher ein paar Löcher aufweist. Mir würde da würklich der primitive Bildschirm-Tastatur-Maus Transfer genügen. Die haben in der Pandemie aber soviel verdient, dass vielleicht auch etwas in die Code-Härtung geflossen ist. ;) Ich machs meistens so: Eine kleine Workstation für den externen DL die im Netz hängt (zum Beispiel mich). Die WS kann je nach Art des DS auch eine VM sein Darauf Teamviewer oder dem DL sein Remotetools installiert Die Workstation kommt entweder übers "normale" Netz oder via eigenem Mobilfunk-Router ins Internet. Letzteres hat den Vorteil, das auch Probleme mit dem Internet gelöst oder zumindest erkannt werden können. Der Kunde kann somit immer schauen was die DL so treiben. Schafft Vertrauen und Transparenz. Egal ob sie es verstehen was getrieben wird oder nicht. Damit die Verbindung eben nur auf Wunsch des Kunden erstellt werden kann und nicht permanent, verwende ich zwei Varianten. Manchmal auch kombiniert. ganz klassisch wie im Maschinenbereich üblich einen Schalter um z.B. die Stromversorgung des Routers oder des Switches zwischen Router und PC zu kappen zwei kleine Scripts (Achtung, keine änderungsrechte für Nicht-Admins!) die per Taskplaner mit höheren Rechten gestartet werden können - auch von Usern - welche die Zulassungsregeln für Teamviewer oder Remote-Tool des Herstellers innerhalb der Windows-Firewall aktivieren oder deaktivieren. Zwei Verknüpfungen auf den Desktop welche die Tasks starten können, fertig. In der Nacht läuft dann automatisch das Trennen-Script wenn es vergessen wurde. Für die elektrische Trennung Schlüsselschalter wenn täglich erlaubt, z.Bsp. ein Zentfenster mit einer 0815 Zeitschaltuhr ein PowerSwitch den man softwaremässig steuern kann (z.B. Net IO) z.Bsp. auch mit Scripts Ein Taster welcher den Schütz mittels Timer-Relay anzieht. Das Relay deaktiviert nach einer bestimmten Zeit dann den Schütz und somit die Stromversorgung. Löst das Problem der Leute, die den Schlüsselschalter aus bequemlichkeit immer auf 1 lassen. Kann man auch mit dem Schlüssel kombinieren. Ist für jeden verständlich, Taster leuchtet = Zugriff erlaubt, Taster leuchtet nicht, Zugriff nicht erlaubt). Die Abneigung gegen VPN ist bei mir ähnlich gross wie gegen WLAN. Wird nur getoppt durch betriebsfremde USB-Sticks. Ist mir schlicht zu komplex in der Absicherung und etwas mehr das ich pflegen müsste, ohne dass ich einen echten Mehrwert in den Umgebungen hätte die ich pflege. Dann mag ich halt einfach keine fremden Arbeitsstationen direkt im Netz mit denen ein DL auch bei anderen Kunden rumschwirrt. Die sollen möglichst mit internen Maschinen arbeiten. Mir fällt da immer die Story unseres Tierarztes ein, der meinte, seine Berufsgattung sei in der Regel hauptschuldig für die Verbreitung von Tierseuchen. Man geht von Stall zu Stall und vernachlässigt oft die Hygiene bewusst- weils mühsam ist - oder unbewusst und verteilt so munter die ganzen Viren, Bakterien und sonstigen Schädlinge. Danach wundert man sich, wie sich eine Seuche so schnell verbreiten konnte. Da war der Vergleich zu unserer Branche nicht weit. Im Maschinenbereich leider nicht ganz so einfach durchzusetzen wegen deren sehr spezifischen und sehr teuren Programmen. ;)

Gerade weil Du vorher anscheinend nicht im User-Kontext verbunden hast, kann das durchaus Ärger geben wenn die Verbindung nicht sauber gelöscht wurde oder wenn Du bei manchen im User-Kontext und bei anderen Systemweit verbindest. Versuch mal auf dem Laufwerk im Script zuerst aktiv einen unmap mit net use bevor du es erneut mappst. net use LW: /d Das komplette, saubere rauslöschen einer Systemweiten Verbindung ist übrigens manchmal nichtmal mit Admin-Rechten sondern nur mit System-Rechten möglich. Entweder das Script so laufen lassen oder eben in einer Konsole mit Systemrechten. (Psexec -i -s cmd.exe) Wenn es serverseitig ein Problem wäre, könntest Du das ebenfalls die Einträge der Freigaben in der Registry unter HKLM\CurrentControl\services\LanManServer\shares vergleichen. Also du Guten mit dem schlechten. Sehen die gleich aus, z.Bsp. die Anz Users oder Permissions, dann dürfte es am Client liegen.

Also ich verstehe nicht wirklich was Du genau tun musst, kannst oder sollst und was davon freiwillig ist und was nicht. Egal was die Aufgabe ist, alles in Verbindung mit Storage Spaces ist nicht 0815. Nicht böse gemeint, aber aktuell sehe ich tendenziell schon ein Begriffsproblem oder ein Unverständis bei Dir welche Technik für was zuständig ist. Somit ist es eigentlich auch umöglich zu sagen wie man Dir helfen soll. =) Unterstützugn kann ich Dir aber mal mit den Begrifflichkeiten und Hintergrundinfos geben, fange mal von vorne an: Storage Spaces: Ist ein hochentwickeltes, sehr Crash-Resistentes Software-RAID. Allerdings ist das ganze nicht mehr im klassischen Sinn basierend auf relativ starren Discs, sondern das Kernstück ist ein Datenblock/Stripe welcher je nach den gewünschter Performance (Anz Discs pro Stripe - 1 bis X coluns) und Sicherheitsanforderung (Anz. Kopien - 1 bis 3) über die Disc(s) verteilt wird. Wenn Du mehr dazu erfahren willst, kann z.Bsp. ein paar alte Threads von mir hier suchen. Müsste ein paar Jahre her sein. Storage Spaces Direct: Ist die Ausdehnung des Konzepts über mehrere Nodes hinweg. Soweit dürfte das klar sein. Das ist das Fundament, also die Speicherung und die Bereitstellung von Datenblöcken zu definierten Kriterien für ein Volume. Im Gegensatz zu einer Disc bzw. Disc-Set auf einem klassischen Hardware-Controller oder Einsteiger SAN welches das Performance/Sicherheitskozept im Voraus festlegt und darauf dann die Volumes erstellt werden. (Etwas vereinfacht gesagt) Der Denkfehler den viele machen ist, dass SOFS und Storage Spaces Direct das selbe sind bzw. zusammen verwendet werden müssen. Was aber so nicht stimmt. Storage Spaces Direct stellt "nur" die Plattform/Unterbau für die Datenblöcke/Volumes zu Verfügung, wer die Veröffentlichung des Volumes übernimmt, ist Storage Spaces Direct egal und zuständig dafür ist es auch nicht. Also das was normal die SAN macht. Ist quasi also auch schon etwas Hyperconverged zusammen mit einer Veröffentlichungs-Rolle (vergleichbar evtl. mit NetApp-Filer). Danach kommen also die verschiedenen Varianten wie ein solches Sammelsurium an organisierten Datenblöcken als Volume veröffentlicht werden und wer somit wie in der Lage ist, diese abzurufen, zu verändern, zu erstellen etc. Das erledigen dann die Cluster-Rollen welche für die Veröffentlichung zuständig sind. Die Cluster Rolle welche die Veröffentlichung übernimmt, schert sich aus klassischer Sicht nicht um das WIE die Daten dahinter abgesichert sind, sie schaut nur, dass sie das gleiche Volume/Blöcke im Fehlerfall des Hosts über einen anderen Host zu Verfügung stellen kann. Sind die Speicher-Blöcke nicht mehr verfügbar, hat sie zwar ihren Job erfüllt, aber es ist trotzdem down. Normal ist das die vollständigem SAN-Ausfall, bei Storage Spaces halt wenn alle Nodes down sind. Ein per NFS-Rolle/iSCSI Target oder "normalem" SMB-Fileserver zu Verfügung gestelltes Volume kann speichertechnisch über alle Nodes laufen, ist aber im Grunde punkto Zugriff ein klassisches Cluster im Aktiv/Passiv Modus. Also läuft der ganze Traffic eines Volumes über einen Node. Fällt dieser aus, übernimmt der nächste Node die Veröffentlichung der identischen Daten. Beim iSCSI Target wird das Volume als Block-Storage weitergegeben. Sprich das ganze File-Handling und somit auch die Pflege der Filetable wird weitergegeben and den Empfänger des Volumes. Ein Teil der Vorzüge von SP sind somit obsolet und man hätte wohl mehr Freude an einer klassischen SAN welche gleich Block-Storage veröffentlicht. Ein Scale-Out-Filse-Server (SOFS) läuft mit den neuesten SMB Erweiterungen, Anbindung an ESXi zum aktuellem Zeitpunkt deshalb nicht möglich. Wie bereits andere kommunziert haben. Dieses Konstrukt läuft im Active-Active Modus. Die Last/Zugriffe kann über mehrere Nodes verteilt werden. Das ganze produziert für jeden File-Zugriff aber einen deutlich höheren Overhead als z.Bsp. normales SMB oder NFS, daher wird es eben aktuell auch nur für vDiscs und Datenbanken empfohlen weil da verhältnissmässig wenig Open/Close/Berechtigungsanfragen/resize stattfinden. Im Grunde spricht aber nichts dagegen einen SOFS als normalen hochverfügbaren Fileserver einzusetzen, wenn alle Clients SMB 3.0 unterstützten und man auch sonst ein paar Dinge in Kauf nimmt, die schlicht noch nicht umgesetzt sind (Weiss ich grad nimmer auswendig, manches davon wie Dedupe geht schon, manches nicht). Dem Konstrukt ist eigentlich egal ob die Files 2TB oder 1MB gross sind. Aber der Zugriff wird tendenziell langsamer sein. Nicht zwingend die Übertragung selbst, sondern das drumherum. Das arbeiten mit einer Access-DB ist mit sicherheit langsamer, das speichern eines Worddokuments wird vermutlich total egal sein. Verschieben von ganzen Ordnerstrukturen mit tausenden Files verursacht eine ziemliche Last. Handling mit grossen Files ist aus Ausfalltechnischer Sicht und der damit einhergehenden Arbeit das ganze wieder online zu bringen, kaum zu toppen. Auch für normale Clients. Anmerkung: Ob SOFS Nicht-SP-Direct Volumes unterstützt kann ich nichtmal sagen, da nie probiert. Findet man aber sicher schnell raus in den Dokus oder mit Tests. Möglich das es notwendig ist, möglich, dass es unabhängig davon ist. Je nach dem wie eng die Layer verzahnt sind/entsprechende Prüfungen erfolgen. Ich tippe gefühlsmässig auf abhängig. Überlasse ich Dir nachzuforschen. Auch das Caching geschieht über verschiedene Ebenen. Write/Read mittels der Tiers auf Poolebene (nicht im eigentlichen Sinne ein Cache,aber irgendwie schon), dem RAM als Read welches Windows sowieso benutzt (allerdings eben wirklich nur für sehr kleine Files von ein paar KB, die grenze kann man mit dem überschreiben von Sektoren herausfinden, Daten nicht mehr da, aber Windows liest die Datei noch korrekt, zumindest spätestens bis zum Reboot), sowie den Cluster-Cache welches zur Zeit die einzige Möglichkeit ist, RAM als schnellen Read-Cache für grössere Files zu Verfügung zu stellen. Dieser ist allerdings Hostbezogen (Keine Ahnung wie das technisch genau funktioniert in Verbindung mit SOFS, da blicke ich nicht ganz durch, tippe darauf, dass einfach der Cache des Host für den Client zuständig ist, via jenen man gerade zugreift, was es ineffizent machen könnte. Wäre noch zu untersuchen/erforschen, heute vielleicht in Dokus). Genau dieser Umstand macht das "normale" Storage Spaces auf einem Single-Node mit Magnetplatten ultralahm. Weil eben der RAM-Cache durch die Cluster-Rolle zustande kommt. Man bräuchte also eine Single-Node-Cluster um davon zu profitieren. Oft kann man aber mit SSD und NVMe gut leben, weil deren Latenz tief genug ist (Daher empfehle ich auch immer Enterprise-HDD's zu nehmen. Diese haben normal eine relativ gute Durschnitts-Latenz, das macht das schreiben und lesen insbesondere mit mehreren Discs pro Stripe/anz Columns auch ohne Cache schnell, weil immer die aktuell langsamste zählt. HDD ist konstant lahm, da konstant hohe Latenz.). Die moderne Art der Verbindung zum SMB ist dann "SMB-Direct". Das lagert Lanspezifische CPU-Zyklen an hochspezifische LAN-Karten aus (RDMA). Notwendig ist das nicht, aber sehr vorteilhaft. Alles was in Verbindung mit Storage Spaces die Latenz senkt, hilft der Performance enorm. Salopp gesagt ist Storage Spaces aktuell auf Geideh und Verderb mit der Latenz verheiratet. Weil eben die Cache-Möglichkeiten aufgrund der Ausfallsicherheit im Vergleich zu klassischen SAN's mit Batterie/Kondi Puffer des RAM's eher Stiefmütterlich sind. Ist diese tief, rennt es, ist sie hoch, lahmt es. Möglicherweise hat hier Intel Optan RAM Abhilfe geschaffen oder wird es in Zukunft (nachforschen, aber wäre prädestiniert dafür). ;) Mein persönliches Fazit Der grösste Showstopper von SP direct ist dem hochverfügbaren, sehr modernen Konzept geschuldet. Damit das ganze überhaupt einen Sinn macht und man aus der Komplexität auch einen Nutzen hat und eben nicht nur Komplexität entsteht die im Fehlerfall eben seinen Dienst versagt, sollte man mind. 4 Nodes betreiben und die Sache entsprechend verstehen. Ist also eine ziemliche Schlacht an Hardware für eine Minimalkonfig und wird erst mit der Skalierung besser. Um zu verstehen warum das so ist, muss man etwas tiefer in die Funktionsweise von Storage Spaces und ReFs tauchen. Die Lektüren sind bei MS aber deutlich besser als vor 10 Jahren, da durfte/musste man das meiste selber herausfinden. Auch warum es optimal 4 Discs/stripe-sets (columns in SP) und nicht wie für RAID 1 deren zwei für einen 2-way Mirror (obwohl es geht!) und deren 5 für einen 3-Way Mirror auf einem Single-Node. Auch möchte man eher nicht direkt einen SOFS für die Clients und gleichzeitig für die VMs auf den gleichen Maschinen. Da würde man die unterste Ebene der Infrastruktur direkt ins LAN stellen. Tut man aber mit den iSCSI Adaptern der SAN auch nicht. ;) So kommt man recht schnell zum Schluss, dass man produktiv entweder eine SAN nimmt oder sich sonst ein paar andere Gedanken machen muss, wenn man keine so grosse Infrastruktur unterhalten/finanzieren möchte (z.Bsp. Single Host mit Storage Spaces statt Hardware-RAID dafür ultraschnelles Recovery). Für den Spieltrieb gibts nicht viel cooleres als SP, zumindest für mich =) Was man beachten sollte beim Entscheid Mit Hyperconverged sind dann ein paar Spielereien möglich die entweder wirklich besser auf der Spielwiese bleiben oder wenigstens eine hervorragende Doku benötigen. Sonst lässt man es besser. Oft erfüllt ein deaktiviertes aber separat repliziertes DFS-Target für File-Services seinen Zweck genauso gut. Noch wichtiger ist, dass einem die Einfachheit der Assistenz-Konfiguration nicht über die Komplexität von Storage Spaces hinwegtäuschen soll. Eigentlich wie bei vielem, insbesondere bei Cluster. Die sind schneller am Ausfall beteiligt, statt dass sie davor schützen als einem Lieb ist wenn man die Infrastruktur vernachlässigt. Nur sind hier die Auswirkungen unter Umständen recht dramatisch, ähnlich einer sterbenden SAN. Mit dem Unterschied, dass die grossen Hersteller einen excellenten Support und Rep-Abteilung haben. Bei Storage Spaces sind die Experten sehr rar und sie zu finden ist ist auch schwierig. Ein paar Tips zur Umsetzung Insbesondere mit wenigen Discs/Hosts ist der Assistent tendenziell unbrauchbar (er macht stripes über zu viele Discs) und man muss selber via Powershell ran. Paradox, weil Grossumgebungen sicher mit Powershell erstellt werden. Man sollte recht genau wissen wie es funktioniert, sonst fällt einem Storage Spaces gerne auf die Füsse (wobei die Kontrollmechanismen von Windows 2022 heute viel besser sind als noch mit 2012). Wenn man aber genügend Zeit in die möglichen Fails investiert und versteht was SP daraus macht (speicher voll, strom weg, strom aller hosts weg, Festplatte kappen, Bad-Sectors erzwingen, DB-Write unter Last usw.), ist Storage Spaces ausfallsicherer als vermutlich jeder Hardware-Controller den man in eine 0815 Büchse steckt (von denen durfte ich in den letzten 10 Jahren so einige tauschen, für Magnet nehme ich die noch). Dann noch die fast vergessenen Ärgernisse die heute noch, wenn auch abgeschwächt bestehen: Der Tod von fast jedem Pool oder ReFs Volume ist übrigens Speicher der ausgeht. Das passiert schneller als einem Lieb ist und man geneigt ist anzunehmen, verursacht durch die Funktion die das Fileystem eigentlich schützen sollte. Insbesondere beim hantieren mit sehr grossen Files die verändert und wieder gespeichert werden, da immer erst die Daten neu geschrieben werden, dann die Metadaten aktualisiert und erst dann der Speicher der alten Kopie wieder freigegeben wird. Daher auch lieber gleichgrosse Platten verwenden, auch wenn man geneigt sein könnte einfach alles an Platten reinzuschieben was gerade so rumliegt. Da verliert man den Überblick über den effektiv freien Speicher für eine grosse Operation nicht. Das sollte man höchstens in grossen Pools und lieber single Hosts/testumgebungenm datengräber. Das "auffinden" von defekten Festplatten erfordert ein Gehäuse welchse auch beim richtigen Slot "leuchten" kann. Hat man das nicht, hilft nur eine Doku. Sonst endet es böse. ;) Ein (eigentlich sehr) wichtiger Bug war mit Version 2019 leider immer noch "schlimm", also nicht behoben. Nicht immer wird ein Mehrheitsentscheid erzwungen. Sprich hat man einen Three-Way Mirror, muss es nicht sein, das die zwei guten Sets das schlechte Set überstimmen. Sprich gibts im Set 1 einen unerkannten Bad Sector, heisst es leider nicht zwingend, dass SP dieses Set korrigiert und stattdessen den Wert der andern Zwei nimmt. Wovon man aber eigentlich ausgehen würde, wozu sonst mehrere Mirror und Prüfsummen. Gilt eigentlich auch beim 2-way, weil grundsätzlich sind meines Wissens Prüfsummen mit von der Party via den Metadaten, sprich SP wüsste eigentlich wenn ein Stripe inkosistent ist und könnte den Stripe von der Kopie lesen und diesen verwenden, wenn er OK ist. Die Wartungsjobs (Aufgabenplanung) erfüllen den Job zwar manchmal, aber dann ist es eventuell zu spät, da bereits gelesen und gecrashed. Manchmal erfüllen Sie ihn auch auch falsch. Wie es mit 2022 aussieht weiss ich nicht, produktiv vorgekommen ist es bei mir noch nicht nicht oder ich habe nichts davon bemerkt. Ist aber auch eher selten bei SSD's, wenn es vorkommt, ist sie meist eh am Ende. In der Testumgebung erzwingen war aber durchaus möglich. Mit 2022 habe ich die Tests noch nicht gemacht. Zum Schluss: Für das testen ist wichtig wie das OS die Discs erkennt/markiert. Als physische Discs oder eben als Shared Disc. Eine Shared Disc kann man nicht einem Storage Spaces Direct Pool hinzufügen. Eine Phyische-Disc nicht einer Cluster-Rolle für die Veröffentlichung der Daten. Notfalls muss man das für Testumgebungen umbiegen. Sorry wurde etwas länger, aber einkürzen bräuchte noch mehr Zeit, das überlasse ich Dir :-P

Genau, mich auch. So ohne den Rest Deiner Aussagen hätte ich glatt auf Replikations-Probleme bei mehr als einem DC getippt, allenfalls in Verbindung mit aktivem, manuellem Eingriff in die Aktualisierungs-Politik der Maschinenkennwörter. *hust*

@NorbertFe Jo mit Exchange sieht die Sache defintiv anders aus. Da bin ich gleicher Meinung. @daabm Hmm und wie kommt das tatsächlich zustande? Kann mir das Szenario irgendwie nur schwer vorstellen. Kam mir auch noch nie unter. Wenn der DC nicht mehr vertrauenswürdig ist, geht ja in der Domäne eh nix mehr, also von extern das Maschinenpasswort zurücksetzen wird dann wohl auch essig sein. Dann müsste eben das Backup her. Aber eben, ich kenne aktuell noch nicht mal die Sympthome die das hervorrufen wird. ;) Auf alle Fälle würde ich die Risiken durch ungewollten Wiederherstellungen z.Bsp. durch Snapshots deutlich höher gewichten. Totalschaden und Rückgriff auf Backup gibts dann wohl bei beiden Fällen. Ausser man nimmt sich unter Umständen viel Zeit. Gab ja grad wieder einen Fall hier im Forum von ungewollter Wiederherstellung. Bei einem wäre das nicht passiert. ;) Werde sobald ich mal etwas Spieltrieb habe, das Szenario mal austesten ob man wirklich nicht an die DB rankommt und das PW ersetzen kann oder die gängigen Powershell-Funktionen mangels Authentifizierung nicht funktinieren (was zu hoffen ist).

Welcher Build ist den dein Server 2022? Nakt ohne GPO's welche die aktuelle Umgebung absichert? Vielleicht sind ja bei neueren Builds standardmässig ein paar Sicherheitsfeatures aktiviert welche Dir den Brei verderben. Würde sicher eine Build vor November letzten Jahres nehmen für solche Übungen. Wobei verdorben ist er ja schon mit SMB 1.0 Eventuell brauchts bei aktuelleren Builds eine Änderung des Standardverhaltens, also explizites setzen von älteren, nicht mehr empfohlenen Einstellungen. Mit Get-SmbClientconfiguration bekommst in Powershell die Grundkonfig für SMB raus die könntest Du mit einer 2012er Maschine vergleichen. Das ganze "unnötige" Sicherheitsgedöhns mal abschalten und nach und nach wieder aktivieren und rausfinden was anbleiben kann und was nicht. Dann evtl. mal Logs für NTLM, Kerberos, Netlogon etwas eskalieren und schauen wie das OS authentifizieren möchte. Dann noch mein Standardtipp, Firewalllogs aktivieren und schauen was für Pakete zugelassen/abgelehnt werden. Sprich ob von vornherein etwas hakt. Die Uhrzeiten mit anderen Einträgen von System/Anwendung etc. abgleichen und man bekommt recht viel raus wos hängt. Die Auswertungen sind deutlich einfacher wenn möglichst viel Telemtrie abgedreht ist die irgendwohin verbinden möchte. Wenn alles nix hilft, die Security-Bulletins der letzten 2-3 Jahre checken und man bekommt recht viel raus was grad mühsam sein könnte mit alten Geräten. Einfach alles aktiv rückgängig machen mit Regsettings oder gpedit.msxc was so empfohlen wird. *rofl* Wieso tut man sich eigentlich freiwillig Samba an, wenn man doch Windows-Systeme einsetzt? Ich werde es nie verstehen und tue es auch heute nicht =)

Die Ansicht mit 3 bis 4x mehr als RAM ist etwas veraltet. Da war RAM noch enorm Mangelware. Am Ende kommt es darauf an, wozu das Pagefile effektiv dienen soll. Bei einem VDI-Client ist mir ziemlich egal ob er ein vollständiges Dump des RAM abspeichern kann oder nicht. Ein paar Minidumps und etwas Paging reicht eigentlich. Eigentlich soll Windows nur den Kernel auslagern, sonst hat die VM im Grunde zu wenig RAM. Siehe auch: https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/how-to-determine-the-appropriate-page-file-size-for-64-bit-versions-of-windows Von einem MS-Mitarbeiter wurde mir mal empfohlen, maximal 1'500 MB zu geben. Auch bei Server. Mehr würde Windows nicht sinnvoll selber verwalten können wenn es zum Paging kommt. Und für normale Dumps, auch mehrere, reiche das aus. Sollte mehr ausgelagert werden, sei die Maschine eh "tot" und somit einigermassen unbrauchbar. Nur für die vollständige Dump-Analyse brauche es mehr. Das heisst RAM + ca. 256M können man vorhalten (steht auch in der Dok so). An diese Empfehlung halte ich mich mittlerweile ~10 Jahre und erhöhe Speicher manuell für die Analyse wenn ein vollständiger Dump benötigt wird. In meinen Klein-Umgebungen funktioniert das bis jetzt einwandfrei. Meist bewegt sich die Pagefile um ein paar 100MB, entspricht also dem Kernel.