Weingeist

Wieso widerspricht sich das? Es muss doch insgesamt einen effektiven Sicherheitsgewinn geben, wenn man eine solche Komplexität im Namen der Sicherheit einführt wo diese nicht beim einrichten selbst bleibt. Ohne effektiven Sicherheitsgewinn für die produktive Umgebung hat eine solche Massnahme doch keinen wirklichen Wert *schulterzuck* Auch wenn ich mich wiederhole: Sobald die ganze produktive Umgebung an den ars*** geht oder Daten abgegriffen wurden, weil sich jemand Domain-Admin-Rights gesichert hat im Netz wo die Daten liegen, wo man arbeitet, ist das Kind doch eh schon in den Brunnen gefallen und man muss das Backup anzapfen welches vorzugweise wirklich komplett separat vom Rest aufgebaut ist. Was hilft ein Auffangnetz auf dem Grund des Brunnens wenn man oben absäuft? Ich verstehs echt nicht. Für mich sieht es aktuell so aus: Viel Komplexität wenn man es durchzieht (inkl. Backup), viel Bla Bla und somit viel gutes Gefühl für wenig effektiven Gewinn. Daher wäre schön wenn jemand der etwas davon versteht, das propagiert, das eben auch für alle verständlich erklärt. Weil ich verstehe das nicht obwohl ich nicht wenig Lektüre zu diesem Thema gelesen habe. Ich sehe den Nutzen anderswo. Aber nicht wirklich bei der Sicherheit der produktiven Umgebung. [Spoiler] Kommt mir grad in etwa so vor wie vor ~15-20 Jahren als die Cluster bei vielen Admins in kleinen und mittleren Umgebungen Hochkonjunktur bekamen weil es die grossen propagiert haben. Die wenigsten - teilweise auch heute noch - sind sich so richtig den Konsequenzen und Voraussetzungen bewusst damit es auch ein Gewinn ist und nicht das Gegenteil. Die wenigsten brauchten diesen Gewinnn sondern wären bei der Investion in schnelles Recovery, Ersatzsystem etc. deutlich besser aufgehoben. Beim Thema Sicherheit ist es schwierig die Grundlagen umgesetzt zu haben, weil es eben keinen sinnvollen Leitfaden seitens des Herstellers gibt, die vernünftigen Einstellungen nicht "ab Werk" gesetzt sind und jede Firma/Dienstleister das Rad quasi neu erfinden muss. Wie immer, meine Meinung, kann man teilen, muss man nicht. ;) [/Spoiler]

Ehrlich gesagt begreife ich das immer noch nicht. Wo liegt genau der Sicherheitsgewinn welcher zur tieferen Angreifbarkeit führen soll? Aktuell interpretiere ich das so - besseres Logging: weniger Einträge, weniger Log-Rotating etc. führt zur klar besseren Auswertmöglichkeiten für Admin-Konten - kürzere Token-Laufzeit, krbtgt-Kennwörter, JIT Berechtigungen, aber könnte man alles auch im "normalen" AD machen (je nach Grösse, praktikabel oder auch nicht) - Grössere Attack-Surface durch mehr Schnittstellen/Kommunikation etc. (klar ist gesichert, aber ist nunmal zusätzlich) - Massive Komplexitäterhöhung (Backup, Recovery, mehr Hardware, mehr Updates etc.): Macht insbesondere kleinere Umgebungen unzuverlässiger als zuverlässiger - Domain Admins sind leer: Geht nicht die Empfehlung dahin, dass man diesen nicht beschneiden sollte und auch entsprechende Notfall-Accounts hat die unabhängig vom Bastion sind? Einem Angreifer ist im Endeffekt doch egal wer ihm die Zugriffsberechtigung "verschafft" um der Produktiv-Umgebung zu schaden. Sehe den Unterschied nicht, wenn man möglichst alle Empfehlungen die für Bastion-Accounts gelten auch für die Produktive umsetzbar wären (weiss nicht ob das möglich ist). Eigentlich wäre es meiner Meinung nach fast wichtiger, die Produktiv-Daten in eine Art Bastion zu schieben und der Zugriff darauf besser gesichert/JIT sein, auf anzahl dokumente beschränkt etc. Vielleicht mag das ja mal jemand erklären. Aktuell sehe ich die Vorteile nicht in der Erhöhung der Sicherheit für das aktuelle Geschehen. Eher zur Erhöhung der passiven Sicherheit weil gewisse Prozesse automatisiert und mit Richtlinien ausgestattet werden und so die Fehlerquote senken oder Admins effektiver "beschnitten" oder mit Rechten ausgestattet werden können. Das wiederum hat eher in grösseren Umgebungen Vorteile. Was genau übersehe ich?

