NilsK

Moin, Was genau soll das heißen, die VM erkennt die Netzwerkkarte nicht? Eine VM hat doch gar nichts mit der Netzwerkkarte im Host zu tun. Bitte mal genauer beschreiben. Gruß, Nils

Moin, gibt es vielleicht auch - aber das weiß eben nur der, der das gebaut hat. Gruß, Nils

Moin, das hat mit Sicherheit mit Berechtigungen zu tun. Mehr kann man auf Grundlage der Informationen aber nicht sagen. Vermutlich startet das "Master"-Programm die weiteren Prozesse irgendwie mit einem eingeschränkten Benutzerkontext. Du wirst das also mit der Stelle klären müssen, die diesen Launcher gebaut hat. Gruß, Nils

Moin, Na, aber das ist ja nicht extrem. Ich sehe da keinen Grund, der einen Neuaufbau ausschließen würde. Gruß, Nils

Moin, mhm. Einen Ansatz habe ich da direkt leider nicht - aber das hier ist mit Sicherheit wirkungslos: Gruß, Nils

Moin, hm, ob das Fehlen dieses Satzes tatsächlich darauf schließen lässt, dass überhaupt was kaputt ist? Funktioniert denn dann auch etwas nicht, wenn die Anzeige fehlt? Gruß, Nils

Moin, oh je, wo hast du dir denn die Fragmente abgeguckt? Da stimmt ja eigentlich gar nichts. Das iast auch kaum korrigierbar. Vorschlag: Mach es lieber auf diesem Weg. [Excel: Admins unbekannter Liebling | faq-o-matic.net] https://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Dass das nur funktioniert, wenn du es mit einem Account ausführst, der auf allen Rechnern Admin ist, ist bekannt? Gruß, Nils

Moin, in der Praxis besteht die PKI entweder aus nur einer CA - dann ist Root = Issuing - oder aus zwei Stufen - Root plus Issuing. Ganz selten gibt es Root - Intermediate - Issuing. In allen Fällen liegt der Aufwand an der Stelle "Issuing". Daher meine Idee, dass man es dann auch gleich ganz neu machen kann. Lohnt sich praktisch immer. Wenn man es von da ab richtig macht. Gruß, Nils

Moin, naja, aber das ist ja das, wo der Aufwand liegt. Wenn ich dabei bin, kann ich doch besser die ganze PKI erneuern, die Root erzeugt ja nahezu keinen Mehraufwand. In bestehenden Umgebungen ist sie aber meist "schlecht" aufgesetzt, sodass man sie besser gleich neu macht. Gruß, Nils

Moin, ich würde das trotzdem als Option nicht ausschließen. Bestehende Zertifikate kann man gut auf einer Alt-CA solange "laufen" lassen, wie sie noch gültig sind. Da braucht man ja eigentlich nur die Pflege der CRLs, neue Zertifikate stellt diese CA dann nicht mehr aus. Alles Neue lässt man dann von einer neuen, gut gemachten und aktuellen CA bedienen. Und igendwann ist die alte CA obsolet und man entfernt sie - meist eine Sache von Monaten, nicht von Jahren. Wieviel ist denn "extrem hohe Anzahl"? Gruß, Nils

Moin, vielen Dank für die Blumen. Ich stimme Gulp zu, die eigentliche Kontentrennung ist schon mal der wesentliche Schritt. Gleichzeitig ist die Überlegung, auch den Rechner zu "separieren", sinnvoll. So bestünde, wenn man es richtig macht, noch eine weitere Hürde für "irgendwas", das sich auf dem Office-Rechner einnistet, auf die administrativen Zugriffe überzugreifen. Da allerdings, und da kommt Gulps Argumentation wieder ins Spiel, sollte man abwägen. Der Aufwand lohnt sich nur, wenn man die administrative Maschine/VM wirklich "sauber" hält - und wenn man umgekehrt wirklich keine Anmeldung mehr mit dem Admin-Konto auf dem Office-Rechner durchführt. Bequemlichkeit und "mal eben" verbieten sich dann. Weiß man, dass man das nicht durchhält, dann ist es nicht nur sinnlos, sondern erhöht sogar die Gefahr, weil man sich in falscher Sicherheit wiegt. Gruß, Nils

Moin, denkbar ist vieles, aber ist es auch sinnvoll? Du verhinderst damit den Zugriff, wenn ein Mitarbeiter sein Handy in ein WLAN hängt. Dafür lässt du beliebige andere Telekom-Nutzer zu. Wenig gewonnen, viel verloren, denke ich. Gruß, Nils

Moin, wenn man es so formuliert - kurz gesagt: ja, so ist die Rechtslage. Zum Glück. In den USA würde ich aus diesem Grund etwa sehr ungern arbeiten wollen. Gruß, Nils

Moin, damit bist du nicht allein. Es gibt hunderte Firmen "da draußen", die glauben, sie hätten ihre Mobil- und BYOD-Szenarien auf diese Weise abgesichert ... Gruß, Nils

