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

[PrometricDriver 2]

Guten Morgen Board,

 

ich bin gerade dabei einen Schlachtplan zu entwickeln uns weitestgehend gegen Privileged Escalation zu schützen.

Eigentlich ist mein Plan schon recht weit vorangeschritten und sieht so aus, GPO-gesteuert

auf allen Servern/Clients die UserRightsAssignments und lokalen User granular zu steuern.

 

Ein Step dieser GPO soll sein, die lokale Gruppe der Administratoren erstmal zu löschen und anschließend mit dem (erforderlichen) lokalen Administrator

und die für den Server/die Servergruppe notewendigen Server-Admins/administrativen Konten zu befüllen ohne die Domänen-Admins nochmal zu adden...

 

Nun bin ich beim Durchforsten der Microsoft-Empfehlungen auf folgenden Passus gestossen der mich hinsichtlich meinem Vorhaben bissel nachdenklich stimmt:

Zitat

Domain Admins are, by default, members of the local Administrators groups on all member servers and workstations in their respective domains. This default nesting should not be modified because it affects supportability and disaster recovery options. If Domain Admins groups have been removed from the local Administrators groups on the member servers, they should be added to the Administrators group on each member server and workstation in the domain via restricted group settings in linked GPOs.

Quelle: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models

 

Finde die Begründung erstmal bissel oberflächlich, möchte auch deshalb mal in die Runde fragen, wie Ihr das so macht und ob ich da tatsächlich ggfs. irgendwas nicht beachte.

Sehe nämlich aktuell keinen wirklichen Grund die Domain-Admins nochmal zu adden und über Deny-Regeln zu arbeiten...

 

Wäre über jeglichen Input dankbar!

 

 

[NorbertFe 2.061]

vor 26 Minuten schrieb PrometricDriver:

Finde die Begründung erstmal bissel oberflächlich, möchte auch deshalb mal in die Runde fragen, wie Ihr das so macht und ob ich da tatsächlich ggfs. irgendwas nicht beachte.

Domänen-Admins haben keine Rechte zu auf nicht DCs zu haben. Das ist schon lange ein schlechtes Design. Es gibt auch keine Probleme, wenn man entsprechende Vorsorge trifft, dass man eben auf diese Systeme mit anderen Admins (notfalls sogar mit dem lokalen) rankommt. 

[NilsK 2.957]

Moin,

 

du hast allerdings auch den wesentlichen Teil der Argumentation in dem Artikel ausgelassen:

Zitat

As is the case with the Enterprise Admins group, membership in Domain Admins groups should be required only in build or disaster-recovery scenarios. There should be no day-to-day user accounts in the DA group with the exception of the local Administrator account for the domain, if it has been secured as described in ...

Wenn man das dazunimmt, ergibt es plötzlich Sinn: Sorgt dafür, dass die DA-Gruppe im Normalbetrieb leer ist. Dann stellt sie kein dauerhaftes Risiko dar.

 

Das kann man natürlich immer noch anders sehen - ich bin da Anhänger der Technik, die DA-Gruppe aus den lokalen Admins zu entfernen und zielgerichtet neue Admingruppen einzurichten, die nur in dem jeweiligen Tier/Containment berechtigt sind. Aber grundsätzlich verkehrt ist der andere Ansatz auch nicht.

 

Gruß, Nils

 

[testperson 1.707]

Hi,

 

bevor du das Rad völlig neu erfindest bzw. für weiteren, guten Input zum Thema: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html

(Den Link hätte der Autor des Artikels dir bestimmt heute Abend auch selber an die Hand gegeben ;))

 

Gruß

Jan

[daabm 1.366]

Ja, hätte er :-))

 

Und er kann noch ergänzen, daß das auch in einem Enterprise-Umfeld prima funktioniert. Bissele nachdenken, passende Variablen deployen (bzw. durch Startskripts erzeugen lassen) und die ganzen lokalen Admin- und Rechtegruppen füllen sich magisch wie von selbst.

[PrometricDriver 2]

vor 15 Stunden schrieb daabm:

Ja, hätte er :-))

 

Und er kann noch ergänzen, daß das auch in einem Enterprise-Umfeld prima funktioniert. Bissele nachdenken, passende Variablen deployen (bzw. durch Startskripts erzeugen lassen) und die ganzen lokalen Admin- und Rechtegruppen füllen sich magisch wie von selbst.

 

Gut zu wissen weil mir bei Recherchen hier im Forum eben genau dieser Link schon öfters untergekommen ist und ich das in etwas abgewandelter Form jetzt in einem Lab implementiert hab

und das eigentlich soweit richtig gut funktioniert.