Das verstehe ich ja grad nicht. Wieso sollen die Admin-Accounts im separaten Admin-Forrest bzw. Bastion-Forrest nicht aus dem produktiven Netz heraus komprimirtiert werden können wenn man sich auch mit Ihnen authentifizieren kann? Die Abläufe sind ja im Grunde identisch nur die Authentifizierungstelle ändert sich. Also was macht sie gegenüber anderen Accounts weniger angreifbar? Und wenn sie komprimitiert sind, haben sie die notwendigen Berechtigungen für das produktive Netz. Klar ist es einfach(er) bei anderen. Wenn man die entsprechenden Lizenzen hat. Aber auch wieder mehr "fremde Software". Welche mittel stehen den als VM nicht zu Verfügung? vTPM gibts ja mittlerweile auch. Nested VM's ebenso, also Credential Guard auch möglich. Und viel mehr kann eine physische ja eigentlich auch nicht bieten. Von der Exklusivität der Hardware mal abgesehen. Aber klar, ich bin bei Dir. Immer frisch ist immer frisch. Obs gegen die automatisierten Angriffe wirklich hilft? *schulterzuck* Darum meine ich ja die grundlegenden Dinge die "ab Werk" eben falsch bzw. unsicher sind. Ein spezieller Dienstleister - der eben auch entsprechend kostet - sollte doch gerade nur für das individuellen Dinge notwendig sein und nicht für den 0815 Teil der eigentlich immer gemacht werden sollte. Ich stelle die These auf, dass 90% aller Firmen sich keinen solchen spezialiserten Dienstleister ins Haus holen. Nichtmal bei den grösseren KMUS mit 50 Leuten und mehr. Maximal deren üblicher Dienstleister selber und die meisten vermutlich auch nicht regelmässig. A weil sie nichtmal auf die Idee kommen B weil sie davon ausgehen ihr aktueller Profi macht es schon richtig C weil es vermutlich definitiv zu teuer wird für einen KMU D weil sie nicht beurteilen können ob der nun etwas davon versteht oder nur so tut - ich meine das ist ja schon für einen Fachman nicht unbedingt trivial zu erkennen Das von einem typsichen KMU von 5-20 Nasen zu erwarten... Ich weiss nicht. Tue ich mir etwas schwer. Selbst von solchen die eben solche Kleinkunden betreuen. Selbst wenn grosse Häuser solche Kunden betreuen wird es schwierig. Weil sie es eben nicht für notwenig erachten, ist ja ne kleine Bude. Wenn dem nicht so wäre, hätten die ganzen Schadware-Verteiler nicht soviel Erfolg. Weder in der öffentlichen Hand noch bei Privatunternehmen. Das ein solcher Leitfaden auch entsprechend gepflegt, aktualisiert und eben +- vollständig in Bezug auf das Grundlegende sein sollte, versteht sich von selbst. Mir kommts halt in der IT immer so vor, dass aus dem was aktuell grad Top aktuell ist, eine Black-Box drumherum konstruiert wird. Ich will gar nicht wissen wie viel Leerläufe so produziert werden. So ähnlich wie bei ISO-Zertifizierung wo auch bei jedem das Rad neu erfunden wird obwohl 90% der Dokumente mit minimalen Aufwand übernommen und leicht angepasst werden könnten. Aber finde mal einen Berater der das so macht, das ist ein sehr sehr sehr kleiner Teil.

Was ich mich schon öfter gefragt habe, gibts eigentlich keine sinnvolle Windows Security bzw. Aufbau-Wiki die man abarbeiten kann und mehr oder weniger das beinhaltet was man tun sollte und warum und wie? Man kann ja schon immer auf die spezialiserten Dienstleister in diese Bereich verweisen, aber A weiss man nicht wie gut die sind, B gehen die guten zu den grösseren Firmen oder sie sind schlicht zu teuer für KMU's und C auch wenn sie gut sind, kann denen gewisse Ding durch die Lappen gehen. Zu 1: Warum genau ist das eigentlich sicherer? So ganz begriffen habe ich persönlich das nicht. Wenn der DC der produktiven Umgebung komprimittiert ist, ist es doch der Rest so oder so auch. Was übersehe ich? Zu 2: Warum eine Non-Peristente VM und bei der physischen setzt man auf Persistent? Vorzüge non-Persistent sehe ich im immer jungfräulichen OS, aber das Patch-Management für die Non-Persistent Admin-VM's ist ja verhältnissmässig aufwendig.

Kurze Rückmeldung, die Authentifizierung gegen ein lokales Konto auf dem Zwischen-Server funktioniert übrigens genauso gut. Insofern im eigentlichen Netz keine NTLM-Ausnahme notwendig. Hätte ich auch früher drauf kommen können. Hätte mir einiges an Arbeit erspart. Jemand eine Ahnung wie man dem UserManager Dienst die NTLM-Abfragen austreibt? Füllt unnötigerweise die Logs

Nope dient hier eigentlich nicht so viel, weil ja eben nicht die Verschlüsselung/Signierung das Problem ist, sondern wie Du sagst die Authenifizierung. Könnte man aber sicher so lösen, dass er sich nur gegen den Raspi authentifiziert. Aber eben, muss ich sowas machen, nehme ich dann doch lieber eine Windows VM wie meine bisherigen Work-Arounds. Dirty aber funktional. Wenn jemand noch Verbesserungsvorschläge für die Logs hat, gerne her damit. Zumindest diese Prob sollte ja theoretisch verbreiteter sein =)

