Frage, Admin Tiering und Delegierungen

[Anubis2k 14]

Hallo zusammen und guten Morgen

 

Ich hätte da mal eine Frage, seit ein paar Monaten bin ich dabei unsere AD (wir haben nur eine Domäne) neu zu strukturieren und Admin Tiering durchzuführen.

 

Der Grundgedanke ist wie folgt, der Generalschlüssel soll nicht mehr so "inflationär" verteilt sein. Dass heißt, der Domänen Administrator (User: Administrator) ist bei uns aktiv und wurde leider historisch gerne mal verwendet. Dieser bekommt (wie fast immer erwähnt) ein neues Kennwort und das Kennwort wird dann irgendwo aufbewahrt.

 

Angefangen habe ich dann mit einer neuen OU auf oberster Ebene, wo ich dann die Tier User und Tier Gruppen verstaut habe. Anschließend folgte ähnlich wie vom damaligen Small Business Server, eine OU wo wir die Struktur neu aufgebaut haben. Somit ist die oberste (erste) Ebene der AD wieder relativ "clean", wie eine Domäne aussieht wenn sie frisch aufgesetzt wurde.

domain.local
- Builtin
- Computers
- Domain Controllers
- Users
- Administration (für Tiering)
- FirmaXY (neue OU)
-- Computer Quarantäne
-- Geschäftsleitung
-- Personal
-- Server
-- Verwaltung
-- Zentrale

 

In der OU "Administration" habe ich dann eine OU für die Benutzerkonten angelegt und eine für Tier Gruppen, die ungefähr so aufgeteilt sind, 

- Tier0Admin (Mitglied der Gruppe Domänen-Admins)

- Tier1Admin (Administratoren für Server)

- Tier2Admin (Administratoren für Clients)

 

Wir haben ein IT Infrastruktur Team, diese Personen haben einen normalen User (bob) und dann ihre Tier User (bob0, bob1, bob2).

 

Da wir aber auch Leute im First-Level Bereich haben, die Benutzer (und Computer) in der Domäne anlegen, deren Berechtigungen steuern oder verschieben sollen, habe ich die Tiering Gruppen um eine weitere Gruppe (Tier1AD) erweitert.

 

Somit haben unsere User im First Level Bereich drei Konten (klaus, klaus1, klaus2), wobei hier deren Tier1 User primär für ein "Run As" der MMC verwendet wird um in der AD etwas zu verändern.

 

Mein Gedanke war somit relativ simple, innerhalb der OU "FirmaXY" sind OUs wie "Geschäftsleitung" oder "Personal" wo nur die Leute der Infrastruktur dran dürfen, aber die First Level Leute sollen halt an die OU "Zentrale", "Verwaltung" oder "Computer Quarantäne" dran, wo sich die Computerkonten, Benutzerkonten oder Sicherheitsgruppen befinden können.

 

Durch "Delegieren" hat das nicht so geklappt wie gewünscht, denn die Berechtigung wirkt sich nur auf die OU aber nicht auf die Objekte darin aus. Ich habe es dann versucht über "Rechtsklick", Eigenschaften -> Sicherheit anzupassen, habe dann die "Tier1AD" Sicherheitsgruppe hinzugefügt, aber auch hier scheint sich die Berechtigung nicht rekursiv nach unten auf die Objekte auszuwirken.

 

Gibt es dafür eventuell einen PowerShell Befehl womit ich sagen kann, dass die Sicherheitseinstellung übernommen werden soll, oder habt ihr da einen anderen Tipp für mich wie man das lösen kann?

 

Für die GPO möchten wir etwas ähnliches machen, da wir von der Infrastruktur, so wenig wie möglich mit dem Tier0 arbeiten möchten und unseren Tier1 ebenfalls delegieren wollen :)

 

Als ich die Suche angeschmissen und andere Threads hier aus dem Forum gefunden habe, wollte ich nicht wieder in den Themen nachfragen, habe aber auch gesehen dass Microsoft und Drittanbieter für so etwas wohl auch Programme hätten. Wie handhabt ihr das denn bei euch, habt ihr das auch delegiert oder mit weiterer Software gelöst?

 

Ich hoffe ich konnte diverse Fragen schon im Vorfeld auflösen und wollte mich nicht so lang fassen.

 

Gruß, Dominik

 

p.s. Einen Grundstein für das Projekt haben wir auch schon mit einem externen Dienstleister begonnen, genauso wie die Einführung von LAPS, aber bei der Umsetzung für die erwähnte Delegierung, gab es mehrere Möglichkeiten, wobei eine Variante bevorzugt darauf gezielt war, eine Software zu kaufen. Daher wollte ich auch noch mal horchen was ihr so für Ideen und Ansätze habt.

