TheDonMiguel 11 Geschrieben 8. März 2006 Melden Teilen Geschrieben 8. März 2006 Hallo zusammen Wir wollen zukünftig Delegationen einsetzen. Bis dahin sollten aber die Supporter dennoch auf die Server zugreiffen können (lokale Admin) und gewisse Tätigkeiten im DNS/DHCP sowie AD (User MGMT) vornehmen können. Ich bin dann auf die BUILTIN Gruppen gestossen. Würdet ihr dies mit denen realisieren? Ich stelle mir das in etwa so vor, dass es eine "Supporter GG" (Global Group) gibt, welche dann bsp. der "Server Operator" zugewiesen wird. Wird dies funktionieren, oder ist die wirkung, resp der Einsatz dieser Gruppe anderst als vorgestellt? Damit ich dieser "Supporter GG" auch bei den Clients lokale Admin-Rechte geben kann, dachte ich an den einsatz von GPO's und den "restricted groups" Danke vielmals für eure Inputs. Gruss, TDM Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 10. März 2006 Autor Melden Teilen Geschrieben 10. März 2006 Hat jemand vielleicht eine andere Idee, wie man die Delegation einfach und sauber implementieren kann? Danke & Gruss, TDM Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 10. März 2006 Melden Teilen Geschrieben 10. März 2006 Nach der Microsoft'schen Empfehleung, und der vieler Consultants und Admins, empfiehlt sich für Berechtigunsgvergabe, dazu zählt auch so eine OU-Delegierung das AGDLP-Prinzip, also Konten werden gemäß gleichen oder ähnlichen Anforderungen in globale Gruppen gruppiert, Domänenlokale Konten erhalten die benötigten Berechtigugnen auf die Resource, und die Globalen Gruppen werden in der Domänenlokalen Gruppe Mitglied. Das ist wie gesagt eine Empfehlung, technisch funktionieren natürlich auch andere Praktiken wie das AGP- oder ADLP-Prinzip. Wenn es geht, bietet es sich natürlich an, vordefinierte domänenlokale Gruppen für das "DL" in dem AGDL-Prinzip heranzuziehen. Aber nur da wo die vordefinierten Rechte und Berechtigugnen der vordefinierten Gruppe auch Sinn machen. Also, wenn ich allen Leuten aus der Domäne auf einem Computer eingeschränkte Rechtre und Berechtigung geben will, dann bietet es sich an, die lokale Gruppe der Benutzer zu nehmen (im AD ist dies eine domänenlokale Gruppe). Da ist die Globale Gruppe der Domänen-Benutzer Mitglied, somit habe alle User aus der Domäne damit erledigt, ohne eine neue Gruppe erstellen zu müssen. Wenn ich Usern das Recht geben möchte, mit ntbackup.exe einen oder mehrere Rechner zu sichen und auch wiederherzustellen, dann erstelle ich eine Globale Gruppe, packe die Benutzer da rein und mache die globale Gruppe dann zum Mitglied der lokalen Gruppe Sicherungs-Operatoren. Die können das. Du möchtest die verwaltung auf eine oder mehrere OUs delegieren und dazu die Globale Gruppe "Supporter GG" hernehmen und sie in eine Domänenlokale Gruppe stecken. Vom Ansatz her völlig korrekt, aber warum in die Server-Operatoren? Dazu sollte man sich klarmachen, was für Rechte und Berechtigungen haben die Server-Operatoren von Haus aus?! Sie können sich an einem DC lokal anmelden, sie können den DC sichern und wiederherstellen. Sie können auf dem DC Datei- und Druckerfreigaben erstellen. Sie können auf dem DC die Uhrzeit ändern :shock: Frage: sollen das deine delegierten Verwalter alles können? Wenn nein, dann mache dir eine domänenlokale Gruppe, für die OU Verkauf beispielsweise eine Gruoppe names "DL_OUVerkauf_Administration" und gib ihr auf die OU die entsprechenden Berechtigungen. Dann stecke deine "Supporter GG" dort hinein, fertig ist die Delegation :) Damit ich dieser "Supporter GG" auch bei den Clients lokale Admin-Rechte geben kann, dachte ich an den einsatz von GPO's und den "restricted groups" Ja, das ist der schnellste, einfachste und am besten zu verwaltende Weg. grizzly999 Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 12. März 2006 Autor Melden Teilen Geschrieben 12. März 2006 Hallo grizzly999 Danke für dein umfangreiches posting. Das mit dem AGDLP Prinzip habe ich mir auch so vergestellt. Die Support Accounts kommen in die "Supporter GG", welche dann der domain local Group, bsp. "Backup Operator" zugewiesen wird. Habe ich das richtig verstanden, dass ich die Gruppen vom AD, also die BUILTIN's verwenden kann, um den Accounts auch zugriff auch die Member Server zu geben? Damit ich dieser "Supporter GG" auch bei den Clients lokale Admin-Rechte geben kann, dachte ich an den einsatz von GPO's und den "restricted groups" Ja, das ist der schnellste, einfachste und am besten zu verwaltende Weg. Der einfachste Weg, ist nicht immer der beste, resp. der richtige. Wie realisiert man dies richtig? Danke & Gruss, TDM Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 12. März 2006 Melden Teilen Geschrieben 12. März 2006 Hallo grizzly999 Danke für dein umfangreiches posting. Das mit dem AGDLP Prinzip habe ich mir auch so vergestellt. Die Support Accounts kommen in die "Supporter GG", welche dann der domain local Group, bsp. "Backup Operator" zugewiesen wird. ...oder einer sleber erstellten local bzw. Domainlocal group, wenn die vordefinierten meinen Zwecken nicht gerecht werden. Das wäre bei dir der Fall, denn keine der vordefinierten Gruppen ist für diesen zweck gedacht, also selber die DL-Groups erstellen. Habe ich das richtig verstanden, dass ich die Gruppen vom AD, also die BUILTIN's verwenden kann, um den Accounts auch zugriff auch die Member Server zu geben? Das ist ist nicht korrekt. Diese können nur und ausschließlich auf DCs verwendet werden. Selber-erstellte(!) Domain Local Groups können ebenfalls nur auf DCs, und nicht in der gesamten Domäne, verwendet werden, wenn Die Domäne in den Domänenfunktionslevlen "2003 Interim" oder "2000 gemischt" läauft. In den beiden höheren Leveln "2000 pur" und "2003 Server" können selber-erstellte(!) Domain Local Groups auf allen Mitgliedern der Domäne verwendet werden. [Q7uote] Der einfachste Weg, ist nicht immer der beste, resp. der richtige. Wie realisiert man dies richtig? Sorry, das kam wohl dann nicht so rüber wie ich wollte. Den einfachsten und besten Weg, die von dir vorgeschlagene Verwendung von Restricted-Groups-GPOs, den wollte ich bejahen, sprich sagen: Mach's so ;) grizzly999 Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 12. März 2006 Autor Melden Teilen Geschrieben 12. März 2006 :shock: OK, deswegen klappte das nicht... Also das heisst, am besten eigene Gruppen nach dem AGDLP Prinzip anlegen und auf diesen Gruppen die Berechtigungen selber definieren. Ich würde dies nun etwa so machen: "Supporter GG" > "Supporter LG" 1. AD Management: AD Delegation Wizard 2. DNS / DHCP: Bestehende Gruppen (DNSAdmins, DHCP Admin) 3. Server local Admin: GPO, restricted groups 4. Client local Admin: GPO, restricted groups Ist das so richtig? Oder schlägst du etwas anderes (besseres, einfacheres) vor? Danke vielmals!!!! :D Gruss, TDM Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 12. März 2006 Melden Teilen Geschrieben 12. März 2006 :shock: OK, deswegen klappte das nicht... Also das heisst, am besten eigene Gruppen nach dem AGDLP Prinzip anlegen und auf diesen Gruppen die Berechtigungen selber definieren. Ich würde dies nun etwa so machen: "Supporter GG" > "Supporter LG" 1. AD Management: AD Delegation Wizard 2. DNS / DHCP: Bestehende Gruppen (DNSAdmins, DHCP Admin) 3. Server local Admin: GPO, restricted groups 4. Client local Admin: GPO, restricted groups Ist das so richtig? Oder schlägst du etwas anderes (besseres, einfacheres) vor? Ja, so ist das richtig. Die Namensgebung sollte halt entsprechend sein, wenn man unterschieldiche DLs für unterschiedliche Berechtigungen nehmen will, z.B. DL-OUVerkauf-Administration und DL-OULager-Administration. Aber ansonsten :jau: grizzly999 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.