@zahni Lexmark unterstützt direkt Kerberos. So nach der verlinkten Beschreibung sollten recht viele Drucker Kerberos direkt können. Scheinbare hinkt von den Herstellern grösserer Drucker nur Canon hinterher. *hmpf* Management-Lösung wäre meistens wohl etwas oversized für eine Handvoll Mitarbeiter die wirklich scannen dürfen/sollen. Würde aber ebenso einen Herstellerwechsel erfordern. :( Danke an alle für die Inputs!

Schon, aber sind ja sehr teure Geräte die grossen Multifunktionsdrucker. Die schmeisst man nicht einfach so raus. Einigermassen mühsam ist es auch, wenn man wieder die Eigenheiten eines neuen Herstellers aneignen muss. Insbesondere punkto Automatisation. Meine Umgebungen sind immer recht ähnlich aufgebaut damit es möglichst wenig Leerläufe gibt und dennoch das meiste an Sicherheitsempfehlungen auch im kleinen umsetzen kann ohne das die Stunden masslos überborden. SMB-Relay mit nem RASPI. Gibts so ein Relay +- transparent? Also ohne Speicher auf dem Raspi? Habe eine 'fertige' Lösung vor einiger Zeit gesucht, aber leider nicht gefunden. Selber auf die Beine stellen ist mir zu mühsam/Pflegeintensiv. Theoretisch wäre das mit Linux ja gut möglich, aber mir fehlt mir schlicht das KnowHow. Da gefällt mir dann eine Windows-Lösungen besser. Ist ja dann ähnlich wie meine Work-Arounds.

Dein Anliegen hat eigentlich wenig mit dem Grundanliegen im Thread zu tun ;) Was am besten einzustellen ist? Remote-Zugriff sperren Einen guten Leitfaden kenne ich leider auch nicht. Das hängt damit zusammen, dass es ziemlich viele verschiedene Möglichkeiten mit allerlei Ausprägungen und Schwerpunkten gibt und MS kein perfektes, günstiges, einfach zu konfigurierendes und sicheres Komplettpaket für jede Unternehmensgrösse anbietet. Sprich es tummeln sich viele verschiedene Firmen im Teich. Schwierig also DEN Leitfaden zu nennen inbesondere weil sich dieser Bereich technisch recht schnell dreht. Sicherheitstechnisch auf alle Fälle so oder so nicht ganz trivial. Das einfachste, in der Summe günstigste, technisch einfachste und daher tedenziell auch das sicherste für eine Kleinumgebung ist auf eine Remote-Lösung wie z.Bsp. Teamviewer zu setzen die einigermassen weit verbreitet ist. Zumindest wenn es nur wenig Arbeitsplätze sind. Auch wenn die Verbreitung tendenziell auch eine Gefahr darstellt. Teamviewer ist heute zwar viel zu überladen für meinen Geschmack, ist aber doch sehr straight in der Einrichtung, Multiscreen funktioniert und es nutzt die vorhandene Bandbreite ziemlich gut. Sobald das nicht mehr ausreicht, sollte man genau definieren was man eigentlich genau möchte. (Im Grunde eh kein Schaden)

