Weingeist

Nun, bei manchen Abo's liegt das Problem halt schlicht und einfach an der Tatsache, dass es nicht vorgesehen ist, Maschinenbasiert zu kaufen. Genauso wie es das anders rum gibt. Auch wenn es an der Rechtsberatung entlangschrammt, konnte ich einem MS Mitarbeiter mal folgende Aussage entlocken: Solange alle Mitarbeiter die in irgendeiner Form direkt oder indirekt mit der Funktion/Geräte/Zugriff zu tun haben auf User-Basis lizenziert sind, sei es Ihnen aus lizenztechnischer Sicht herzlich egal wenn ein rein geräte-basierter Zugriff nebenher läuft. Das Maximalziel sei ja bereits erreicht, jede Person die damit zu tun hat ist lizenziert. Einfaches Beispiel: Ein Multifunktionsdrucker kann auf ein Fileshare scannnen. Nur ein Mitarbeiter darf effektiv scannen. 1. der Scanner steht in der Caffeteria 2. der Scanner in einer Abteilung 3. der Scanner steht im Büro eines Mitarbeiters, andere haben nichts verloren im Büro ist optimalerweise sogar abgeschlossen. Entweder kann das nun je nach räumlicher/phyischer Trennung auf User Basis lizenziert werden oder eben das Gerät selbst. Bei 1. und 2. macht sicher das Gerät Sinn. Wozu allen Mitarbeitern eine CAL kaufen, wenn nur ein User überhaupt Scannen darf. Selbst wenn alle dürften und keiner etwas mit PC's am Hut hat wäres sinnvoller für das Gerät. Bei 3. wäre es übertrieben auch für das Gerät eine zu kaufen wenn der User schon eine hat. Angenommen es gibt die Geräte-CAL aber nicht und das Gerät steht dennoch in der Caffeteria: Jetzt haben wir ein Problem, es darf zwar nur einer Scannen, aber jeder könnte Scannen. Wir müssten folglich jedem Mitarbeiter eine CAL kaufen. oder wir müssen mit geeigneten Massnahmen sicherstellen, dass niemand der nicht darf, eben auch nicht kann. Schlüssel/Keycard/Passwort am Scanner/Scanner in das Büro des Mitarbeiters verschieben etc. Auch das ist für MS in Ordnung. Wenn man dieses Prinzip auf die anderen MS Produkte überträgt und sich nicht selbst belügt/schön redet oder Zugriffsbeschränkungen vernachlässigt, dann ist man Grundsatz korrekt lizenziert. Bei einer rein administrativen E-Mail-Adresse auf welche mehrere Admins Zugriff haben/Meldungen erhalten würde das heissen: Wenn alle die automatisiert Meldungen von Geräten erhalten oder Zugriff auf das Mailkonto haben selber über eine eigene Lizenz verfügen, ist für MS die Maximalforderung aus lizenztechnischer Sicht erfüllt weil auf physischer-User-Basis lizenziert wird. Im Umkehrschluss heisst das aber auch: Man muss wohl oder übel alle Admins lizenzieren auch wenn die Adresse gemeinsam ist. Man bezahlt den Physischen User. Für ein allenfalls gemeinsame Administrativ E-Mail-Adresse bezahlt man dann nicht in dem Sinne für eine Lizenz, sondern für die Dienstleistung Speicherplatz/Management. Im Detail muss man natürlich die Bestimmungen für das entsprechende Produkt lesen, aber generell kann man davon ausgehen, dass wenn es in den Bestimmungen keine Einschränkungen oder allenfalls auch Begünstigungen zu diesem Prinzip gibt, dieses Prinzip auch angewendet werden kann.

Ich präzisiere: Für Lokale Accounts in Maschinen die an eine Domäne gebunden sind und man sich von extern authentifizieren möchte. Diese anfragen werden auch abgeblockt wenn man z.Bsp. auf ein Share zugreifen möchte und enforcement aktiviert ist. Edit: Deine Frage habe ich weiter oben beschrieben, dass ich das weiterhin als Ausnahme haben möchte für die Workarounds. Also NTLM. Stand jetzt, geht das nicht mit Enforcement. Sprich man muss NTLM-Blockieren wieder aufheben. Aber das weisst Du bestimmt oder? Edit2: Und nein man kann - wie auch auch weiter oben beschrieben - keine Ausnahme für das Zielgerät machen sobald gängige Sicherheitsfeatures wie SMB-Signing aktiviert ist. Weil nicht das zugreifende Gerät in der Auswertung erscheint sondern eben das Gerät auf das zugegriffen wird. Auch wenn das nach dem November theoretisch keinen Unterschied mehr macht. Glaube zwar nicht, das dies von MS so gewollt ist, fakt ist es aber. Das lokal ohne Domäne Kerberos "schwierig" ist, versteht sich ja von selbst oder?

Ein wenig frech ist das aber schon... Soviel kostet ja das Original in neu!

Stimmt... Für WMI gibts ja auch fast alles, nur ist das dann wirklich die Kategorie obermühsam da was rauszupfriemeln wenn man nicht täglich damit arbeitet.

Die meinte ich mit "Manche Services" hab nur die optische akzentuierung vergessen Cluster sind ja ne Kleinigkeit *hust* Mit 2022 hat das geändert. Nicht mehr NTLM abhängig. Glaube man bekommt heute alles mit Kerberos zum laufen (Bis auf das was man nicht zum laufen bekommt und wir vielleicht noch nicht wissen). Sonst könnte MS ja schlecht per Ende Jahr alles abschalten. Ich persönlich glaube zwar noch nicht daran, sondern tippe auf erst mal Messer ansetzen aber noch nicht ganz zustechen. Mein Wett-Tipp: NTLM für lokale Accounts wird die letzte Ausnahme sein, die vermutlich nicht mal fallen wird weil man damit die Würg-Arounds hinbekommt, den manchernorts vermutlich noch 10 Jahre oder mehr notwendig sein werden. Auch wens unschön ist, ich würde es begrüssen und Risiko ist tendenziell abschätzbar.

Weitergraben hilft... MS - wenn man mal zu den richtigen Leuten durchgestellt wird - hat durchaus sehr fähige Leute. Aber es braucht immer eine gewisse Hartnäckigkeit wenn man nicht auf Anhiebe jemanden schlaues bekommt. Manchmal scheint mir, der FirstLevel bekommt eine Erfolgsprämeie für selber abgeschlossene Fälle oder so...

An die guten Leute ist je länger je schwieriger zu kommen. Wie bei jeder grösseren Firma. Haarsträubend teilweise. Die Preise gehen dafür fleissig nach oben. Eigentlich gibt es nur zwei Möglichkeiten: Telefonisch (äusserst) hartnäckig bleiben, notfalls x-mal anrufen, vorgesetzte verlangen wenn man nicht weiter kommt usw. Zweie: Anfrangen per E-Mail kurz und knapp formulieren mit der Bitte an einen Spezialisten auf diesem Gebiet verwiesen zu werden. Richtig toll sind die Chats. Das sind oft Bots und keine richtigen Leute. :( Mir fällt grad ein: LTSC Produkte sind jetzt in einem speziellen Store, möglicherweise auch die Non-Profit?!? Mein Distri hat einen Store bei MS und da kann ich Produkte kaufen und die kommen dann gleich ins Konto.

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