michelo82

Ja richtig das DR-Konzept sollte da nicht vermischt werden. Aber stimmt, ein lokaler User könnte sich dennoch anmelden, auch bei einem Domänen-Mitglied. Die Workstations haben kein Win10 Enterprise BS um Credentials Guard zu nutzen - das kann aber wiedderum auf den Adminhost, da es ein Server BS ist, genutzt werden.

Diejenigen die auf die Adminmaschinen Zugriff haben, haben ebenso Zugriff auf die VMWare Umgebung - es ist der gleiche Personenkreis. Wir vertrauen uns. Wird das Passwort bei RDP zwischengespeichert? Das spricht dann dagegen. Da bin ich mir aber gerade nicht sicher. Ich habe bis jetzt noch nichts nachteiliges festgestellt, wenn die VM kein Domänenmitglied ist. Sinn war, dass die Maschine so immer autark betrieben werden kann, auch wenn die Domäne nicht verfügbar wäre (Disaster). EDIT: Vorläufig ja. Da wir nicht die (zeitlichen) Ressourcen haben einen weiteren Host bereitzustellen. Aber das zu ändern, habe ich bereits im Hinterkopf. Wenn man es ganz genau nimmt müsste ja nach dem PAW/SAW Prinzip, ein separater physicher Admin-PC in einem abgesperrten Raum stehen. Das ist nur im Alltag garnicht umzusetzen. Ein dedizierte Admin-VM um überhaupt erstmal eine Trennung zur Office-Workstation zu schaffen, war ein wichtiger Schritt.

Ja, warum nicht?

Hallo zusammen, Microsoft selbst empfiehlt ja die Nutzung dedizierter Maschinen für die administrative Verwaltung. https://docs.microsoft.com/de-de/windows-server/identity/securing-privileged-access/privileged-access-workstations Dazu existieren verschiedene Begrifflichkeiten um die Verwirrung komplett zu machen. Wir haben uns für die Variante Admin-Host bzw. Jump-Host entschieden. Jeder Admin hat seine eigene Server 2019 VM, die nicht Mitglied der Domäne ist, auf einem ESX. Die VM wurde mit den Microsoft Security Baseline gehärtet. Darin sind einige Tools und ein RDP-Manager. Auf diese Maschine wird per VMWware-Konsole zugegriffen. Mich würde interessieren, wie ihr das umgesetzt habt bzw. damit arbeitet? Spricht etwas dafür- bzw. dagegen, dass ein Adminhost nicht Mitglied der Domäne ist? MfG bleibt gesund!

Okay. Das habe ich soweit verstanden und auch die Forum-Suche genutzt. Sehr viel zu dem Thema findet man nicht. In diesem Thema hat jemand quasi von 0 angefangen: Dazu kann ich sagen, dass das ab jetzt so umgesetzt ist. Im aktuellen Schritt habe ich die persönlichen Admin-Konten für das Tier 0 erstellt und die Gruppe den Domänen-Admins hinzugefügt. Meine Gruppe mit delegierten Berechtigungen auf bestimmte OU belasse ich trotzdem. Das ist vielleicht für die Zukunft Interessant um einen "abgespeckten" Zugriff auf bestimmte OU's für bestimmte User freizugeben. Kennt jemand weitere gute Quellen, die die praktische Umsetzung des Themas veranschaulichen?

Hallo, und danke für die ausführliche Antwort. Damit meine ich das Default Administrator-Konto. Das Passwort dazu möchte ich idealerweise versiegelt in den Safe legen, da es nicht mehr verwendet werden soll. Die Tier0-Admins möchte ich delegieren um diese dadurch von den Berechtigungen her einzuschränken. Meine Idee war, dass die Tier0-Admins nicht generell, sondern nur temporär Domain-Admin-Berechtigungen bekommen. Einfache Tätigkeiten im AD sollen die noch weiter beschränkten daily-use-Konten erledigen. Vielleicht liegt hier mein Verständnisproblem und es stellt kein Sicherheitsproblem dar, wenn die Tier0-Admins generell zu den Domain-Admins gehören? Die Anmeldebeschränkung nur auf die DC's ist bereits geregelt. Ein Red Forest bzw. das ESAE-Modell zu implementieren scheint mir aktuell zu hoch gegriffen. Ich würde erstmal Schritt für Schritt vorgehen und eine verbesserte Basissicherheit mit der Tier-Level Implementierung und separierung der Administrativen-Anmeldungen herstellen. Wir haben nur einen Forest, eine Domäne. Ich verlange ja auch kein fertiges Konzept von euch. Das ist schon klar. Eher etwas unter die Arme greifen. Ich habe mir erhofft, dass sich mein Verständnisproblem auflöst. Über die Strukturänderungen mache ich mir bereits einige Wochen Gedanken. Ganz so hemdsärmelig bin ich dann doch nicht. Mich bringt vielleicht einfach ein Umriss weiter, wie andere Organisationen die Tier-Level und Berechtigungsdelegierung lösen. Eben die Notizen und Anmerkungen sind der Anstoß in die richtige Richtung weiterzugehen.