Salut zusammen, Mal wieder ein Sicherheitsthema das seit längerem für mal mehr mal weniger Ärger sorgt. Vermutlich nicht nur bei mir. =) Folgende Ausgangslage: Aktueller Drucker, aktueller Firmwarestand Filer mit Freigabe, (auch via DFS), alle üblichen SMB-Hardening-Features aktiv (signing, servernamhardening, nocompression, encryption usw.) Drucker kann mit Zertifikaten umgehen unterstützt 802.1x unterstützt SSL/TLS für Web-Kommunikation inkl. Deaktivierung alter Protokolle unterstützt Verschlüsselung/Signierung für die Verbindungen für SMB (alle Härtungseinstellungen am Filer sind unterstützt) Im Grunde alles was man heute so erwartet, ausser eben Kerberos-Authentifizierung. Gibt auch Hersteller die Kerberos können aber halt nicht alle. Nun soll dieses Teil weiterhein auf eine SMB Freigabe Dokumente ablegen können wo die User dann die Files abholen können. Szenario 1: Zugriff vom Drucker auf die Freigabe via \\DomäneFQDN\DFS-Root\FreigabeName Fehlermeldung 4002 nur auf dem DC dann in etwa so: Calling Process ID: 4 Calling Process LUID: 0x37 Calling Process User Identity: Computer Account Name des DC Calling Process Domain identity: DomainFQDN Mechanism-OID: 1.3.6.1.4.1.311.2.2.10 NTLM Authentication request to this server ist blocked Wie man unschwer erkennen kann, erhält man keinerlei Angaben von wem die ursprüngliche Anfrage kam. Nichtmal das "Relay" also den Filer, erkennt man. Mit Firewall-Logging (BFE) kann man schauen was zur gleichen Zeit reinkam, aber ist natürlich wenig praktikabel wenn eine gewisse Menge Traffice läuft. Eine Ausnahme für das Gerät ist so - wenig verwunderlich - auch nicht möglich. Szenario 2: Zugriff vom Drucker auf die Freigabe direkt auf dem Server, ohne DFS (Tschüss DFS-Komfort) Übliche Fehlermeldung auf dem DC die gut auswertbar ist. Ausnahme für den Filer kann erteilt werden. Auf dem Filer habe ich das gleiche Problem wie vorher auf dem DC. Der Verursacher erscheint nicht im Log wenn die Verbindung signiert/verschlüsselt ist. Folglich keine granulierte Ausnahme sondern nur die Schleuse möglich. Es müsste der komplette NTLM Verkehr auf den Filer zugelassen werden. Nicht so sinnvoll für einen allgemein zugänglichen Server. Den Filer selbst kann man dafür auf dem DC als Ausnahme definieren. Szenario 3: E-Mail-Versand. So prickelnd finde ich das nicht, mit grossen Scan-Files den E-Mail Server zuzumüllen. Dafür extra einen internen Mailserver aufziehen und pflegen ist definitiv zu viel Aufwand für so eine eigentlich triviale Anforderung. Bis jetzt habe ich zwei Workarounds die ich im produktiven Test/Einsatz habe: Der erste ist ein separater Filer der nur mit dem Drucker und den Infrastrukturservern (DC, CA, WSUS) sowie diesen Druckern kommunzieren darf. Dann synchronisiere ich dem Hauptordner mit dem Filer auf den die User Zugriff haben. DFSR und Robocopy habe ich seit längerem im produktiven Test. Funktioniert soweit beides aber halt mit den üblichen Nachteilen. Und schön ist es nicht wirklich. Eine Festplatte die ich in mehrere VM's einfüge (physical shared) und die VM's nur in ihren jeweiligen Netzen kommunzieren können. Die Kommunikationseinschränkungen können sowohl physische (Netzwerkkarten) als auch logisch mit Firewalls durgesetzt werden. Also nur die Drucker dürfen mit Server A kommunzieren. Der Server selbst in Richtung Infrastruktur-Server und Drucker. Server B ganz normal. *1) Soweit OK (nicht gut), aber die zusätzliche Maschine muss bei beiden Würg-around-Varianten, gepflegt, gesichert und insbesondere bei der zweiten Variante 1A dokumentiert werden. Dafür kann man sich auch gleich überlegen ob die Authentifzierung überhaupt gegen AD erfolgen soll oder ob es nicht auch ein lokales Dienstkonto tun würde. DFS fällt logischerweise flach. Eine NTLM-Anfrage in die eigentliche Domäne muss nicht getätigt werden und somit auch keine Ausnahme erfolgen. Die Frage Entweder stehe ich auf dem Schlauch oder das geht tatsächlich nicht besser? Löst man das besser ganz anders? Davon abgesehen, habe nur ich das Gefühl, dass die NTLM-Logs sowie Ausnahme-Regeln etwas halbgar umgesetzt wurde wenn die Ausgangslage nicht "Keinerlei Sicherheit" ist? Bis die Hersteller durchgängig ihre Software und Gerät angepasst haben, dürfte es wohl noch eine ganze Weile dauern, eine Lösung wäre daher schön. Interessant finde ich, dass auch nach fast einem Jahr wo das nun im Netz breitgetreten wird, mein Druckerlieferant meint, ich wäre der einzige der das überhaupt anfragt. Er beliefert auch diverse Gross-Firmen und SMB sei fast immer eingerichtet für den Scanner. Wird in grösseren Betrieben einfach noch grosszügiger mit Ausnahmen hantiert? Ist die NTLM-Problematik in den IT-Abteilungen wirklich noch nicht angekommten oder ist das ganze doch nicht so problematisch wie einem das die ganzen Internetartikel vermitteln wenn alles über signierte Clients läuft? Grüsse und vielen Dank für Inputs! Zusatzinfo zu 1) Das funktioniert mit NTFS, solange auf einer Seite nur gelesen wird. Knackpunkt ist die Indexierung, die muss am besten auf beiden Seiten deaktiviert werden. Man kann mit aktivieren/deaktivieren der Disc arbeiten (bei manuellen oder zeit/triggergesteuerten Aufgaben) oder mit Lockfiles welches die andere Seite vor einem Schreibvorgang prüft. Funktioniert 1A, ist aber halt aufwendig in der Einrichtung und nicht jeder versteht so ein Konstrukt. Dafür kann man auch eine quasi-physische Netztrennung - zumindest auf Netzwerkebene - erreichen und hat dennoch den Komfort eines Datenaustausches. Klar ist ein Würg-Around. Weder schön noch besonders Wartungsfreundlich. Aber immerhin kann man gewissen Anforderungen einigermassen Rechnung tragen ohne gleich alles freizugeben.

Jo, das hilft einem enorm zu verstehen was, es überhaupt macht wenn sich einer die Mühe nimmt. Je nach Quelle muss man dann nicht alles selber durchanalysieren.. =)