[cj_berlin 1.306]

Moin,

wenn Du eine Berechtigung im AD vergibst, kannst Du immer einen Scope für die Berechtigung angeben, zum Beispiel "alle Computer-Objekte in dieser OU" oder "diese OU, Unterstruktur und Objekte darin".

Es gibt keinen PowerShell-Befehl, der "von alleine alles richtig macht", denn "richtig" ist von Organisation zu Organisation unterschiedlich. Das Zoning per PowerShell zu machen, hat trotzdem den großen Vorteil, dass es a. wiederholbar und b. quasi automatisch dokumentiert ist.

[Anubis2k 14]

Moin und vielen Dank, ich gucke noch mal nach ob ich den Scope vielleicht falsch gesetzt habe, war aber der Meinung dass ich den entsprechend gesetzt hatte als ich den Punkt sah. Ich packe noch mal eben meine Struktur aus,

domain.local
- [...]
- FirmaXY (neue OU)
-- Computer Quarantäne
-- Geschäftsleitung
-- Personal
-- Server
-- Verwaltung
-- Zentrale
--- Computer
--- Benutzer
--- Gruppen

 

Und auf die OU "Zentrale" hatte ich "diese OU, Unterstruktur und Objekte" ausgewählt, was dann auch auf Computer, Benutzer und Gruppen angewandt war, aber die darin befindlichen Objekte nicht. Das prüfe ich aber noch mal

 

Bezüglich PowerShell und einem "richtigen" Befehl stimme ich dir da vollkommen zu, dass ist ja auch abhängig von der Situation und dem Unternehmen etc., daher schmunzle ich gerne, wenn mir andere IT'ler sagen "Best Practice", auch dieses Wort ist eine Auslegungssache (finde ich). Aber zurück zum Thema, ich prüfe es noch einmal und gebe Feedback.

 

Nachtrag: Ich habe einmal die Berechtigungen für die OU "Deaktivierte Benutzer" nachgeschaut. Eigentlich ist alles korrekt hinterlegt. Gehe ich nun also mit meinem Test-User der delegiert wurde zu einem Benutzerkonto, kann ich z.B. die E-Mail Adresse nicht abändern. Das ist für mich der erste Indikator, dass ich an dem Benutzerkonto nicht alles ändern kann.

bearbeitet 2. November 2022 von Anubis2k
Screenshot beigefügt

[daabm 1.348]

Ich werf mal den AdminSDHolder in den Raum, hast Du das mal kontrolliert? Oder ist bei Deinen User-Objekte die Vererbung evtl. aus "anderen Gründen" deaktiviert?

[Anubis2k 14]

Moin, damit konnte ich zwar noch nichts anfangen, aber wenn ich diesen Artikel richtig verstehe, hängt das auch ein wenig mit "Protected" Benutzern, Gruppen, Konten etc. zusammen. Und hier muss ich sagen, es waren (warum auch immer) sehr sehr viele Benutzerkonten, Sicherheitsgruppen etc. mit dem "Protected" Flag versehen.

 

Ich musste mir dann echt ein PowerShell Skript suchen und zurecht schneiden mit "Get-ADobjects", welches mir erst alle User (Benutzerkonten) und dann alle Sicherheitsgruppen auflistet und dort den Protected entfernt, denn bei dem Beginn meiner Umstrukturierung war gefühlt jedes zweite Benutzerkonto oder jede zweite Benutzergruppe geschützt.

 

Hier vermute ich, dass dies der eine oder andere Admin (meine Vorgänger) gemacht haben und einfach guten glaubens waren, dass das gut ist. Ich selbst hab ja auch die Benutzerkonten von Geschäftsleiter und Prokuristen ebenfalls wieder guten Glaubens, protected. Aber dann stelle ich das mal um :)

 

Kann man eigentlich die Gruppen und Benutzer im Reiter "Sicherheit" von der AD selbst auch auf einen "Ursprung" zurücksetzen?

 

Ich hatte nämlich unserer "Tier1Admin" Gruppe schon mal versucht auf oberster Ebene Vollzugriff gewähren und auch dieses klappte ja nicht (vermutlich wegen "AdminSDholder") und vielleicht kann man die Berechtigungen sowie Delegierungen auf eine Art "Basis" zurücksetzen.

 

Morgen schaue ich mir das mit dem AdminSDholder aber mal genauer an und gebe ein Feedback und bedanke mich schon mal im Vorfeld für den Tipp!

[daabm 1.348]

vor 19 Minuten schrieb Anubis2k:

 

