NilsK

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

Moin, wenn ich die in der Fehlermeldung zitierte Zeile richtig deute, hast du dort ja auch keinen XML-Dokumentnamen angegeben, sondern einen Suchstring mit *. Dann kommt auch kein XML-Dokument zurück. Gruß, Nils

Moin, und es handelt sich dabei um die User-Anmeldung, nicht die des Rechners. Mit dem User gibt es ja aber gar kein Problem. Der erste Blick gilt in so einer Situation dem Eventlog. Weitere Quellen sind dann meist gar nicht nötig. Gruß, Nils

Moin, danke, aber - du hast gesehen, dass der Beitrag fast vier Jahre alt ist? Ist ja nicht so, dass das Board nicht warnen würde. Aus Gründen. Gruß, Nils

Moin, das ist eine der Fragen, die bislang nicht beantwortet wurden. Der TO könne sich nicht an die Fehlermeldung erinnern, er könne gerade nicht ins Eventlog schauen ... da kann man dann nicht viel tun. Gruß, Nils

Moin, ich habe mir den Thread noch mal angesehen. Soweit ich sehe, hattest du seinerzeit keine Informationen geliefert, die uns in die Lage versetzen würden, dir irgendwas zu empfehlen. Gruß, Nils

Moin, wow, wieviel sperrt ihr denn so, dass ihr solche Intervalle braucht? Oder um Jans Frage noch mal zu stellen: Wozu dient denn die CA? Wenn sie wichtig ist (darauf würde das CRL-Intervall hindeuten), dann solltet ihr noch mal dringend über das Design und die Details der Implementierung nachdenken. Wenn sie nicht wichtig ist (darauf deutet hin, dass ihr drei Jahre lang nicht gemerkt habt, dass die CRL nicht wirksam aktualisiert wird), dann solltet ihr sie vielleicht abschaffen - ernst gemeint, denn eine schlecht betriebene CA ist ein Risiko. Gruß, Nils

Moin, wenn keine Datenbanken im Spiel sind, könnte VSS verzichtbar sein. Dann könnte es ein normaler Snapshot auch tun (Crash-consistent), Gruß, Nils

Moin, ich denke auch, dass die Abfrage der VSS Writer an der falschen Stelle stattgefunden hat. Es geht hier um VSS in der VM, nicht auf dem Host. Ihr versucht gerade, einen "Production Checkpoint" der VM zu machen, der geht aber nur dann, wenn VSS in der VM korrekt läuft. Tut es das nicht, dann geht nur ein Standard Checkpoint, der den Zustand der Applikationen in der VM nicht berücksichtigt. Also entweder in der VM korrigieren oder, wenn die Applikation dort kein VSS kann, auf ein Verfahren ohne VSS-Integration umsteigen. Gruß, Nils

Moin, es spricht überhaupt nichts dagegen, ein Kennwort zu ändern, solange man ein gutes Kennwort durch ein neues gutes ersetzt. Wenn es allerdings schon ein gutes Kennwort ist - wozu es dann ändern? Dafür gibt es aus meiner Sicht nur einen Grund: Man vermutet, dass es kompromittiert wurde. Dann nutzt ein Turnus aber nichts, sondern dann muss man es sofort machen. Ein gutes Kennwort ist dann gut, wenn es einen Brute-Force-Angriff aussichtslos macht. Die Begründung für regelmäßige Wechsel war früher mal: Man ändert das Kennwort so häufig, dass man die zeitliche Wahrscheinlichkeit, dass es geknackt wurde, unterläuft. Diese Argumentation ist aber nur valide, wenn die Kennwörter zu schlecht sind, etwa weil ein System die Kennwortlänge begrenzt. Wer sein Kennwort also ändern will, kann das gerne tun, auch als Admin. Es ist aber eben unsinnig, dafür einen Turnus vorzugeben. Gruß, Nils PS. und nein, ich sehe mich da überhaupt nicht in der Pflicht, das zu belegen. Da dies keine exotische Einschätzung ist, wird man "offizielle" Belege dafür finden, wenn man welche braucht.