Und wenn man dann die Links die alle ins Leere führen irgendwie weiterverfolgt, landet man irgendwann beim eigentlich Autor der das ganze mittlerweile ziemlich weiterentwickelt hat. Inklusive Log etc. https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 Ist ein Monster-Script für einfach "nur" Passwort ändern Aber scheint sehr viele Umgebungsvarianten abzudecken und enthält auch viel Auswertung und Testfunktionen.

Gut, dann ist ja defintivi geklärt Vielen Dank an alle Beteiligten!

Wenn es weg soll aber nicht unbedingt wieder hin lösche ich generell und aktualisiere dann. Dem Löschen Befehl ists egal wenn nix da ist. Dem Aktualisierungsbefehl ist auch alles egal ausser das er eben nicht löscht. Mache ich standardmässig so, weils Ersetzen mir immer wieder mal Kopfschmerzen bereitet hat. Seither nie mehr Ärger gehabt. Stand irgendwo mal als Tipp nachdem mir ersetzen den letzten Nerv geraubt hat. Verursacht halt entweder Traffic - der in meinen Umgebungen zum Glück heute nie ein Problem ist - oder man muss etwas mehr Zeit in granularere GPO's investieren (was aber nervig und mitunter aufwendig in der Pflege sein kann, also Löschen nur wenn Bedingungen erfüllt sind. Quasi eine Clean-GPO). Reine Files könnte man auch wunderbar mit Robocopy gemäss Abteilung via Aufgabenplanung synchronisieren. Nur so als Idee. Ich persönlich mag ja die guten alten Scripts und nutze in der Regel solche für Modifikation an Filesystem/Drucker. ;) Mir hat das Update ausnahmsweise mal gar keine Probleme beschert. Habe es sogar aus versehen viel zu früh in meiner eigenen Umgebung installiert. Normal warte ich immer erst ein paar Tage Günters Blog ab, dann kommts in meine, dann in fremde.

@lizenzdoc Mir geht es nicht um Client OS sondern ausschliesslich um Server OS. Ich versuchs nochmal mit der Beschreibung. 1. ESXi als Host 2. Windows Server als VM 3. ThinClient/ZeroClient/MAC/Handy das kein Windows ist, greift auf die GUI der Windows Server VM zu (was zur Folge hat das sowohl RDS als auch Zugriff-Cal fällig wird, soweit ja logisch) 4. Die Frage: Ist auch die VDA notwendig oder nicht weil der Zugriff nicht durch einen qualifiziertes Gegenstück erfolgt. Mittlerweile habe ich auch ein paar Dokumente gewälzt und konnte den Passus, dass ein qualifziertes Windows-Zugriffsgerät verwendet werden muss wie es bei den Desktop-OS der Fall ist, auch nicht finden.

Hmmmmmmm OK... Mal wieder lustig. Dankeschön! @lizenzdoc gleicher Meinung oder hast Du irgendwo den Zusatz bezüglich qualifiziert gesehen?

RDS-CAL ist klar und logisch, brauchts für Remote-Serverzugriffe immer ausser wenn es administrative Zwecke sind Device CAL oder User CAL einzel oder als Bundle braucht man klasische on Premise auch immer irgendwie wenn Server OS beteiligt sind, soweit auch klar. Nur am Zugriff in die Windows-Server-Welt ohne qualifiziertes Windows-OS scheiden sich die Geister irgendwie. Früher hätte ich gesagt VDA brauchts nicht. Aber angeblich darf die RDS-CAL nur zusammen mit einem qualifizierten OS genutzt werden. Da es das bei einem Nicht-Windows-Gerät nicht gibt, ist automatisch eine VDA fällig. Korrekt, nur kam man früher auch als KMU locker flockig durch die Levels wenn man etwas hartnäckig blieb. Heute wird man mit "Eröffnen Sie ein Case" abgewimmelt. Gesagt getan, Antwort fragen sie ihren Distri, case geschlossen. Einer der Gründe warum ich bei allen Umgebungen von Device auf User geschwenkt bin. Gibt keinerlei Diskussionen bei einem Audit. Die paar Piepen die man einspart sind den potenziellen Ärger nicht wert. Doku auch einfacher, also gesparte Zeit. Ausser man hat 3-Schicht-Betrieb und nur Benutzer ohne Zweit und Drittgeräte, dann kann es für manche Arbeitsplätze wieder anders aussehen. Aber ich schweife ab. ;)

Zwei Profis, zwei Meinungen Naja mittlerweile sinds sogar mehrere. Mein Distri hat ja auch mal bei MS nachgehakt die wollten ne VDA sehen. Begrüdung war die gleiche wie die von Lizenzdoc. Ein zweiter fand nein und sagte das gleiche wie Evgenij. Finde es immer wieder mühsam, dass man nicht mehr von MS selbst qualifizierte Antworten bekommen kann. Manches war früher halt doch besser

Guten Morgen, Ganz konkret ein virtueller Desktop aber ein Server OS. Aso Zero/Thin/MAC per Remoteprotokoll von Windosws oder 3rtParty auf Windows Server 2022 auf ESXi Ich sehe das genau so: WIN-CAL + RDS-CAL + eben VDA weil die RDS-CAL alleine den Zugriff nicht erlaubt, da kein qualifizierter Unterbau. Grüsse und Danke!

