NilsK

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

Moin, Spricht etwas dagegen, die CA ordentlich komplett neu zu machen? Geht oft schneller, als etwas Altes zu reparieren. Gruß, Nils

Moin, diese Frage können wir nicht beantworten. Die Gegebenheiten in eurem Unternehmen kennen wir ja schließlich nicht. Vielleicht aber noch ein Hinweis dazu: Ein LAPS-Admin ist nicht identifizierbar. Das ist in einigen Situationen ein Kriterium. Gruß, Nils

Mom, Du musst zuerst die ganze CA-Kette auf SHA-256 umstellen. Und dann musst du das Zertifikat korrekt ausstellen, sodass der Name drinsteht, der tatsächlich von Client verwendet wird. Gruß, Nils

Moin, "von KISS lernen, heißt siegen lernen!" (Arnim Teutoburg-Weiß) Gruß, Nils ... aber wir schweifen ab ...

Moin, und genau das sehe ich nicht als Grund an. In der IT wird so viel gemacht, nur weil es technisch "geht" ... und wenn man es dann doch mal braucht, gibt es oft lange Gesichter, weil es dann eben in Wirklichkeit doch nicht geht wie gedacht. Und in diesem Fall sind sogar Nachteile im laufenden Betrieb zu erwarten (von der unnütz aufgewendeten Energie mal abgesehen). Gruß, Nils

Moin, wozu das Ganze? VM-Replikation ist ja nicht "kostenlos", sondern erzeugt im Gegenteil einiges an Last - und je nach Applikation auch an Risiken. Das stellt man nicht einfach mal so ein, nur weil man eine Maschine übrig hat. Ist ein "Downgrade" von VMs überhaupt möglich? Als ich das letzte Mal damit zu tun hatte, ging das gar nicht. Und mit den Win-7- und Win-10-Maschinen wirst du in dem Szenario Lizenzverstöße begehen. Also eine ganze Menge an Nachteilen bzw. Einschränkungen, für die ich zumindest aus den bisherigen Beschreibungen keine Vorteile finde, die das aufwiegen könnten. Gruß, Nils

Moin, für Details bin ich der falsche, ich wollte nur das Prinzip aufzeigen. Was ich meine: Wenn Unternehmen A und B zusammengehören (Tochterunternehmen, gemeinsame Holding oder was immer), dann können sie gemeinsam die Lizenzen eines der Unternehmen nutzen. Sind es getrennte Unternehmen, dann darf das eine Unternehmen nicht die Lizenzen des anderen nutzen. Gruß, Nils

Moin, wenn du so sparsam mit Informationen bist, vermute ich: niemand. Gruß, Nils