Delegierung der Tier-Level Berechtigungen

[michelo82 12]

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.

 

 

[daabm 1.348]

Ich verstehe nicht, warum Du die T0-Admins unbedingt aufwändig delegieren willst. Steck sie in die Dom-Admins und fertig. Was ist für dich "das Domänen-Admin Konto"? Ein T0-Admin ist Admin der Domäne(n).

 

Wir machen das so: Ausgewählte named User sind Mitglied der Dom-Admins in einem Red Forest. Über Shadow Principals sind sie auch direkt Mitglied aller Dom-Admins der "untergeordneten" Forests (PAM-Trust). Müßte man eigentlich mit zeitlimitierten Tickets machen, aber wir sind ein Konzern, wir kriegen nicht alles, was wir uns wünschen   Alle anderen Accounts liegen in einem eigenen Blue Forest und werden über einen konventionellen Oneway Trust auf den Zielservern berechtigt.

 

Die Dom-Admins dürfen sich nur auf DCs und einer Handvoll T0-Systemen anmelden. Die T1-Admins nur auf den Systemen, die zu ihrer Rolle gehören. Analog für T2. Das klappt ohne Deny, weil wir schlicht schon das Allow-Recht und die lokalen Admins (die ja immer dürfen) passend einstellen.

 

Das Delegationsprinzip basiert auf dem hier: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html

Wurde ein wenig erweitert auf Umgebungsvariablen, die die Gruppennamen definieren - und die Variablen wiederum kommen aus dem Service, zu dem das System gehört. Exemplarisch:

GG-ServerAdmins-SQL -> Variable wäre %ServiceName%=SQL, Gruppe in einer Master-GPO dann GG-ServerAdmins-%ServiceName%. Damit reicht eine GPO für alle. Und weil Namen mir eigentlich wumpe sind - die lauten bei uns natürlich anders, aber das Prinzip ist so umgesetzt. Name des Service = Variable, Name der Gruppe enthält Variable, fertig. Wie die Variable zustandekommt, ist dabei egal. Bei uns kommt sie aus der Parent-OU des Computers, kann aber natürlich auch aus einer CMDB im Deployment gesetzt werden. Was besser wäre - aber siehe oben, man muß mit dem arbeiten, was man hat oder bekommt.

 

Bei den Benutzerrechten machen wir das analog, aber mit zwischengeschalteten computerlokalen Gruppen. Auf jedem (!) Member werden 47 lokale Gruppen für jedes User Privilege angelegt und geleert. Nachrangige GPOs füllen die dann mit Mitgliedern. Funktioniert prima und ist um Größenordnungen einfacher als direkt die User Privileges zu verwenden, die ja bekanntlich nicht kumulativ sind. In der GPO dazu steht dann

"Lokal anmelden zulassen" -> "seInteractiveLogonPrivilege". In der gleichen GPO wird über Preferences seInteractiveLogonPrivilege angelegt und geleert. Und die Gruppe GG-ServerAdmins-%ServiceName% hinzgefügt. Mit Item Level Filtering auf den LDAP-Pfad der Gruppe, die MUSS in der OU sein, in der der Computer ist. Sonst könnte irgendwer irgendwo eine Gruppe anlegen und die hätte dann Rechte - geht gar nicht Ein LDAP-Filter im ILT braucht etwa 2 bis 5 ms, ein Performance Issue ist das IMHO also nicht.

 

Muß man mal durchspielen, klappt aber und ist sehr einfach zu verwalten...

 

PS: Kontenverwaltung im Blue Forest macht das Identity Management. Kontenverwaltung im Red Forest ist manuell, weil wir keine 2 IDM-Instanzen bekommen. Delegation von Userverwaltung im Blue Forest (wenn kein IDM da ist) wäre dann an einen Account im Blue Forest, der da auch Dom-Admin sein kann. Oder halt nur Konten-Administrator. Oder sonst ne delegierte Rolle. Du mußt glaub mal Bilder malen und aufschreiben, was Du genau erreichen willst, dann können wir besser über das "wie" reden.

 

Und wenn Du nur einen Forest hast: T0-Admins sind in den Dom-Admins. T1-Admins siehe oben. Konten-Admins für T0-Accounts können selbst nur T0-Accounts sein. Konten-Admins für T1-Accounts können delegiert werden, T0-Admins können das aber immer auf jeden Fall auch machen, da brauchst keinen 2. Account. Das Kernelement der Tier-Trennung IMHO ist nicht "was darf ich im AD", sondern "wo kann ich mich administrativ anmelden".

[NilsK 2.930]

Moin,

 

vor allem ist das ein Thema, für das man sich Zeit und Ruhe nehmen muss und das man nicht mit ein paar Notizen und Anmerkungen in Foren abhandelt. Auch wenn Admins das ungern hören.

 

Das muss kein monatelanges Schwärzen von Papier in Aktenordnern sein, aber ohne Plan und Sorgfalt kann man es gleich bleiben lassen. Die ganze Idee beruht darauf, von dem hemdsärmeligen Mal-Eben wegzukommen, das insbesondere in Windows-Netzwerken üblich ist.

 

Gruß, Nils

PS. ... und auch wenn man nicht monatelang an Konzepten schreiben muss, dauern Konzeption, Planung und Umsetzung in der Praxis eben durchaus Monate.

[michelo82 12]

Hallo,

und danke für die ausführliche Antwort.

 

Zitat

Was ist für dich "das Domänen-Admin Konto".

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.

[NilsK 2.930]

Moin,

 

Vor allem ist Martins Hinweis relevant, dass "Tier 0" eben die Domänen-Admins sind. Da wird nix delegiert, das ist der Level, der alles kann und darf. Genau deswegen separiert man den ja.

 

Alles andere wird dann delegiert.

 

Bitte beachten: das ist jetzt grob vereinfacht. Ich habe aber bei vielen Kunden festgestellt, dass der Tier 0 tatsächlich die größten Verständnisprobleme hervorruft.

 

Gruß, Nils

[michelo82 12]

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?

[NilsK 2.930]

Moin,

 

Beim Hersteller findest du einiges dazu. Und auch sonst gibt es viel Material. Aber erwarte bitte keine Anleitungen zum direkten Umsetzen.

 

Gruß, Nils

[daabm 1.348]

Für die praktische Umsetzung verkauft MSFT gerne jede Menge Consulting Service Und da gibt es eh kein "Patentrezept"; das MUSS immer im unternehmensintern möglichen Rahmen passieren. Kein AD-Admin hat unbegrenztes Budget... Oder kann mal eben so das gesamte Berechtigungs- und Zutritts-/Zugriffskonzept auf rückwärts bürsten.

 

In o.a. Thread hab ich ja schon ein paar Sachen gepostet. Vielleicht magst den hier auch noch intensiv studieren:

 

PS: Mit dem Builtin Admin haben wir vor 20 Jahren schon nicht gearbeitet - auf die Idee wäre ich jetzt (kein Witz!) echt nicht gekommen.

[v-rtc 88]

Gab es bei MS nicht ein kleines Beispiel Skript?

Dort aber zusätzlich noch viele Infos und Bilder :)