Jump to content

michelo82

Members
  • Content Count

    297
  • Joined

  • Last visited

Community Reputation

11 Neutral

About michelo82

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Doch. Nur führen die Links nicht dahin. Aber ich suche mal die 12/2016.
  2. Das wäre eine wichtige Maßnahme die Credentials zu schützen. Danke für die Links - die funktionieren aber leider nicht.
  3. 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.
  4. 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 weiter
  5. 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
  6. 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. Ken
  7. 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
  8. 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 entspre
  9. 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 rundl
  10. 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?
  11. 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?
  12. Weil es ja Ursprünglich um einen Inhalt aus einem Buch ging...was empfehlt ihr in die Richtung GPO's?
  13. Danke für den Tipp. Ich schaue mich mal um!
×
×
  • Create New...