bunnyinfra klingt irgendwie nach ner Pornoseite... Vielleicht einer am surfen wo er nicht sollte... Oder Ein Spam-Mail das externe Inhalte nachladen möchte aber die Seite nicht mehr extiert oder ... Keine Ahnung. Zumindest wenn die Richtung wirklich von innen nach aussen ist wie hier allgemein vermutet wird. Edit: Sorry, schon 3 Wochen her.... *grrrr* und so weit oben caramba...

Salut zusammen, Wir hatten letzthin wieder mal ein kleineres Streigespräche. =) Braucht es für den Zugriff auf Server via Remote von einem Nicht-Windows-Client wie Mac oder Nicht-Windows-ThinZero Client auch eine VDA oder reicht die RDS-Lizenz aus? Ich bin der Meinung es braucht beides und so habe ich das bis anhin auch lizenziert weil mir das so nahegelegt wurde. Aber ist das wirklich so? Gruss und Danke

Wenn Ihr schon einen Proxy habt, wäre es wohl das einfachste, diesen auch mit den bereits genannten Vorschlägen zu benutzen. Oder aber, man nimmt den beschwerlichen Weg. Auch mittels Application-Whitelisting kann Usern das Ausführen von wenigen Programmen erlaubt werden (so oder so sinnvoll, aber aufwendig). Hilft aber hier nur beschränkt wenn nicht eine Anwendung selbst, sondern wenige Ziele erlaubt werden soll. Auch eine eigene Gruppe auf einer Firewall/Proxy wäre denkbar mit granularer Freischaltung ist Netz/Web auf User-Anmeldungsbasis. Die Windows-Firewall ist ziemlich easy zum dichtmachen... Einfach Standard Block Out einrichten und alle Regeln rauskicken. Solange ein User keine Admin-Rechte hat, bleibt das auch dicht. Der TMG basiert direkt auf dieser FilterEngine und der war richtig gut und flexibel und bot eigentlich genau das was du willst. Schade wurde der nicht Fit auf IPv6 getrimmt und hat ins Standard-Repertoir als Rolle gewechselt. Hat einen minimalsten Footprint und super granulare Steuerung direkt in Windows-Konten integriert. Alles erlauben was notwendig ist, ist dafür gar nicht so trivial. Die Standardregeln sind einigermassen unbrauchbar und manche nichtmal funktionstüchtig. Da taugen nur die In-Regeln etwas. Wer macht schon Standard-Block-Out. Das Leben sehr viel leichter machst Du Dir, wenn du einfach alle Kommunikation zu Infrastrukturserver wie DC, Filer, WSUS nen Freipass-Out gibst. Das reduziert die Arbeit auf unter 10%. Von MS gibt es leider keine Zuverlässige Quelle wo alles an einem Ort beschrieben ist. Überschneidende Regeln (insbesondere Systemregeln der Gruppe Static/Configurable) können zu unerwünschten Effekten führen. Wie und warum die Probleme zustande kommen, habe ich noch nicht genauer analysiert) Auf Benutzerebene Firewall-Regeln zu erstellen ist grundsätzlich möglich aber ein Krampf. Ich löse das jeweils mit Scripts die konfigurierte Regeln Aktiv oder Inaktiv setzen. Möchte man eine effektive Filterung mit der Windows-Firewall, empfiehlt es sich, sich auf ein Protokoll zu beschränken, sonst macht man alles doppelt und Fehlersuche ist wirklich obermühsam (IPv4 oder IPv6, ich nehme IPv4 und blockiere IPv6 da einfacher -->PrefixPolicy anpassen!) einige der Dienste werden durch Windows maskiert. Eine Filterung auf den Service ist also nicht möglich obwohl einem das die Einstellungen suggerieren. svchost muss für gewisse Ports also eigentlich pauschal freigegeben werden. Auf Wunsch liefere ich hier weitere Infos. Ist eine längere Abhandlung das zu umgehen. Windows versucht manchmal erst "unsicher" zu verbinden, kommunziert also erstmal über unsichere Ports obwohl sichere vorhanden wären. Führt zu False Positives die man angeblich freigeben muss (da liegt aber meist irgend eine Policy oder Regwert zugrunde mit der man es Windows abgewöhnen kann, erstmal die unsichere Variante zu versuchen, ist im Grunde aber für diesen Zweck hier wurst). Windows hat die lästig Angewohnheit vermehrt mit Apps zu arbeiten. Also Software auf Benutzerebene. Das Firewall-Handling dafür ist grässlich gelöst, aber wird mit jeder grösseren Windows-Version etwas besser aber leider auch oft anders. Gleiches gilt für Versionierung von Exe's. Keine Ahnung warum die teilweise unbedingt eine Nummer im Dateinamen haben müssen (z.Bsp. Defender). Kann man alles lösen und automatisch die Regeln anpassen wenn die Internet-Zugriff haben sollen, ist aber halt aufwendig (RegKeys, Programmordner, Dateiname etc. auslesen und Exenamen/Pfad extrahieren und die Firewallregeln auf neue Version anpassen, täglich ausführen). Am Ende muss man entscheiden ob und in welchem Umfang man das realisieren möchte und welchen Zweck man verfolgt. Das meist der Zeit spart man wie gesagt, wenn man sich die Arbeit mit den Infrastrukturserver spart und sich auf alles andere konzentriert. Sonst artet das in eine Sysiphus-Arbeit aus. Wenn Du Dir aber mal die Mühe gemacht hast, dann ist es eigentlich kein Problem mehr -manchmal mit etwas Kreativität - die meisten gewünschten Freigaben ausserhalb der Basis-Funktionalität von Windows zu tätigen. Zumindest für alle was irgendwie eine fixe Logik hat. z.Bsp. dem Browser oder einem Lizenzserver einzelne Zieladressen freizugeben. Solange diese die gleiche Adresse behalten (DHCP-Reservierung). Das ist im Grunde sehr wirkungsvoll und easy. Das ganze mit DNS-Namen bzw. Computer-Accounts wird wieder komplizierter. Genau wie die Benutzer-Regeln. Am einfachsten und gut bewährt hat sich ein Powershell-Script welches die Regeln auch gleich mit Namen stattt GUID's erstellt (können dann im Konfig-Script erstellt, gelöscht, geändert werden). Wenn ein gutes Regelset besteht, kann man es z.Bsp. granular mit GPO's verteilen. Die Lernkurve ist relativ steil. Für Verwaltungszwecke erstellst ein Script welches zusätzliche Firewallregeln freischaltet (auf ACTIV setzt). Mit einem Script welches automatisch beim abmelden/in der Nacht/beim anmelden eines normalen Users etc. ausgeführt wird, deaktivierst Du die Regeln mit einem Gegenscript oder Parameterübergabe an das gleiche Script. --> Ist mein Standardvorgehen für Industriemaschinen und mittlerweile auch in geänderter Form für Windows-Client um die Update-Runden planbar zu machen wenn ich das möchte, evtl. vor Ort bin (Maschinen) und Zeit für die allfällige Fehlerbehebung habe. Macht das Adminleben viel planbarer. Aber jeder wie er mag, hier ist es verpöhnt. Mir ist das wurscht. Muss jeder für sich sehen was für ihn am besten zum arbeiten ist. Ich automatisiere, standardisiere und plane gerne damit ich möglichst wenig Nerven verbraten muss/in Zugzwang komme Kann gerne weiter behilflich sein mit konkreten Tipps/Vorgehensweise wenn Du das machen willst. Ist recht spannend wohin sich Windows und seine Dienste überall hinverbinden. Spannend aber leider teilweise auch nervtötend ist die Erstellung eines granularen, flexiblen Regelsets. Habe das ursprünglich wegen der ganzen Telemetrie/Datensammlungswut/Index-Übermittlung sowie Industriemaschinen-Abschottung sowie Update-Schutz in Angriff genommen. Mittlerweile nutze ich das gerne auch für solche Dinge. =)

