NilsK

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

Moin, richtig, das wäre ein möglicher Weg. Die Idee hinter dem Archivieren ist ja, dass die SIDs weiter aufgelöst werden können. Das wäre dann ja gegeben. Den "historischen" Namen kann man dann ja noch mal in einem anderen Feld dokumentieren, ebenso die Metadaten (Konto aktiv von/bis usw.). Gruß, Nils

Moin, dabei verlieren die doch ihren SID, oder? Gruß, Nils

Moin, die "offen" angebotenen Kurse orientieren sich einerseits an der Nachfrage und andererseits an der Unterstützung durch die jeweiligen Hersteller. Da lässt sich beobachten, was Evgenij beschreibt. Das war aber eigentlich schon immer so - offen angebotene Kurse waren schon immer die, nach denen Kunden viel gesucht und gefragt haben, also die "offiziellen", herstellernahen Kurse. Da war schon immer viel Produktorientierung der Hersteller drin, der Themenanteil, der im echten Leben praxisrelevant war, konnte mitunter gering sein. Die Hersteller wollten eben ihre eigene Technik voranbringen. Wenn es um Praxis geht, sind zugeschnittene, frei vereinbarte Kurse meist viel besser. Das ist dann allerdings auch nur für Firmen finanzierbar, die mehrere Leute auf einmal schulen wollen, weil man dann nicht mehr über günstige Pauschalpreise pro Teilnehmer spricht, sondern über Tagessätze. Gruß, Nils

Moin, ich habe das zu lösende Problem noch nicht ganz verstanden. Vorab die Einschätzung: Da Excel eine Tabellenkalkulation ist und kein Layoutprogramm, kann es durchaus sein, dass es mit bestimmten Anforderungen überfordert ist. Gruß, Nils

Moin, Ich bin dann raus. Gruß, Nils

Moin, was da funktioniert, ist doch nur die Frontend-Webseite. Die Funktionen dahinter kannst du aus dem Web-Archiv doch gar nicht wiederherstellen, weil sie dort nie gelandet sind. Oder was genau hast du da jetzt am Laufen? Ich verstehe immer noch nicht, warum du in deinem Szenario so eine Infrastruktur nachbilden willst, wo du vollständig aktualisierte OS-Installationen auch für neue Rechner viel einfacher herstellen kannst. Aber vielleicht weißt du das ja. Gruß, Nils