Jump to content

AD-Delegation mit BUILTIN Gruppen


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar
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

Link zu diesem Kommentar

: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

Link zu diesem Kommentar
: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

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...