Zwar schon etwas her, aber dafür gibts auch gute Lösungen, zumindest wenn man das öfter machen muss: PDF-Printer mit Overlay Funktion Bei PDF-Printern zwar etwas seltener anzugreffen aber aber funktioniert so ähnlich wie bei den Business-Drucker der grossen Hersteller für physische Ausdrucke. Die hier machen sowas zbsp. https://www.pdfprinter.at/addoverlay/ Selber benutzt habe ich genau diesen aber noch nicht. Hatte auch mal in einem Betrieb einen physischen Drucker (Canon?) der auch PDF-Ausdrucke und nicht nur physische mit einem Overlay versehen konnte. Ansonsten: Word kann das für die reine Darstellung doch problemlos. Für das Drucken limitiert der Treiber den minimalen Rand. Wenn Word gar nichts vergeigen soll, das gewünschte per Image einfügen (Beim Import wählen). Auch HTML geht oft. Oder per VBA die Import-Funktion schreiben. (Naja, ob man für sowas Makros aktivieren will?) Excel habe ich nie so wirklich rausgefunden wie man das hinbekommt. Denke das geht nicht. Da man nirgends etwas über die Ränder schieben kann wie bei Word/PP. PP kann das wie bereits erwähnt wurde "einfach" so. Nur ist PP Mehrseitig obergrässlich einfach zu machen. Access ist zumindest das Zeichnen ausserhalb der Druck-Bereiche mittels VBA möglich. Ob man auch eine Grafik per VBA dahin zwingend kann weiss ich grad nicht. Der Report-Designer ist von der Auflösung her aber eh etwas kastriert (ach wenn ab 2016? viel besser). Ohne VBA bis maximal an das Limit des gewählten Druckers. Wenn der PDF-Drucker 0mm Ränder erlaubt, dann kannst auch bis nach aussen bedrucken. Halt wieder lästig wenn auch auf normale Drucker gedruckt wird. Auch mit Crystal Reports/.NET dürfte man relativ zügig sowas realisieren können (halt wieder je nach der Importanforderung, so ganz genau verstanden was du importieren möchtest habe ich nicht)

