Per LDAP User auf Admin Gruppen untersuchen

[BS_Chris 10]

Hallo Leute,

 

wir müssen ein monatliches Audit vorlegen, ob AD User Mitglied gewisser und administrativer Gruppen sind.

 

Schön wäre, wenn man auch noch die Domain-Computer überprüfen könnte.

 

Kann man sowas per VB etc lösen, kann man sich da wo einlesen.

 

 

mfg

chris

[NilsK 2.930]

Moin,

 

im Wesentlichen müsst ihr ja nur die betreffenden Gruppen mit ihren Mitgliedslisten exportieren:

 

faq-o-matic.net Wie kann ich die Mitglieder einer Gruppe in eine Datei schreiben?

 

(csvde eignet sich eigentlich nicht, weil das nur kleine Gruppen ausgibt. Am besten wäre wohl "dsget group" mit "expand".)

 

Für lokale Gruppen hab ich mal was gebaut:

 

Falsche Admins entlarven | it-administrator.de

http://www.it-administrator.de/magazin/download/ita0706-AdminInventar.zip

 

Gruß, Nils

[P.Foeckeler 11]

Halli Hallo,

 

eine kleine Idee am Rande, die ganz gut zu Deinem Anliegen passt. Probier mal den LDAP-Filter hier aus:

 

DSQUERY * dc=domaene,dc=de –filter "(adminCount=1)"

 

Damit kriegst du alle Objekte, für die das System die AdminSDHolder-Berechtigungen erzwingt. Das sind im Prinzip alle hoch privilegierten Gruppen

 

Account Operators

Administrators

Backup Operators

Domain Admins

Domain Controllers

Enterprise Admins

Print Operators

Read-only Domain Controllers

Schema Admins

Server Operators

 

und alle Objekte (User, Computer, Gruppen), die dort Mitglied sind, entweder direkt oder über verschachtelte Mitgliedschaften. Das sind doch dann genau die, die Du suchst, oder?

 

Gruss,

Philipp

[NilsK 2.930]

Moin,

 

hm, hübsch! Dann biete ich mal folgende Variation:

 

Die äquivalente Abfrage in SQL-Syntax lautet

SELECT * FROM 'LDAP://DC=domain,DC=tld' WHERE adminCount=1

 

Wenn man das über Carmen abfragt, bekommt man das gleich als speicherbare HTML-Tabelle (z.B. um sie in Excel weiterzubearbeiten).

 

faq-o-matic.net Carmen: Mit SQL das AD abfragen

 

Die Abfrage kann man auch noch um weitere Felder erweitern, z.B. anstelle des * "name,memberOf", was gleich noch die Gruppenmitgliedschaften der Objekte ausgibt.

 

EDIT: Mir fällt gerade ein Nachteil dieser Methode auf. Das Attribut adminCount behält den Wert 1, wenn ein User wieder aus einer überwachten Gruppe entfernt wird. Man erhält also nicht nur die aktuellen Mitglieder, sondern auch ehemalige.

 

Gruß, Nils

bearbeitet 13. April 2010 von NilsK
Hab grad was gesehen ...

[P.Foeckeler 11]

Oouch! Stimmt, adminCount wird nicht zurückgesetzt, auch nach dem Entfernen aus den Gruppen. Na da hilft nur das Durchforsten der hochprivilegierten Gruppen nach direkten und indirekten Mitgliedern mit diesem Monster-Filter:

 

DSQUERY * dc=domain,dc=tld –filter "(|(memberOf:1.2.840.113556.1.4.1941:=CN=Domain Admins,CN=Users,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Administrators,CN=Builtin,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Account Operators,CN=Builtin,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Backup Operators,CN=Builtin,DC=domain,DC=tld))"

 

wuuaaaaaa :)

[blub 115]

für ein richtiges Audit ist das so m.E. gar nicht lösbar, da nur man nur eine Augenblicksaufnahme zur Laufzeit des Skripts bekommt.

Wir benutzen für diese Anforderung Intrust von Quest Security Event Log Management für Windows, Unix & Linux - InTrust von Quest Software , da siehst du u.a., wer und wann einen User in eine privilegierte Gruppe gesteckt hat.

Scripting ist geil, aber hat auch seine Grenzen :)

 

cu

blub

[NilsK 2.930]

Moin,

 

für ein richtiges Audit ist das so m.E. gar nicht lösbar

 

das kann man so allgemein nicht sagen, weil der Auditor die Regeln vorgibt und es dafür in den meisten Bereichen keine definierten Standards gibt.

 

Der Hinweis ist trotzdem berechtigt.

 

Gruß, Nils

[olc 18]

Hi,

 

mal abgesehen von den reinen Audit-Fragen: Ich denke, daß - wenn Du diese LDAP-Filter Abfrage mit "memberOf" durchführst - die primary groups nicht beachtet werden. Das könnte wieder zum Problem werden.

 

Die Geschichte mit dem AdminCount könnte man umgehen, indem man diesen vorher wieder auf "0" setzt und etwas abwartet (1h + Replikationslatenz).

 

Ansonsten würde ich es für einen groben Überblick einfach mit den von Nils genannten Methoden versuchen - was natürlich nicht heißt, daß die Methode von Philipp nicht auch interessant wäre. ;)

 

Viele Grüße

olc

[P.Foeckeler 11]

Ich noch mal, ich lass nicht locker ;)

 

olc hat mal wieder Recht, ich habe die Sache mit der Primary Group verschlafen. Also hier nur noch mal der Vollständigkeit halber der vollständige LDAP Filter, der auch die primäre Gruppenmitgliedschaft in Domain Admins (RID 512) und Enterprise Admins (RID 519) auffängt (die dom-lokalen BuiltIn-Gruppen können keine Primary Gruppen für einen User sein):

 

 

DSQUERY * dc=domain,dc=tld –filter "(|(memberOf:1.2.840.113556.1.4.1941:=CN=Domain Admins,CN=Users,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Enterprise Admins,CN=Users,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Administrators,CN=Builtin,DC=domain,DC= tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Account Operators,CN=Builtin,DC=domain,DC=tld)(memberOf:1.2.840.113556.1.4.1941:=CN=Backup Operators,CN=Builtin,DC=domain,DC=tld)(primaryGroupID=512)(primaryGroupID=519))"

 

Schöne Grüße,

Philipp

[olc 18]

Hi Philipp,

 

gut, daß Du nicht locker läßt. ;) :)

 

Obwohl man dann aufpassen muß, den richtigen DN zu wählen: Wenn Du die Abfarge in einer Child-Domäne ausführst, müßten alle Global- und Domain Local-Groups mit dem DN der Child angegeben werden, die Enterprise Admins (Universal-Group) jedoch mit DN der Root.

 

Aber gut, das wird jetzt zuviel des guten (Herumnörgelns). :p

 

Viele Grüße

olc