NilsK

Moin, wenn es tatsächlich um die Gruppe Konten-Operatoren geht und das nicht nur ein unglückliches Beispiel war - dann wäre es weit besser, die Gruppe Konten-Operatiren zu leeren und zu überwachen, dass sie immer leer ist. Diese Gruppe braucht seit Windows NT niemand mehr, dafür erzeugt sie erhebliche Risiken. Da sie durch die Vererbung aber immer wieder auftaucht, geht man das Problem besser an einer geeigneten Stelle an - nämlich indem man die Gruppe nicht verwendet und leer lässt (Letzteres kann man auch periodisch per Skript oder GPO erzwingen). Gruß, Nils

Moin, auf Anforderung von Evgenij sagte ich vor ein paar Monaten: "PKI ist böse." Wie die anderen vermute ich auch, dass der TO gar keine PKI will, sondern Webserver-Zertifikate. Die kann man einfacher, sicherer und günstiger haben, wie auch schon ausgeführt wurde. Ich empfehle das sehr. Mit PKIs kann man so dermaßen viel falsch machen, dass man es lieber bleiben lässt, wenn man es nicht wirklich braucht. Gruß, Nils

Moin, gemeint ist "dsacls", das hat einen Schalter, um die Berechtigungen für Objekte auf den Standard zurückzusetzen (also auf die Berechtigungen, die gemäß Objektklasse vorgesehen sind). Ob das zu deinem Szenario passt, weiß ich nicht. Sonst müsstest du mit den Einzelaktionen arbeiten, was aber hakelig ist. Gruß, Nils

Moin, wobei der Fehler, den du jetzt rausgefunden hast, ja schon relevant ist, den könntest du mal an den Hersteller melden. Die Suche bzw. die Ansprache der DLL könnte er ja auch schlauer regeln. Gruß, Nils

Moin, also ... ich lese das anders. Aber wir sollten uns hier nicht mit Haarspaltereien befassen. Von einer Zertifizierung hat der TO nichts geschrieben. Er wollte Hinweise zur Umsetzung haben, und seinen Antworten nach zu urteilen, ist er an Praxishinweisen auch interessiert. Was er davon dann umsetzt, ist allein seine Sache. Gruß, Nils

Moin, also, zunächst einmal war Evgenijs Antwort nach meinem Verständnis auf eine viel engere Frage bezogen und hatte nicht den Fokus, den Übergriff unmöglich zu machen. Bezüglich der ursprünglichen Frage, wie man eine VM so anbindet, dass sie nicht zum selben Netz gehört, stimme ich Evgenij natürlich zu. Und zum anderen: Ich sage nicht, dass es simpel sei, von einer VM aus den Host durchzugreifen. Aber in den vergangenen Jahren hat jeder einzelne Hersteller von Hypervisoren in seinem Produkt den GAU gehabt, dass eine Sicherheitslücke entdeckt wurde, mit der genau sowas möglich ist. Bei VMware war es z.B. mal die virtuelle Grafikkarte, die man über einen manipulierten Treiber für den Übergriff nutzen konnte. Hyper-V hatte zwei oder drei Jahre später eine ähnliche Lücke - was genau es da war, weiß ich gerade nicht mehr. Und da ist man dann schlicht machtlos - wenn ich schon VMs in separate Netzwerke stecke, dann gehören sie nicht auf denselben Host. Finde ich jedenfalls, und dabei werde ich wohl auch noch eine Weile bleiben. Was mir wichtig ist: Virtualisierung per se bedeutet eben nicht Separierung. Man kann einfach auch in der Konfiguration viel falsch machen. Pentests etwa finden normalerweise nur in Umgebungen statt, die sehr weit entwickelt sind, da kommen solche simplen Dinge gar nicht vor, wie ich sie in der freien Wildbahn leider oft sehe. Dass Evgenij und ich uns hier mit unterschiedlichen Meinungen und Interpretationen beharken, gehört zur Folklore. Gruß, Nils

