Jump to content

Domänen-Admins lokal löschen (Memberserver/Clients)


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

Empfohlene Beiträge

Am 4.10.2020 um 22:53 schrieb daabm:

Fast :-) Ich hab ein Startskript, das den Namen und den DN der OU in eine Umgebungsvariable schreibt. Kurzname in Deinem Beispiel "WEBSERVICE", DN dann OU=Webservice,OU=irgendwas,DC=contoso.

Die Gruppen in der GPO sind generische definiert als %ServiceOU%-Admins, %ServiceOU%-Users etc. Die Zielgruppenadressierung geht auf nen sAMAccountName %ServiceOU%-Admins mit ner Searchbase von LDAP://%ServiceOUDN%. GPP löst diese Variablen zur Laufzeit auf (was ja in den "alten" Benutzerrechten nicht geht).

 

Die GPO hängt über allen Services. Leg ne neue OU an, steck nen Server rein. Nach dem ersten Reboot sind die Umgebungsvariablen da, nach dem 2. Reboot stimmen die Benutzerrechte.

Der Rest (diese 47 Rechtegruppen) funktioniert nach dem gleichen Schema.

 

Jeder Service hat natürlich auch ne Standardgruppe für Serviceaccounts - Du ahnst es schon, %ServiceOU%-ServiceAccounts. Die stecken in der seServiceLogonRight Gruppe (und in seBatchLogonRight). Das kann man beliebig granular weiter runterbrechen, aber Admins, Users, Serviceaccounts reichte uns.

 

Ich glaub, ich muß da mal ne Blogpost dazu machen :-)

 

Die Gruppen dürfen nur Domain Admins bearbeiten - und der Service Account des IDM, über das man die zugehörigen Rollen beantragt. Da es aber immer nach "Schema F" läuft, ist sogar das relativ easy.

 

PS: Die Gruppennamen bei uns sind anders - wir haben noch ein paar Prä- und Postfixe. Aber für das Prinzip spielt das keine Rolle.

 

So... Antwort hat bissel auf sich warten lassen, weil ich das jetzt mal in einem kleinen LAB nachgestellt hab.

 

Was soll ich sagen?! Einfach nur genial und eigentlich auch genau das was ich gesucht hab, weil übelst granular steuerbar. Eben auch, weil es hier "Dienstüberschneidungen" gibt und man das mit dieser Herangehensweise unglaublich fein berechtigen kann.

Vor allem aber mit nur einer einzigen GPO :shock2:

Als Startup-Script dient jetzt ein kleines Powershellscript. An das bin ich bissel vorschnell ran ohne bedacht zu haben, dass ja nicht jeder Server per se das Powershell-Modul für ADDS installiert hat. Hat aber auch wunderbar mit ADSI umd CIM funktioniert. Das ergänzt eben die notwendigen Umgebungsvariablen über die dann die GPP wirkt.

 

Nochmal ganz herzlichen Dank für diesen grandiosen Input :thumb1:

 

 

 

Link zu diesem Kommentar
vor 8 Stunden schrieb daabm:

Hey, keine Ursache - schön, wenn ich so ein Feedback kriege, danke dafür :thumb1: Und übrigens auch Kompliment, daß Du das mit meinen doch nicht sooo dummy-tauglichen Infos umgesetzt hast. Das ist heutzutage leider selten geworden...

Also offen gestanden empfand ich deine Infos alles andere als dummy-tauglich ;-) Das was Du geschrieben hast feat. dem was man in Deinem Blog dazu findet, sollte eigentlich auch dem größten "Dummy" die nötige Unterstützung geben. Problem heute ist aus meiner Sicht eher, dass die Leute meist fertige Lösungen präsentiert haben wollen und sich Dinge selten selbst erarbeiten.

 

Dennoch, danke für die Blumen :shy:

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...