Wird halt ein richtiges Stück Arbeit, weil die Umgebung in die ich reingeraten bin zwar weiß, dass es AD gibt aber von der Umsetzung noch das Meiste nach alter NT4-Manier handhabt...

 

Keine Delegation, keine managed Service-Accounts, kein Splittung von privilegierten Konten und ich weiß nicht wie viele User-Accounts mit AdminCount 1 und bspw. Helpdeskmitarbeiter in BUILTIN/Kontenoperatoren nur um hier und da mal ein Passwort zu resetten...

 

Fürchte, die schmeißen mich spätestens dann raus, wenn ich denen allen eine PAW unterjubeln werde 

 

Für Eure Antworten herzlichen Dank.

 

[NilsK 2.957]

Moin,

 

vor 10 Minuten schrieb PrometricDriver:

eine PAW

oha, du hast dir ja was vorgenommen. 

Aber finde ich gut. (Ernst gemeint.)

 

Gruß, Nils

 

[MurdocX 953]

vor 2 Stunden schrieb PrometricDriver:

Fürchte, die schmeißen mich spätestens dann raus, wenn ich denen allen eine PAW unterjubeln werde 

Veränderungen sind b***d, denn man hat’s ja schon immer anderst gemacht. 

 

Viel erreichen kannst du mit dem AppLocker und der Tier-Trennung. Wobei bei Letzterem schon viel mit verschieben Admin-Accounts auf Dom, Server und Clients getan ist. Der Weg ist der Richtige 

[SandyB 9]

@Pro: Meintest du "Privilege Escalation" oder "Lateral Movement". 

https://attack.mitre.org/

 

bearbeitet 3. Oktober 2020 von SandyB

[PrometricDriver 2]

vor 1 Stunde schrieb MurdocX:

Veränderungen sind b***d, denn man hat’s ja schon immer anderst gemacht. 

 

Viel erreichen kannst du mit dem AppLocker und der Tier-Trennung. Wobei bei Letzterem schon viel mit verschieben Admin-Accounts auf Dom, Server und Clients getan ist. Der Weg ist der Richtige 

 

Tier-Trennung definitiv... muss halt nur schauen ob ich das vollumfänglich auch budgetmäßig verkaufen kann.  Applocker soll für den Anfang auch her halten, in Ausbaustufe ggfs. dann WDAC.

 

Ich stoße leider schon mit der Konzepterstellung auf reichlich Gegenwehr bei den Kollegen, die halt seit Jahrzehnten Day-2-Day als DA unterwegs sind  Aber ich beiß mich da durch und hab glücklicher Weise die notwendige Rückendeckung von weiter oben weil halt auch klar ist, dass das aktuell grob fahrlässig zu werten ist  

 

[MurdocX 953]

vor 9 Minuten schrieb PrometricDriver:

Ich stoße leider schon mit der Konzepterstellung auf reichlich Gegenwehr bei den Kollegen, die halt seit Jahrzehnten Day-2-Day als DA unterwegs sind

Aus Erfahrung ist es gut eine Kollegen auch gedanklich „mitzunehmen“. Es können sich Kollegen schnell „überfahren“ fühlen. Vielleicht mal in einer ruhigen Minute die Vorteile erklären und aufzeigen, dass es mit Emotet und Co kaum andere Mittel gibt.

[daabm 1.366]

vor 10 Stunden schrieb PrometricDriver:

Gut zu wissen weil mir bei Recherchen hier im Forum eben genau dieser Link schon öfters untergekommen ist und ich das in etwas abgewandelter Form jetzt in einem Lab implementiert hab

und das eigentlich soweit richtig gut funktioniert.

Der Link läuft vermutlich ziemlich vielen über den Weg - nur verstehen leider auch ziemlich viele nicht, was darin für Möglichkeiten liegen, diese lästige Delegation von Admin-Rechten zu vereinfachen. Aber wie schon mehrfach geschrieben wurde: Gut, daß wieder einer anfängt, den alten Kram aufzuräumen

 

BTW: Wir haben im aktuellen Neu-Design nur noch eine Policy, die Admin- und User-Rechte auf allen (!) Member-Servern regelt. Alle Server eines "Service" liegen in einer OU. Für diese OU wird eine Umgebungsvariable gebildet (Startskript). Und diese Variable ist auch Bestandteil der Namen der delegierten Admin- und Usergruppen. Neuer Service? Kein Problem - OU anlegen, Maschine reindeployen. Gruppen anlegen, fertig. GPO ist schon da... Und natürlich hat diese GPO für alle delegierten Gruppen eine Zielgruppenadressierung - die Gruppe MUSS sich in der OU befinden, in der auch der Server ist (LDAP-Filter - braucht keine 5 ms). Sonst könnte ja wer irgendwo anders eine entsprechende Gruppe anlegen.

[PrometricDriver 2]