Moin, wie gesagt, die BSI-Bausteine sind aktuell gut und insgesamt viel besser als die ersten Würfe vor einigen Jahren. Man sollte sie aber a) nicht absolut setzen und b) nicht für vollständig halten. Früher hat das BSI mal von "Grundschutz" gesprochen und damit ausgedrückt, dass man damit eine Basis legt, aber eben nicht fertig ist. "Weitere Quellen" sind alles Mögliche. Vor allem lasse ich z.B. das Argument nicht gelten, dass man etwas genau so-und-so tun müsse, weil das ja schließlich "das BSI" so vorgebe. Gruß, Nils

Moin, das gewährleistet dein Design nicht. Dafür musst du ganz andere Dinge tun. Separate vSwitches erhöhen den Aufwand, führen aber nicht zu mehr Separation auf demselben Host. Aus Best-Practices-Sicht ist dein Design ausgesprochen ungünstig. Gruß, Nils

Moin, und was hat ein vSwitch mit einer IP-Adresse zu tun? Ich denke, du solltest dir das technische Konzept noch mal in Ruhe ansehen. Gruß, Nils

Moin, vor allem aber: den physischen Zugang zum DC sowie bei VMs den Zugang zur VM-Verwaltungskonsole einschränken. Bei einem unautorisierten Neustart geht es primär darum, dass man den DC nicht mit einem anderen OS oder mit dem Recovery-OS starten kann. Darüber wären nämlich sehr einfache und sehr weitreichende Angriffe möglich. Übrigens darf (und sollte) man die BSI-Empfehlungen durchaus kritisch sehen. Die sind zwar heute viel besser als vor einigen Jahren, aber es stehen immer noch bisweilen unsinnige Dinge darin. In der Nähe des zitierten Absatzes etwa die Empfehlung, Images von DCs vorzuhalten - sowas tut man nicht. Gruß, Nils

Moin, ja, wobei du den vSwitch natürlich auch schlauer benennen kannst. Spontan fiele mir sowas ein wie "vSwitch Internet-direkt". (Braucht ihr wirklich fünf vSwitches? Oder fehlt da das Verständnis, wie das in Hyper-V funktioniert?) Aber bist du dir sicher, dass du deinen Webserver ohne Firewall ans Web hängen willst? Und dann noch auf einem Host laufen lässt, wo auch interne VMs laufen? Nur weil die VM einen anderen vSwitch nutzt, ist sie ja nicht vom Rest des Hosts separiert - im Gegenteil. Gruß, Nils

Moin, ach so. Keine Ahnung. Ich würde das nicht so lesen, dass es geht. Im dritten Spiegelstrich unter 4. ist auch nur von "Licenses" die Rede, was hier nur denselben Typ meinen kann, nichts von "or previous versions" oder so. Dazu würde ich ansonsten aber jetzt auch nicht mehr sagen als diese Vermutung. Weder habe ich den Bedarf, noch bin ich der Lizenzgeber. Nur so viel: Da auch mittelständische und kleine Kunden bei Falschlizenzierung empfindlich nachzahlen müssen, würde ich mich im Zweifel nicht auf Interpretationen verlassen, sondern die paar hundert Euro gleich investieren. Da ohnehin ja anscheinend der Umstieg auf 2022 geplant ist, dürfte es sich nicht um rausgeworfenes Geld handeln, sondern nur um eine vorgezogene Zahlung. Gruß, Nils

Moin, hm, als Beleg ist das aber arg dünn ... Ich finde die Product Terms da aber auch ziemlich eindeutig: Quelle: https://www.microsoft.com/licensing/terms/productoffering/WindowsServerStandardDatacenterEssentials/OL#UseRights Ich brauche also so viele Lizenzen, dass alle Cores auf dem Server abgedeckt sind. Da ist ja gar kein Platz, um noch andere Versionen hineinzumischen. Ein Konstrukt à la "4 Cores lizenziere ich mit 2022, die anderen 4 mit 2016" ist dadurch ausgeschlossen. Gruß, Nils