Moin, Ganz dünnes Eis. Ich wage zu bezweifeln, dass du das darfst. Ah deiner Stelle würde ich mich rechtlich beraten lassen, bevor ich sowas täte. Gruß Nils

Moin, mal von vorne gefragt: Was möchtest du denn erreichen? Gruß, Nils

Moin, um es noch mal ausdrücklich zu sagen: der kostenlose Hypervisor hat keine Vorteile gegenüber den Standard, wenn Lizenzierung kein Thema ist (wie hier). Es erübrigt sich also, schon deshalb, weil es dafür keinen Support gibt. Gruß, Nils

Moin, ja, das ist korrekt. Und es lässt sich nicht verhindern. Zertifikate sind nicht geeignet, um Hardware eindeutig zu identifizieren - solange diese Zertifikate nicht mit der Hardware "fälschungssicher" und "untrennbar" verbunden sind. Letzteres ist das Prinzip eines TPM, das lässt sich aber durch nachträglich ausgestellte Zertifikate nicht nachbilden. Anders, als viele oft annehmen, sind Zertifikate keine Garanten für Sicherheit. In den meisten praktischen Situationen sind sie sogar eher das Gegenteil. Gruß, Nils

Moin, es werden mehrere Leute darauf anspringen, die dir sagen, dass Batch kein guter Ansatz dafür ist. Ist es auch nicht. Mach sowas künftig lieber per PowerShell. Die Hürde mit der Local Expansion hat dein Skript schon korrekt genommen. Nun ist aber noch der Vergleich selbst "falsch", weil du ihn so geschrieben hast, wie man das in einer ordentlichen Sprache tun würde. Das ist Batch aber nun mal nicht. Dein Vergleich lautet: Das ist dann wahr, wenn in der Variablen "Wahl" der Wert "'j'" steht - beachte die Anführungsstriche. Batch nutzt an dieser Stelle keine Begrenzer. Der Vergleich müsste also lauten: if /i '!wahl!'=='j' ( Oder aber: if /i !wahl!==j ( Du vergleichst also entweder "Anführungsstriche Variable Anführungsstriche" mit "Anführungsstriche Wert Anführungsstriche" oder direkt "Variable" mit "Wert". Ja, das ist gruselig. Und ja, sieht man beides in der freien Wildbahn. Gruß, Nils

Moin, das "Verhindern" des Exports ist Schlangenöl. Windows bietet seit Jahrzehnten ein Häkchen mit dieser Bezeichnung und tut damit so, als könne man das steuern. Kann man aber nicht. Man steuert damit nur das Verhalten der mitgelieferten Verwaltungstools, mehr nicht. Selbst wenn der Schlüssel als "nicht exportierbar" markiert ist, kann ein User ihn exportieren, sobald er Zugriff darauf hat, er braucht nur ein Werkzeug dafür. (Ist ja auch klar: Um den Schlüssel nutzen zu können, muss ich ihn lesen können. Und zwischen "Lesen" und "Kopieren" gibt es auf einem Computer keinen Unterschied.) Die Frage ist ja eher, was du denn erreichen willst und warum du das beschriebene Verhalten für problematisch hältst. Darüber sollten wir sprechen, bevor wir weiter nach "Lösungen" suchen. Gruß, Nils

Moin, grundsätzlich spricht nichts dagegen, nein. Wenn du es damit zuverlässig hinbekommst, dann mach es. Gründe, warum man vom USB-Durchleiten eher abrät: Diese Funktion neigt dazu, nicht ausreichend zuverlässig zu sein, gerade, wenn es um Nicht-Standard-Geräte geht. Und, meist noch wichtiger: Auf die Weise ist ein USB-Gerät immer an genau einen Host gebunden. In der Virtualisierung kommen aber schnell Host-Cluster ins Spiel, und da kann eine VM auch mal den Host wechseln - und verliert dann die USB-Verbindung, wenn das Gerät an den Host angestöpselt ist. Gruß, Nils

Moin, Wie waren denn da die Zeiträume? Gruß, Nils

Moin, das ist kein Linux-Server, sondern ein Windows-Server, auf dem eine Open-Source-Komponente läuft. Linux wäre ein anderes Betriebssystem, auf dem würde dann aber kein Active Directory laufen. Gruß, Nils

Moin, um es klar zu sagen: Bei der Problemlage kommt ihr mit einem Forum nicht weiter. Sucht euch jemanden, der euch vor Ort unterstützt. Gruß, Nils

Moin, für mich hört sich das an, als würde da eine Schulsoftware als geschlossenes System laufen. Anders ist ein OpenLDAP auf einem Windows-Server kaum zu erklären. Ich würde da also nicht vorschnell irgendwas ändern. Es mag "gebastelt" sein, aber wenn es nicht mehr funktioniert, wäre das gerade jetzt doch eher problematisch. Gruß, Nils