3
Dom Admins die Rechte per GPO entziehen sich zu Org Enterpriseadmins hochzustufen
Hallo,
Meine Frage ist, wie kann man am elegansten und schnellsten folgendes per GPO umzusetzten:
- Domains Admins die Rechte entziehen sich zu einem Orgadmin/Enterprise Admin hochzustufen?
Meine Frage ist, wie kann man am elegansten und schnellsten folgendes per GPO umzusetzten:
- Domains Admins die Rechte entziehen sich zu einem Orgadmin/Enterprise Admin hochzustufen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 304615
Url: https://administrator.de/contentid/304615
Ausgedruckt am: 24.11.2024 um 09:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo vinevg,
ich würde dir dringend Raten folgende Seite "sehr aufmerksam" durchzulesen
https://msdn.microsoft.com/en-us/library/cc875827.aspx
denn "mal schnell" machen führt hier meistens zu unausgereiften Konzepten in der Absicherung von administrativen Gruppen und Accounts einer AD Domäne.
Normalerweise erstellt man sich wie im Link beschrieben eine Administrative OU in der sämtliche Konten die für die Administration der Domäne hinein gepackt werden.
Dann unterbricht man die Vererbung und vergibt spezielle Rechte die dann auch nicht mehr von oben geerbt werden.
Will man dann z.B. das bestimmte Accounts oder Gruppen die Mitgliedschaft der Enterprise-Admins Gruppe ändern können vergibt man das entsprechende Recht auf den Container.
Die Mitgliedschaft in der Domain-Admins-Gruppe sollte aber aus einem ganz bestimmten Grund nur absolut vertrauenswürdigen Personen genehmigt werden (meist reichen 1-2 Accounts auch in größeren Firmen), denn diese Gruppe befindet sich in der lokalen "Administrators"-Gruppe die alle Gruppen und Accounts der Domäne bearbeiten dürfen.
Man sollte also immer benutzerdefinierte administrative Gruppen anlegen, die nur die expliziten Rechte bekommen die sie wirklich benötigen. Dazu müssen und sollten sie niemals in der Domain-Admins Gruppe Mitglied sein !! Das ist der größte Fehler den die meisten Leute bei der Admin-Delegation begehen!
Deswegen immer nur so wenig Rechte wie möglich, und so viel wie nötig.
"Principle of least Privilege!"
Ein simpler Workstation Admin braucht z.B. keine Domain-Admin rechte wie so viele immer glauben, das ist Quark denn dazu reicht ein simpler User der Mitglied der lokalen Administratoren auf den Clients ist.
Man könnte zwar jetzt auf die ACLs der Enterprise Admins Gruppe eine Deny-Rule zum Ändern dieser für die Domain-Admins setzen, aber das ist sehr unsauber hier mit Deny-Rules zu arbeiten und man sollte das definitiv vermeiden. Denn wenn man den Container nicht entsprechend absichert könnten sich die Domain-Admins diese Rechte wieder selber geben.
Also, lieber ruhig und besonnen ein für eure Firma passendes Konzept nach den oben verlinkten Basiseinstellungen ausarbeiten, dann ausgiebig testen und erst dann umsetzen!
Grüße und frohe Pfingsten
Uwe
ich würde dir dringend Raten folgende Seite "sehr aufmerksam" durchzulesen
https://msdn.microsoft.com/en-us/library/cc875827.aspx
denn "mal schnell" machen führt hier meistens zu unausgereiften Konzepten in der Absicherung von administrativen Gruppen und Accounts einer AD Domäne.
Normalerweise erstellt man sich wie im Link beschrieben eine Administrative OU in der sämtliche Konten die für die Administration der Domäne hinein gepackt werden.
Dann unterbricht man die Vererbung und vergibt spezielle Rechte die dann auch nicht mehr von oben geerbt werden.
Will man dann z.B. das bestimmte Accounts oder Gruppen die Mitgliedschaft der Enterprise-Admins Gruppe ändern können vergibt man das entsprechende Recht auf den Container.
Die Mitgliedschaft in der Domain-Admins-Gruppe sollte aber aus einem ganz bestimmten Grund nur absolut vertrauenswürdigen Personen genehmigt werden (meist reichen 1-2 Accounts auch in größeren Firmen), denn diese Gruppe befindet sich in der lokalen "Administrators"-Gruppe die alle Gruppen und Accounts der Domäne bearbeiten dürfen.
Man sollte also immer benutzerdefinierte administrative Gruppen anlegen, die nur die expliziten Rechte bekommen die sie wirklich benötigen. Dazu müssen und sollten sie niemals in der Domain-Admins Gruppe Mitglied sein !! Das ist der größte Fehler den die meisten Leute bei der Admin-Delegation begehen!
Deswegen immer nur so wenig Rechte wie möglich, und so viel wie nötig.
"Principle of least Privilege!"
Ein simpler Workstation Admin braucht z.B. keine Domain-Admin rechte wie so viele immer glauben, das ist Quark denn dazu reicht ein simpler User der Mitglied der lokalen Administratoren auf den Clients ist.
Man könnte zwar jetzt auf die ACLs der Enterprise Admins Gruppe eine Deny-Rule zum Ändern dieser für die Domain-Admins setzen, aber das ist sehr unsauber hier mit Deny-Rules zu arbeiten und man sollte das definitiv vermeiden. Denn wenn man den Container nicht entsprechend absichert könnten sich die Domain-Admins diese Rechte wieder selber geben.
Also, lieber ruhig und besonnen ein für eure Firma passendes Konzept nach den oben verlinkten Basiseinstellungen ausarbeiten, dann ausgiebig testen und erst dann umsetzen!
Grüße und frohe Pfingsten
Uwe
Hi,
dem was @colinardo schreibt, kann man eigentlich nichts mehr hinzufügen, außer vielleicht, dass es in der Root Domain überhaupt nicht möglich ist, den Domain Admins irgendwie dauerhaft das Recht zu entziehen, sich jederzeit wieder direkt oder indirekt zum Mitglied der Enterprise Admins zu machen. Für bestimmte Gruppen und deren Mitglieder sind Schutzmechanismen eingebaut, die deren Berechtigungen regelmäßig wieder auf Default stellen. Für die Gruppe der BuiltIn-Administratoren bedeutet das z.B., dass die Domain Admins das Recht haben, sich selbst dieser Gruppe hinzuzufügen. Und die BuiltIn-Admins der Root Domain dürfen dann wieder die Enterprise Admins bearbeiten. Die Domain Admins anderer Domains des Forest haben kein Recht, sich den Enterprise Admins hinzuzufügen, es sei denn, die sind (abweichend vom Standard) gleichzeitig Mitglied der BuiltIn-Administratoren der Root Domain.
Die Enterprise Admins sind auch so eine Gruppe. Man kann deren ACL zwar ändern, aber die Domain Controller der Root Domain werden diese immer wieder auf Default zurückstellen.
E.
dem was @colinardo schreibt, kann man eigentlich nichts mehr hinzufügen, außer vielleicht, dass es in der Root Domain überhaupt nicht möglich ist, den Domain Admins irgendwie dauerhaft das Recht zu entziehen, sich jederzeit wieder direkt oder indirekt zum Mitglied der Enterprise Admins zu machen. Für bestimmte Gruppen und deren Mitglieder sind Schutzmechanismen eingebaut, die deren Berechtigungen regelmäßig wieder auf Default stellen. Für die Gruppe der BuiltIn-Administratoren bedeutet das z.B., dass die Domain Admins das Recht haben, sich selbst dieser Gruppe hinzuzufügen. Und die BuiltIn-Admins der Root Domain dürfen dann wieder die Enterprise Admins bearbeiten. Die Domain Admins anderer Domains des Forest haben kein Recht, sich den Enterprise Admins hinzuzufügen, es sei denn, die sind (abweichend vom Standard) gleichzeitig Mitglied der BuiltIn-Administratoren der Root Domain.
Die Enterprise Admins sind auch so eine Gruppe. Man kann deren ACL zwar ändern, aber die Domain Controller der Root Domain werden diese immer wieder auf Default zurückstellen.
E.
Für bestimmte Gruppen und deren Mitglieder sind Schutzmechanismen eingebaut, die deren Berechtigungen regelmäßig wieder auf Default stellen.
Genau, für den TO dann vielleicht noch interessant wie dieser Mechanissmus heißt und er was zum Googlen hat: AdminSDHolderhttp://www.msxfaq.de/konzepte/adminsdholder.htm
Das ist auch der Grund warum viele oft erstaunt sind wenn sie einem Account, der in diesen administrativen Gruppen nur einmal oder immer noch Mitglied war/ist plötzlich die extra vergebenen Rechte verliert.
Ein typisches Beispiel: Man vergibt einem User dessen LDAP Eigenschaft bereits auf AdminCount = 1 gesetzt ist SendAs Rechte auf eine Mailbox ... Stunden später bekommt der User dann beim Senden "Keine Berechtigung". => AdminSDHolder hat zugeschlagen