Moin, ah, OK, dann hast du ja einen Ansatz. Das konkrete Problem hatte ich tatsächlich etwas überlesen. Gruß, Nils

Moin, das hattest du im Oktober 2021 vermutet, aber ohne Beleg. Einen Thread dazu habe ich nicht gefunden. Es würde mich wundern, aber was kann man heutzutage schon ausschließen. Microsoft selbst verweist an einer Stelle immer noch auf den Licensing Guide von Server 2016, in dem das Mischen ausdrücklich ausgeschlossen wird. Ja, ich weiß, keine PUR, aber die hat hier ja auch noch niemand wirksam zitiert. Gruß, Nils

Moin, du lizenzierst keine Windows-VMs, sondern den Hardware-Host, auf dem die VMs laufen. Möchtest du auf dem Host also eine 2022-VM betreiben, dann muss der Host ausreichend Lizenzen für Windows Server 2022 haben. Da man Lizenzversionen nicht mischen kann, heißt das: Auf dem Host genügend 2022-Lizenzen, damit alle Windows-Server-VMs abgedeckt sind, egal, was dort tatsächlich ausgeführt wird. Gruß, Nils

Moin, hat der Hersteller dazu keine Empfehlungen? Normalerweise beantwortet man "Client besteht die Prüfung nicht" ja nicht damit, dass der Client im normalen Netz bleibt, oder? Gruß, Nils

Moin, Jedenfalls wertet dcdiag die Ereignisprotokolle aus und meldet Fehler, die es dort im letzten Zeitraum findet. Der Teil ist dann leider oft nicht so aussagekräftig. Ob die Fehler tatsächlich ihrerseits durch dcdiag verursacht werden, kann ich nicht beurteilen. Gruß, Nils

Moin, na, dann solltest du /q mal weglassen, damit du auch den Kontext der Fehlermeldung siehst und nicht nur den Fehler selbst. Die Kombi /c, /v und /q ergibt irgendwie wenig Sinn. Gruß, Nils

Moin, in welchem Abschnitt des DCDiag-Logs steht denn die Meldung? Gruß, Nils

Moin, ja, tut es. Noch mal: Das Profil hat mit der eigentlichen Anmeldung nichts zu tun. Nein. Der User ist ganz normal angemeldet und hat ein ganz normales Access-Token. Damit kann er ganz normal zugreifen wie sonst auch. Gruß, Nils

Moin, [AD: Betriebsmaster-Ausfall – was tun? | faq-o-matic.net] https://www.faq-o-matic.net/2010/09/09/ad-betriebsmaster-ausfall-was-tun/ Die Grundannahme ist aber schon falsch. DC2 kommt nicht erst ins Spiel, wenn DC1 nicht mehr da ist. Profile haben mit der Anmeldung nichts zu tun, die kommen erst später ins Spiel. Der User wird, wenn er an einen Rechner geht, wo er noch nicht angemeldet war, dann lange warten müssen, bekommt ein temporärer Profil und hat ein 1a-Risiko für Datenverluste. Auf einem Rechner, wo der User schon angemeldet war, liegt sowieso eine Kopie des Profils. Eigentlich ist es sogar umgekehrt: Auf dem PC ist das Original, auf dem Server liegt eine Kopie. Die Fragen, die du zu Profilen stellst, sind berechtigt. Servergespeicherte Profile sind per se problematisch. An Arbeitsplätzen, wo man sie nicht wirklich dringend braucht, sollte man sie nicht einsetzen. Gruß, Nils

Moin, wem sollen die Schulungen und die Anbieter denn "entsprechen"? Gruß, Nils

Moin, vielleicht beschreibst du besser das konkrete Problem, das du lösen willst. Sonst stochern wir hier wild herum. Gruß, Nils

Moin, kann man machen, ist aber ein sehr heikler Workaround. Effektiv weist du das System damit an, abgelaufene Zertifikatssperrlisten zu verwenden. Kann man machen, wenn man weiß, was man tut. Ist aber vom Prinzip her natürlich nicht so vorgesehen, aus gutem Grund, Gruß, Nils