Kann man eigentlich die Gruppen und Benutzer im Reiter "Sicherheit" von der AD selbst auch auf einen "Ursprung" zurücksetzen?

 

Nein. Wenn die Vererbung deaktiviert ist, kommst Du "von oben" nicht mehr durch, Du mußt die "leafs" anfassen.

[Anubis2k 14]

vor 15 Stunden schrieb daabm:

Wenn die Vererbung deaktiviert ist, kommst Du "von oben" nicht mehr durch

So hatte ich das allerdings nicht gemeint. Ich wollte erst die Vererbungen korrigieren und dann die Berechtigungen gerade ziehen :)

 

Dass anhand der deaktivierten Vererbung mein Vorhaben nicht geklappt hätte, war mir schon bewusst.

 

Hab heute übrigens mal geschaut, es scheint AdminSDHolder zu sein, was hier zwischen schlägt. Da diverse Benutzerkonten oder auch die Sicherheitsgruppen wo einer der Benutzer drin war "geschützt" waren, wird auch die Vererbung deaktiviert.

 

Mit diesem Befehl hab ich erst einmal das "Protected" für alle Benutzer und Gruppen deaktiviert, die OUs selbst sind unangetastet...

Get-ADObject -Filter {(objectClass -eq "user") -or (objectClass -eq "group")} -SearchBase $OU | Set-ADObject -ProtectedFromAccidentalDeletion:$false -PassThru

 

Und mit dem folgenden Skript (welches ich auch nur gefunden habe, Quelle), hab ich die Vererbungen wieder aktiviert...

# Some Varibales
[bool]$isProtected = $false
[bool]$PreserveInheritance = $true
# Get Users
$Users = Get-ADObject -Filter {(objectClass -eq "user") -and (objectCategory -eq "user")} -SearchBase $OU
# Do the Magic
if($Users -ne $null) {
  foreach($Entry in $Users) {
    [string]$dn = (Get-ADUser $Entry).DistinguishedName
    $user = [ADSI]”LDAP://$dn”
    $acl = $user.objectSecurity
    Write-Host “Set Permissions for User:”(Get-ADUser $Entry).SamAccountName
    if($acl.AreAccessRulesProtected) {
      $acl.SetAccessRuleProtection($isProtected,$PreserveInheritance)
      $inherited = $acl.AreAccessRulesProtected
      $user.commitchanges()
    }
  }
}
else {Write-Host “No User found”}

 

Allerdings muss ich jetzt noch sicherstellen, dass AdminSDHolder nicht wieder bei einigen die Einträge rückgängig macht. Wenn ich mich jetzt nicht irre, stand nämlich auf einer der diversen Seiten, wenn ein User einmal "protected" war, wird das vermerkt und AdminSDHolder stellt den User dennoch wieder um.

[NilsK 2.930]

Moin,

 

mach sowas NIE, NIE, NIE über das GUI. Es gibt seit -zig Jahren eine skriptfähige Lösung, die zwar nicht schön ist, aber das Nötige steuerbar - und vor allem wiederholbar - macht: dsacls. Such dir dann ein Tool dazu, mit dem du die AD-Berechtigungen anzeigen kannst, z.B. LIZA:

[LIZA - Active Directory Security, Permission and ACL Analysis]
https://www.ldapexplorer.com/en/liza.htm

Zwei Beispielseiten zu dsacls:

[AD-Adressen im Sekretariat bearbeiten lassen | faq-o-matic.net]
https://www.faq-o-matic.net/2008/06/23/ad-adressen-im-sekretariat-bearbeiten-lassen/

 

[dsacls-Ergebnis im Skript effizient prüfen | faq-o-matic.net]
https://www.faq-o-matic.net/2010/05/25/dsacls-ergebnis-im-skript-effizient-prfen/

 

Außerdem würde ich die Objektstruktur noch mal überdenken - da ist zu sehr das Organigramm im Vordergrund, wie mir scheint.

Gedanken dazu:

[Active Directory: Best Practice zur OU-Struktur | faq-o-matic.net]
https://www.faq-o-matic.net/2020/11/16/active-directory-best-practice-zur-ou-struktur/

 

Und: Aus deinen Ausführungen höre ich heraus, dass dort noch zu wenig Analyse und Planung drinsteckt, um wirklich mit der Umsetzung zu beginnen. Das ist aber wesentlich. Ich habe gerade erst ein Security-Audit hinter mir, wo der Kunde dachte, er hätte ein tolles Tiering, aber in Wirklichkeit war das so weit von den echten Anforderungen entfernt, dass die Domäne in weniger als 30 Minuten hätte übernommen werden können.

 

