AD-Sicherheit / Auflistung von Usern und Gruppenmitgliedschaften einschränken

[wznutzer 35]

Hallo und guten Tag,

 

es ist gut möglich, dass ich da etwas nicht ganz verstanden habe.

 

Ziel

Normalen Usern soll es nicht erlaubt sein z. B. Mitgliedschaften von privilegierten Konten abzufragen oder Objekte (Benutzer, Computerobjekte) außerhalb ihrer eigenen OU sehen zu können.

 

Was zu tun ist.

1. Man leert die Gruppe Prä-Windows 2000.
2. Man entfernt die Authentifizierten Benutzer vom AdminSDHolder-Objekt oder (besser) ersetzt das durch eine vorerst leere eigene Gruppe. Wenn nötig könnte diese Gruppe dann erweitert werden.
3. Man entfernt auf den entsprechenden OUs ebenfalls die Authentifizierten Benutzer und ersetzt diese durch die Gruppe der berechtigen User.

 

Es scheint zu funktionieren, aber ist es auch gut so?

 

1)

Es gibt noch den Registry Key „List Object“ unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Ist das gesetzt, sollen Objekte nur noch gelistet werden, wenn das Recht vorhanden ist. Ich kann keinen Unterschied feststellen, ob dieser gesetzt ist oder nicht. Es hängt alles am expliziten Recht. Brauche ich das?
 

2)

Muss man die Berechtigungen von OUs wirklich über ldp.exe setzen? Ich habe mal irgendwo gelesen, dass das der beste Weg sein soll. Zum Anschauen ist es jedenfalls besser. Es funktioniert, aber muss es sein?

 

3)

Man kann ja trotzdem noch die Standardgruppen sehen. Ist das ein Problem? Ich will ja nicht verhindern das AD zu sehen, sondern nur evtl. das Auskundschaften erschweren.

 

Grüße und ein schönes Wochenende

 

 

 

 

[testperson 1.728]

Hi,

 

in der Theorie findest du hier (Active Directory: Controlling Object Visibility – List Object Mode | Microsoft Learn) bzw. auch hier (https://www.mcseboard.de/topic/217849-eine-domäne-für-mehrere-mandanten/) ein paar Infos in die Richtung.

 

Wenn du die Berechtigungen der "Authenticated Users" entfernst, könntest du durchaus Probleme bekommen, sofern du die Computerkonten nicht ebenfalls passend berechtigt werden.

 

Das Ziel kommt von der eigentlichen Anforderung eines "mandantenfähigen Active Directory" oder vor dem Hintergrund "Security"?

 

Gruß

Jan

 

[cj_berlin 1.342]

Moin,

 

ad 1. List Object Mode setzt man über dsHeuristics, nicht über die Registry. Wenn man die Sicherheit in seinem AD ernst nimmt, ja, sollte man machen, und man muss auch den Stand erreichen, dass Auth Users aus der PreWin2K raus können.

 

ad 2. Nein, Berechtigungen "muss" man über die Automatisierung setzen. Hat man keine, ist es für DACL egal, für SACL ist LDP.EXE das einzige GUI-Tool, dass das Audit-Recht "Write SACL" offenbart und damit auch setzen lässt. Tatsächlich finde ich persönlich aber die ACL-Anzeige in LDP.EXE besser geeignet als in den MMC-basierten Tools, Hat man kein Bock auf LDP.EXE und keine Automatisierung, empfehle ich stets, ADSIEdit zu nutzen und nicht ADUC, denn auch zwischen den beiden gibt es feine Unterschiede.

 

Shameless Plug: Ich behandle diese Themen in meinem Buch  

 

ad 3. Privilegierte Objekte sollte ein nicht privilegierter User/Computer nicht sehen können. Bei nicht-privilegierten ist es aus Elevation-Sicht tolerierbar, aber je nachdem, was das Ziel des potentiellen Angreifers ist, können z.B. Anwendungsgruppen durchaus wertvoll sein...

[wznutzer 35]

  

vor 36 Minuten schrieb testperson:

Das Ziel kommt von der eigentlichen Anforderung eines "mandantenfähigen Active Directory" oder vor dem Hintergrund "Security"?

Es ist eine Mischung aus beidem.

 

vor 41 Minuten schrieb testperson:

Wenn du die Berechtigungen der "Authenticated Users" entfernst, könntest du durchaus Probleme bekommen, sofern du die Computerkonten nicht ebenfalls passend berechtigt werden.

Meinst Du die Berechtigungen auf AdminSDHolder oder auf einzelnen OUs?

 

vor 26 Minuten schrieb cj_berlin:

List Object Mode setzt man über dsHeuristics, nicht über die Registry.

OK, das muss ich mir dann nochmals anschauen. Ich habe den Registry Key gesetzt und evtl. deswegen keinen Unterschied festgestellt.

 

vor 26 Minuten schrieb cj_berlin:

ad 2. Nein, Berechtigungen "muss" man über die Automatisierung setzen.

Ich bin mir nicht sicher, ob wir unter „Automatisierung“ das gleiche verstehen. Ich habe für meinen Fall ein Powershell-Script um einen User anzulegen. Beim ersten User der Gruppe wird auch die OU angelegt und die Berechtigungen mit dsacls gesetzt. Also schon „automatisch“, aber halt ohne irgendein großartiges System dahinter. Im Prinzip ist es so, dass das Script „nur“ für mich klickt.

 

vor 38 Minuten schrieb cj_berlin:

Shameless Plug: Ich behandle diese Themen in meinem Buch

Wenn Du mir noch sagst, welches Buch, kaufe ich mir das am Ende noch :-).

 

 