Auch wenn Du es vielleicht nicht nicht für Möglich hälst, es gibt noch andere Gründe Updates nicht einfach pauschal freizugeben. - Produktionsmaschinen die nachher nicht mehr laufen - Waagen die nicht mehr kommunizieren - Labor-Geräte die ihre Ergebnisse nicht mehr eintragen - Updates die von Leitsystemen im dümmsten Moment gezogen wurden - Automatisierungen die nach Sicherheitsupdates problemlos funktionieren, nicht jedoch nach Funktionsupdates (stell Dir vor, in effizienten Kleinbetrieben gibts das ;) ) - usw. Das sind Real-Life und keine Pseudo-Anforderung die Du mir hier indirekt unterstellst und haben manche Betriebe schon viele 1000 Euro gekostet. Die Hersteller drehen die Updates meistens komplett ab. Nur selten zuverlässig bei W10/2022 wodurch es dann zu obigem Verhalten kommt sobald z.Bsp. eine Fernwartung aufgemacht wird. Früher konnte ich einzelne Updates zurückhalten welche die Fehlfunktion verursacht haben und alle anderen Updates direkt installieren. Danach in Ruhe eine Lösung für das jeweilige Update suchen. Mir war das generelle +- zeitnahe Update von soviel wie möglich wichtiger als das vollständige Paket. Klar im Büro ist das hundwurscht, in der Produktion aber nicht. Deshalb brauche ich eine zuverlässige Verzögerung der Installation auf genau das Wartungsfenster was ich brauche. Seit MS die automatische Installation durchgeboxt hat und "Downloaden/Warten bis Installation" nicht mehr geht ist das wichtiger den je geworden. WSUS: Wo genau liegt das Problem wenn man Ihn mit einfachen Mitteln fürs Management hernehmen kann auch wenn er dafür nicht gemacht ist? Manchmal verstehe ich echt nicht wieso man alles schlecht reden muss wenn etwas funktioniert. Insbesondere nicht wenn die Komplexität verhältnissmässig tief ist wie bei WSUS, die Übersicht bis ~50 Maschinen top ist, Bordmittel sind, keine Fremdsoftware/Zusatzsoftware auf dem Client braucht die gepflegt werden muss und sogar noch umsonst. Ich persönlich wüsste nicht wie das einfacher und kostengünstiger geht, lasse mich aber gerne aufklären. Und stell Dir vor, die Themen die Du ansprichst werden auch von manchen KMU's angegangen. Man glaubt es kaum. Auch wenn nicht so viele sein dürften. Dafür aber auch Grossbetriebe, Spitäler, öffentliche Hand, Kraftwerke etc. wo das nicht der Fall ist. Diese wirklich problematischen Dinge gibt es in grösseren Produktionsbetrieben und bei grossen Herstellern übrigens genau so viel. Wenn nicht noch schlimmer, da Automatisierungsgrad grösser ist und die Systeme teilweise sehr alt. Habe vor 4 Monaten den letzten W95 Roboter ausser Betrieb genommen. Diverse XP Steuerung im Einsatz, teilweise sind die Maschinen gerade mal 8 Jahre alt. Das ist Real Life. Ob man es wahrhaben will oder nicht. Nicht jeder Betrieb kann nach 6 Jahren alle Maschinen entsorgen und die Produktion über den Haufen werfen. Müsste man aber, weil die Maschinenhersteller fast immer uralte OS einsetzen. Grad letztens mit einem SEHR grossen Hersteller in Kontakt gewesen, dessen ganzes Ersatzteilmanagement seiner Anlagen über Access läuft. Die haben die uralte Anwendung weiterentwickelt weil ein anderer sehr grosser ERP-Anbieter immer nur Ärger gemacht hat und die Wartung viel zu komplex/Kosteninstensiv/nicht zeitnah war. Klar hätte man vermutlich besser lösen können mit einer Neuprogrammierung, aber da ging schon soviel Geld (Millionen) in das ERP, dass die einfach keine Lust mehr darauf hatten. Jetzt läuft nur noch die Lagerverwaltung/Rechnungsstellung der Ersatzteile etc. über das ERP. Auch sonst gibt es einiges an Branchenlösungen welche auch von grösseren Betrieben eingesetzt werden und nicht wirklich Up to date sind.

Common. Das Netz ist voll von solchen Beiträgen. Insofern ging das nicht nur mir so. Und auch hier gibts einige davon wenn ich mich richtig erinnere. Im richtigen Leben ist WSUS nunmal Bestandteil des Patchmanagements in Kleinumgebungen. Zumindest da wo nicht einfach Blind MS vertraut wird das es schon funktionieren wird. Und das kann es auch ausreichend gut finde ich. Alles weitere wäre Overkill. Beim Code: Sorry, den habe ich tatsächlich einfach Copy Paste von der Seite gemacht. Habe selber nur die obige Zeile verwendet. Aber auch die funktioniert mit dem $criteria ob nun notwendig oder nicht.