Moin, der Witz an Ransomware ist, dass diese einen Großteil ihres Schadens anrichten kann, ohne dafür Adminrechte zu brauchen. Das, wo User mit ihren Rechten hinkommen, sind ja normalerweise genau die Daten, die für das Geschäft eines Unternehmens wichtig sind und die daher zur Erpressung taugen. Damit Ransomware ihr Schadens- und damit Erpressungspotenzial erhöhen kann, kommt sie meist im Verbund mit anderer Schadsoftware daher, die ihrerseits durchaus Systeme auf der administrativen Ebene angreift. Dagegen können gute Adminkennwörter helfen, sie sind aber kein umfassendes Mittel. Und ein gutes Adminkennwort zeichnet sich nicht dadurch aus, dass es regelmäßig geändert wird, sondern dadurch, dass es - simpel gesprochen - lang ist. Aus gutem Grund sind regelmäßige Kennwortwechsel "out". Um modernen Angriffen mit Aussicht auf Erfolg vorzubeugen, muss man allerdings eine ganze Menge anderer Dinge tun, die von vielen ebenfalls als "Gängelung" empfunden werden. Da das so ist, muss man sie dann wenigstens ordentlich umsetzen, halbherzig bringt nix. Gruß, Nils

Moin, ist das eine Testumgebung oder eine produktive? Als Hintergrund zu den Anmerkungen der Kollegen willst du dir vielleicht dies ansehen: [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Die Clients im AD dürfen deshalb nicht direkt einen externen DNS-Server ansprechen, weil sie sonst interne Adressen nicht auflösen können. Gruß, Nils

Moin, na, dann ist ja gut, dass wir drüber geredet haben. Da man beim Beeinflussen der GPO-Abarbeitung sehr schnell in solche Fallen läuft, sollte man das nur dann tun, wenn es wirklich erforderlich ist. Und gut dokumentieren, sobald man sowas macht. (Vermutlich wirst du dir das jetzt auch gedacht haben, aber der Hinweis gehört an dieser Stelle einfach dazu. ) Gruß, Nils

Moin, darüber hinaus rate ich dazu, noch mal durchzuschnaufen und sich abzuregen. Ich habe Evgenij nicht so verstanden, dass er irgendwem irgendwas Böses unterstellen wollte. Gruß, Nils

Moin, die kommt aus einer separaten ADM-/ADMX-Datei? Ich würde nicht ausschließen, dass das einfach falsch implementiert ist. Oder, wie Jan auch schon sagt - der Loopback-Modus greift ja gerade in die Verarbeitung ein. Ebensogut kann es also sein, dass der das Verhalten erzeugt. Da musst du dann parallel auch noch die Policies in den Blick nehmen, die auf das Computerkonto wirken. Wie verhält es sich, wenn du "normale" GPO-Einstellungen (also solche, die nicht aus einem separaten ADM/ADMX kommen) aus dem administrativen Zweig auf diese Weise setzt? Gruß, Nils

Moin, um welche Einstellung geht es denn genau, die nicht das gewünschte Verhalten zeigt? Gruß, Nils

Moin, Nun mal langsam. Ich wollte niemandem zu nahe treten, sondern nur meine Vermutung äußern, dass hier evtl. in der falschen Richtung gesucht wird. Da ich mit Firewalls nicht viel zu tun habe, habe ich darauf auch hingewiesen. Anscheinend war meine Vermutung nicht korrekt, dann ist sie ja auch hinfällig. Zu dem eigentlichen Problem kann ich trotzdem nichts beitragen. Dass das AD kompromittiert sei, halte ich momentan für unwahrscheinlich. Gruß, Nils

Moin, Zu dem konkreten Problem kann ich nichts beitragen, aber mir kommt die Beschreibung der Funktion sehr abenteuerlich vor. Bist du sicher, dass das so funktionieren soll? Mit ist völlig schleierhaft, warum eine Firewall die Login-Events auslesen soll, wenn sie eigentlich Gruppenmitgliedschaften prüfen soll. Das könnte sie auch völlig ohne Kontakt zum DC tun, wie alle anderen Rechner das auch tun. Gruß, Nils

Moin, Über das Web -Archiv bekommst du ja nur die Frontend-Seite, aber weder das API dahinter noch die Backend-Funktion. Ich glaube nicht, dass das so zum Ziel führt. Wenn du mit so alten Versionen arbeiten musst, wirst du doch voll aktualisierte Fassungen davon haben. Warum nicht auf der Basis neue Images erzeugen? Gruß, Nils

Moin, Dass versucht wird, sich an einen öffentlich erreichbaren Server anzumelden, ist ja nicht verwunderlich. Es ist auch völlig egal, von oder auf welchen Ports das versucht wird. Wichtig ist, dass es nicht klappt. "Ports" werden oft völlig missverstanden. Ein "offener Port" ist per se überhaupt kein Problem. Das wird es erst, wenn auf dem Port etwas ungesichert reagiert und Dinge ausführt, die nicht erwünscht sind. Das wiederum kann man ja durchaus als Betreiber im Griff haben. Gruß, Nils