[NorbertFe 2.089]

vor 15 Minuten schrieb wznutzer:

Wenn Du mir noch sagst, welches Buch, kaufe ich mir das am Ende noch :-).

 

Schau in seine Signatur. ;)

[wznutzer 35]

vor 56 Minuten schrieb wznutzer:

Beim ersten User der Gruppe wird auch die OU angelegt und die Berechtigungen mit dsacls gesetzt.

Nachtrag: Genau das ist mir noch nicht klar, ob und was ich mit dsacls setzen muss.

[wznutzer 35]

Hallo,

 

ich verstehe den List Mode (dsHeuristics) nicht. Es gibt List Content und List Object. Aber es macht nicht das was es soll bzw. wie es heißt und das noch abhängig, ob es eine Unter-OU gibt. Wenn ich z. B. bei der OU2 (siehe unten) die Berechtigung List Content entferne, wird der Content trotzdem angezeigt. Rot verhält sich irgendwie nicht wie erwartet.

 

Evtl. kann mich jemand in die richtige Richtung schubsen.

[NorbertFe 2.089]

Vielleicht hilft das:

https://www.gruppenrichtlinien.de/artikel/administrative-konten-schuetzen-ad-im-list-object-mode-betreiben

[vkf 0]

gibts das Buch auch auf deutsch?

"Build a “secure by design” AD "? Secure by design oder Secure by configuration?

[wznutzer 35]

Hallo und guten Tag,

 

ich habe mal noch ein wenig rumgespielt um zu verstehen wie das mit dem ListMode funktioniert.

 

ohne ListMode (dsHeuristics)

1)
Man kann auf die Idee kommen, einfach den OUs das Recht "Inhalt auflisten" zu entziehen. Auf den ersten Blick funktioniert das. Man sieht als "normaler" Nutzer z. B. in den RSAT-Tools dann die Benutzer unter der OU ohne "Inhalt auflisten" nicht mehr und auch keine Unter-OUs. Aber Nutzer in Unter-OUs werden in Suchen angezeigt.
OU001 ("Inhalt auflisten" entfernt)
    OU001.01    - nicht sichbar
        Usr002    - z. B. in RSAT-Tools nicht sichbar, aber in Suchen schon.
    Usr001         - nicht sichtbar
    
Das scheint daran zu liegen, dass das AD die Berechtigungen auf eine unerwartete Art auswertet und der Kombination mit vererbten und direkt zugewiesenen Rechten. In diesem Fall ist das Recht "Inhalt auflisten" bei der Unter-OU OU001.01 noch gesetzt und somit kann der User Usr002 gefunden werden.

 

Die Auswertung der Rechte scheint so zu sein:
1. verweigern, direkt zugewiesenen
2. erlaubt, direkt zugewiesenen
3. verweigern, vererbt
4. erlaubt, vererbt

 

Sobald eine Bedingung zutrifft wird nicht weiter ausgewertet. D. h. ein vererbtes verweigern ist schwächer als ein direktes erlauben. Darauf muss man auch erst mal kommen.

 

2)
Weiterer Versuch ohne AD ListMode. Man ersetzt einfach in der entsprechenden OU "Authentifizierte Nutzer" durch eine Gruppe die alle Benutzer- und Computerobjekte der entsprechenden OU enthält. Funktioniert prima, für alle außerhalb der OU sind die Inhalte nicht sichtbar, auch nicht in Suchen. GPOs werden sauber abgearbeitet. Aber je nach Tool mit dem man das AD anschaut, sieht man die oberste OU mit dem tatsächlichen Namen als "unbekannt".

 