Hallo zusammen, ich benötige etwas Hilfe bei der implementierung der Tier-Level. Ich habe in meiner Umgebung eine OU “Administration” und darunter liegend die OUs “Administrative Gruppen” und “Administrative Konten”. Darunter entsprechend befinden sich dann die Gruppen “Tier0Admins”, “Tier1Admins” und “Tier2Admins”, sowie personalisierte Admin-Konten für jedes Tier-Level. Wir sind mehrere Admins. Die Tier1- und Tier2Admins werden per GPO als lokale Administratoren auf Server bzw. Clients verteilt. Eine Anmeldung auf ein System (z.b. Server) ist nur mit entsprechendem Login aus dem entsprechendem Tier(1)-Level erlaubt. Anmeldungen zwischen den Tier-Level ist nicht erlaubt. Kein higher oder lower Tier logon möglich - ebenfalls per GPO geregelt. Die Tier0-Verwaltung stellt mich allerdings noch vor offene Fragen. Bis jetztwurde sich immer direkt als Domänen-Admin remote am AD angemeldet und die Domäne verwaltet. Zukünftig soll das anders werden: - zunächt erfolgen sämtliche administrativen Aufgaben und Zugänge von einem speziell gehärteten Adminhost über z.b. RSAT etc. - für die täglichen Arbeiten (wie z.b. Passwort zurücksetzen, eine Gruppe oder Nutzer anlegen etc.) erhält jeder Admin ein persönliches ("daily-use-admin") Admin-Konto und hat die entsprechende delegierungen auf die OU "User" und "Clients". - die daily-use-admin Konten bekommen allerdings keine delegierung auf die OU “Administration” um sich nicht selber höher privilegieren zu können. - die daily-use-admin Konten dürfen sich nirgends anders im Netzwerk mit ihrer Kennung anmelden. Problem: - da es sich manchmal nicht vermeiden lässt auch Remote an den DC's zu arbeiten (gerade jetzt bei Einführung der Tier-Level wird noch nicht alles sofort rundlaufen), benötige ich dafür ebenfalls einen Admin-Account. Mit diesen sollte bei Bedarf die komplette Verwaltung des AD's möglich sein. Aktuell nutze ich dafür den Domänen-Admin. Dieser soll aber nicht mehr für die täglichen Arbeiten verwendet werden. Das Passwort des Domänen-Admins soll in noch kürzeren Abständen geändert werden können. Meine Lösung könnte so aussehen (wenn ich denn damit auf der richtigen Fährte bin : Die Tier0Admins in welcher wieder ein neues persönliches Admin-Konto steckt, habe ich in die Builtin-Gruppe Remotedesktopbenutzer geschoben und in der DDCP unter "Anmelden über Terminaldienste zulassen" eingetragen. Somit ist erstmal ünerhaupt die RDP anmeldung auf den DC's möglich. Eine Verwaltung der DC's bzw. des AD's funktioniert so aber logischerweise noch nicht. Ich würde dieser Tier0Admin-Gruppe per Delegierung Rechte auf die OU “Administration” und "Domänen-Admins" geben. So könnte ich bei Bedarf die Tier0Admins temporär in die Gruppe der Domänen-Admins verschieben und damit arbeiten. Nach erledigter Arbeit wird die Gruppe wieder entfernt. Später soll dafür das Privileged Access Management Feature verwendet werden. Das bearbeiten der Administrativen Gruppen soll überwacht werden. Meine Frage: Wäre das eine passable Lösung um das arbeiten mit dem Domänen-Admin Konto zu vermeiden? Oder wie macht ihr das? Ich bedanke mich schonmal für zahlreiche Tipps :) Bis bald.

Hallo Nils, ja du hast Recht!

Guten Morgen, Danke für das Feedback. die Rahmenbedingungen wären: - die tägliche Arbeit (Passwort zurücksetzen, eine Gruppe anlegen, einen Nutzer anlegen etc.) erfolgt von einem Adminhost über RSAT. Das verwendete Konto dafür hat die entsprechende delegierung(en) und darf sich sonst nirgends im Netzwerk damit anmelden. Vorher wurde sich immer direkt als Domänen-Admin remote am AD angemeldet. Problem: Da es sich manchmal nicht vermeiden lässt auch Remote an den DC's zu arbeiten (gerade jetzt bei Einführung der Tier-Level wird noch nicht alles sofort rundlaufen), benötige ich dafür einen Account. Dieser sollte die Serverwaltung möglich machen. Aktuell nutze ich dafür den Domänen-Admin. Dieser soll aber nicht mehr verwendet werden. Meine Lösung: Ich habe eine neue Gruppe angelegt (für das Tier 0) in welcher ein neues "Admin"-Konto steckt. Diese Gruppe habe ich in dei Builtin-Gruppe Remotedesktopbenutzer geschoben und in der DDCP unter "Anmelden über Terminaldienste zulassen" eingetragen. Meine Frage: Wäre das eine passable Lösung? Ich würde nur gerne wissen, ob es sich lohnt in diese Richtung weiter zu arbeiten. Wenn ja, kann ich diesen Nutzer auch in den anderen Gruppen (Serveroperatoren) berechtigen. (So dass er überhaupt was darf, außer nur über RDP anmelden).

Ich habe es mir eben so vorgstellt, dass die Gruppe der Tier0 Administratoren vollen Zugriff auf den DC hat, aber eben entsprechend selten verwendet wird. Es soll damit eigentlich nur ein lokales / RDP anmelden möglich sein um die "Administrative" OU verwalten zu können. Ein Konto muss doch ähnlich des Domain-Admins handlungsfähig sein . Gibt es eine bessere Lösung?

Hallo nochmal, Ich nutze für meinen dedizierten Admin (Tier0) - die Builtin Gruppe Administratoren. So hab ich vollen Zugriff auf den DC. Bin aber kein Domain-Admin. Der Login soll nur für die Verwaltung (lokale Anmeldung / RDP Anmeldung) der DC's genutzt werden bzw. um Administrative Konten/Gruppen zu verwalten. Der Ziugriff mit diesen Konto auf Tier1 / Tier2 ist verboten. Für die tägliche Arbeit gibt es ein weiteres Konto mit dem über RSAT von einem Adminhost bestimmte delegierte OU's verwaltet werden dürfen. Spricht da sicherheitstechnisch etwas dagegen? MfG

Weil es ja Ursprünglich um einen Inhalt aus einem Buch ging...was empfehlt ihr in die Richtung GPO's?

Danke für den Tipp. Ich schaue mich mal um!

@daabm Finde ich nicht

Ich danke euch für die nützlichen Infos! Dann ein schönes Wochenende - bleibt gesund!

Genau das ist die Erklärung! Danke. Ich habe es mir zusammengereimt ;) Erstens das gelesene aus dem Buch + Und das Missverständnis war perfekt! Ein anderes Beispiel: Mir ist noch unklar, warum meine Auditing-Einstellung durch meine neue Richtlinie außer Kraft gesetzt wurden. Hier habe ich die Erweiterte Überwachungskonfiguration bearbeitet. Danach waren die Audit-Events aus der DDCP nicht mehr im Ereignislog zu sehen. (z.b. 4771).

