Weingeist

Schadcode nachladen: Das war logischerweise auf 3rd Party Tools gemünzt. Sorry Deine Einstellung ist komplett falsch. Präventionsarbeit zu leisten und Mitarbeiter und insbesondere die GL für das Thema zu sensibilisieren gehört zu den Aufgaben eines externen Dienstleisters. Dafür stellen die ja einen ein, weil sie selber keine oder wenig Ahnung haben. Sprich man muss dafür Sorgen, dass die selber merken, dass entsprechende Schulungen für die Mitarbeiter notwendig sind und gewisse Verhaltensregeln aufgestellt werden müssen. Damit diese eben nicht versuchen, Sicherheitsmassnahmen zu umgehen, sondern verstehen wozu die da sind. Genau weil es immer einen kreativen Weg gibt. Ganz ehrlich, schafft man das als Dienstleiter nicht, gehört man selber in eine Kommunikationsschulung. Vor 20 Jahren war das teilweise tatsächlich schwierig die Leute zu Überzeugen, heute ist das wirklich keine Hexerei mehr. Die Überzeugungsarbeit leisten bereits die Medien, man muss nur noch sagen was sie tun sollen oder eben nicht. Das reinste Heimspiel. Jeder hat heute zu Hause viele private Fotos, die er nicht gerne verliert. Selbst die Senioren. Das Problem ist nur, sie wissen manchmal über die einfachsten Verhaltensregeln nicht bescheid. Ansonsten: Für den Umgang mit Chemikalien/Maschinen sind die Leute gewohnt zu unterschreiben, dass Sicherheitsmassnahmen verstanden, befolgt und insbesondere nicht aktiv ausgehebelt/umgangen werden. Das gleiche Prinzip muss man auf die IT anwenden. Inklusive allfälliger Massnahmen. Ansonsten gilt es wie in der Landwirtschaft, die faulen Äpfel werden nicht gesund nur weil um sie herum alles gesunde Äpfel sind. Der Faule muss raus. So einfach ist das.

OK. Also mit der Windows-Firewall ist das ziemlich trivial. Weil halt auch die Log-Einträge zeitlich exakt übereinstimmen. Sprich man kann im gleichen Sekunden/Sekunden-Bruchteil die entsprechenden Pakete mit den Remote-IP's auffinden, welche zur Zeit des NTLM-Eintrages geloggt worden sind. Solange MS die Authentifizierung gegen Lokale Accounts von Nicht-DC-Maschinen erlaubt bzw. das Enforcement auf Nicht-DC's nicht per se zwingend ist, kann man sich mit Nicht-Domain-Accounts behelfen.

Gegen den Physischen Mous-Jiggler hätte ich noch nicht mal so richtig was. Kriegt er Kreaktiv Punkte. Gegen den Rest welcher die IT-Abteilung nicht zu Verfügung stellt schon. WEIL: Genau mit so schwachsinnigen Programmen die oberflächlich einen Nutzen haben, wird später Schadcode nachgeladen. Daher Verbot für jegliche Tools und Umgehungsversuche inkl. Abmahnungen. Da gibts eine 0 Toleranz. So werden oder sollten die MA's geschult werden. Und es funktioniert tatsächlich, weil man täglich in den Zeitungen lesen kann was passiert und nicht nur passieren kann. Optimalerweise hat man AppLocker, dann können sie die Fremdsoftware noch so lange ausprobieren.

Salut zusammen, Bei Windows 11 22H2 wurde das ja standardmässig eingeführt. Siehe: https://learn.microsoft.com/en-us/troubleshoot/windows-client/printing/windows-11-rpc-connection-updates-for-print Im Netz habe ich nun gefühlt 1000 Anleitungen gefunden wie man das Feature rückgängig machen kann, aber keine einzige wie man diese Verbesserung tatsächlich nutzen kann *schulterzuck* Da alls was mit Printer zu tun hat eh Exploit-Anlaufstelle Nummer 1 ist und jede Verbesserung gemacht werden sollte daher die Frage: Kann man auch das Gegenteil machen? Also den Printserver beibringen, dass sie solche Verbindungen akzeptieren? Falls ja welche Server-Versionen unterstützen das? Das ganze natürlich am liebsten auch bei Windows 10 / Server 2022.... Sprich geht das oder nicht? Und falls ja, kennt jemand grad einen Artikel dazu? Ich vermute ist noch ein exklusives W11 Feature, da ich nichts dazu gefunden habe. Aber vielleicht weiss ja jemand mehr. Grüsse und Danke

@testperson: So verstehe ich das auch. Ich scheitere etwas damit was tatsächlich eingestellt werden soll bei den anderen Bits/Zeichen. 28/29 ist ja dann für das enforcement des aktuellen Zeugs. Beide auf 1 und es ist aktiviert. Soweit so gut. Immerhin scheint man - weil eben Standardmässig alle Werte 0 sind - am Standardverhalten nichts zu ändern wenn man einfach die letzten Zeichen für die aktuellen Enforcements auf 1 setzt und ansonsten nur die Erweiterungsbits auf 1 (10) bzw. 2 (20). Betreffend Powershell: Hier sind die verschiedenen Variante gut beschrieben, inkl. Powershell. Einfahc für ältere Werte, aber kann man ja adaptieren: https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/duplicate-spn-errors-active-directory-migration-tools-and-kb/ba-p/258102 Bei manchen habe ich aber das Gefühl, man sollte aus Sicherheitsgründen vom Standard abweichen. Manche sind selbsterklären durch die Beschreibung, andere eher nicht. Aber beurteilen welche Variante nun sicherer ist, fällt mir nur aufgrund der Beschreibung bei manchen einigermassen schwer. Gibt es da Empfehlungen? Als Beispiel Bit bzw. Zeichen 9, das scheint mir z.B. relevant zu sein, da es um Passwörter geht: Was ist den da nun tatsächlich erwünscht? Will man diese Heuristic aufs fUserPwdSupport haben oder nicht? Falls man sie haben will, will man das nur bei AD LDS (0) oder auch bei AD DS (1) haben oder eben nirgends? Wenn ich es richtig interpretiere ist es besser mit. ABER: Warum ist es dann standardmässig bei AD DS nicht aktiviert obwohl es die einstellung schon mindestens 15 Jahre gibt? Aus irgend einem Grund wurde die ja geschaffen und standardmässig für eine der beiden Varianten aktivert und für die andere deaktiviert.

Woher die Anfrage kommt, kannst in der Regel mit Firewall-Auditing herausbekommen. Die exakte Zeit der Logs vergleichen für Allow und/oder Rejected Packets.

Na klar ist es nicht geheim. Das ist eher in Bezug darauf gemeint, das MS-Mitarbeiter einem das nicht mitteilen wollen obwohl es eben eigentlich relativ klar wäre. Darum gehts ja, sie wollen keine Stellung (mehr) beziehen und/oder dürfen das auch nicht mehr. Dass sich einer zu dieser Aussage hinreissen lässt, ist tendenziell selten bis nicht (mehr) gegeben. Und auch klar, aus den Bestimmungen kriegen man alles raus. Auf deren Basis erhält man die ja die ensprechenden Nutzungsrechte und sind allenfalls Pflichten definiert. Nur ist nicht unbedingt sofort klar wo man suchen und wie man es interpretieren muss.

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