NilsK

Moin, man könnte sowas überlegen, das wäre meine Variante 2 oben. Es bleibt aber dabei: Sinnvoller ist, das Problem zu lösen statt die Auswirkungen zu beseitigen. [Just Enough Administration: Material von der CDC Germany 2017 | faq-o-matic.net] https://www.faq-o-matic.net/2017/06/12/just-enough-administration-material-von-der-cdc-germany-2017/ Gruß, Nils

Moin, dann wäre die Gelegenheit günstig, die Frage noch mal zu stellen. Die eigentliche Aufgabe ist nur lösbar, wenn entweder der User, der das ausführt, eben kein normaler User ist, sondern das Recht hat, im AD den User zu entsperren oder man mit einer Infrastruktur dahinter arbeitet, mit der der ausführende "normale" User etwas auslöst, was den gesperrten Account entsperrt, dieser Vorgang aber mit einem separaten, dazu berechtigen Konto läuft Beide Varianten bedeuten erheblichen Aufwand und ebenso erhebliches Risiko. Gruß, Nils

Moin, abgesehen davon, dass die Aufgabe so, wie sie formuliert ist, nicht umsetzbar ist - wäre es nicht klüger, die Ursache dafür abzustellen, dass der betreffende Account immer gesperrt wird? Gruß, Nils

Moin, Der Thread ist sieben Jahre alt. Lasst ihn ruhen. Gruß, Nils

Moin, keine Ahnung. Ist der Ordner denn als "ad_daten" für alle Benutzer zum Lesen freigegeben? Dann sollte es passen. Ich verweise übrigens noch mal auf den korrekten Hinweis von Rolf - du solltest die internen Informationen eurer Firma aus den Screenshots oben entfernen. Du gibst sonst eine ganze Menge über euer Unternehmen preis. Gruß, Nils

Moin, du hast einen lokalen Pfad auf dem Server angegeben. Die Clients interpretieren das aber dann als lokalen Pfad bei sich - sie suchen also auf ihrer eigenen C-Platte, wo der Pfad sicher gar nicht existiert. Du musst das Bitmap in eine Freigabe legen, auf die alle zugreifen können. Den UNC-Pfad trägst du dann in der Policy ein. Gruß, Nils

Moin, und wo hast du den eingetragen? Um das einschätzen zu können, brauchen wir schon ein paar mehr Informationen. Was willst du genau erreichen? Was hast du bislang genau wo eingerichtet? Was geschieht genau bzw. geschieht genau nicht? Gruß, Nils

Moin, auf einem Terminalserver laufen Usersessions. User haben auf einem DC aber nichts zu suchen, weil dieser ein zentrales Sicherheitssystem ist. Das fängt an bei simplen Dingen wie Dateien, die User nicht manipulieren und auch nicht lesen dürfen/sollen, geht über Anwendungsprogramme, die nicht sicher genug sind, um sie auf einem DC zu betreiben, bis hin zu Prozessen, die auf einem Sicherheitssystem nicht erwünscht sind. Dazu kommen Aspekte wie der Netzwerkverkehr eines DCs, den man nicht von den Unwägbarkeiten eines Systems beeinträchtigt sehen will, das Clientaufgaben ausführt. Usw. usf. Und nein, in der Praxis wirst du das nicht so einschränken können, dass es Sinn ergibt. Den Aufwand sollte man dann lieber in separierte Systeme stecken. Du wirst im Web genug dazu finden. Einen DC von einem Terminalserver zu trennen, verursacht Kosten im vernachlässigbaren Bereich (vielleicht dreistellig, vielleicht moderat vierstellig), für die man kein Risiko eingehen will. Würdest du einen Anwender mit all seinen Programmen direkt auf einer Firewall arbeiten lassen? Siehste - auf einem DC eben auch nicht. Gruß, Nils

Moin, sorry, aber hier wird dir niemand ein Sizing oder ein Gesamtkonzept für eine IT-Umgebung geben. Viele von uns verdienen ihr Geld als IT-Dienstleister, und da kosten solche Beratungen naheliegenderweise Geld. Wir helfen gern bei konkreten technischen Fragen, aber diese Anfrage ist in einem Forum nicht an der richtigen Adresse. Gruß, Nils

Moin, nein, wie gesagt, gibt es das in der SAM-Datenbank nicht. Gruß, Nils

Moin, du meinst den Effekt, nachdem die Auswahl auf das lokale System gestellt wurde? Das wird einfach daran liegen, dass es im AD eine eigene Funktion zur unscharfen Suche gibt (Ambiguous Name Resolution), in der SAM-Datenbank aber nicht. Da letztere üblicherweise nicht groß ist, hat man sowas dort wohl nicht implementiert. Gruß, Nils

Moin, Schwank aus der Berater-Realität: Man kann mit einem Kunden über ESAE reden und ein Red-Forest-Konstrukt entwerfen und aufbauen. Und dann ist man bei einem harmlosen Supportfall (Typ: Datei wiederfinden), und der Kunde meldet sich an den DC mit "Administrator" an ... Gruß, Nils

Moin, das deutet darauf hin, dass Hyper-V den Saved State nicht erzeugen konnte. Vielleicht geht der Shutdown zu schnell. In dem Fall könnte es sein, dass auch das Herunterfahren der VMs keine Besserung bringt, weil der Shutdown des Hosts auch dafür zu schnell ist. Abhilfe hab ich auf die Schnelle nicht, weil ich praktisch nie mit Einzelsystemen zu tun habe. Eigentlich sollte sich, falls die Vermutung zutrifft, aber auch dazu was im Eventlog finden. Gruß, Nils