Ich habe mich hierrauf bezogen https://www.rheinwerk-verlag.de/sichere-windows-infrastrukturen-das-handbuch-fuer-administratoren/ Und hier wird eine eigene Policy auf die DC losgelassen:

Doch die neue Richtlinie wirkt sobald ich diese in der Reihenfolge vor die DDCP schiebe. Soweit wäre das verständlich. Allerdings hebelt das verschieben der Reihenfolge die DDCP aus! Ich habe zum testen ein weiteres Test-Konto in die Gruppe der Server-Operatoren gesteckt. Die dürfen sich nämlich ebenfalls am DC lokal anmelden. Nach dem verschieben der Reihenfolge, dürfen diese sich nicht mehr anmelden. Es ist ein Test-AD in einer VM. Ich habe nämlich schon bei meinen letzten versuchen eine Audit-Policy anzulegen gemerkt, dass danach die vorher getätigten Audit-Einstellung der DDCP nicht mehr galten. Die entsprechenden Events waren dann im Evenlog nicht mehr zu finden, weil meine vorherigen Einstellungen in der DDCP wieder überschrieben waren. Habe ich eben gelesen. Das wäre eine Möglichkeit. Aber warum geht es denn nicht additiv? Habe das auch so in der Fachliteratur gelesen. Welche wäre das? Danke schonmal für die sehr schnellen Antworten :)

Hallo, und zwar möchte ich mich lokal oder mit RDP mit einem personalisierten Admin-Account an den DC's anmelden. Dazu habe ich eine "Delta-Richtlinie" zur DDCP angelegt. Ist die Verknüpfungsreihenfolge nach der DDCP wirkt meine neu erstellte Richtlinie nicht. Ist die Verknüpfungsreihenfolge vor der DDCP wirkt meine DDCP nicht . Ich war der Annahme, dass die Policys additiv arbeiten und ich somt die Default Domain Controller Policy mit meiner neuen Delta-Richtlinie einfach ergänzen kann. Mache ich etwas falsch? Ich wollte nicht unbedingt die Default Domain Controller Policy verändern. MfG Michi

