NilsK

Moin, Spricht was dagegen, eine Gruppe zu nehmen, die es auch im AD gibt? Gruß, Nils

Moin, gibt es deshalb nicht, weil das sehr schnell sehr individuell wird und eine ganze Menge mit Prozessanalyse und -beratung zu tun hat. Das ist als Checkliste nicht sinnvoll zu leisten. Wer es ernst meint, muss da ganzheitlich ran. Und da ist es auch sinnvoll (für den Kunden) und legitim (für den Anbieter), dafür gutes Geld einzuplanen. Die Nachteile von Checklisten kann man übrigens gerade bei dem Thema in der freien Wildbahn gut beobachten. Als es die ESAE-Doku von Microsoft noch gab, war dort ein Verfahren beschrieben, wie man die PAWs grundlegend aufbaut. Das war so ziemlich die einzige Anleitung zu dem ganzen Themenkomplex, die ganzen eigentlich wichtigen Dinge waren nicht in der Form beschrieben. Viele Admins - und leider auch viele Berater - haben dann geglaubt, das sei alles. Sie haben das umgesetzt und dann geglaubt, sie hätten eine vollständige ESAE-Umgebung. Von den ganzen Prozessen und Härtungen drumrum aber keine Spur. Gruß, Nils

Moin, sorry für OT, aber: beides wunderschön formuliert! Gruß, Nils

Moin, du machtest meinen Tag! Gruß, Ni"romani ite domum"ls

Moin, das hat mit großen oder kleinen Netzwerken nichts zu tun. Schadsoftware ist heutzutage technisch gesehen richtig geile Software. Die ist so clever gebaut, dass sie ihren Weg automatisiert findet. In realen Netzwerken gibt es so viele Punkte, an denen man ansetzen kann, dass die Wahrscheinlichkeit sehr groß ist, schnell Schwachstellen zu finden, mit denen man das Netzwerk ruck-zuck übernimmt. Genauso ist es mit den Einfallstoren - da gibt es nicht nur eins. Das längerfristige Ausspähen ist nur eine Option, die ein Angreifer wählen kann. Das setzt meist auf denselben Vorbereitungen auf wie ein vollautomatisierter Angriff. Wenn das Opfer attraktiv genug erscheint, da manuell mehr zu machen, dann tut man das. Hat man die Zeit oder die Fähigkeiten nicht, dann lässt man die Software einfach machen - dann erpresst sie eben auf Basis wahllos (und umfassend) verschlüsselter Daten. (Fun Fact: Was kaum ein Admin weiß, ist, dass mit EFS ein Verschlüsselungstool in Windows enthalten ist, das man nicht erst nachladen muss und das wunderbare Schäden anrichten kann.) Was Heise betrifft: Die haben großes Glück im Unglück gehabt. Natürlich sind die nur ein mittelständisches Unternehmen wie die meisten anderen auch, und damit prima angreifbar. Sie haben es rechtzeitig gemerkt, und sie hatten sich offenbar einen Angreifer eingefangen, der es nicht richtig ernst meinte, sondern einfach den automatisierten Weg ging. Das konnten sie ausbremsen. Ein paar Tage Einschränkung, aber kein echter Schaden. Aufgrund ihrer Position in der Öffentlichkeit ist Heise aber natürlich ein hoch attraktives Ziel - die richtig bloßzustellen, könnte für böse Buben sehr interessant sein. Mit etwas Mühe hätte man da echt was anrichten können, und Heise wäre weg vom Fenster gewesen. Genau das ist übrigens jetzt deren erhöhtes Risiko: Stellt euch vor, Heise wird jetzt zum zweiten Mal Opfer ... Gruß, Nils PS. VPN ist kein Problemlöser, sondern erzeugt zunächst zusätzliche Risiken - man lässt damit unkontrollierbare Clients direkt in sein Netzwerk ...

Moin, ich habe das Problem jetzt nur halb durchdrungen, vermute aber, dass du das Automatic Site Link Bridging abschalten musst. Gruß, Nils

Moin, . Die beschrieben "langsamen" Angriffe gibt es durchaus. Häufiger ist aber, dass das alles automatisiert geschieht und einfach in kurzer Zeit möglichst viel Porzellan zerschlägt. Das erhöht den Druck, schnell ein hohes Lösegeld zu zahlen. Bei heise war es sehr wahrscheinlich auch diese Sorte Angriff. Der Einstieg ließ sich dort recht sicher auf eine Phishing-E-Mail zurückführen. In einem anderen Fall, wo ich bei der Nachlese dabei war, war es ein Client, dessen RDP-Zugang schlecht gesichert war. Man sollte auch nicht davon ausgehen, dass diese Netze nach so einer Attacke wirklich gut geschützt werden würden.... Gruß, Nils