Gruß, Nils

 

[Anubis2k 14]

Hallo Nils,

 

vielen Dank für das Feedback. Ich muss sagen, den einen oder anderen Link kannte ich sogar schon. Gerade den mit der OU Struktur, da ich selbst noch keine gute Idee für eine Struktur hatte. Wir hatten dann den Dienstleister gefragt der uns dabei begleitet hat und da kamen dann Aussagen wie "ja, dass könnte man so machen" oder "es gibt auch die Option XY", und am Ende sind wir noch zu keiner passenden Lösung gekommen.

 

Der Gedanke unserer OU Struktur ist leicht am Unternehmen angeknüpft, dass liegt aber daran dass wir den Baum kleiner haben wollten (er war vorher viel unübersichtlicher und größer), dazu wollten wir dann noch eine Möglichkeit haben unsere First Level Leute relativ einfach delegieren zu können und dann kam noch der Gedanke, wie verfahren wir mit GPO... viele OUs wenig Sicherheitsgruppen, wenig OUs und mehr Sicherheitsgruppen.

 

Wir hatten vorher sogar OUs für Marketing, Einkauf und diverse andere Bereiche, diese sind gebündelt in der Zentrale gelandet. Genauso wie ich alle Benutzer innerhalb der Zentrale in eine OU gepackt habe, dass gleiche mit Computerkonten und Sicherheitsgruppen. Hab da ein Beispiel gefunden, mit meinem Kollegen haben wir das erste Testweise aufgebaut, im Team besprochen und man fand die Idee gut uns übersichtlich.

 

Thema Tiering, hab ich mich hieran und anderen Beispielen orientiert, mit dem Dienstleister durch geschaut, dann die entsprechenden GPOs gebaut und auch da meinte er dann "sieht gut aus!", zumal diese Basis jetzt gerade Mitte Oktober an alle anderen Kollegen durch gereicht und Dokumentiert wurde.

 

Das alles war jetzt auch kein zwei Monats Ding, Anfangen hatte das alles ende Januar und fertiggestellt, Anfang Oktober und dann an alle anderen aus der IT mitgeteilt.

 

Wenn das natürlich jetzt alles für den Hintern war, ist dass das klassische Beispiel, wieso ich seit Jahren gerne an die Decke gehe, wenn jemand in einem Forum um Hilfe bittet und man immer wieder auf Systemhäuser verweist. Hier wäre dann nämlich der Fall "hätte man sich mal mit mehreren ausgetauscht", auch wenn viele Köche den Brei verderben ;)

 

Lange Rede (war nicht meine Absicht), aber die Tipps sind schon mal gut, ich gehe das mit dem "dsacls" mal durch und versuche das in einer Test OU so hin zu biegen wie wir es gerne hätten (oder ungefähr).

 

vor 2 Stunden schrieb NilsK:

mach sowas NIE, NIE, NIE über das GUI.

Frage hierzu, generell keine GUI verwenden, oder am besten die Windows GUI weg lassen? Sonst wäre hier die Frage, gibt es eine Software (GUI) die man empfehlen könnte? :)

 

Gruß, Dominik

 

p.s. Vielleicht kommt jetzt eine böse Aussage, aber als Linux Admin, finde ich einige Dinge ohne GUI auch interessanter. Hab mal bemerkt, dass solche Dinge gut und gerne viele Dinge drum herum machen, die NICHT gemacht werden sollten.

 

Nachtrag: LIZA schaue ich mir gleich mal genauer an (wollte ich eben noch schreiben), dann sehe ich ja welcher User nicht mehr wo etwas tun darf in der AD. Gibt es eventuell auch ein GUI gesteuertes Tool, womit ich mir für "dsacls" die Attribute zusammenbauen kann?

bearbeitet 3. November 2022 von Anubis2k

[NilsK 2.930]

Moin,

 

Mach es nie mit dem Windows-GUI, weil das Schrott ist. Mach sowas nur per Skript, dann ist es wiederholbar (erst Labor, dann Produktion) und das Skript ist die Dokumentation.

 

Gruß, Nils

[Anubis2k 14]

Alles klar, vielen Dank.

 

An sich finde ich es über ein Skript auch gar nicht schlecht. Man hat (wie ihr ja schon gesagt habt) eine Doku und man kann selbst hinein schreiben was der User (oder die Gruppe) darf und was nicht. Auf der einen Seite von faq-o-matic waren sogar die LDAP Felder mit bei, so könnte man sich zumindest schon mal was zusammen bauen.

 