vor 14 Stunden schrieb daabm:

Der Link läuft vermutlich ziemlich vielen über den Weg - nur verstehen leider auch ziemlich viele nicht, was darin für Möglichkeiten liegen, diese lästige Delegation von Admin-Rechten zu vereinfachen. Aber wie schon mehrfach geschrieben wurde: Gut, daß wieder einer anfängt, den alten Kram aufzuräumen

 

BTW: Wir haben im aktuellen Neu-Design nur noch eine Policy, die Admin- und User-Rechte auf allen (!) Member-Servern regelt. Alle Server eines "Service" liegen in einer OU. Für diese OU wird eine Umgebungsvariable gebildet (Startskript). Und diese Variable ist auch Bestandteil der Namen der delegierten Admin- und Usergruppen. Neuer Service? Kein Problem - OU anlegen, Maschine reindeployen. Gruppen anlegen, fertig. GPO ist schon da... Und natürlich hat diese GPO für alle delegierten Gruppen eine Zielgruppenadressierung - die Gruppe MUSS sich in der OU befinden, in der auch der Server ist (LDAP-Filter - braucht keine 5 ms). Sonst könnte ja wer irgendwo anders eine entsprechende Gruppe anlegen.

 

Zum Verständnis und mitschreiben... Du beschreibst im o.g. Link unten bei den Kommentaren, dass du pro lokales User-Right lokal eine Gruppe auf den Member-Servern anlegst.

Sprich SeNetworkLogonRight, SeInteractiveLogonRight etc. (insgesamt 47 UserRights) als lokale Gruppe in der GPO.

 

Du gruppierst die entsprechenden Maschinen nach angebotenem "Service", bspw. hast Du eine Webapplikation bestehend aus einem Webserver und einem Datenbankserver die beide in diese

OU wandern. Die OU nennt sich exemplarisch "WEBSERVICE" und beim Booten der Maschine nach dem Deployment innerhalb der OU greift EINE GPO die einerseits ein Startup-Script ausführt, welches Umgebungsvariablen anlegt (LDAP-Path = ServiceName, LDAP-Folder = LDAP-Pfad zum Service und dessen Objekten). 

Du legst innerhalb dieser Service-OU globale Gruppen an die in etwa so lauten... GG_WEBSERVICE_SERVERADMINS, GG_WEBSERVICE_RDP, GG_WEBSERVICE_SERVICEACCOUNTS...

 

Beim Befüllen der lokalen Gruppen auf den Servern löschst Du bspw. die lokalen Administratoren, nimmst in einem zweiten Schritt den lokalen Admin und zusätzlich eine Gruppe "GG_%OUFOLDER%_SERVERADMINS " mit einer Zielgruppenadressierung die auf den LDAP-Pfad und den Gruppennamen zeigt (also in etwa LDAP://%OUPATH%/GG_%OUFOLDER%_SERVERADMINS)?!

 

Und im GPO-Template steht beim "Zuweisen von Benutzerrechten" zusätzlich bei bspw. "Anmelden als Dienst" dann bspw. seServiceLogonRight um der gleichnamigen lokalen Gruppe dann das Recht zu geben, als Dienst starten zu dürfen? Bei der Verlinkung im GPMC überschreibt dann diese GPO die UserRights von ggfs. verlinkten Baseline-GPOs, die Emfehlungen von Microsoft wer welche Rechte bekommen sollte übernimmst Du in diese Master-GPO (mir fällt kein besserer Begriff dafür ein)

 

Wenn ja frage ich mich zweierlei...

 

Du schreibst oben EINE GPO, die Du ja an irgendeiner "BASE" verlinken musst. Deine Service-OUs wären ja dann Sub-OUs und erben diese eine GPO. (oder verlinkst du die pro Sub-OU?!)

Angenommen Du benötigst jetzt einen gMSA den Du nur auf den beiden Maschinen innerhalb von "WEBSERVICE" installierst... Wie bildest Du sowas ab? Neue GPO mit Abweichungen von der Regel, welche nur an der Service-OU verlinkt wird oder innerhalb der Master-GPO mit Zielgruppenadressierung?

 

und... Wie handhabt ihr das dann mit der Delegation. Wer darf die Gruppen in der Ziel-OU bearbeiten und mit Usern füllen? 

 

Also wenn ich das alles richtig verstanden hab, dann wäre das ja übelst fein steuerbar 

 

bearbeitet 4. Oktober 2020 von PrometricDriver

[daabm 1.366]

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.

[NorbertFe 2.061]

vor 37 Minuten schrieb daabm:

Prä- und Postfixe

Mußte jetzt grad nachschauen und lernen, dass man tatsächlich lt. Wikipedia auch Postfixe sagen kann statt Suffixe. :)