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

[daabm 1.366]

Merke - nicht jedes Postfix ist ein Mailer

[NorbertFe 2.061]

Oder gelb. ;) achnee das is ja ein postit;)

[PrometricDriver 2]

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

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

 

 

 

[daabm 1.366]

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

[PrometricDriver 2]

vor 8 Stunden schrieb daabm:

Hey, keine Ursache - schön, wenn ich so ein Feedback kriege, danke dafür 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