Jawoll! Ich habe nur in dem Test meinen Testuser verwendet. Wichtig, war wie ich es überhaupt löse.

@tesso Danke Uff...so einfach ist es wenn man es richtig macht und die expliziten Berechtigungen anpasst. Also kann ich jetzt alle Freigaben auf die der User NTFS-Berechtigungen hat unter dem Namespace "DFS" sammeln. Oder: ich erstelle mir einen weiteren Namespace "Abteilungen" und darunter dann alle Abteilungsordner.

Hallo, und zwar muss ich unseren Fileserver (Srv2008 R2) ersetzen und möchte die Daten auf mehrere neue Fileserver (Srv2019) verteilen. Die Datenmenge soll somit pro Server "übersichtlicher" und einfacher zu managen sein und bei Wartungsarbeiten werden nicht alle Abteilungen gleichzeitig lahmgelegt. Ich habe DFS, AD-intigriert eingerichtet. Hier das Problem: Wir haben auf den alten Filer u.a. ein Verzeichnis "Abteilungen", welches die Abteilungsverzeichnisse (Marketing, Vertrieb etc) enthält. Dieses Verzeichnis habe ich über die drei neuen Fileservern (Srv2019) aufgeteilt. Ich musste leider feststellen, dass ich mit DFS keine Freigaben von den drei Server in eine flache Struktur zusammenfassen / bündeln kann, die dann unter einem Freigabenamen erreichbar ist. Schade. Dann hätte ich den User nur \\domäne.local\dfs\Abteilungen bereitgestellt und mittels ABE, hätte jeder nur das gesehen, was er sehen darf. Wie könnte ich es jetzt einfach realiseren, den User sein Abteilungslaufwerk zugänglich zu machen? Könnte ich dazu einfach pro Abteilung (es sind 39 Abteilungsverzeichnisse) einen Namespace anlegen und diese den User mappen? z.b. Oder ist es eher nicht ratsam soviele Namespaces anzulegen? Bloß wie bekomme ich dann die Abteilungen in einem einzigen Namespace realisiert? Mir fehlt da die Best Practice. Was wäre eine elegante Lösung? Vielen Dank und bleibt gesund.

Hi, ich habe eine Fehler gemacht. Ich habe bei der Freigabe mit Berechtigung JEDER, nur lesen statt ändern geklickt. Ich habe da wohl im Eifer des Gefechts nicht richtig hingeschaut. @Squire An die Variante habe ich auch schon gedacht. Ich lese aber immer, dass man die Vererbung eben nicht deaktiveren soll. Jetzt bin ich mir etwas unschlüssig darüber. Kannst du deine Variante eventuell noch mit einem Screenshot unterfüttern?

Ok. Folgendes verstehe ich allerdings nicht: 1. Ich erstelle eine Freigabe für den Ordner “e:\Freigabe” mit dem Namen “Freigabe”. 2. Ich erstellen eine Berechtigungsgruppe im AD “NTFS_Abteilung1_RW” 3. Ich vergebe der Gruppe “Ändern”-Berechtigungen auf den Ordner “E:\Freigabe” 4. Ich vergebe der Freigabe JEDER mit “Ändern”-Berechtigungen Ich erwarte, dass: Ich mit einem Benutzer der in der Gruppe von “NTFS_Abteilung1_RW” steckt ein neues Verzeichnis anlegen kann. Ich stelle fest, dass: der Benutzer den Ordner Freigaben öffnen kann, dort aber keine Berechtigungen hat. Was mache ich falsch?

Hallo Nils, Danke! Prima! Ich dachte es mir schon. Ja das habe ich wohl nicht ausführlich beschrieben. Ich setze die Freigabeberechtigungen auf JEDER (AUTHENTIFIZIERTE oder gar die Gruppe Freigabename_RW, dürfte ja auch gehen) => auf ÄNDERN, sodass die User selbst keine Berechtigungen editieren dürfen. Hier wiederum bekomme ich ein Problem mit der UAC, da mein Admin ja als normaler User im Explorer unterwegs ist. (Quelle) Also würde ich die Gruppe Benutzer zu entfernen, dafür dann meine Gruppe Freigabename_RW oder Freigabename_R hinzufügen. Zusätzlich würde noch eine z.b. File-Admin Gruppe, die Mitglied der Gruppe der lokalen Administratoren ist und “Vollzugriff” auf das NTFS Volume bekommt, hinzufügen. Da meine Freigaben direkt in einem Verzeichnis unterhalb der Wurzel (z.b. E:\Freigaben) liegen ist es doch besser, wenn ich die Vererbung im Verzeichnis "Freigaben" deaktiveren und nicht auf E:\ ? Ist es dann der richtige Weg?