Spannend wäre jetzt nur ein Tool gewesen womit man eventuell sagen kann "ich brauche Schreibrechte für XY" und der nennt einem die Parameter die man anschließend in das Skript rein schreibt. Aber anhand diverser Seiten etc., scheine ich so langsam voran zu kommen und versuche gerade die Berechtigungen gerade zu ziehen.

 

Da AdminSDHolder auch Nested Groups berücksichtigt, gucke ich gerade wo noch ein adminCount gesetzt ist, wo noch "Protect" drin sein könnte damit ich dann in Ruhe die Delegierungen durchführen kann

 

Nachtrag: Ich bin nicht immer der schnellste (Legasthenie, Verständnis etc.) aber ich hab (denke ich) dass gefunden und geschafft was ich wollte. Mit drei PowerShell Skripten habe ich mich durch gekämpft. Ich habe als erstes bei allen Sicherheitsgruppen und Benutzerkonten den "adminCount" gelöscht. Danach habe ich noch einmal mit einem weiteren Skript "ProtectedFromAccidentalDeletion" deaktiviert und zum Schluss mit dem dritten Skript die Vererbung wiederhergestellt.

 

Jetzt zum Schluss hab ich mir zwei Batch Skripte gebaut, einmal remove ich mittels "dsacls" die Berechtigungen und dann setze ich sie neu mittels "/I:S /G", wobei ich trotz Anleitung noch leichte Verständnis und Logik Probleme habe, aber dass ist cool und tut was ich möchte :)

 

Soll ich meine drei kleinen PowerShell Skripte hier mal Posten?? Interessiert vielleicht auch andere...

bearbeitet 3. November 2022 von Anubis2k

[Damian 1.526]

Hi

 

vor 3 Stunden schrieb Anubis2k:

Soll ich meine drei kleinen PowerShell Skripte hier mal Posten?? Interessiert vielleicht auch andere...

Ja, gerne.

 

Aber bitte auf die eventuell nötige Anonymisierung achten.

 

VG

Damian

[Anubis2k 14]

Wie bereits beschrieben, habe ich zuerst "adminCount" weg gemacht...

$OU = "DC=xxxx,DC=local"
Get-ADObject -Filter {admincount -eq 1} -Properties samaccountname,admincount -SearchBase $OU | Set-ADObject -clear admincount -PassThru

 

Man kann mit "Get-ADUser" arbeiten, aber ich arbeite auch gerne mit "Get-ADObject" und filtere was ich suche und gebe gerne auch eine "SearchBase" mit an, so kann ich das genauer eingrenzen wo ich mein Skript ausführen möchte.

 

Als nächstes dann ich ja dann das "protected" mit folgendem Skript weg gemacht...

$OU = "DC=xxxx,DC=local"
Get-ADObject -Filter {(objectClass -eq "user") -or (objectClass -eq "group")} -SearchBase $OU | Set-ADObject -ProtectedFromAccidentalDeletion:$false -PassThru

 

Anhand der "objectClass" hab ich sowohl Benutzerkonten, Computerkonten und Sicherheitsgruppen erwischt. Die OUs hab ich hierbei unberührt gelassen!

 

Zum Schluss dann noch mit einem gefundenen und minimal angepassten Skript die Vererbung wieder herstellen...

# Set Organization Unit
$OU = "DC=xxxx,DC=local"

# Some Varibales
[bool]$isProtected = $false
[bool]$PreserveInheritance = $true

# Get Users or something
$Users = Get-ADObject -Filter {(objectClass -eq "user") -and (objectCategory -eq "user")} -SearchBase $OU

# Do the Magic
if($Users -ne $null) {
  foreach($Entry in $Users) {
    [string]$dn = (Get-ADUser $Entry).DistinguishedName
    $user = [ADSI]”LDAP://$dn”
    $acl = $user.objectSecurity
    Write-Host “Set Permissions for User:”(Get-ADUser $Entry).SamAccountName
    if($acl.AreAccessRulesProtected) {
      $acl.SetAccessRuleProtection($isProtected,$PreserveInheritance)
      $inherited = $acl.AreAccessRulesProtected
      $user.commitchanges()
    }
  }
}
else {Write-Host “No User found”}

 

Wie erwähnt, anschießend habe ich dann mit "dsacls" erst einmal die Delegierungen die via GUI erstellt wurden entfernt und anschließend mit "dsacls" dann die OUs einzeln gewählt und die Berechtigungen hinterlegt. Die "Permissionen" sind eventuell für die Erfahreneren hier sehr simple und einfach, ich muss da erst noch durchsteigen, aber eigentlich sind unsere Anforderungen jetzt nicht BSI mäßig angesiedelt.

 

Gruß, Dominik