Moin, das haben wir doch jetzt schon mehrfach beantwortet. Das Computerkennwort wird durch den Client (also den PC) geändert. Dieser fordert das AD an, das Kennwort einzutragen, und wenn das als erfolgreich zurückgemeldet wird, führt auch der Client den Wechsel tatsächlich durch. Das AD macht da von selbst überhaupt nichts. Was da bei deinen beiden Rechnern im Busch ist, können wir dir aus der Ferne nicht sagen. Es wäre klug, sich die Eventlogs der Rechner intensiv anzusehen, insbesondere das System- und das Sicherheitsprotokoll. Wonach du genau schauen sollst, können wir dir auch nicht sagen, weil so ein Verhalten eben fehlerhaft ist. Gruß, Nils

Moin, ja, genau. Gruß, Nils

Moin, fehlendes Sysprep ist aus verschiedenen Gründen keine gute Idee, aber mit dem SID des Computerkontos im AD hat Sysprep tatsächlich nichts zu tun. Der lokale SID und der AD-SID sind zwei getrennte Dinge. Dass dasselbe Computerkonto von mehr als einem Computer verwendet wird, ist durch Klonen der lokalen Installation nicht zu erreichen. Die müssten sich dann ja auch mit demselben Namen melden. Gruß, Nils PS. [Eindeutige Computer-SIDs unwichtig? | faq-o-matic.net] https://www.faq-o-matic.net/2009/11/17/eindeutige-computer-sids-unwichtig/ und: https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/the-machine-sid-duplication-myth-and-why-sysprep-matters

Moin, der Ablauf deutet darauf hin, dass das Computerkennwort sehr wohl erneuert wurde, aber der PC danach ein Problem hat. Da muss also an dem Rechner was im Busch sein. Das Computerkennwort wird nur dann gewechselt, wenn der Client selbst das anfordert und durchführt. Das AD macht da nix von selbst, es legt nur den Turnus fest, in dem das geschehen soll. Der Ablauf soll genau solche Phänomene verhindern, dass ein Client sich plötzlich nicht mehr anmelden kann. Solche Phänomene kenne ich aus Umgebungen, in denen mit Images gearbeitet wird oder mit Mechanismen, die einen Rechner irgendwie auf einen "definierten Stand" zurücksetzen. Gruß, Nils

Moin, na, dann hat es sich ja geklärt. Das ist auch plausibel. Weil du in dem Fall das Kennwort als Administrator zurücksetzt. Das ist immer möglich, unabhängig von den Zeitbeschränkungen. Dass es sich dabei zufällig um dein eigenes Konto handelt, ändert nichts daran. Per Affengriff hingegen ändert der User selbst sein eigenes Kennwort. Das ist durch die Regeln eingeschränkt. Gruß, Nils

Moin, Das kann aber auch heißen, dass man vielleicht irgendwann in der Zukunft was mit Cloud machen will und es deshalb gut wäre, wenn jemand das schon kann. Oder es heißt, dass man schon ein bisschen was mit Cloud macht und nun doch mal jemanden braucht, der ... Letzteres dürfte der Normalfall sein. Es gibt nur wenige Firmen die wirklich in die Cloud "umgezogen" sind, aber es gibt noch weniger, die gar nichts mit Cloud machen. Gruß, Nils

Moin, nur vorsichtshalber: hast du die Kennwortrichtlinie lokal überprüft? In einem CMD mit net accounts Und: hast du geprüft, dass du über das GUI auch tatsächlich das lokale Adminkonto änderst? Wenn du per Affengriff die Änderung anforderst, dann bezieht sich das auf den User, der gerade angemeldet ist. Das wäre dann ja aber gar kein Domänenuser, daher erstaunt mich, dass in der Fehlermeldung angeblich auf die Domänenrichtlinie Bezug genommen wird. (Ich kann das grad selbst nicht testen, aber das wäre evtl. ein Punkt zum Prüfen.) Gruß, Nils