Moin, puh, Hannover-Dresden ist anstrengend. Ich mag das Zugmaterial nicht, dieser umlackierte Nahverkehrszug, der da als IC firmiert, ist eine Zumutung. Hatte ich grad letzte Woche. Gruß, Nils

Moin, das wird dann der erste Mechanismus sein. Möglicherweise hätte es auch so eine Aktualisierung gegeben, aber dazu weiß ich die Details nicht aus dem Kopf. Gruß, Nils

Moin, dazu gibt es zwei Wege: die CA-Zertifikate einer Enterprise-CA holt sich ein Client selbst, wenn er über das AD die CA entdeckt für alle CA-Typen können die Zertifikate auch per GPO verteilt werden Oft macht man beides parallel, um sicherzugehen, dass die Zertifikate ankommen. Die Clients brauchen diese, damit sie den CAs vertrauen und von diesen ausgestellte Zertifikate akzeptieren. Gruß, Nils

Moin, und was ist jetzt deine Frage? Gruß, Nils

Moin, kannst du machen, musst du aber nicht. Der dort angegebene Pfad wird dir beim manuellen Erzeugen einer VM jeweils als Vorschlag angegeben, den du akzeptieren oder überschreiben kannst. Mehr nicht, es besteht keine weitere Abhängigkeit von diesem Wert. Gruß, Nils

Moin, nein, das würde nicht funktionieren. Der Pfad an der angegebenen Stelle ist nur ein Vorgabewert für neue VMs. Der hat mit bestehenden VMs nichts zu tun. Beim Anlegen einer neuen VM kannst du auch jeweils einen individuellen Pfad vergeben und musst die Vorgabe nicht nutzen. Als Best Practice gilt, alle Daten einer VM in einem Ordner zu sammeln, also die Config-Files nicht separat vom Rest zu halten. Technisch ist das egal, aber auf die Weise hat man alles übersichtlich zusammen. Sofern es keine harte Notwendigkeit gibt, das für bestehende VMs zu ändern, würde ich die in Ruhe lassen. Falls doch, ist der einfachste Weg vermutlich, die betreffenden VMs zu beenden, zu löschen, alles an den Zielort zu verschieben und dort per Import-Funktion neu zu registrieren. Gruß, Nils

Moin, nachgelagerte Systeme. Applikationen, Dateiserver, CMD-Codepages ... you name it. Gruß, Nils

Moin, das erste Dokument ist schon sehr alt. Das zweite ist etwas weniger alt. Windows Server 2019 ist unter Hyper-V vor 2016 überhaupt nicht supported. Lizenzrechtlich hätte es auch wenig Sinn: Um 2019 als Gast zu betreiben, muss auf dem Host eine 2019-Lizenz vorliegen. Wenn man die hat, ist es unsinnig, 2012 R2 zu installieren. Dasselbe gilt zwar auch für 2016, welches in der Kombination supported ist. Aber es liegt nun mal beim Hersteller, was er supported und was nicht. "Nicht supported" heißt auch nicht, dass es nicht läuft, es gibt nur eben keinen Support. Windows Server 2019 ist als Gast erst ab Hyper-V 2016 supported. Zu Windows 10 sind keine Einschränkungen dokumentiert. Da der Support für Client-OS aber auch geringer ist als für Server-OS, kann man daraus keine Analogien ableiten. EDIT: Ich habe gerade noch mal nachgesehen. Für Hyper-V gibt es eine "N+1"-Regel für den Gast-Support, d.h. das direkt nachfolgende Server-OS ist i.d.R. ebenfalls supported. Über zwei Generationen hinweg aber eben nicht. (Und: Es gilt nur für VMs, nicht für Container, da muss der OS-Level identisch sein.) Gruß, Nils

Moin, siehst du, genau sowas meine ich. Dir fehlen Kenntnisse der Technik (was an sich kein Problem ist), und jetzt versuchst du aufs Geratewohl herum (und da ist das Problem). Sowas macht man nicht mit einer zentralen Sicherheitskomponente. Nimm es mir nicht übel, aber solche kritischen Systeme supporte ich nicht auf dieser Ebene in einem Forum. Gruß, Nils

Moin, ja ... leider ist eine Windows-PKI auch mit aktuellen Betriebssystemen nicht leicht zu handhaben. Alles keine Technik, die undurchdringlich wäre, aber leider unnötig kompliziert gemacht. Anscheinend hast du da jetzt schon einiges rumprobiert. Da eine CA ein sicherheitskritisches System ist, rate ich davon ab, an der Stelle jetzt mit Forensupport weiter zu machen. Ein Dienstleister, der sich auskennt, sollte da mit vertretbarem Aufwand das Nötige tun können, ohne zusätzliche Risiken zu erzeugen. Eine Root-CA auf fünf Jahre zu setzen, wäre keine gute Idee. Aber vielleicht ist das jetzt auch nur ein Missverständnis. Gruß, Nils

Moin, vermutlich hast du für AIA (Speicherort für Informationen über die CA) und CRL (Zertifikatssperrliste) Werte angegeben, die ungültig sind. Jetzt gibt es keinen Pfad, an dem ein Client diese Daten abrufen kann. Was steht denn in den vorhandenen Zertifikaten und den verwendeten Zertifikatsvorlagen dazu drin? Und auf was für "5" hast du die Gültigkeit umgestellt? Jahre? Tage? ...? Wie lang ist denn das Root-Zertifikat noch gültig? Gruß, Nils

Moin, sagen wir es kurz: Du hast eine falsche Vorstellung von Active Directory. Insgesamt betrachtet, macht es was völlig anderes als du vermutest. Bitte lass das bleiben, auch das mit dem eigenen Exchange. Du handelst dir selbst und deiner Umgebung erhebliche Sicherheitsprobleme ein. Gruß, Nils