mit ListMode (dsHeuristics)

Hier gehen die Infos wild durcheinander und sind teilweise schlicht falsch oder vielleicht auch einfach nur veraltet. Teilweise wird behauptet, dass "Inhalt auflisten" dann nicht mehr gebraucht wird oder auch die Vererbung unterbrochen werden muss. Evtl. waren aber auch die Microsoft-Entwickler bei der Idee betrunken.

 

1)
Ist der ListMode aktiv und es wird bei einer OU das Recht "Inhalt auflisten" entzogen, verhält es sich anders als ohne ListMode. Es werden dann trotzdem noch die Unter-OUs, aber nicht direkt zugeordnete Benutzer-/Computerobjekte angezeigt.

 

2)
Man darf nicht den Fehler machen und den Namen der Rechte versuchen einen Sinn zu geben um das zu verstehen. "Inhalt auflisten" und "Objekt auflisten" stehen in direktem Bezug zueinander:

 

Ein Objekt (OU, Benutzer, Computer usw.) sieht man dann, wenn das zugreifende Objekt (mein Scope) das Recht "Objekt auflisten" auf dem anzusehenden Objekt besitzt und man auf dem Elternobjekt das Recht "Inhalt auflisten" hat. Es gibt also eine strikte Beziehung zwischen Objekt (Objekt auflisten) und Elternobjekt also Parent (Inhalt auflisten).

 

Anhand der obigen Regel lässt sich das ganze Verhalten erklären. Außer es handelt sich um Computerobjekte. Die sieht man auch dann nicht, wenn man auf dem Computerobjekt das Recht "Objekt auflisten" besitzt und man auf dem Elternobjekt das Recht "Inhalt auflisten" nicht hat. Bei Benutzerobjekten hat man das Recht nicht standardmäßig.

 

Wenn man solche Sachen macht, sollte man sich die Verarbeitung der GPOs anschauen. Im meinem Fall funktioniert es wunderbar, wenn man pro Mandant eine Gruppe hat in der alle Benutzer- und Computerobjekte drin sind und diese die entsprechende OU lesen können. Also praktisch eine mandantenspezifische "authentifizierte Benutzer - Gruppe".

 

 

[cj_berlin 1.342]

vor 23 Minuten schrieb wznutzer:

Das scheint daran zu liegen, dass das AD die Berechtigungen auf eine unerwartete Art auswertet und der Kombination mit vererbten und direkt zugewiesenen Rechten. In diesem Fall ist das Recht "Inhalt auflisten" bei der Unter-OU OU001.01 noch gesetzt und somit kann der User Usr002 gefunden werden.

 

Die Auswertung der Rechte scheint so zu sein:
1. verweigern, direkt zugewiesenen
2. erlaubt, direkt zugewiesenen
3. verweigern, vererbt
4. erlaubt, vererbt

 

Sobald eine Bedingung zutrifft wird nicht weiter ausgewertet. D. h. ein vererbtes verweigern ist schwächer als ein direktes erlauben. Darauf muss man auch erst mal kommen.

Daran ist nichts unerwartet, so funktioniert das Sicherheitssystem in Windows, auch beispielsweise bei NTFS, seit es das gibt. Tatsächlich gibt es noch eine weitere Feinheit, denn das gleiche Recht kann auch von mehreren darüberliegenden Ebenen vererbt worden sein, und dann gilt das Obige für jede Ebene  

[wznutzer 35]

vor 17 Minuten schrieb cj_berlin:

Daran ist nichts unerwartet,

Hoppla, dann unerwartet für mich . Aber schön, dass man immer noch dazulernen kann.

[wznutzer 35]

Fall das auch jemand bauen will. Ich habe mich dazu entschieden, die Rechte auf den OUs nicht zu entfernen (authentifizierte Benutzer), sondern stattdessen ein explizites verweigern zu setzen. Der einfache Grund ist, dass beim scripten mit dsacls es nicht möglich ist, einzelne Rechte zu entfernen. Es funktioniert so aber auch prima.

[NorbertFe 2.089]

vor 6 Minuten schrieb wznutzer:

dsacls es nicht möglich ist, einzelne Rechte zu entfernen.

Dafür gibts dsrevoke. ;)

https://www.microsoft.com/en-us/download/details.aspx?id=19288

[wznutzer 35]

vor 30 Minuten schrieb NorbertFe:

Dafür gibts dsrevoke. ;)

Ist es OK das zu verwenden, ist ja schon etwas älter, aus 2003?