Moin, nun ... Das ergibt evtl. eine Umgebung, die ähnlich ist, aber 1:1 ist das ganz sicher nicht. Ob du beispielsweise die DNS-Probleme "in echt" auch hättest - oder ganz andere ... das kann niemand einschätzen. Also wäre zu fragen, warum du das überhaupt machst. Das grundlegende Verfahren als solches ist ja bekannt und dokumentiert. Um das einfach zu üben, musst du kein Backup der Realumgebung im Labor wiederherstellen (was ich, nebenbei gesagt, auch aus anderen Gründen selten für eine gute Idee halte). Das kannst du viel einfacher haben und weißt dann, wie es funktionieren sollte. Nicht ganz unwichtiges Wissen. Stattdessen schlägst du dich mit Problemen rum, die du nicht einschätzen kannst. Was könnten also die Ziele des Aufwands sein? Weil die Arbeitszeit, die du für deine Versuche aufbringst, nichts kostet? Weil du das in deiner Magic Time machst, also deiner Firma die Arbeit schenkst? Weil man das Risiko liebt? Kann sein, aber du kannst dich sicher dazu äußern, ob du die Verantwortung übernehmen willst, wenn es mangels Erfahrung eben nicht klappt. 2000 User sind keine kleine Umgebung. Und nur weil ihr bislang fahrlässigerweise nur mit einem Einzelserver arbeitet, ist die Umgebung noch lange nicht unkomplex. Es geht nicht darum, dich bloßzustellen. Niemand kann von einem Admin erwarten, dass er sich einfach so mit einer großen Exchange-Migration auskennt. Es geht darum, dir einen sinnvollen Weg aufzuzeigen. Das gehört für die meisten hier zur Professionalität dazu. Gruß, Nils

Moin, ich kann nicht recht nachvollziehen, was du da eigentlich machst. Es klingt allerdings nicht zielführend. Wenn ihr so wenig Personal habt und keine Erfahrung mit Exchange-Migrationen, warum macht ihr das dann selbst ohne externe Unterstützung? Und warum fängst du dann damit an, eure sehr komplexe Umgebung nachzubauen - in einer Form, die dann gar nicht mehr aussagekräftig ist? Das Risiko, vor dem euer Unternehmen steht, ist enorm. Ich würde das an deiner Stelle nicht selbst und schon gar nicht allein machen. Das "gesparte" Geld wiegt die möglichen Schäden nicht auf. Gruß, Nils

Moin, die kurze Antwort ist: nein. Es gibt weder bestimmte Voraussetzungen, wann man das tun sollte, noch gibt es handfeste Gründe dafür oder dagegen. Für die lange Antwort frag eine Suchmaschine nach "renew pki certificate with same key" oder was in der Art. Es gibt Diskussionen darüber, aber am Ende ist es keine echte Sicherheitsfrage. Gruß, Nils

Moin, die VM nicht neu starten, sondern herunterfahren und dann warten. Nur dann wird der noch vorhandene Snapshot mit der Basis-VHDX zusammengeführt. Bei einem Neustart der VM geht Hyper-V davon aus, dass die VM schnell wieder laufen soll und macht deshalb dann kein Merge. Gruß, Nils

Moin, theoretisch bekommt man sowas hin, es wird aber vermutlich auf eine Menge Gebastel hinauslaufen. Ob die Kommunikation aus der VM mit dem Scanner ordentlich funktioniert, muss man sehen. Kann klappen, kann haken. Abstriche und Umgewöhnung wird man in Kauf nehmen müssen. Man könnte mit Autologon und Autostart was hinbekommen, aber es wird sich nicht so verhalten wie eine "App". Ob das dann den Aufwand wert ist ... muss man sehen. Gruß, Nils

Moin, hmja, kann man machen, aber in Wirklichkeit ist das Schlangenöl. Wer "den" Administrator angreifen will, kann ihn leicht anhand seines RID -500 identifizieren, egal, wie der Account heißt. In den allermeisten Situationen wird man "den" Administrator aber gar nicht angreifen müssen. Wichtig ist, dass der Account wirksam geschützt ist. Und dafür ist und bleibt die wichtigste Maßnahme, ihm ein sehr langes Kennwort zu geben. Es gibt noch weitere sinnvolle Maßnahmen, aber ohne diese hier kann man die alle vergessen. Gruß, Nils

Moin, Und dass es keinen PDC mehr gibt. Aber wir schweifen ab Gruß, Nils

Moin, einem Angreifer wird es in der Regel ziemlich egal sein, welchen Admin-Account er übernimmt. Er wird den nehmen, den er am leichtesten übernehmen kann. Ob das der vordefinierte oder ein anderer ist, ist dabei ohne Belang. Es kommt also darauf an, dass Admin-Accounts sehr gute Kennwörter haben, was in der Praxis einfach heißt: Sehr lange. Gruß, Nils

Moin, das ist so eine typische Admin-Antwort. Das ist doch ganz offenkundig nur ein Mittel zum Zweck. Solange wir den Zweck nciht kennen, wird es uns schwerfallen, dir sinnvolle Hinweise zu geben. Gruß, Nils

Moin, Moment, du schriebst von "mal was ausprobieren". Genau dafür ist eine Free Trial da. Du willst also Geld damit verdienen, aber TechSmith soll dir das schenken? Finde ich ... kritikwürdig. Gruß, Nils

Moin, https://www.techsmith.com/download/snagit/ Reicht kostenlos aus? Gruß, Nils