Wenn ein Administrator ein Objekt im AD löscht, sollte er das bewusst tun und ein versehentliches löschen sollte nie vorkommen. Jedoch passieren die meisten Missgeschicke gerade im Alltag versehentlich, obwohl die Microsoft Werkzeuge (z.B. die MMCs Active Directory-Benutzer und -Computer sowie Active Directory-Standorte und -Dienste, dsrm, AD-PowerShell etc.) eine Sicherheitsabfrage stellen, ob man das Objekt auch wirklich löschen möchte. Handelt es sich bei dem zu löschenden Objekt um eine OU in dem weitere Objekte enthalten sind (Benutzer, Gruppen, OUs etc.), wird sogar noch eine weitere Sicherheitsabfrage gestellt.
Ein Objekt vor dem versehentlichen Löschen schützen
Damit ein Objekt nicht ausversehen gelöscht werden kann, sollte man ab Windows Server 2008 von der Option Objekt vor zufälligem Löschen schützen (auf Englisch: Protect object from accidental deletion) regen Gebrauch machen. Es ist empfehlenswert diesen Schutz mindestens auf OU-Ebene anzuwenden, sie vererbt sich aber nicht auf die untergeordneten Objekte wie z.B. auf untergeordnete OUs oder auf Benutzer-, Gruppen oder Computerobjekte die sich innerhalb der OU befinden. Einzelne Objekte wie Benutzerobjekte, Sicherheits- sowie Verteilergruppen- und Computerobjekte lassen sich ebenfalls vor dem versehentlichen Löschen schützen. Auch die Objekte in der MMC Active Directory-Standorte und -Dienste (AD-Standorte, Subnetze) lassen sich vor dem versehentlichen Löschen schützen.
Die Option Objekt vor zufälligem Löschen schützen lässt sich in den Eigenschaften eines Objekts im Reiter „Objekt“ aktivieren. Dieser Reiter kommt aber in der MMC „Active Directory-Benutzer und -Computer“ erst dann zum Vorschein, wenn unter „Ansicht“ die Option „Erweiterte Features“ aktiviert wurde.
Unter Windows 2000 und Windows Server 2003 existiert zwar die Möglichkeit zum aktivieren der Option „Objekt vor zufälligem Löschen schützen“ nicht, doch man kann natürlich auch unter Windows 2000 und Windows Server 2003 ein Objekt vor dem versehentlichen löschen schützen. Denn das aktivieren der Option „Objekt vor zufälligem Löschen schützen“ bewirkt nichts anderes, als das im Security-Descriptor des Objekts das "Verweigerungsrecht" zum "Löschen" für "Jeder" gesetzt wird. Genau das kann man auch unter Windows 2000 und Windows Server 2003 z.B. auf einer OU oder einem Benutzerobjekt konfigurieren.
Mit DSACLS, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich eine OU folgendermaßen vor dem versehentlichen Löschen schützen:
Dsacls „<DN der OU>“ /D Jeder:SDDT
In der Kommandozeile (CMD) lässt sich mit einer FOR-Schleife und den ds*-Tools die ab Windows Server 2003 "on Bord" sind, eine OU samt den untergeordneten OUs vor dem versehentlichen Löschen wie folgt schützen. Die Objekte wie z.B. Benutzer-, Gruppen- oder Computerobjekte die sich innerhalb dieser OUs befinden, werden dabei aber nicht vor dem versehentlichen Löschen geschützt:
FOR /F "tokens=*" %i in ('Dsquery OU "<DN der OU>" -Limit 0') do Dsacls %i /D "Jeder:SDDCDT"
Alle OUs innerhalb einer Domäne lassen sich in einer CMD mit dieser FOR-Schleife vor dem versehentlichen Löschen schützen:
FOR /F "tokens=*" %i in ('Dsquery OU -Limit 0') do Dsacls %i /D "Jeder:SDDCDT"
Über die AD-Powershell lässt sich diese Option auf einer OU wie folgt aktivieren:
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentalDeletion 1
bzw.
Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentalDeletion $true
Auf allen bestehenden OUs lässt sich die Option wie folgt aktivieren:
Get-ADOrganizationalUnit -Filter * | Set-ADOrganizationalUnit –ProtectedFromAccidentalDeletion 1
Deaktivieren lässt sich die Option „Objekt vor zufälligem Löschen schützen“ in der AD-PowerShell wie folgt:
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentalDeletion 0
oder
Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentalDeletion $false
Wird eine bestehende Domäne auf mindestens „Windows Server 2008“ aktualisiert, wird bei bestehenden Objekten diese Option nicht automatisch aktiviert. Auch nach dem installieren einer neuen Windows Server 2008 Domäne ist auf den bestehenden Objekten die Option „Objekt vor zufälligem Löschen schützen“ nicht aktiv. Der Schutz ist standardmäßig nur beim erstellen von neuen OUs ab Windows Server 2008 aktiviert, nicht jedoch beim erstellen von Benutzer-, Gruppen- oder Computerkonten bzw. AD-Standorten und Subnetzen.
Ist hingegen dieser Schutz auf einer OU aktiviert und man möchte diese OU verschieben, erhält man folgende Fehlermeldung. Denn zum Verschieben einer OU benötigt man das Löschrecht am Quell- und Schreibrecht am Zielort. Das Verschieben der OU ist erst dann möglich, wenn die Option deaktiviert wurde.
Das gilt natürlich auch beim löschen einer OU. Erst wenn die Option deaktiviert ist, kann die OU nach bestätigen der Sicherheitsabfrage gelöscht werden. Spätestens mit dieser Option gehört das versehentliche Löschen eines Objekts endlich der Vergangenheit an.
Wer hat den Benutzer gelöscht?
Wenn nun doch mal ausversehen z.B. das Benutzerobjekt des GFs gelöscht wurde, möchte man evtl. aufklären wer das Benutzerobjekt auf welchem DC gelöscht hat. Im Sicherheitsprotokoll des DCs auf dem das Objekt gelöscht wurde, wird unter Windows Server 2003 die EventID 630 und unter Windows Server 2008 sowie Windows Server 2008 R2 die EventID 4726 protokolliert. Denn standardmäßig wird unter Windows Server 2003 und Windows Server 2008 R2 beim Löschen eines Benutzerkontos ein Eventlogeintrag generiert, nicht jedoch unter Windows Server 2008.
Unter Windows Server 2008 muss zuerst die Unterkategorie Verzeichnisdienständerungen mit der Option Erfolgreich durch den folgenden Befehl aktiviert werden:
Auditpol /set /subcategory:Verzeichnisdienständerungen /success:enable
Erst danach wird das Löschen eines Objekts auch unter Windows Server 2008 protokolliert.
Active Directory Domain Services (AD DS) - Protokollierung
Achtung: Eine Protokollierung ist vom Betriebsrat bzw. Datenschutzbeauftragten zu genehmigen!
Die Information auf welchem DC das Objekt gelöscht wurde, wird aber nicht zwischen den DCs repliziert. Die Aufgabe besteht also darin, herauszufinden wann das Benutzerkonto auf welchem DC gelöscht wurde, um anschließend den Eventlogeintrag ausfindig zu machen. Sofern der Eventlogeintrag natürlich noch auf dem betroffenen DC existiert und nicht überschrieben wurde.
Auch das Löschen von Gruppen wird standardmäßig mit folgenden EventIDs protokolliert:
Unter Windows Server 2003
- Domänenlokale Sicherheitsgruppe = EventID 638
- Globale Sicherheitsgruppe = EventID 634
- Universelle Sicherheitsgruppe = EventID 662
- Domänenlokale Verteilergruppe = EventID 652
- Globale Verteilergruppe = EventID 657
- Universelle Verteilergruppe = EventID 667
Unter Windows Server 2008 und Windows Server 2008 R2
- Domänenlokale Sicherheitsgruppe = EventID 4734
- Globale Sicherheitsgruppe = EventID 4730
- Universelle Sicherheitsgruppe = EventID 4758
In kleineren AD-Umgebungen lassen sich die Eventlogs auf den DCs vielleicht noch schnell und vor allem manuell durchforsten, doch in großen bzw. weltweiten AD-Umgebungen ist das schier eine unmögliche Aufgabe. Zumindest nicht ohne Zusatzwerkzeuge wie z.B. SCOM, Log Parser oder EventComb.
Doch es gibt auch eine einfache Methode, um den Übeltäter ausfindig zu machen. Mit Hilfe von LDP und REPADMIN kann man in Erfahrung bringen, auf welchem DC das Objekt wann zu welcher Uhrzeit gelöscht wurde. Anschließend öffnet man das Sicherheitsprotokoll des betroffenen DCs und kann anschließend in der Beschreibung des Eventlogeintrags erkennen, wer das Objekt gelöscht hat. Es spielt auch keine Rolle ob unter Windows Server 2008 R2 der AD-Papierkorb aktiviert ist oder nicht.
Dazu sind die folgenden Schritte notwendig.
In LDP
Mit LDP gilt es zuerst herauszufinden, wie der Distinguished Name (DN) des gelöschten Objekts im Deleted Objects Container das sich in der Domänenpartition befindet lautet.
- Im ersten Schritt verbindet man sich mit einem DC aus der Domäne, in der das Objekt gelöscht wurde. Unter Windows 2000 und Windows Server 2003 wählt man im Menü „Connection – Connect…“ und unter Windows Server 2008 sowie Windows Sever 2008 R2 „Remotedesktopverbindung – Verbinden…“ und gibt den DC an, mit dem man sich verbinden möchte.
- Im zweiten Schritt binded man sich mit dem AD. Unter Windows 2000 und Windows Server 2003 wählt man dazu im Menü „Connection – Bind“ und unter Windows Server 2008 und Windows Server 2008 R2 „Remotedesktopverbindung – Gebunden…“.
- Danach wählt man im Menü unter Windows 2000 und Windows Server 2003 „Options – Controls“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Optionen – Steuerelemente“. Im darauf erscheinenden Fenster „Controls“ bzw. „Steuerelemente” fügt man das LDAP-Control „Return deleted objects“ mit der OID (Object Identifier) 1.2.840.113556.1.4.417 hinzu.
-
Als nächstes ruft man unter Windows 2000 und Windows Server 2003 im Menü „Browse - Search“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Durchsuchen - Suchen“ das Suchfenster auf. Dort gibt man als Basis-DN den „Deleted Objects“ Container in der Domänenpartition an. Dieser lautet: CN=Deleted Objects,DC=<Domäne>,DC=<de>
Im Feld Filter gibt man die Kriterien an, nach denen man die Suche im Container “Deleted Objects” durchführen möchte. Ist der Benutzeranmeldename (Prä-Windows 2000), also das Attribut sAMAccountName bekannt, trägt man in dem Feld sAMAccountName=<Benutzeranmeldename> ein. Es kann natürlich auch ein anderes Attribut angegeben werden, dass das gewünschte Benutzerobjekt identifiziert.
Als Scope/Bereich wählt man OneLevel/Eine Ebene aus. Wählt man als Suchbereich Subtree/Unterstruktur aus, funktioniert das ebenfalls. Unter Windows Server 2008 und Windows Server 2008 R2 gibt man im Feld „Attribute“ die Attribute an, die in der rechten Hälfte von LDP, im Suchergebnis zusätzlich zum DN angezeigt werden sollen. Gibt man keine Attribute an, werden alle Attribute des gelöschten Objekts angezeigt.
- Anschließend ruft man mit einem Klick auf Optionen die Suchoptionen auf und konfiguriert die Einstellungen wie folgt. Mit einem Klick auf OK übernimmt man die vorgenommenen Einstellungen.
- Unter Windows 2000 und Windows Server 2003 muss man vorher auf Options klicken, um die gewünschten Attribute und die weiteren Einstellungen vornehmen zu können.
-
Führt man die Suche nun mit einem Klick auf Run/Ausführen aus, erscheint in der rechten Hälfte von LDP unter anderem der gesuchte DN des gelöschten Benutzerobjekts. Dieser sieht z.B. so aus: Dn: CN=Yusuf Dikmenoglu\0ADEL:3e9e243e-8ba9-473a-a1ee-f1b001337923,CN=Deleted Objects,DC=ad2008R2,DC=dikmenoglu,DC=de
In REPADMIN
Da nun bekannt ist wie der DN des gelöschten Benutzerobjekts lautet, gilt es auf einem DC in der Domäne in der das Benutzerobjekt gelöscht wurde, den folgenden REPADMIN-Befehl in der Kommandozeile auszuführen. Die Ausgabe von REPADMIN wird zur besseren Übersicht in eine Textdatei exportiert.
Repadmin /showobjmeta <DC> "CN=Yusuf Dikmenoglu\0ADEL:2ffa7423-7b00-4962-96f6-69d052e08c51,CN=Deleted Objects,DC=ad2008r2,DC=dikmenoglu,DC=de" > C:\Repadmin.txt
Entscheidend in der Ausgabe ist das Attribut isDeleted.
Daraus kann man erkennen, dass das Benutzerobjekt am 14.11.2009 um 23:05:08 Uhr auf dem DC R2DCON01 gelöscht wurde. Nun kann man hoffen, dass auf dem DC der erwähnte Zeitpunkt im Sicherheitsprotokoll noch nicht überschrieben wurde. Wenn der Eintrag noch existiert, findet man in der Beschreibung des Eventlogeintrags den Übeltäter.
Weitere Informationen:
Der Container Deleted Objects
Repadmin /showobjmeta
In einigen Attributen wie z.B. badPasswordTime, Last-Logon, Last-Logon-TimeStamp oder pwdLastSet wird ein Large Integer Wert (im Integer8 Format) gespeichert. Da man mit solch einem Wert herzlich wenig anfangen kann, muss dieser in unser Zeitformat umgerechnet werden. Das geht mit den Windows Support Tools oder mit Bordmitteln wie folgt.
LDP
In LDP das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, werden Large Integer Werte bereits in unserem Zeitformat angezeigt, ohne diese umrechnen zu müssen.
REPADMIN
Eine weitere Möglichkeit einen Large Integer Wert umzurechnen, ist das Schweizer Messer Werkzeug für die AD-Replikation REPADMIN. Unter Windows 2000 und Windows Server 2003 befindet sich REPADMIN in den Windows Support Tools und ist ab Windows Server 2008 bereits „on Bord“. Bei dem REPADMIN-Befehl müssen jedoch die letzten sieben Zeichen des Integer Wert entfernt werden. Der Befehl lautet wie folgt: REPADMIN /SHOWTIME 12903275725
NLTEST
Auch mit NLTEST, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich ein Large Integer Wert umrechnen. Doch dazu muss zuerst der Large Integer Wert im Taschenrechner von Windows („Start-Programme-Zubehör-Rechner“ oder „Start-Ausführen-CALC“) in einen Hexadezimal Wert umgerechnet werden. Um das zu tun, wechselt man die Ansicht des Taschenrechners unter dem Menüpunkt „Ansicht“ von „Standard“ auf „Wissenschaftlich“. Anschließend fügt man per Copy&Paste den Integer Wert hinzu. Man muss nur darauf achten, dass der Wert als „Dezimal“ (Dez) hinzugefügt wird.
Anschließend wandelt man den eingetragenen Wert mit einem Klick auf Hex in einen Hexadezimal Wert um.
Nun gibt man in einer Kommandozeile den Befehl NLTEST /TIME:<HEX> ein. Bei dem Hexadezimal Wert gilt es zu beachten, mit einem Leerzeichen dazwischen, die rechten acht Zeichen voranzustellen. Der Befehl sieht dann so aus: NLTEST /TIME:EC821F4A 1CA6A9B
W32tm
In der Kommandozeile (CMD) lässt sich ein Large Integer Wert, ab Windows Server 2003, mit dem Befehl w32tm /ntte <Wert> in ein lesbares Format umrechnen.
Der Attribut-Editor
Ab Windows Server 2008 und Windows Vista (mit installiertem RSAT) werden die Large Integer Werte im Attribut-Editor, der in den Eigenschaften eines Benutzerobjekts in der MMC Active Directory-Benutzer und -Computer oder in ADSIEdit zu finden ist, in der Übersicht bereits in unserem Zeitformat angezeigt. Der Reiter „Attribut-Editor“ erscheint aber erst dann, wenn unter „Ansicht“ die „erweiterten Features“ aktiviert wurden.
Möchte man Rechte an ein Sicherheitsprinzipal wie z.B. an einen Benutzer oder besser an eine Gruppe im Active Directory (AD) delegieren, kann man das über den Objektdelegierungsassistenten, die Discretionary Access Control List (kurz DACL) oder mit dem Kommandozeilentool DSACLS durchführen.
Objektdelegierungen einrichten
Führt man die Delegierung über die grafische Oberfläche (GUI) mit dem Delegierungsassistenten oder über die DACL durch, ist es durchaus möglich, dass das gewünschte Attribut auf das man die entsprechenden Rechte erteilen möchte in der GUI nicht angezeigt wird. Denn standardmäßig wird nicht jedes Attribut in der GUI angezeigt, um die Liste der angezeigten Attribute übersichtlich zu halten.
Das ist aber auch nicht weiter tragisch, da es ohnehin empfohlen ist die Delegierung mit DSACLS durchzuführen. Denn somit hat man es zum einen mit der Dokumentation einfacher und zum anderen, lassen sich die erteilten Rechte im AD schnell wieder entfernen. Im Gegensatz zur GUI existieren in der Kommandozeile keine Beschränkungen und in Verbindung mit einem Skript, können Delegierungen einfach durchgeführt werden. Bei der Delegierung mit dem Kommandozeilentool muss man natürlich das Attribut kennen, auf das man Rechte erteilen möchte.
Siehe auch:
Die Active Directory-Attribute hinter den Feldnamen
Wer die Delegierung doch lieber über die GUI durchführen möchte, der kann die gefilterten Attribute die standardmäßig nicht angezeigt werden zum Vorschein bringen. Dazu muss die Datei „dssec.dat“ die sich seit Windows 2000 im Verzeichnis „%systemroot%\System32\“ befindet bearbeitet werden.
Möchte man z.B. die Attribute physicalDeliveryOfficeName (das Feld “Büro” in den Eigenschaften eines Benutzerobjekts) oder sn (Nachname eines Benutzers) zum Vorschein bringen, muss in der Datei „dssec.dat“ im Abschnitt [User] hinter den jeweiligen Attributen die Zahl 7 auf 0, 1 oder 2 geändert werden.
Die Zahlen bedeuten:
7 = Das Attribut wird in der GUI nicht angezeigt.
0 = Es werden die Eigenschaften „lesen“ und „schreiben“ für das Attribut angezeigt.
1 = Es wird nur die Schreib-Eigenschaft eines Attributs angezeigt.
2 = Es wird nur die Lese-Eigenschaft eines Attributs angezeigt.
Wurde die Datei dssec.dat bearbeitet, muss anschließend die MMC Active Directory-Benutzer und -Computer neu gestartet werden, damit das gewünschte Attribut angezeigt wird.
Eine andere Variante ist, dass man bei der Objektdelegierung über die GUI beim erstellen eines benutzerdefinierten Tasks nicht beim "Zuweisen der Verwaltung von" die Option "Benutzer"-Objekte auswählt, sondern die Objektklasse "InetOrgPerson"-Objekte. Danach hat man auch Zugriff und die standardmäßig nicht eingeblendeten Attribute und kann diese an die entsprechende Gruppe delegieren.
Mit DSACLS könnte man das Schreibrecht auf das Attribut physicalDeliveryOfficeName (Feldname: Büro) einer Gruppe wie folgt erteilen:
DSACLS "<DN der OU>" /G "<Gruppe>:WP;physicalDeliveryOfficeName;user" /I:S
Das Schreibrecht auf die Nachnamen aller Benutzer die sich in einer OU befinden, lässt sich einer Gruppe folgendermaßen delegieren:
DSACLS "<DN der OU>" /G "<Gruppe>:WP;sn;user" /I:S
Weitere Informationen:
Der Objektdelegierungsassistent
Das aktivieren/deaktivieren eines Benutzerkontos delegieren
Delegierte AD-Berechtigungen anzeigen und entfernen
How to modify the filtered properties of an object
Mit dem Kommandozeilentool Whoami das sich unter Windows 2000 im Ressource Kit befindet und ab Windows Server 2003 on Bord ist, lässt sich der komplette Inhalt des Access-Tokens des aktuell angemeldeten Benutzers anzeigen und exportieren. Im Accesss-Token ist die SID des Benutzers, die SIDs der SID-History (ab Windows Server 2003) und die SID's aller Gruppen in denen der angemeldete Benutzer innerhalb der Domäne direkt oder verschachtelt Mitglied ist enthalten. Whoami zeigt auch direkte oder verschachtelte domänenübergreifende universelle Gruppenmitgliedschaften an.
Führt man in einer CMD den Befehl Whoami /all > C:\Temp\Whoami.txt aus, wird solch eine Datei im angegebenen Pfad erstellt:
Die Hilfe zu Whoami lässt sich in gewohnter Windows-Manier mit Whoami /? anzeigen.
In welcher Situation ist es sinnvoll Whoami auszuführen?
Wenn ein Benutzer zu einer Gruppe hinzugefügt und dieser Gruppe die entsprechenden Rechte auf eine Ressource (Dateien, Drucker etc.) erteilt wurde, der Benutzer aber immer noch keinen Zugriff auf die Ressource hat, sollten zwei Punkte sichergestellt werden:
-
Hat sich der Benutzer nach dem hinzufügen zur Gruppen erneut an seinem Client angemeldet? Denn Gruppenmitgliedschaften werden nicht während einer Benutzersitzung ausgewertet, sondern nur bei der Anmeldung.
-
Hat sich der Benutzer bereits neu angemeldet, kann mit Whoami /all das Access-Token ausgewertet werden. Damit kann man überprüfen, ob sich der Benutzer auch tatsächlich in der entsprechenden Gruppe befindet.
Die Gruppenmitgliedschaften eines Benutzers mit der AD-PowerShell exportieren
Das Pendant zu Whoami stellt mit „Windows Server 2008 R2“ und Windows 7 die „Active Directory-PowerShell“ dar. Wird auf einem „Windows Server 2008 R2“ DC oder auf einem Windows 7 Client mit installiertem RSAT (Remote Server Administration Tools) das Cmdlet Get-ADAccountAuthorizationGroup ausgeführt, werden ebenfalls die direkten und verschachtelten Gruppenmitgliedschaften des angegebenen Benutzerkontos angezeigt. Domänenübergreifende „domänenlokale“ Gruppenmitgliedschaften werden nicht angezeigt, aber domänenübergreifende „universelle“ Gruppenmitgliedschaften schon. Domänenübergreifende globale Gruppen sind aus technischen Gründen ohnehin nicht möglich, da eine globale Gruppe nur Mitglieder aus der eigenen Domäne enthalten kann.
Ein DC kann „domänenlokale“, „globale“ und „universelle“ Gruppenmitgliedschaften eines Benutzers, nur innerhalb seiner Domäne ermitteln. Domänenlokale- und globale Gruppen werden zwar (neben den universellen Gruppen) auch in den globalen Katalog (GC) repliziert, allerdings nicht die Mitglieder dieser Gruppen! Deshalb findet auch bei Gruppenveränderungen in domänenlokalen und globalen Gruppen keine GC-Replikation statt. Da aber ein Benutzer Mitglied einer universellen Gruppe in unterschiedlichen Domänen sein kann, ist für die Abfrage von domänenübergreifenden universellen Gruppenmitgliedschaften ein GC notwendig. Denn nur der GC kennt die domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers, da das member Attribut von universellen Gruppen auf den GC repliziert wird. Wenn sich ein Benutzer in einer Gesamtstruktur mit mehreren Domänen an einer Domäne anmeldet, muss der DC einen GC kontaktieren um die universellen Gruppenmitgliedschaften abzurufen, in denen der Benutzer evtl. in anderen Domänen Mitglied ist. Oder es ist ab Windows Server 2003 das „zwischenspeichern der universellen Gruppenmitgliedschaften“ auf einem AD-Standort aktiviert.
In einer Multidomänen-Gesamtstruktur ist es zwingend erforderlich, dass zum Zeitpunkt der Abfrage mit dem Cmdlet Get-ADAccountAuthorizationGroup ein GC erreichbar ist. Denn schließlich wird für die Auswertung der domänenübergreifenden universellen Gruppenmitgliedschaften ein GC benötigt. Wenn zum Zeitpunkt der Abfrage kein GC erreicht werden kann schlägt die Abfrage fehl. Allerdings schlägt die Abfrage nur dann fehl, wenn es sich um eine Multidomänen-Gesamtstruktur handelt!
Die Option „Das zwischenspeichern von universellen Gruppenmitgliedschaften“ bringt nicht den gewünschten Erfolg. Die Abfrage mit dem Cmdlet in einer Gesamtstruktur mit mehreren Domänen schlägt auch in diesem Fall fehl.
Ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften ist für die Benutzeranmeldung nur in einer Gesamtstruktur mit mehreren Domänen notwendig. Handelt es sich um eine Einzeldomänen-Gesamtstruktur (Single-Domänen Forest), wird weder ein GC, noch das zwischenspeichern von universellen Gruppenmitgliedschaften benötigt. Es existieren ohnehin keine domänenübergreifenden Gruppenmitgliedschaften, wozu ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften notwendig wäre.
In einer Einzeldomänen-Gesamtstruktur benötigt das Cmdlet deshalb auch keinen GC. Schließlich kennt in einer Einzeldomänen-Gesamtstruktur der DC alle Gruppenmitgliedschaften eines Benutzers. Auch der Benutzer kann sich in einer Einzeldomänen-Gesamtstruktur ohne einen GC erfolgreich an der Domäne anmelden.
In einer Windows Server 2003 oder Windows Server 2008 Umgebung lässt sich die AD-PowerShell ebenfalls z.B. von einem Windows 7 Client nutzen. Dazu muss jedoch das „AD MGS“ auf mindestens einem DC installiert werden:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Das Cmdlet Get-ADAccountAuthorizationGroup liest das Attribut tokenGroups des angegebenen Sicherheitsprinzipals aus. Dabei kann ein Benutzer oder Computer angegeben werden, aber keine Gruppe! Es werden zum einen alle direkten und verschachtelten Sicherheits-Gruppenmitgliedschaften (domänenlokale, globale und universelle Gruppen) innerhalb der Domäne und zum anderen die direkten und verschachtelten domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers angezeigt. Es werden jedoch keine Verteilergruppen angezeigt!
Das mehrwertige Attribut tokenGroups ist zwar im Schema definiert, es enthält jedoch selbst keinen Wert. Die Attributwerte werden erst im Moment der Abfrage errechnet. Diese Art von Attribut bezeichnet man als Constructed Attribute oder auch Computed Attribute. Da das Attribut tokenGroups "constructed" ist, kann es nicht repliziert werden. Sein Wert wird auch nicht in den GC übertragen.
Siehe auch:
Die konstruierten Attribute abfragen
Die Gruppenmitgliedschaften eines Benutzers werden wie folgt in eine CSV-Datei exportiert:
Get-ADAccountAuthorizationGroup Yusuf | Export-CSV C:\Yusuf.csv -NoTypeInformation
Soll die Ausgabe bis auf wenige Attribute gekürzt werden, lautet der Befehl wie folgt:
Get-ADAccountAuthorizationGroup Yusuf | Select distinguishedName,sAMAccountName,GroupCategory,GroupScope,objectClass | Export-CSV C:\Yusuf.csv -NoTypeInformation
Die Ausgabe sieht wie folgt aus:
Die Hilfe zu dem Cmdlet lässt sich mit diesem Befehl anzeigen:
Get-Help Get-ADAccountAuthorizationGroup -Full
Die Gruppenmitgliedschaften eines Benutzers mit den ds*-Tools exportieren
Mit den beiden Kommandozeilentools dsquery und dsget die sich seit Windows Server 2003 "on Bord" befinden, lassen sich ebenfalls die Gruppenmitgliedschaften eines Benutzers exportieren.
Möchte man die direkten Gruppenmitgliedschaften eines Benutzers exportieren, so kann dazu der folgende Befehl verwendet werden:
dsquery user -samid <Benutzername> | dsget user -memberof > C:\Temp\Gruppenmitgliedschaften.txt
oder:
dsget user "DN des Benutzerobjekts" -memberof > C:\Temp\Gruppenmitgliedschaften.txt
Sollen hingegen auch die verschachtelten Gruppenmitgliedschaften angezeigt werden, dann gilt es diesen Befehl auszuführen:
dsget user "DN des Benutzerobjekts" -memberof -expand > C:\Temp\Gruppenmitgliedschaften.txt
bzw.
dsquery user -samid <Benutzername> | dsget user -memberof -expand > C:\Temp\Gruppenmitgliedschaften.txt
Hinweis: Unter Windows Server 2008 R2 und Windows 7 liefert dsget nicht die korrekten Daten.
Das lässt sich jedoch durch einen Hotfix beheben:
The "dsget user -memberof -expand" command returns incorrect results in Windows Server 2008 R2 and in Windows 7
Die Gruppenmitgliedschaften eines Benutzers mit "Net User" exportieren
Auch mit dem Kommandozeilentool NET kann man die Gruppenmitgliedschaften eines Benutzer wie folgt exportieren:
Net User <sAMAccountName> /Domain > C:\Temp\Gruppenmitgliedschaften.txt
Weitere Informationen:
Delegierte Berechtigungen im AD verstehen
Active Directory – Abfrage
AD-PowerShell Befehle
Token-Groups Attribute (Windows)
How to enumerate a user's security group membership using Visual Basic or Visual Basic Script
Im Active Directory-Schema sind verschiedene Arten von Attribute definiert. Die meisten davon sind in der Active Directory-Datenbank (NTDS.dit) gespeichert und können einen festen Wert enthalten.
Aber längst nicht alle Attribute für ein Objekt sind in der AD-Datenbank gespeichert. Diese Art von Attribut bezeichnet man als Constructed Attribute, auch bekannt als Computed Attribute.
Die Merkmale eines solchen Attributs sind:
-
Constructed Attribute, zu Deutsch „konstruierte Attribute“ sind zwar im Schema definiert, sie enthalten jedoch selbst keinen Wert. Die Attributwerte werden erst von einem Domänencontroller im Moment der LDAP-Anfrage gebildet.
-
Da diese Attribute "constructed" sind, können sie auch nicht repliziert werden. Die Werte können auch nicht in den globalen Katalog (GC) übertragen werden.
-
Wird eine Abfrage nach solch einem Attribut durchgeführt, bildet jeder DC eigenständig den Wert.
-
Ein Wert eines konstruierten Attributs kann nicht vergeben bzw. geschrieben werden. Diese Art von Attribut wird lediglich für eine gezielte Abfrage vom DC zusammengesetzt.
-
Konstruierte Attribute können in der Regel nicht für Abfragen verwendet werden (die Ausnahme stellt das Attribut aNR oder memberOf dar).
-
In einigen Fällen muss bei der Abfrage im Parameter -Scope die Option BASE angegeben werden, wie z.B. für das Attribut tokenGroups. Mit dieser Option wird auf ein einziges Objekt zugegriffen.
-
Eine Abfrage nach allen Objekten in einem Container, die ein konstruiertes Attribut der Objekte die sich in dem Container befinden anzeigt, bringt kein Ergebnis.
Ein konstruiertes Attribut wird durch das dritte Bit im System-Flags Attribut definiert. Verbindet man sich in LDP z.B. mit dem konstruierten Attribut CN=Token-Groups,CN=Schema,CN=Configuration,DC=Root-Domäne lässt sich das System-Flag folgendermaßen kontrollieren:
Die konstruierten Attribute einer Gesamtstruktur anzeigen
In der AD-Powershell
Get-ADObject -LDAPFilter “(&(objectClass=attributeSchema)(systemflags:1.2.840.113556.1.4.803:=4))” -Searchbase “CN=Schema,CN=Configuration,DC=Root-Domäne” | Select Name
Oder:
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties Systemflags | Where {$_.Systemflags -band 4} | Select Name
Mit LDP
-
Nach dem Starten von LDP gilt es zuerst eine Verbindung zu einem DC herzustellen.
-
Im zweiten Schritt muss man sich mit dem AD binden.
-
Anschließend gibt man im Suchfenster (unter Browse/Durchsuchen-Search/Suchen) als Basis-DN CN=Schema,CN=Configuration,DC=Root-Domäne ein und verwendet als Filter (&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4)).
-
Als Scope/Bereich gilt es One Level/Eine Ebene zu wählen.
-
Im Feld Attribute können dann die gewünschten Attribute angegeben werden.
In der Kommandozeile mit Dsquery, ab Windows Server 2003
dsquery * “CN=Schema,CN=Configuration,DC=Root-Domäne” -Scope Onelevel -attr Name -Filter "(&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4))"
Weitere Informationen:
AD-PowerShell Befehle
Microsoft Windows 2000 Scripting Guide - Operational Attributes
How to query Active Directory by using a bitwise filter
System-Flags Attribute
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|