NilsK

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

Mon, Der Punkt ist doch einfach, dass der TO bei dieser Nebensache etwas verwechselt. Was er wahrscheinlich meint: es gab man einen Verteiler mit einer bestimmten Adresse. Diese Adresse ist dann später einer Mailbox zugewiesen worden. Da das aber mit den Regeln nichts zu tun hat und wir das wissen, können wir uns ja auch wieder auf das Problem konzentrieren. Gruß, Nils

Moin, du hast den Path-Parameter ja sogar in deinem New-ADUser-Kommando drin. Dann übergib gleich den richtigen Pfad und fertig. Gruß, Nils

Moin, ich nehme auch an, dass man da nicht viel findet. Am Ende läuft es ja darauf hinaus, dass du die Mimik nachbauen müsstest, die es damals gab. Das wird seinerzeit niemand gemacht haben, weil es ja keinen Bedarf dafür gab. Da es ja aber auch keine neuen Updates mehr gibt, gibt es für beide Systeme auch einen endgültigen Stand. Daher sähe ich den Bedarf auch heute nicht. Gruß, Nils

Moin, Was ist denn der Hintergrund deiner Frage? Was willst du erreichen? Gruß, Nils

Moin, du hast dir deine Fragen schon fast selbst beantwortet. Du wirst alles "retten" müssen, was mit Berechtigungen zu tun hat. Auch bei nur 20 Usern kann das eine Menge Arbeit sein. Fragen wir mal andersrum: Was erhoffst du dir denn als Nutzen von einem Neuaufbau? Meist gibt es da falsche Vorstellungen, daher lass uns mal drüber reden. Erfahrungsgemäß ist es oft sinnvoller, eine AD-Umgebung aufzuräumen, als sie neu zu machen. Und was soll der Nutzen eines Linux-DCs sein? Solange du weiter mit Windows-RDS arbeitest, werden die Lizenzkosten für die gesamte Umgebung nahezu dieselben sein. Da würde ich dann auch einen echten und vom Hersteller supporteten DC nehmen, keinen Nachbau. Gruß, Nils

Moin, @Stephan Betken von den zwölf Slots stand nur die Hälfte für Externe zur Verfügung. Schon etwas ... eigen. Gruß, Nils