LDAP://Yusufs.Directory.Blog/ - Active Directory|Erweiterte Abfragen

Alte oder deaktivierte Computerkonten mit der AD-PowerShell löschen

Yusuf Dikmenoglu — Sun, 02 May 2010 13:29:23 GMT

Das Active Directory (AD) stets zu pflegen, ist eines der Aufgaben eines AD-Administrators. Mit der Zeit entstehen Leichen was die Computerkonten im AD betrifft. Clients die verschrottet wurden, sind vorher nicht aus der Domäne entfernt worden. Aber auch wenn Clients oder Mitgliedsserver aus der Domäne entfernt und zu einer Arbeitsgruppe (AG) hinzugefügt werden, wird nicht automatisch das Computerkonto im AD gelöscht. Es wird lediglich deaktiviert und bleibt im AD bestehen. Im Nachgang muss dann das Computerkonto manuell entfernt werden.

State oft the Art löscht man die Computerkonten mit der AD-PowerShell. Weitere Möglichkeiten findet man im folgenden Artikel:

Computerkonto löschen

# Alle deaktivierten Computerkonten, also alle Computer (Clients und Mitgliedsserver) die aus der Domäne entfernt und in eine AG hinzugefügt oder manuell deaktiviert wurden, werden mit diesem Befehl angezeigt:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object | FT Name -A

Sollen die deaktivierten Computerkonten aus einer bestimmten Organisationseinheit (OU) angezeigt werden, so gilt es diesen Befehl zu verwenden:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object | FT Name -A

# Alle deaktivierten Computerkonten werden auf Nachfrage, nacheinander mit diesem Befehl gelöscht:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object| Remove-ADComputer

Deaktivierte Computerkonten aus einer bestimmten OU werden auf Nachfrage mit diesem Befehl entfernt:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object| Remove-ADComputer

Sollen alle deaktivierten Computerkonten auf einmal ohne Nachfrage gelöscht werden, so muss der Parameter „-Confirm:“ mit dem Wert „$False“ mit angegeben werden. Sprich:
Search-ADAccount –AccountDisabled -ComputersOnly | Remove-ADComputer -Confirm:$False

Ohne Nachfrage werden die deaktivierten Computerkonten aus einer OU wie folgt gelöscht:
Search-ADAccount –AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False

# Alle Computer die sich seit 180 Tagen nicht am AD angemeldet haben werden mit dem folgenden Befehl angezeigt. Damit der Parameter AccountInactive verwendet werden kann, muss sich jedoch der Domänenfunktionsmodus mindestens auf der Ebene “Windows Server 2003” befinden:
Search-ADAccount -AccountInactive –Timespan 180 –ComputersOnly | Sort-Object | FT Name -A

Möchte man sich alle Computer aus einer bestimmten OU anzeigen, die sich seit 180 Tagen nicht mehr am AD angemeldet haben, so sieht der Befehl folgendermaßen aus:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A

Gelöscht werden die Computerkonten dann wie folgt:
Search-ADAccount -AccountInactive –Timespan 180 -ComputersOnly | Remove-ADComputer -Confirm:$False

Aus einer bestimmten OU werden die Computerkonten so entfernt:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False

# Alle Computer die seit dem 01.01.2010 inaktiv sind und sich nicht mehr am AD angemeldet haben, werden wie folgt angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Sort-Object | FT Name -A

Alle Computer aus einer bestimmten OU, die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, werden so angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A

Alle Computerkonten die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, lassen sich dann mit diesem Befehl löschen:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Remove-ADComputer -Confirm:$False

Die Computer einer bestimmten OU, die seit dem 01.01.2010 inaktiv sind, werden wie folgt gelöscht:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Remove-ADComputer -Confirm:$False

Weitere Informationen:
Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
AD-PowerShell Befehle

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Welche Verzeichnispartitionen befinden sich auf einem DC?

Yusuf Dikmenoglu — Sun, 21 Mar 2010 12:48:25 GMT

Der Distinguished Name (DN) der einzelnen Verzeichnispartitionen die auf einem Domänencontroller (DC) gespeichert sind, werden in den folgenden Attributen gespeichert. Diese Attribute gehören zur nTDSDSA-Objektklasse und befinden sich in den Eigenschaften des „NTDS Settings“ Objekts des jeweiligen DCs. Zu finden ist das Objekt in diesem LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.

Die im Verlauf dieses Artikels verwendeten Abfragen werden unter anderem über alle AD-Standorte hinweg durchgeführt. Möchte man die Abfrage auf einen bestimmten AD-Standort eingrenzen, so muss im Filter der gewünschte AD-Standort mit angegeben werden. Also anstatt "CN=Sites,CN=Configuration,DC=Root-Domäne" muss es dann so lauten: "CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne".

In welchen Attributen ist die Information gespeichert, welche Verzeichnispartitionen sich auf einem DC befinden?

hasMasterNCs = In diesem mehrwertigen (multivalue) Attribut werden die DNs der beschreibbaren Verzeichnispartitionen die sich auf einem DC befinden gespeichert. Diese sind standardmäßig die Schema-, Konfigurations- und Domänenpartition. In diesem Attribut werden aber keine Anwendungsverzeichnispartitionen gespeichert, wie z.B. die beiden DNS-Partitionen ForestDNSZones sowie DomainDNSZones. Auf RODCs enthält dieses Attribut logischerweise keinen Wert, da auf einem RODC keine beschreibbaren Verzeichnispartitionen gespeichert sind da der RODC auf alle Verzeichnispartitionen lediglich das Leserecht besitzt!

hasPartialReplicaNC = In diesem mehrwertigen Attribut werden die DNs der Domänenpartitionen aus den anderen Domänen innerhalb einer Gesamtstruktur gespeichert, die sich auf einem DC befinden. Das Attribut enthält nur dann einen Wert, wenn zum einen mehr als eine Domäne in der Gesamtstruktur existiert und zum anderen, auf dem DC der globale Katalog (GC) aktiviert wurde! Da ein GC lediglich das Leserecht auf die Domänenpartitionen aus anderen Domänen hat, sind in diesem Attribut die DNs der Domänenpartitionen worauf ausschließlich das Leserecht besteht gespeichert. Da man auf einem RODC auch den GC aktivieren kann, werden bei der Abfrage nach diesem Attribut auch RODCs angezeigt.

msDS-HasDomainNCs = In diesem einwertigen (single-value) Attribut das erst ab Windows Server 2003 existiert, wird der DN der Domänenpartition die sich auf einem DC befindet gespeichert. RODCs verwenden ebenfalls dieses Attribut und werden demzufolge auch bei Abfragen mit angezeigt.

msDS-hasFullReplicaNCs = In diesem mehrwertigen Attribut das nur von einem RODC genutzt wird, sind die DNs der Verzeichnispartitionen: Schemapartition, Konfigurationspartition, Domänenpartition (in der sich der RODC befindet) sowie den beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones gespeichert.

msDS-hasMasterNCs = In diesem mehrwertigen Attribut werden sämtliche DNs der beschreibbaren Verzeichnispartitionen die sich auf einem DC befinden gespeichert. Standardmäßig enthält das Attribut ab Windows Server 2003 die DNs der folgenden Verzeichnispartitionen: Schemapartition, Konfigurationspartition, Domänenpartition sowie die beiden Anwendungsverzeichnispartitionen DomainDNSZones (der eigenen Domäne) und ForestDNSZones. Da ein RODC keine beschreibbaren Verzeichnispartitionen vorhält, erscheinen bei der Abfrage nach diesem Attribut demzufolge auch keine RODCs!

Welche beschreibbaren Verzeichnispartitionen sind auf einem DC gespeichert?

Um herauszufinden welche beschreibbaren Verzeichnispartitionen auf einem DC gespeichert sind, sollte eine Abfrage nach dem Attribut msDS-hasMasterNCs erfolgen.

Mit der AD-PowerShell

$ADSI = [ADSI]"LDAP://<DC>:389/CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne"
$ADSI."msDS-hasMasterNCs" >

Oder mit diesem AD-PowerShell Befehl:

Get-ADObject -LDAPFilter “(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=*))“ -Searchbase "CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne" -Properties msDS-hasMasterNCs -SearchScope Subtree | Select msDS-hasMasterNCs | % {write $_."msDS-hasMasterNCs"} >

Mit LDP

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN das „NTDS Settings“ Objekt des entsprechenden DCs in der Konfigurationspartition angeben. Also: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=*)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute msDS-hasMasterNCs angegeben werden.

Mit Dsquery

dsquery * "CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne" -attr msDS-hasMasterNCs >

Alle Verzeichnispartitionen einer Gesamtstruktur anzeigen

Die Verzeichnispartitionen einer Gesamtstruktur sind standardmäßig:

die Schemapartition (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).

die Konfigurationspartition (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).

die jeweilige Domänenpartition (wird auf alle DCs innerhalb der jeweiligen Domäne repliziert). Wenn sich mehrere Domänen in der Gesamtstruktur befinden, werden alle Domänenpartitionen aufgelistet.

die Anwendungsverzeichnispartition ForestDNSZones (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).

die Anwendungsverzeichnispartition DomainDNSZones der jeweiligen Domäne (wird auf alle DCs innerhalb der jeweiligen Domäne repliziert). Existieren mehrere Domänen in einer Gesamtstruktur und wurde die Forward Lookup Zone der entsprechenden Domäne in der DomainDNSZones-Partition gespeichert, werden alle DomainDNSZones-Anwendungsverzeichnispartitionen aufgelistet. > >>

Alle Verzeichnispartitionen einer Gesamtstruktur mit der AD-PowerShell abfragen

Get-ADObject -LDAPFilter "(objectCategory=crossRef)" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" | ? {$_.systemFlags -band 5} –SearchScope OneLevel | Select ncName >

Oder mit dieser AD-PowerShell Abfrage

Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(systemflags:1.2.840.113556.1.4.804:=5))" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -SearchScope OneLevel | Select ncName >

Mit LDP

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectCategory=crossRef)(systemFlags:.12.840.113556.1.4.803:=5)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute ncName angegeben werden.

Mit Dsquery

dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectCategory=crossRef)(systemFlags:1.2.840.113556.1.4.804:=5))" -Scope OneLevel -attr ncName >

Alle beschreibbaren DCs und die Verzeichnispartitionen anzeigen, die jeweils auf den DCs gespeichert sind

Mit der AD-PowerShell

Get-ADObject -LDAPFilter "(objectClass=nTDSDSA)" -Properties msds-hasMasterNCs -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" | Select distinguishedName,msDS-hasMasterNCs | FT –A -Wrap >

Mit LDP

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (objectClass=nTDSDSA). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName;msDS-hasMasterNCs angegeben werden.>

Mit Dsquery

dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(ob jectclass=nTDSDSA)" -attr distinguishedName msds-hasMasterNCs -Limit 0 > C:\Temp\dsquery.txt>

Alle Anwendungsverzeichnispartitionen einer Gesamtstruktur anzeigen

Alle Anwendungsverzeichnispartitionen die in einer Gesamtstruktur existieren, standardmäßig sind das ab Windows Server 2003 die beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones, werden mit der folgenden AD-PowerShell Abfrage angezeigt. Existieren mehrere Domänen in der Gesamtstruktur die mindestens unter Windows Server 2003 betrieben werden, wird für jede Domäne die DNS-Anwendungsverzeichnispartition DomainDNSZones angezeigt.

AD-PowerShell

Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(systemflags:1.2.84 0.113556.1.4.803:=5))" -Properties * -Searchbase "CN=Partitions,CN=Configuration ,DC=Root-Domäne" -SearchScope OneLevel | Select dnsRoot | FT

Auch mit diesem AD-PowerShell Befehl lassen sich alle Anwendungsverzeichnispartitionen einer Gesamtstruktur Anzeigen:

Get-ADObject -LDAPFilter "(objectCategory=crossRef)" -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Properties * -SearchScope OneLevel | Where {$_.systemFlags -band 4} | Select dnsRoot
>

Mit LDP

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectCategory=crossRef)(systemFlags:.12.840.113556.1.4.803:=5)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute dnsRoot angegeben werden.

Mit Dsquery

Mit Dsquery werden alle Anwendungsverzeichnispartitionen einer Gesamtstruktur mit dieser Kommandozeilenabfrage angezeigt:

dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectCategory=crossRef)(systemflags:1.2.840.113556.1.4.803:=5))" -Scope OneLevel -attr dnsRoot>

Welche Anwendungsverzeichnispartitionen sind auf einem DC gespeichert?

Um sich die Anwendungsverzeichnispartitionen die auf einem bestimmten DC gespeichert sind anzuzeigen, gilt es eines der folgenden Abfragen durchzuführen. Standardmäßig werden ab Windows Server 2003 die beiden DNS-Partitionen ForestDNSZones und DomainDNSZones (der jeweiligen Domänen) angezeigt.>

Mit der AD-PowerShell

Get-ADObject -LDAPFilter "(&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msds-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))" –Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -SearchScope OneLevel | Select dnsRoot

Oder mit diesem AD-PowerShell Befehl:

Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(msds-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC= Root-Domäne" -SearchScope OneLevel | Where {$_.systemFlags -band 5} | Select dnsRoot>

Mit LDP

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msds-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute dnsRoot angegeben werden.

Mit Dsquery

dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Scope OneLevel -attr dnsRoot -Filter "(&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msds-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))" >>

Auf welchen beschreibbaren DCs ist die Anwendungsverzeichnispartition ForestDNSZones gespeichert?

Mit dem folgenden AD-PowerShell Befehl werden alle DCs angezeigt, auf denen die ForestDNSZones-Partition gespeichert ist. Dabei spielt es auch keine Rolle, an welchem AD-Standort sich die DCs befinden.

Get-ADObject -LDAPFilter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne))" -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Select distinguishedName | FT
>

Mit LDP

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName angegeben werden.

Mit Dsquery

dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne))" -Scope Subtree -attr distinguishedName >>

Auf welchen beschreibbaren DCs ist die Anwendungsverzeichnispartition DomainDNSZones gespeichert?

Um die DCs abzufragen auf denen die DNS-Partition DomainDNSZones gespeichert ist, gilt es den folgenden AD-PowerShell Befehl auszuführen. Die DomainDNSZones Verzeichnispartition wird jeweils nur innerhalb der Domäne repliziert.

Get-ADObject -LDAPFilter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne))" –Properties * -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Select distinguishedName | FT -A –Wrap>

Mit LDP

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName angegeben werden.

Mit Dsquery

dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne))" -Scope Subtree -attr distinguishedName >>

Einfache Abfrage mit DNSCMD

Eine andere einfache Variante um zu überprüfen ob auf einem bestimmten DC die beiden DNS-Anwendungsverzeichnispartitionen gespeichert sind, stellt das DNS-Kommandozeilentool dnscmd dar. Die Abfrage in einer Kommandozeile die auch domänenübergreifend funktioniert lautet so:

Dnscmd <DC> /EnumDirectoryPartitions>

Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen

>>>>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den gefilterten Attributsatz abfragen

Yusuf Dikmenoglu — Sun, 07 Mar 2010 22:32:34 GMT

Mit Windows Server 2008 führte Redmond den Read Only Domänencontroller (kurz RODC) ein. Der RODC der für Außenstellen die eine geringe bis keine physikalische Sicherheit den Servern bieten können konzipiert wurde, ist ein Domänencontroller (DC) der ausschließlich einen lesenden Zugriff auf die Active Directory-Domänendienste (AD DS) hat. Der RODC kann keine Änderungen in den AD DS und im AD-integrierten DNS vornehmen (RODNS). Clients oder Applikationen die einen Lesezugriff auf die AD DS benötigen erhalten Zugriff auf den RODC, während Clients oder Applikationen die einen Schreibvorgang in die AD DS durchführen wollen, diesen nicht auf dem RODC durchführen können sondern vom RODC an einen beschreibbaren DC verwiesen werden.

Der RODC besitzt ein vollständiges Replikat der AD-Datenbank, mit allen Attributen und Objekten die sich auch auf einem beschreibbaren DC befinden. Neben dem Unterschied das der RODC lediglich das Leserecht auf die AD-Datenbank hat, werden im Gegensatz zu einem beschreibbaren DC standardmäßig auch keine Benutzer- oder Computeranmeldeinformationen auf dem RODC gespeichert, außer das eigene Computerkonto sowie ein besonderes krbtgt-Konto für diesen RODC. Damit die Anmeldeinformationen der entsprechenden Benutzer-, Computer- und Dienstkonten auf dem RODC gespeichert werden können, muss das explizit in der Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) auf einem beschreibbaren DC gestattet werden, damit der RODC Authentifizierungs- und Dienstticketanforderungen eigenständig verarbeiten kann. Mit der Kennwortreplikationsrichtlinie wird bestimmt, ob die Anmeldeinformationen eines Benutzer- oder Computerkontos von einem beschreibbaren DC auf den RODC repliziert werden können.

Weitere Informationen zum RODC bekommt man in den folgenden beiden Artikeln:

Read-Only Domain Controller (RODC)
Die Installation eines RODC

Der gefilterte Attributsatz vom RODC

Diverse Applikationen könnten die AD-Domänendienste als Datenspeicher verwenden und sensible Daten darin speichern. Oder evtl. möchte man einfach nicht, dass bestimmte Daten von Benutzern (z.B. die Adressdaten oder die Personalnummer) auf einen RODC repliziert werden. Natürlich sollen diese kritischen Daten ebenfalls geschützt sein und nicht auf einem RODC gespeichert werden, falls der RODC kompromittiert, gestohlen oder die Sicherheit gefährdet wird. Und für genau diesen Anwendungstyp gibt es den gefilterten Attributsatz. Der gefilterte Attributsatz (auf Englisch: Filtered Attribute Set, kurz FAS) ist ein dynamischer Attributsatz, die nie auf einen RODC in der Gesamtstruktur repliziert werden da sie sensible oder vertrauliche Daten enthalten. Der gefilterte Attributsatz kann aber erst ab Windows Server 2008 konfiguriert werden.

Damit ein Attribut das wichtige Daten enthält nicht auf einen RODC repliziert wird, sollten die folgenden Schritte durchgeführt werden:

Das entsprechende Attribut sollte zu dem gefilterten Attributsatz (FAS) hinzugefügt werden. Damit wird verhindert, dass das Attribut an die RODCs in der Gesamtstruktur repliziert wird. Die Konfiguration des gefilterten Attributsatzes betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden!
Des Weiteren sollte das Attribut als vertraulich gekennzeichnet werden. Dies ist eine weitere Sicherheitseinstellung das konfiguriert werden sollte, wenn man nicht möchte das ein sensibles Attribut zu einem RODC repliziert werden soll! Ein Attribut wird als vertraulich gekennzeichnet, in dem die Leseberechtigung für das entsprechende Attribut für die Gruppe Authentifizierte Benutzer entfernt wird. Somit können diese Attribute von den Mitgliedern der Gruppe Authentifizierte Benutzer (das betrifft alle Benutzer- sowie Computerkonten, inklusive RODCs) nicht mehr gelesen werden. Auch die Konfiguration eines vertraulichen Attributs betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden! Doch bevor ein Attribut als vertraulich gekennzeichnet wird, sollte der Vorgang in einer Testumgebung ausgiebig getestet werden!
Der Gesamtstrukturfunktionsmodus sollte sich aus Sicherheitsgründen mindestens auf Windows Server 2008 befinden. Denn die Attribute die sich im gefilterten Attributsatz befinden, werden nur von DCs die mindestens unter Windows Server 2008 laufen berücksichtigt! Windows Server 2003 DCs ignorieren die Konfiguration das ein Attribut geschützt ist und replizieren die Attribute die sich in dem gefilterten Attributsatz befinden trotzdem auf einen RODC.
Die Domänenpartition in der sich der RODC befindet wird zwar erst ab einem beschreibbaren Windows Server 2008 DC auf den RODC repliziert, doch wenn auf dem RODC der globale Katalog (ROGC) aktiviert wird, baut sich eine eigene Replikationstopologie für die Replikation des GCs auf. Existieren in der Gesamtstruktur noch weitere Domänen mit Windows Server 2003 GCs in denen ebenfalls ein gefilterter Attributsatz konfiguriert wurde, ist es durchaus möglich das ein Windows Server 2003 GC den gefilterten Attributsatz aus seiner Domäne zu einem RODC repliziert.
Das Hinzufügen eines systemkritischen Attributs zum gefilterten Attributsatz ist nicht möglich! Ein systemkritisches Attribut ist ein Attribut, das z.B. für die ordnungsgemäße Funktion der AD DS oder für das Kerberos-Authentifizierungsprotokoll benötigt wird. Erst wenn in den Eigenschaften des entsprechenden Attributs im Attribut schemaFlagsEx, das aus einer Bitmaske besteht, das Flag FLAG_ATTR_IS_CRITICAL aktiviert ist, handelt es sich um ein systemkritisches Attribut. Dieses Flag existiert aber erst seit Windows Server 2008 und Windows Server 2003 DCs würden diese Einstellung ignorieren.
Daher ist es umso mehr wichtig, dass sich nicht nur der Schemamaster auf mindestens einem Windows Server 2008 DC, sondern der Gesamtstrukturfunktionsmodus sich zwingend im Modus Windows Server 2008 oder höher befindet. Denn wäre der Schemamaster ein Windows Server 2003 DC, würde sich ein systemkritisches Attribut dem gefilterten Attributsatz scheinbar erfolgreich hinzufügen lassen. Aber da ein Windows Server 2003 DC die Konfiguration eines gefilterten Attributsatzes sowieso nicht kennt, sollte in einer Gesamtstruktur in der ein gefilterter Attributsatz genutzt wird ein Windows Server 2003 DC ohnehin nicht mehr existieren!

Die technische Umsetzung wie ein Attribut zum gefilterten Attributsatz hinzugefügt wird, findet wie folgt statt

Um ein Attribut zum gefilterten Attributsatz hinzuzufügen und somit die Replikation des entsprechenden Attributs zu einem RODC zu verwehren, muss im zu schützenden Attribut das zehnte Bit (also Bit 9) im searchFlags Attribut gesetzt werden. Im searchFlags Attribut kann unter anderem bestimmt werden, dass ein Attribut zum gefilterten Attributsatz hinzugefügt wird und das es vertraulich ist. Im searchFlags Attribut das aus einer Bitmaske besteht, muss im zehnten Bit als Wert in Hexadezimal 0x200 und in Dezimal 512 eingetragen werden. Anschließend wird das entsprechende Attribut zu keinem RODC in der Gesamtstruktur repliziert.
Im Attribut searchFlags liegt auch das Geheimnis, warum ein Windows Server 2003 DC die Attribute im gefilterten Attributsatz nicht berücksichtigt. Denn das zehnte Bit, also Bit 9 in searchFlags ist erst mit Windows Server 2008 und der Einführung des RODCs hinzugekommen.
Soll ein Attribut zum gefilterten Attributsatz hinzugefügt werden, sollte es auch als vertraulich deklariert werden. Als vertraulich deklariert und somit die Leseberechtigung den Authentifizierten Benutzern entzogen, wird ein Attribut durch das Setzen des achten Bits (Bit 7) ebenfalls im searchFlags Attribut. Dieses Flag kam mit Windows Server 2003 SP1 hinzu. Daher sollte darauf geachtet werden, dass wenn mit diesem Flag Attribute als vertraulich definiert werden, alle DCs in der Gesamtstruktur mindestens unter Windows Server 2003 SP1 installiert sind. Alle älteren Serverversionen ignorieren die Kennzeichnung als vertraulich! Im achten Bit des searchFlags Attributs muss als Wert in Hexadezimal 0x080 und in Dezimal 128 eingetragen werden.
Demnach erhält also searchFlags als Wert 640 in Dezimal (in Hexadezimal 0x280), damit zum einen das gewünschte Attribut zum gefilterten Attributsatz hinzugefügt und zum anderen, als vertraulich definiert wird. Trägt man als Wert 641 ein, wird zugleich das Attribut indiziert. Sollten bereits andere Flags im searchFlags Attribut konfiguriert sein, müssen die Werte addiert werden!

Den gefilterten Attributsatz abfragen

Standardmäßig befinden sich die folgenden Attribute ab Windows Server 2008 im gefilterten Attributsatz:

ms-FVE-KeyPackage

ms-FVE-RecoveryPassword

ms-PKI-AccountCredentials
ms-PKI-DPAPIMasterKeys
ms-PKI-RoamingTimeStamp

ms-TPM-OwnerInformation

Um die Attribute die sich im gefilterten Attributsatz befinden abzufragen, muss eine Abfrage nach dem Attribut searchFlags mit dem Wert 512 (das zehnte Bit in searchFlags) durchgeführt werden.

Die Abfrage mit der AD-PowerShell könnte wie folgt lauten

Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties searchFlags | Where {$_.searchFlags -band 512} | Select Name,searchFlags | Sort Name | FT -Autosize -Wrap

Auch mit diesem AD-PowerShell Befehl lassen sich die gefilterten Attribute anzeigen:

Get-ADObject -LDAPFilter "(&(ObjectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=512))" -SearchBase “CN=Schema,CN=Configuration,DC=Root-Domäne” -SearchScope Subtree | Select Name | Sort Name | FT -Autosize -Wrap

Mit LDP lässt sich der gefilterte Attributsatz folgendermaßen anzeigen

Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN die Schemapartition und als Filter (searchFlags:1.2.840.113556.1.4.803:=512) angeben.

Weitere Informationen:
How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
Anhang D: Schritte zum Hinzufügen eines Attributs zu einem Attributsatz mit RODC-Filter
Search-Flags Attribute
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen

Yusuf Dikmenoglu — Sun, 07 Feb 2010 13:06:18 GMT

Die Information wann ein AD-Objekt erstellt wurde, ist im einwertigen (single-valued) Attribut whenCreated gespeichert. Um also das Erstellungsdatum z.B. eines Domänen-Benutzers in Erfahrung zu bringen, muss eine Abfrage des Attributs whenCreated auf irgendeinem DC erfolgen, denn das Attribut whenCreated wird sowohl zwischen den Domänencontrollern (DCs), als auch in den globalen Katalog (GC) repliziert.

Um die Abfrage jedoch State of the Art durchzuführen, ist die Wahl des Werkzeugs die AD-PowerShell.

Andere Möglichkeiten um an diese Information zu kommen, werden im folgenden Artikel erläutert:

Erstellungsdatum eines Benutzerobjekts

Das Attribut whenCreated mit der AD-PowerShell abfragen

Wann ein bestimmter Benutzer erstellt wurde, erfährt man mit diesem Befehl:

Get-ADUser -Filter {sAMAccountName -eq "Yusuf"} -Properties whenCreated | Select Name,whenCreated,distinguishedName | FT -Autosize -Wrap

Oder mit diesem Befehl:

$user = [ADSI]"LDAP://CN=<Benutzer>,OU=<OU>,DC=Domäne,DC=de"
$user.Get("whencreated")

Oder so:
$User = Get-ADUser -Filter { sAMAccountName -eq "Yusuf" } -Properties whenCreated
$User.whenCreated
Vor wie vielen Tagen ein bestimmter Benutzer erstellt wurde, erfährt man wie folgt:
$Heute = Get-Date
$Damals = Get-ADUser -Filter { Name -Like "Yusuf*" } -Properties whenCreated
($Heute - $Damals.whenCreated).Days
Alle Benutzer die in den letzten 90 Tagen erstellt wurden, lassen sich mit diesem AD-PowerShell Befehl anzeigen:

Get-ADUser -Filter * -Properties whenCreated | where { $_.whenCreated -gt (Get-Date).AddDays(-90) } | FT Name,whenCreated,distinguishedName -Autosize -Wrap

Eine andere Variante ist:

$Date = (Get-Date) - (New-Timespan -Days 90)
Get-ADUser -Filter { whencreated -gt $Date } -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap

Oder diese Abfrage:

$VorvielenTagen = (Get-Date).AddDays(-90)
Get-ADUser -Filter { whenCreated -gt $VorvielenTagen } -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap

Oder wie folgt:
Get-ADUser -Filter * -Properties whenCreated | ? { ((Get-Date) - $_.whenCreated).Days -lt 90} | FT Name,whenCreated,Name,distinguishedName -Autosize -Wrap
Alle Benutzer die ab einem bestimmten Datum, in diesem Beispiel ab dem 01.01.2010 erstellt wurden, werden mit diesem AD-PowerShell Befehl angezeigt:

$Date = New-Object DateTime(2010,01,01,0,0,0)
Get-ADUser -Filter { whenCreated -gt $date } -Properties whenCreated | Select Name,whenCreated,distinguishedName | FT -Autosize -Wrap

Oder mit diesem Befehl:

$Date = New-Object System.Datetime -ArgumentList @(2010,01,01,0,0,0)
Get-ADUser -Filter { whenCreated -gt $date } -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap

Auch mit diesem Befehl werden alle Benutzer die ab dem 01.01.2010 erstellt wurden angezeigt:
Get-ADUser -LDAPFilter "(&(objectCategory=person)(whenCreated>=20100101000000.0Z))" -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Alle Benutzer die bis vor 10 Tagen und früher erstellt wurden werden mit diesem Befehl angezeigt:
$Date = Get-Date
Get-ADUser -Filter * -Properties whenCreated | ? { ($date - $_.whenCreated).days -gt 10 } | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Alle Benutzer die in einem bestimmten Zeitraum, hier zwischen dem 01.09.2009 und 30.09.2009 erstellt wurden, werden wie folgt angezeigt:
$Anfang = Get-Date -Day 01 -Month 09 -Year 2009 -Hour 00
$Ende = Get-Date -Day 30 -Month 09 -Year 2009 -Hour 23 -Minute 59
Get-ADUser -Filter * -Properties whenCreated | ? { ($_.whenCreated -gt $Anfang) -and ($_.whenCreated -le $Ende) } | FT Name,whenCreated,distinguishedName -Autosize -Wrap
In den oben genannten AD-PowerShellbefehlen handelt es sich um Benutzerabfragen. Möchte man sich jedoch statt Benutzer --> Gruppen anzeigen lassen, so muss man lediglich in den Abfragen das Cmdlet Get-ADUser durch das Cmdlet Get-ADGroup ersetzen, mit dem man gezielt Gruppen abfragen kann.

Demnach sieht die Abfrage nach einer bestimmten Gruppe so aus:

Get-ADGroup -Filter {sAMAccountName -eq "ADConsultants"} -Properties whenCreated | Select Name,whenCreated,distinguishedName | FT -Autosize -Wrap

Die Abfrage welche Gruppen in den letzten 90 Tagen erstellt wurden lautet so:

Get-ADGroup -Filter * -Properties whenCreated | where { $_.whenCreated -gt (Get-Date).AddDays(-90) } | FT Name,whenCreated,distinguishedName -Autosize -Wrap

Und welche Gruppen ab dem 01.01.2010 erstellt wurden, werden wie folgt angezeigt:
$Date = New-Object DateTime(2010,01,01,0,0,0)
Get-ADGroup -Filter { whenCreated -gt $date } -Properties whenCreated | Select Name,whenCreated,distinguishedName | FT -Autosize -Wrap
Sollen hingegen Computer abgefragt werden, so muss das Cmdlet Get-ADComputer angegeben werden, anstelle vom Cmdlet Get-ADUser.

Alle Computerkonten die in den letzten 90 Tagen im AD erstellt wurden (wenn ein Client zur Domäne hinzugefügt wird), lassen sich mit diesem Befehl anzeigen:

Get-ADComputer -Filter * -Properties whenCreated | ? { ((Get-Date) - $_.whenCreated).Days -lt 90} | FT Name,whenCreated,Name,distinguishedName -Autosize -Wrap

Alle Computerkonten die ab dem 01.01.2010 im AD erstellt wurden abfragen:

Get-ADComputer -LDAPFilter "(&(objectCategory=person)(whenCreated>=20100101000000.0Z))" -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap

Alle Computerkonten die in einem bestimmten Zeitraum, hier zwischen dem 01.11.2009 und 30.11.2009 im AD erstellt wurden, werden wie folgt angezeigt:
$Anfang = Get-Date -Day 01 -Month 11 -Year 2009 -Hour 00
$Ende = Get-Date -Day 30 -Month 11 -Year 2009 -Hour 23 -Minute 59
Get-ADComputer -Filter * -Properties whenCreated | ? { ($_.whenCreated -gt $Anfang) -and ($_.whenCreated -le $Ende) } | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Oder wenn man Organisationseinheiten (OUs) anzeigen lassen möchte, muss man in den o.g. Befehlen Get-ADOrganizationalUnit angeben anstatt Get-ADUser.

Alle OUs die ab dem 01.01.2010 erstellt wurden, werden folgendermaßen angezeigt:
$Date = New-Object System.Datetime -ArgumentList @(2010,01,01,0,0,0)
Get-ADOrganizationalUnit -Filter { whenCreated -gt $date } -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Sollen hingegen alle und nicht nur bestimmte AD-Objekte angezeigt werden, so muss in den o.g. Befehlen das Cmdlet Get-ADObject angeben werden.

Alle AD-Objekte (Benutzer, Gruppen, Computer, OUs, Drucker etc.) die seit dem 01.01.2010 erstellt wurden, werden folgendermaßen angezeigt:
Get-ADObject -LDAPFilter "(&(objectClass=*)(whenCreated>=20100101000000.0Z))" -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Möchte man statt den neu erstellten Objekten die geänderten Objekte abfragen, so muss statt whenCreated, das Attribut whenChanged abgefragt werden. Dazu muss in den o.g. Befehlen nur das Attribut whenCreated, durch das ebenfalls einwertige Attribut whenChanged ersetzt werden. Auch whenChanged wird zum einen zwischen den DCs und zum anderen in den GC repliziert.

Weitere Informationen:
AD-PowerShell Befehle
Die Active Directory-Attribute hinter den Feldnamen
Gespeicherte Abfragen für dsa.msc
Alle Gruppenmitgliedschaften eines Benutzers exportieren
Den OS- und SP-Stand abfragen
Wie finde ich heraus wo sich ein Objekt befindet?
Die AD-Powershell im Windows Server 2008 R2
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Gespeicherte Abfragen für dsa.msc

Yusuf Dikmenoglu — Sun, 24 Jan 2010 16:12:46 GMT

Dem Administrator steht seit Windows Server 2003 die gespeicherte Abfrage im Snap-In Active Directory-Benutzer und -Computer (dsa.msc) zur Verfügung. Mit dieser Funktion hat man die Möglichkeit, Suchanfragen zu speichern. Die gespeicherten Abfragen stehen dann für erneute Suchanfragen zu einem späteren Zeitpunkt zur Verfügung. Komplexe Abfragen müssen somit nicht jedesmal neu erstellt werden und können bei gleichbleibenden Bedingungen jedesmal genutzt werden. Mit einer gespeicherten Abfrage können auch benutzerdefinierte Abfragen erstellt werden, die einen LDAP-Suchfilter enthalten.

Alle erstellten Abfragen werden im Ordner Gespeicherte Abfragen gespeichert. Dort können sie bearbeitet und gelöscht werden. Die gespeicherten Abfragen werden jedoch nur in der MMC gespeichert, in der sie durchgeführt wurden und dort auch nur unter dem angemeldeten Benutzer. Fügt man die dsa.msc in eine neue MMC (Start-Ausführen-MMC) hinzu, kann dieses Snap-In als MSC-Datei mit samt den gespeicherten Abfragen gespeichert und auf einer anderen Maschine verwendet bzw. den IT-Kollegen zur Verfügung gestellt werden.

Die gespeicherten Abfragen kann man aber auch als XML-Datei exportieren und auf einer anderen Maschine importieren. Mit einem Rechtsklick auf die gespeicherte Abfrage kann aus dem Kontextmenü die Abfrage mit der Option Abfragedefinition exportieren… als XML-Datei exportiert werden. Auf einer anderen Maschine lässt sich anschließend mit einem Rechtsklick auf den Ordner Gespeicherte Abfrage oder auf einem selbst erstellen Ordner die Option Abfragedefinition importieren… auswählen, um danach die XML-Datei zu importieren.

In der folgenden ZIP-Datei sind 72 gespeicherte Abfragen, sortiert nach Benutzer-, Gruppen-, Computer-, Drucker und Exchange-Abfragen als XML-Datei gespeichert.

Gespeicherte-Abfragen.zip (55,66 KB)

Weitere Informationen:
Wie finde ich heraus wo sich ein Objekt befindet?
Die Active Directory-Attribute hinter den Feldnamen
Active Directory - Abfrage
AD-PowerShell Befehle
>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Massenimporte- und -exporte mit CSVDE und der AD-PowerShell durchführen

Yusuf Dikmenoglu — Sun, 10 Jan 2010 13:35:20 GMT

Neben dem CSVDE das seit Windows 2000 „on Bord“ existiert, kann mit der AD-PowerShell und einer Comma-Separated Value (CSV)-Datei ebenfalls ein Massenimport- sowie -export von Objekten durchgeführt werden. CSVDE steht bis einschließlich Windows Server 2003 nur auf einem Serverbetriebssystem zur Verfügung. Erst ab Windows Vista steht das CSVDE in den Remote Server Administration Tools (kurz RSAT) auf dem Client zur Verfügung. Doch auch unter Windows 2000 und Windows XP ist es möglich die Csvde.exe von einem Server aus dem Verzeichnis „%windir%\system32“ auf eine Admin-Workstation zu kopieren, um das Kommandozeilentool unter diesen beiden Clientversionen zu verwenden. Denn CSVDE steht weder im Adminpak, noch in den Windows Support Tools zur Verfügung.

Die AD-PowerShell steht ab Windows Server 2008 R2 sowie Windows 7 in den RSAT (Remote Server Administration Tools) zur Verfügung und kann ab Windows Server 2003 und Windows XP nachinstalliert werden.

Siehe:
Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0)

Mit der AD-PowerShell lässt sich ebenfalls eine CSV-Datei mit den Cmdlets Import-CSV sowie New-ADUser (für den Import von Benutzern) ins AD importieren und mit dem Cmdlet Export-CSV, Daten aus dem AD exportieren.

Der Vorteil eines Massenimports mit einer CSV-Datei ist, dass man sich die Datei mit den zu importierenden Objekten und Daten in Excel übersichtlich erstellen und als CSV-Datei speichern kann. Nach anschließender Überarbeitung der CSV-Datei kann dann der Import ins AD stattfinden. Auch der Export von vielen Objekten in eine CSV-Datei hat seine Vorteile. Die exportierte CSV-Datei lässt sich zur weiteren Bearbeitung in Excel importieren.

CSVDE und die AD-PowerShell können mit der Dateiendung CSV und TXT einen Im- sowie Export durchführen.

CSVDE zum Im- und Export verwenden

Mit CSVDE, das im Übrigen für Comma Separated Value Data Exchange steht, können Daten im kommaseparierten Format importiert sowie exportiert werden. CSVDE liest beim Import die Informationen aus einer Datendatei und erstellt anschließend AD-Objekte entsprechend den Anweisungen in der Datendatei. Es können jedoch keine bestehenden Objekte geändert werden. Nur das Hinzufügen von neuen Objekten ist möglich! Mit CSVDE können auch keine Benutzerkennwörter gesetzt werden.

Ist neben dem Im- oder Export das Ändern von bestehenden Objekten gewünscht, kann das neben der AD-PowerShell mit LDIFDE durchgeführt werden, das sich auch seit Windows 2000 standardmäßig auf einem Server befindet. LDIFDE kann zwar ebenfalls beim Import von neuen Benutzerobjekten keine Kennwörter setzen, doch dafür kann es Kennwörter von bestehenden Benutzerobjekten ändern, wenn vorher eine 128Bit SSL-Verbindung zum DC hergestellt wurde.>

LDIFDE - LDAP Data Interchange Format Data Exchange

CSVDE kann beliebige Objekte, wie beispielsweise Organisationseinheiten (OU), Benutzer-, Gruppen- und Computerkonten ins AD importieren. Damit CSVDE seine Arbeit korrekt verrichtet, müssen alle notwendigen Parameter angegeben werden.

Die Parameter die für den Im- sowie Export gelten:

-c Dieser Parameter ersetzt bestimmte Daten der Datendatei. Hat man z.B. eine Datendatei zur Hand in der der Distinguished Name der Objekte angepasst werden muss, so hat man zwei Möglichkeiten: Entweder man nutzt im Editor (Notepad) die „Ersetzen…“ Funktion oder man verwendet diesen Parameter, ohne die Datei bearbeiten zu müssen. Die Eingabe würde so aussehen: „-c <DC=alte,DC=Domäne> <DC=neue,DC=Domäne>“.
-f Mit diesem Parameter wird die Datei für den Im- bzw. Export angegeben.
-j Wenn ein Im- oder Export aus welchen Gründen auch immer nicht funktioniert, sollte man diesen Parameter angeben, gefolgt von einem Pfad (z.B. „-j C:\“). Im Fehlerfall werden zwei Protokolldateien erstellt „csv.log“ und „csv.err“. Bei Erfolg wird lediglich die „csv.log“ erstellt.
-s Mit diesem Parameter kann man gezielt einen DC angeben, der für den Im- oder Export verwendet werden soll.
-v Bei der Angabe dieses Parameters wird der ausführliche Modus aktiviert. Es werden in der CMD mehr Informationen angezeigt.
-t Dieser Parameter gibt den LDAP-Port an. Standardmäßig wird der LDAP-Port 389 verwendet. Möchte man aber Daten z.B. von einem globalen Katalog exportieren, so muss der Port 3268 angegeben werden.
-u Umlaute in den zu exportierenden Daten werden mit diesem Parameter korrekt dargestellt. Dieser Parameter verwendet das Unicodeformat.
csvde -? In gewohnter Windows Manier zeigt dieser Befehl die Hilfe zu CSVDE an.

Die relevanten Parameter für einen Import sind:

-f Mit diesem Parameter wird die Datei für den Import angegeben.
-i Dieser Parameter aktiviert den Importmodus. Standardmäßig wird CSVDE ohne Angabe dieses Parameters im Export-Modus ausgeführt.
-k Damit die Fehler „Beschränkungsverletzung“ und „Objekt ist bereits vorhanden“ beim Import ignoriert werden, gilt es diesen Parameter anzugeben.

Die relevanten Parameter für einen Export sind:

-d Dieser Parameter gibt den DN für den zu exportierenden LDAP-Pfad an.
-f Mit diesem Parameter wird die Datei für den Export angegeben.
-g Deaktiviert die seitenweise Suche.
-l Die zu exportierenden Attribute werden mit diesem Parameter angeben (durch Komma getrennt). Dieser Parameter sollte nicht zusammen mit dem Parameter -i verwendet werden, da beide Parameter für andere Szenarien gedacht sind.
-m Aktiviert die SAM-Logik beim Export. Mit diesem Parameter werden die Systemattribute wie z.B. ObjectGUID, objectSID und pwdLastSet nicht exportiert. Daher ist es sinnvoll stets diesen Parameter beim Export zu verwenden. Denn wenn die gleiche Datendatei zum Import verwendet werden soll, müssen ohnehin die Systemattribute aus der Datendatei entfernt werden, da ansonsten der Import fehlschlägt.
-n Exportiert keine Binärwerte.
-o Die Liste der Attribute (durch Komma getrennt), die beim Export ausgelassen werden sollen, werden mit diesem Parameter angegeben.
-p Den Suchbereich (Base/OneLevel/SubTree) gibt man mit diesem Parameter an.
-r Mit diesem Parameter gibt man den LDAP-Suchfilter an. Wird der Parameter nicht angegeben, nimmt CSVDE standardmäßig diesen Suchfilter "(objectClass=*)".

Einen Import mit CSVDE durchführen

Für den Import wird zuerst eine Dateidatei mit den zu importierenden Attributen sowie gewünschten Werten benötigt. Diese Datei lässt sich einfach und übersichtlich in Excel erstellen.>

Für den erfolgreichen Import muss die Datendatei folgenden Bedingungen entsprechen:

In der ersten Zeile der Exceldatei müssen die zu importierenden AD-Attribute angegeben werden. Welche Attribute hinter den Feldnamen stecken, erfährt man in diesem Artikel:

Die Active Directory-Attribute hinter den Feldnamen
Zwingende- und Mindestangaben für den Import von Benutzern und Gruppen sind: DN, objectClass und sAMAccountName. Für den Import von Organisationseinheiten (OUs) sind es die beiden Attribute DN und objectClass.
Die Reihenfolge in der die Attribute in der ersten Zeile angegeben werden, spielt keine Rolle.
Die Reihenfolge der Werte bzw. Feldinhalte ab der zweiten Zeile in der Datendatei, müssen allerdings mit der ersten übereinstimmen.
Sollen neben Benutzern auch Gruppen importiert werden, in denen die zu importierenden Benutzer Mitglied sein sollen, so müssen die Benutzereinträge vor den Gruppeneinträgen in der Datendatei enthalten sein. Oder wenn auch die OU importiert werden soll, in der die Benutzer und Gruppen erstellt werden sollen, so muss der Eintrag zum erstellen der OU ebenfalls vor den Benutzer- und Gruppenobjekten zuerst in der Datendatei enthalten sein. Beide Fälle sind in diesem Beispiel aufgeführt.
Wird ein Wert für ein angegebenes Attribut nicht eingetragen, muss es dennoch in der Datendatei durch ein Komma angegeben werden.
Systemattribute wie z.B. die ObjectSID oder ObjectGUID können nicht importiert werden. Wie es der Name „Systemattribute“ schon verrät, sind das Attribute die vom System vergeben werden.
Die Exceldatei könnte z.B. so aussehen:
Ist die Exceldatei fertiggestellt, muss diese als CSV-Datei abgespeichert werden. Dazu klickt man in Excel in der Menüleiste auf das Diskettensymbol oder verwendet das Tastaturkürzel „STRG + S“. Das Fenster „Speichern unter“ öffnet sich. Als Dateityp wählt man die Option „CSV (Trennzeichen-getrennt)(*.csv)“ aus und vergibt einen Dateinamen. Mit einem Klick auf Speichern folgt eine Warnung die darauf hinweist, dass der gewählte Dateityp keine Arbeitsmappen mit mehreren Blättern unterstützt und deshalb nur das aktuelle Blatt gespeichert wird. Mit einem Klick auf OK erscheint eine weitere Information die darauf hinweist, dass in der CSV-Datei Merkmale enthalten sein können, die mit „CSV (Trennzeichen-getrennt)“ nicht kompatibel sind. Mit einem Klick auf „Ja“ wird nun endlich die CSV-Datei gespeichert.
Nun muss die CSV-Datei mit dem „Editor“ (Notepad) noch bearbeitet werden. Mit einem Rechtsklick auf die CSV-Datei wählt man à Öffnen mit à Editor. Danach öffnet sich die CSV-Datei im Editor.
Als Trennzeichen verwendet Excel das Semikolon (;), das durch das Komma (,) ersetzt werden muss. Dies kann man am einfachsten, wenn man im Editor auf Bearbeiten – Ersetzen… klickt. Dort gibt man dann im Feld „Suchen nach“ das Semikolon an und im Feld „Ersetzen durch“ das Komma. Anschließend werden mit einem Klick auf „Alle ersetzen“ die Änderungen durchgeführt.
Werte die selbst ein Komma enthalten, müssen in Anführungszeichen (im Volksmund auch als „Gänsefüßchen“ bekannt) gesetzt werden. Das kann man ebenfalls durch die Ersetzen-Funktion im Editor durchführen. In diesem Beispiel müssen die Werte von DN, displayName und Member in Anführungszeichen gesetzt werden.

Vorsicht: Importiert man so wie in diesem Beispiel auch eine Gruppe in der ebenfalls die zu importierenden Benutzer Mitglied sein sollen, müssen die DNs der Benutzer zwingend durch eine Semikolon getrennt werden. Des Weiteren darf das Anführungszeichen nur am Anfang und am Ende der Einträge stehen. Also: „<DN Benutzer1>;<DN Benutzer2>;<DN Benutzer3>“.
Die fertige Datendatei sieht dann wie folgt aus:
Die gelben Markierungen in dem Beispiel kennzeichnen die Werte die Kommas enthalten und somit in Anführungszeichen gesetzt werden müssen und die roten Markierungen kennzeichnen die nicht enthaltenen Werte, die trotzdem durch ein Komma gesetzt werden müssen.
Zur Vollständigkeit, hier der komplette Inhalt der Datendatei:

DN,objectClass,givenname,sn,displayname,description,sAMAccountName,userPrincipalName,Member,groupType,userAccountControl
"OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",organizationalUnit,,,,,,,,,
"CN=Sabine Mueller,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Sabine,Mueller,"Mueller, Sabine",Festangestellte,sabine,sabine@ad2008r2.dikmenoglu.de,,,544
"CN=Klara Tolle,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Klara,Tolle,"Tolle, Klara",,Klara,Klara@ad2008r2.dikmenoglu.de,,,544
"CN=Simone Wagner,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Simone,Wagner,"Wagner, Simone",Aushilfe,Simone,Simone@ad2008r2.dikmenoglu.de,,,544
"CN=Maria Schmitt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Maria,Schmitt,"Schmitt, Maria",,Maria,Maria@ad2008r2.dikmenoglu.de,,,544
"CN=Bettina Bauer,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Bettina,Bauer,"Bauer, Bettina",Befristet,Bettina,Bettina@ad2008r2.dikmenoglu.de,,,544
"CN=Andrea Schmidt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Andrea,Schmitt,"Schmitt, Andrea",,Andrea,Andrea@ad2008r2.dikmenoglu.de,,,544
"CN=Sonja Neu,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Sonja,Neu,"Neu, Sonja",Praktikant,Sonja,Sonja@ad2008r2.dikmenoglu.de,,,544
"CN=Silke Vogt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Silke,Vogt,"Vogt, Silke",Festangestellte,Silke,Silke@ad2008r2.dikmenoglu.de,,,544
"CN=AD-Consultants,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",group,,,,,AD-Consultants,,"CN=Sabine Mueller,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de;CN=Silke Vogt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",-2147483644,
Die Datendatei kann dann mit diesem Befehl importiert werden:
Csvde -i -f C:\Datendatei.txt
Wenn beim Import ein Fehler auftritt, sollte man den Parameter -j verwenden damit die beiden Protokolldateien erstellt werden, um dann dem Fehler auf die Schliche zu kommen. Der Befehl würde dann so aussehen:
Csvde -i –v -f C:\Datendatei.txt –j C:\

Mit dem Attribut userAccountControl den Kennwortstatus der zu importierenden Benutzer steuern

Gibt man beim Import von Benutzern das Attribut userAccountControl in der Datendatei nicht oder mit dem Wert 514 an, erhält man anschließend deaktivierte Benutzer im AD. Denn wie bereits anfangs in diesem Artikel erwähnt, kann CSVDE keine Kennwörter setzen, was zwingend notwendig ist um hinterher aktive Benutzer zu erhalten. Der Wert 512 im userAccountControl würde zwar aktive Benutzer erstellen, jedoch reicht dass alleine nicht aus, da auch hierbei kein Kennwort vergeben wird. Das Deaktivieren der Kennwortrichtlinie würde zwar den gewünschten Erfolg bringen, nämlich nach dem Import aktivierte Benutzer im AD zu erhalten, jedoch ist das in einer produktiven Umgebung keineswegs empfohlen! Das ist höchstens für eine Testumgebung zulässig!

Aber das Abschalten der Kennwortrichtlinie ist auch nicht notwendig. Bekanntlich besteht das userAccountControl aus einer Bitmaske, bestehend aus mehreren Flags. Kombiniert man zwei davon, erhält man nach dem Import aktivierte Benutzer ohne ein Kennwort vergeben zu haben!

Kombiniert man die beiden Flags:

NORMAL_ACCOUNT	512
PASSWD_NOTREQD	32

und trägt in der Datendatei als Wert für userAccountControl 544 ein (wie im o.g. Beispiel), erhält man aktive Benutzerkonten im AD!

Die Benutzer melden sich ohne ein Kennwort an und werden direkt aufgefordert ein neues Kennwort zu vergeben. Denn das userAccountControl mit dem Wert 544 in den Benutzerobjekten aktiviert die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“.

How to use the UserAccountControl flags to manipulate user account properties >

Gruppen mit CSVDE importieren

Die Werte die in der Datendatei für einen Import von Gruppen zwingend angegeben werden müssen sind: DN,objectClass und sAMAccountName. Somit werden aber lediglich „globale Sicherheitsgruppen“ erstellt. Daher ist es ratsam noch das Attribut groupType anzugeben, um den „Gruppenbereich“ und „Gruppentyp“ zu bestimmen.

Der Import der Datendatei erfolgt mit diesem Befehl:
Csvde -i -f C:\Gruppen.txt

Beispiele einer Datendatei zum Import von Gruppen

# Eine domänenlokale Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=DLSG,OU=<OU>,DC=Domäne,DC=de",group,DLSG,-2147483644

# Eine globale Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName
„CN=GG1,OU=<OU>,DC=Domäne,DC=de“,group,GG1

Oder:
DN,objectClass,sAMAccountName,groupType
„CN=GG1,OU=<OU>,DC=Domäne,DC=de“,group,GG1,-2147483646

# Eine universelle Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=USG,OU=<OU>,DC= Domäne,DC=de ",group,USG,-2147483640

# Eine domänenlokale Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=DLVG,OU=<OU>,DC= Domäne,DC=de ",group,DLVG,4

# Eine globale Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=GVG,OU=<OU>,DC= Domäne,DC=de ",group,GVG,2

# Eine universelle Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=UVG,OU=<OU>,DC= Domäne,DC=de ",group,UVG,8 >

Einen Export mit CSVDE durchführen

CSVDE wird standardmäßig ohne die Angabe eines Parameters im Export-Modus ausgeführt. Die Kunst beim Export ist es, lediglich die Informationen zu exportieren die von Interesse sind. Daher ist das entscheidende beim Export der Filter, der mit dem Parameter -r eingeleitet wird und die Attribute, die mit dem Parameter –l angegeben werden.

Beispiel Exportbefehle:

# Alle Benutzer mit den Attributen sAMAccountName und name exportieren:
Csvde -m -n -u -f C:\AlleBenutzer.txt -r "(&(objectclass=user)(objectcategory=person))" -l sAMAccountName,name

# Alle Benutzer aus einer OU mit den Attributen sAMAccountName und name exportieren:
Csvde -m -n -u -f C:\ExportBenutzer.txt -s DCON01 -d "OU=<OU>,DC=Domäne,DC=TLD" –p OneLevel –r "(&(objectClass=user)(objectcategory=person))" -l sAMAccountName,name

# Alle Kontakte mit den angegebenen Attributen exportieren:
Csvde -m -n -u -r "(objectClass=Contact)" -d "OU=<OU>,DC=Domäne,DC=de" -l displayname,telephoneNumber,othertelephone,mobile,homePhone,Pager,facsimileTelephoneNumber,ipPhone,otherHomePhone,otherPager,otherMobile,otherFacsimileTelephoneNumber,otherIpPhone -f C:\Kontakte.txt

# Mitglieder einer bestimmten Gruppe exportieren:
Csvde -m -n -u -f C:\Benutzer.txt -r "(&(objectcategory=user)(memberof=CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de))" -l samaccountname,name

# Alle Benutzer anzeigen, die NICHT Mitglied einer bestimmten Gruppe sind:
Csvde –m –n –u –f C:\Benutzer.txt -r „(&(objectCategory=person)(objectClass=user)(!memberof=CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de))“ –l name,sAMAccountName

# Alle Benutzer mit ihrem DN und dem LastLogon exportieren:
Csvde -m -n -u -f C:\Benutzer.txt -r "(&(objectClass=user)(objectCategory=person))" -l DN,LastLogon

Der Wert von LastLogon kann dann folgendermaßen in unsere Zeitangabe umgerechnet werden:

Einen Large Integer Wert umrechnen

# Alle Benutzer mit ihrem Anmeldenamen und dem eingetragenen Anmeldeskript exportieren:
Csvde -f C:\BenutzermitAnmeldeskript.txt -r "(&(objectClass=user)(scriptPath=*))" -l sAMAccountName,scriptPath

# Alle Benutzerobjekte exportieren, die NICHT deaktiviert sind (also aktive Benutzer):
Csvde -m -n -u -f C:\AktiveBenutzer.txt -r "(&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" –l sAMAccountName,name

# Alle Benutzer exportieren und überprüfen, bei wem die Option „Zugriff gestatten“ im Reiter „Einwählen“ aktiviert ist. Steht als Wert TRUE, ist die Option aktiviert:
Csvde -f C:\Ras.txt -u -r "(&(objectClass=user)(objectCategory=person))" -l name,sAMAccountName,msNPAllowDialin

# Alle deaktivierten Computerkonten exportieren:
Csvde –f C:\DeaktiviertePCs.txt –r „(&(objectclass=computer)(userAccountControl:1.2.840.113556.1.4.803:=2))“ –l DN

# Alle Public Folder exportieren:
Csvde -m -n -u -f C:\PublicFolders.txt -r "(objectClass=publicFolder)" -l name

# Alle SMTP-Adressen exportieren:
Csvde -m -n -u -f C:\SMTPList.txt -d "DC=Domäne,DC=de" -L proxyaddresses –r "(proxyaddresses=*smtp:*@*)"

Weitere Filter können aus diesem Artikel entnommen werden:

Gespeicherte Abfragen

Eine Datendatei mit Excel, zum Import mit der AD-PowerShell erstellen

Auch mit der AD-PowerShell können beliebige Objekte, wie beispielsweise Organisationseinheiten (OU), Benutzer-, Gruppen- und Computerkonten ins AD importiert werden. Für den erfolgreichen Import mit der AD-PowerShell wird zum einen eine Datendatei mit den korrekten Angaben benötigt und zum zweiten, der AD-PowerShell Befehl mit dem der Import durchgeführt wird.

Für das Erstellen einer Datendatei um Benutzerobjekte in Verbindung mit der AD-PowerShell zu importieren, gilt es folgendes zu beachten: >

In der ersten Zeile müssen die Felder stehen, für die man einen Wert eintragen möchte. Möchte man Benutzer importieren, ist es hilfreich sich in der AD-PowerShell mit dem Befehl Get-Help New-ADUser -detailed die Syntax des Cmdlets anzuschauen. Dort werden die genauen Feldbezeichnungen genannt, wie es die AD-PowerShell in der Datendatei gerne hätte. Die Angaben unterscheiden sich teilweise von den unter CSVDE, da die AD-PowerShell nicht den LDAP-Display-Name eines Attributs verwendet (anstatt „sn“ für Nachname möchte die AD-PowerShell die Angabe „surname“)
Zwingend notwendige und die Mindestangaben für den Import von Benutzerobjekten sind: Path, Name und sAMAccountName. Für Gruppenobjekte sind es die Werte: Path, GroupScope, Name und sAMAccountName.
Im Gegensatz zu CSVDE darf es nicht DN (für Distinguished Name) heißen, sondern muss Path lauten. Dabei darf auch nicht das eigentliche Objekt (sprich der RDN) mit angegeben werden. Des Weiteren ist auch die Angabe von objectClass (oder userAccountControl) nicht notwendig, da durch das Cmdlet New-ADUser die Information bereits mitgegeben wird.
In welcher Reihenfolge die Felder in der ersten Zeile angegeben werden, spielt keine Rolle. Die Reihenfolge der Werte bzw. Feldinhalte ab der zweiten Zeile müssen jedoch mit der ersten übereinstimmen.
Wird ein Wert für ein angegebenes Feld nicht eingetragen, muss es dennoch in der Datendatei durch ein Komma angegeben werden.
Systemattribute wie z.B. die ObjectSID oder ObjectGUID können nicht importiert werden. Wie es der Name „Systemattribute“ schon verrät, sind das Attribute die vom System vergeben werden.
Beispielsweise könnte die Excel-Datei wie folgt aussehen:
Ist die Exceldatei fertiggestellt, gilt es diese als CSV-Datei abzuspeichern. Dazu klickt man in Excel in der Menüleiste auf das Diskettensymbol oder verwendet das Tastaturkürzel „STRG + S“. Das Fenster „Speichern unter“ öffnet sich. Als Dateityp wählt man die Option „CSV (Trennzeichen-getrennt)(*.csv)“ aus und vergibt einen Dateinamen. Es folgt eine Warnung die darauf hinweist, dass der gewählte Dateityp keine Arbeitsmappen mit mehreren Blättern unterstützt und deshalb nur das aktuelle Blatt gespeichert wird. Mit einem Klick auf OK erscheint eine weitere Information die darauf hinweist, dass in der CSV-Datei Merkmale enthalten sein können, die mit „CSV (Trennzeichen-getrennt)“ nicht kompatibel sind. Mit einem Klick auf „Ja“ wird nun endlich die CSV-Datei gespeichert.
Nun muss die CSV-Datei mit dem „Editor“ (Notepad) noch bearbeitet werden. Mit einem Rechtsklick auf die CSV-Datei wählt man à Öffnen mit à Editor. Danach öffnet sich die CSV-Datei im Editor.
Excel verwendet nämlich als Trennzeichen das Semikolon (;), das durch das Komma (,) ersetzt werden muss. Dies kann man am einfachsten, wenn man im Editor auf Bearbeiten – Ersetzen… klickt. Dort gibt man dann im Feld „Suchen nach“ das Semikolon an und im Feld „Ersetzen durch“ das Komma. Anschließend werden mit einem Klick auf „Alle ersetzen“ die Änderungen durchgeführt.
Werte die selbst ein Komma enthalten, müssen in Anführungszeichen (im Volksmund auch als „Gänsefüßchen“ bekannt) gesetzt werden. Das kann man ebenfalls durch die Ersetzen-Funktion im Editor durchführen. In diesem Beispiel müssen die Werte von „Path“ sowie „Name“ in Anführungszeichen gesetzt werden.
Die fertige Datendatei sieht dann wie folgt aus:
Die gelben Markierungen in dem Beispiel kennzeichnen die Werte die Kommas enthalten und somit in Anführungszeichen gesetzt werden müssen und die roten Markierungen kennzeichnen die nicht enthaltenen Werte, die trotzdem durch ein Komma gesetzt werden müssen. In diesem Fall sind es die Felder „description“ und „HomePage“.
Zur Vollständigkeit, hier der komplette Inhalt der Datendatei:

Path,name,givenname,surname,displayname,description,Office,emailaddress,HomePage,streetAddress,pobox,city,state,postalCode,country,userPrincipalName,sAMAccountName,profilePath,scriptPath,title,department,company
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Mueller, Sabine",Sabine,Mueller,Sabine Mueller,Festangestellte,Buero Mainz,s.mueller@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sab@ad2008r2.dikmenoglu.de,sab,\\Server\Profile\smueller,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Tolle, Klara",Klara,Tolle,Klara Tolle,,Buero Frankfurt,k.tolle@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,kla@ad2008r2.dikmenoglu.de,kla,\\Server\Profile\ktolle,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Wagner, Simone",Simone,Wagner,Simone Wagner,Aushilfe,Buero Istanbul,s.wagner@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sim@ad2008r2.dikmenoglu.de,sim,\\Server\Profile\swagner,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Schmitt, Maria",Maria,Schmitt,Maria Schmitt,,Buero Berlin,m.schmitt@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,mar@ad2008r2.dikmenoglu.de,mar,\\Server\Profile\mschmitt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Bauer, Bettina",Bettina,Bauer,Bettina Bauer,Befristet,Buero Muenchen,b.bauer@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,bet@ad2008r2.dikmenoglu.de,bet,\\Server\Profile\bbauer,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Schmidt, Andrea",Andrea,Schmidt,Andrea Schmidt,,Buero Hamburg,a.schmidt@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,and@ad2008r2.dikmenoglu.de,and,\\Server\Profile\aschmidt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Neu, Sonja",Sonja,Neu,Sonja Neu,Praktikantin,Buero Stuttgart,s.neu@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,son@ad2008r2.dikmenoglu.de,son,\\Server\Profile\sneu,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Vogt, Silke",Silke,Vogt,Silke Vogt,Festangestellte,Buero Dresden,s.vogt@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sil@ad2008r2.dikmenoglu.de,sil,\\Server\Profile\svogt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH

Das Importieren der Datendatei mit der AD-PowerShell

Zum importieren von Benutzerobjekten mit der AD-PowerShell hat man folgende Möglichkeiten.

Variante 1

Der AD-PowerShell Befehl mit dem die Datendatei ins AD importiert wird sieht so aus:

Import-CSV C:\Massenimport.csv | New-ADUser -AccountPassword (ConvertTo-SecureString –AsPlainText “Pa$$w0rd!” -Force) -Enabled:$true -ChangePasswordAtLogon:$true

Wie unschwer aus dem Befehl zu erkennen ist, wird mit dem Cmdlet Import-CSV der Inhalt der Datendatei Massenimport.csv durch die Pipeline-Funktion (|) der AD-PowerShell, in das Cmdlet New-ADUser gepiped. Der Vorteil der AD-PowerShell gegenüber CSVDE ist, dass mit CSVDE keine Kennwörter gesetzt werden können, mit der AD-PowerShell aber sehr wohl! Mit diesem AD-PowerShell Befehl erhält jeder Benutzer das Startkennwort Pa$$w0rd!. Durch die Angabe von -Enabled:$true erhält man nach dem Import aktivierte Benutzer (wozu zwingend ein Kennwort vergeben werden muss). Die Angabe von -ChangePasswordAtLogon:$true aktiviert bei allen importierten Benutzern die Kontooption Benutzer muss Kennwort bei der nächsten Anmeldung ändern.

Variante 2

Eine andere Variante zum importieren von Benutzerobjekten mit dem gleichen Ergebnis, ist dieser Befehl:

Import-Csv C:\Massenimport.csv | Foreach { New-ADUser -Path $_.path -Name $_.name -givenname $_.givenname -surname $_.surname -displayname $_.displayname -office $_.office -emailaddress $_.emailaddress -HomePage $_.HomePage -streetaddress $_.streetaddress -pobox $_.pobox -city $_.city -state $_.state -postalCode $_.postalCode -userPrincipalName $_.userPrincipalName -sAMAccountName $_.sAMAccountName -profilePath $_.profilePath -scriptPath $_.scriptPath -title $_.title -department $_.department -company $_.company -PasswordNotRequired:$true -Enabled:$true }

Die Parameter wie z.B. „-Path $_.path“ entsprechen den Angaben aus der ersten Zeile der Datendatei. Dabei spielt die Reihenfolge bei der Angabe der Werte keine Rolle. Z.B. könnte die erste Zeile in der Datendatei so aussehen: sAMAccountName,Path,Name,… und der Befehl wie folgt:
Import-Csv C:\Massenimport.csv | Foreach { New-ADUser -Name $_.name –sAMAccountName $_.sAMAccountName -Path $_.path …

Die Hauptsache ist, es werden alle Felder im Befehl angegeben, die auch in der Datendatei enthalten sind.

Auch mit diesem Befehl erhält man nach dem Import aktivierte Benutzerkonten im AD! Denn der Parameter -PasswordNotRequired:$true bewirkt nichts anderes, als das im Attribut userAccountControl im Benutzerobjekt als Wert 544 eingetragen wird. Das userAccountControl besteht nämlich aus einer Bitmaske, bestehend aus mehreren Flags.

Der Parameter -PasswordNotRequired mit dem Wert $true kombiniert diese beiden Flags:

NORMAL_ACCOUNT

512

PASSWD_NOTREQD

32

Doch der Eintrag -PasswordNotRequired:$true alleine reicht nicht aus, um aktivierte Benutzerkonten zu erhalten. Es muss zwingend noch der Parameter mit dem Wert -Enabled:$true eingegeben werden. Erst dadurch sind die Benutzerkonten aktiv.

Die Benutzer melden sich dann ohne ein Kennwort an und werden direkt aufgefordert ein neues Kennwort zu vergeben. Denn der Wert 544 im userAccountControl aktiviert bei jedem importierten Benutzerobjekt die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“.

How to use the UserAccountControl flags to manipulate user account properties>

Variante 3 >

Eine weitere Möglichkeit und recht simpel noch dazu, stellt dieser Befehl zum importieren von Benutzerobjekten dar:

Import-Csv -Path C:\Massenimport.txt | New-ADUser -PasswordNotRequired:$true -Enabled:$true

Auch bei diesem Befehl erhält man anschließend aktive Benutzerkonten im AD. Die Benutzer melden sich dann ohne ein Kennwort an der Domäne an und werden direkt aufgefordert
ein neues Kennwort zu vergeben.

Gruppen mit der AD-PowerShell importieren>

Die Werte die in der Datendatei für einen Import von Gruppen zwingend angegeben werden müssen sind: Path, GroupScope, Name und sAMAccountName. Somit werden lediglich Sicherheitsgruppen erstellt. Daher ist es ratsam noch GroupCategory anzugeben, um den „Gruppentyp“ zu bestimmen.

Der Import der Datendatei erfolgt mit diesem Befehl:
Import-CSV C:\Gruppen.csv | New-ADGroup

Beispiele einer Datendatei zum Import von Gruppen:

# Eine domänenlokale Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,domainlocal,DLSG1,DLSG1,Vertrieb

# Eine globale Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,global,GSG1,GSG1,Buchhaltung

# Eine universelle Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,universal,USG1,USG1,Einkauf

# Eine domänenlokale Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,domainlocal,DLVG1,DLVG1,Key Account

# Eine globale Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,global,GVG1,GVG1,Techniker

# Eine universelle Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,universal,UVG1,UVG1,Support

Einen Export mit der AD-PowerShell durchführen

Wie mit jedem Werkzeug mit dem man einen Export durchführt, kommt es auch bei der AD-PowerShell auf die gewünschten Informationen und somit auf den Filter an. Wird ein „falscher“ Filter genutzt, bekommt man unter Umständen gar keine Informationen exportiert. Nutzt man hingegen einen „ungenauen“ Filter, erhält man diesmal ggf. zu viele Informationen die es dann mühselig zu durchforsten gilt. Die wichtigste Aufgabe beim Export ist es zu definieren, welche Informationen benötigt werden und dann den Filter (sofern möglich) zu bauen.

Die folgenden Beispiele zeigen jeweils eine LDAP-Abfrage, die dann durch die Pipeline-Funktion der AD-PowerShell an das Cmdlet Export-Csv übergeben und somit die Ausgabe exportiert wird.

Export Beispiele

# Alle Benutzer aus einer OU mit allen Eigenschaften exportieren:
Get-ADUser -Filter * -Searchbase "OU=<OU>,DC=Domäne,DC=de" -Properties * | Export-Csv C:\Export.txt -NoTypeInformation

Hinweis: Nutzt man das Cmdlet Get-ADUser um Benutzerinformationen zu exportieren, werden in jedem Fall diese Attribute ausgegeben: DistinguishedName, Enabled, givenName, Name, ObjectClass, ObjectGUID, SamAccountName, ObjectSID, Surname, userPrincipalName. Gibt man beim Parameter -Properties eigene Attribute an, werden diese zusätzlich zu den bereits genannten Attributen mit ausgegeben.

# Alle Benutzerkonten exportieren, die als Vorgesetzten „Yusuf“ eingetragen haben:
Get-ADUser -Filter { Manager -eq "Yusuf" } | Export-Csv C:\Export.txt -NoTypeInformation

# Alle Organisationseinheiten (OU) der Domäne exportieren:
Get-ADOrganizationalUnit -Filter {Name -Like „*“} | Export-Csv C:\OUs.txt -NoTypeInformation

# Alle Objekte einer OU exportieren:
Get-ADObject -Filter { Name -Like "*" } -Searchbase "OU=<OU>,DC=Domäne,DC=de” | Export-Csv -NoTypeInformation C:\AlleObjekte.txt

# Alle Attribute und Klassen eines Active Directory exportieren:
Get-ADObject -Filter { Name -Like “*” } -SearchBase “CN=Schema,CN=Configuration,DC=Domäne,DC=de” | Export-Csv -NoTypeInformation C:\Schema.txt

AD-PowerShell Befehle>

Eine Datendatei in Excel importieren

In Excel lässt sich eine Datendatei wie folgt importieren:

Unter Excel 2007 wählt man in der Menüleiste zuerst „Daten“ und danach die Option „Aus Text“ aus.
Danach muss man die zu importierende Textdatei auswählen. Das kann eine CSV- oder TXT-Datei sein. Anschließend startet der Textkonvertierungs-Assistent.
Im Textkonvertierungs-Assistenten wählt man die Option Getrennt aus und klickt auf Weiter.
Im nächsten Schritt wählt man als Trennzeichen die Option Komma und als Texterkennungszeichen das Anführungszeichen aus (was standardmäßig eingestellt ist) aus.
Im darauffolgenden Schritt gilt es als Datenformat der Spalten die Option Standard zu wählen.
Zum Schluss bestätigt man, dass der Import im bestehenden Arbeitsblatt ab der ausgewählten Zelle durchgeführt werden soll.

Weitere Informationen:
How to use CSVDE.EXE to back up and restore connection agreements
>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Alle Gruppenmitgliedschaften eines Benutzers exportieren

Yusuf Dikmenoglu — Sun, 22 Nov 2009 20:49:32 GMT

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
> >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die konstruierten Attribute abfragen

Yusuf Dikmenoglu — Sun, 08 Nov 2009 16:14:39 GMT

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 >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den OS- und SP-Stand abfragen

Yusuf Dikmenoglu — Fri, 02 Oct 2009 10:57:55 GMT

Es gibt verschiedene Möglichkeiten nach Computern die ein bestimmtes Betriebssystem sowie Service Pack installiert haben zu suchen. Die Attribute in denen diese Informationen enthalten sind wären: OperatingSystem, OperatingSystemVersion und OperatingSystemServicePack.

Es ist empfehlenswert das Attribut OperatingSystem bei der Abfrage zu verwenden und nicht nur(!) das Attribut OperatingSystemVersion. Denn die Versionsnummer lautet je nach Betriebssystem sowie Service Pack zwischen Servern und Clients gleich.

Z.B. lautet die Versionsnummer zwischen „Windows Vista SP1“ und „Windows Server 2008 SP1“ bei beiden Betriebssystemen „6.0 (6001)“. Auf einem „Windows Vista SP2“ und einem „Windows Server 2008 SP2“ lautet die Versionsnummer bei beiden Betriebssystemen „6.0 (6002)“. Oder zwischen einem „Windows Server 2008 R2“ und „Windows 7“ jeweils ohne Service Pack, lautet die Versionsnummer bei beiden Betriebssystemen gleich „6.1 (7600)“.

Hinweis: Die genaue Schreibweise welches Betriebssystem sowie Service Pack installiert ist, erfährt man neben der Versionsnummer in der MMC Active Directory-Benutzer und -Computer (dsa.msc). Dort werden die Informationen in den Eigenschaften eines Computerkontos im Reiter „Betriebssystem“ angezeigt.

In der AD-PowerShell unter Windows Server 2008 R2 und Windows 7

# Alle Computerobjekte zusätzlich mit den Werten Betriebssystem, Version und Service Pack anzeigen:
Get-ADComputer –Filter {Name –Like „*“} –Properties OperatingSystem, OperatingSystemVersion, OperatingSystemServicePack

# Es ist auch möglich die Ausgabe in eine CSV-Datei zu exportieren, um diese z.B. in Excel weiterzuverarbeiten. Exportieren lässt sich das Ergebnis dank der Pipeline-Fähigkeit der AD-PowerShell und dem Cmdlet Export-CSV wie folgt:
Get-ADComputer –Filter {Name –Like „*“} –Properties OperatingSystem, OperatingSystemVersion, OperatingSystemServicePack | Export-CSV Computer.csv

Nach Windows Server 2008 R2 suchen

# Alle Computerobjekte in der Domäne mit dem Betriebssystem „Windows Server 2008 R2“ (alle Versionen) anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server 2008 R2*“}

# Alle Computerobjekte in der Domäne nur mit dem Betriebssystem „Windows Server 2008 R2 Standard“ anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server 2008 R2 Standard“}

# Alle Computerobjekte mit dem Betriebssystem „Windows Server 2008 R2“ (alle Versionen) aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server 2008 R2*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle „Windows Server 2008 R2“ (alle Versionen) Computerobjekte mit einem bestimmten Service Pack aus einer OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server 2008 R2*“ –and OperatingSystemServicePack –eq „Service Pack x“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

Nach Windows Server 2008 suchen

# Um lediglich „Windows Server® 2008 Standard“ Computerobjekte mit Service Pack 1 einer Domäne anzuzeigen, kann dieser Befehl verwendet werden:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server® 2008 Standard“ –and OperatingSystemServicePack –eq „Service Pack 1“}

Hinweis: Das ® Symbol kann per Copy&Paste in die AD-PowerShell kopiert werden.

# Alle “Windows Server 2008” (alle Versionen) Computerobjekte, egal welches Service Pack installiert ist einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –Like „6.0*“}

# Alle “Windows Server 2008” (alle Versionen) Computerobjekte mit Service Pack 1 einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –eq „6.0 (6001)“}

# Alle „Windows Server 2008“ (alle Versionen) Computerobjekte mit „Service Pack 2“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server*“ –and OperatingSystemVersion –eq „6.0 (6002)“}

# Alle Computerobjekte mit dem Betriebssystem „Windows Server 2008“ (alle Versionen), egal welches Service Pack installiert ist aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –Like „6.0*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle „Windows Server® 2008 Standard“ Computerobjekte mit „Service Pack 2“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server® 2008 Standard“ –and OperatingSystemServicePack –eq „Service Pack 2“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle „Windows Server 2008“ (alle Versionen) Computerobjekte mit „Service Pack 1“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –eq „6.0 (6001)“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle „Windows Server 2008“ (alle Versionen) Computerobjekte mit „Service Pack 2“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –eq „6.0 (6002)“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

Nach Windows Server 2003 suchen

# Um lediglich „Windows Server 2003“ Computerobjekte einer Domäne anzuzeigen, kann dieser Befehl verwendet werden:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server 2003“}

Hinweis: Unter „Windows Server 2003“ unterscheidet Microsoft im Attribut OperatingSystem nicht zwischen „Standard“ oder „Enterprise“.

# Alle Computerobjekte mit „Windows Server 2003“ und dem „Service Pack 2“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server 2003“ –and OperatingSystemServicePack –eq „Service Pack 2“}

# Alle Computerobjekte mit dem Betriebssystem „Windows Server 2003“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server 2003“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle Computerobjekte mit „Windows Server 2003“ und dem „Service Pack 2“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server 2003“ –and OperatingSystemServicePack –eq „Service Pack 2“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

Nach Windows 2000 Server oder Clients suchen

# Alle „Windows 2000“ Computerobjekte (Clients und Server) einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 2000*“}

# Alle „Windows 2000 Server“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Server“}

# Alle „Windows 2000 Server“ mit „Service Pack 4“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Server“ –and OperatingSystemServicePack –eq „Service Pack 4“}

# Alle „Windows 2000 Server“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Server“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle “Windows 2000 Server“ mit „Service Pack 4“ aus einer OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Server“ –and OperatingSystemServicePack –eq „Service Pack 4“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle „Windows 2000 Professional“ Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Professional“}

# Alle „Windows 2000 Professional“ mit „Service Pack 4“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Professional“ –and OperatingSystemServicePack –eq „Service Pack 4“}

# Alle „Windows 2000 Professional“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Professional“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle „Windows 2000 Professional“ mit „Service Pack 4“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Professional“ –and OperatingSystemServicePack –eq „Service Pack 4“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

Nach Windows XP suchen

# Alle Windows XP Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows XP*“}

# Alle Windows XP Clients mit „Service Pack 2“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows XP*“ –and OperatingSystemServicePack –eq „Service Pack 2“}

# Alle Windows XP Clients aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows XP*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle Windows XP Clients mit “Service Pack 3” aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows XP*“ –and OperatingSystemServicePack –eq „Service Pack 3“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

Nach Windows Vista suchen

# Alle Windows Vista Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista*“}

# Alle Windows Vista Clients mit „Service Pack 1“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista*“ –and OperatingSystemServicePack –eq „Service Pack 1“}

# Alle Windows Vista Ultimate Clients mit „Service Pack 1“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista* Ultimate“ –and OperatingSystemServicePack –eq „Service Pack 1“}

# Alle Windows Vista Clients aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle Windows Vista Clients mit “Service Pack 2” aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista*“ –and OperatingSystemServicePack –eq „Service Pack 2“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

Nach Windows 7 suchen

# Alle Windows 7 Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 7*“}

# Alle Windows 7 Ultimate Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 7 Ultimate“}

# Alle Windows 7 Clients mit einem bestimmten Service Pack einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 7*“ –and OperatingSystemServicePack –eq „Service Pack x“}

# Alle Windows 7 Clients aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 7*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

# Alle Windows 7 Clients mit “Service Pack 2” aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 7*“ –and OperatingSystemServicePack –eq „Service Pack x“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel

CSVDE

In der Kommandozeile lassen sich die gewünschten Informationen mit CSVDE exportieren. Der Vorteil des Exports mit CSVDE ist, das man die exportierte CSV-Datei mit Excel öffnen und weiterverarbeiten kann.

Windows Server 2008 R2 exportieren

# Alle Windows Server 2008 R2 aus der Domäne exportieren:
Csvde –f Win2008R2.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Server 2008 R2 mit einem bestimmten Service Pack aus der Domäne exportieren:
Csvde –f Win2008R2.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" -l name,dNSHostName

# Alle Windows Server 2008 R2 aus einer OU exportieren:
Csvde -f Win2008R2.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Server 2008 R2 mit einem bestimmten Service Pack aus einer OU exportieren:
Csvde –f Win2008R2.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" -l name,dNSHostName

Windows Server 2008 exportieren

# Alle Windows Server 2008 (und nicht “Windows Server 2008 R2”) aus der Domäne exportieren:
Csvde –f Win2008.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Server 2008 mit Service Pack 1 aus der Domäne exportieren:
Csvde –f Win2008.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)(!OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName

# Alle Windows Server 2008 aus einer OU exportieren:
Csvde -f Win2008.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Server 2008 mit Service Pack 1 aus einer OU exportieren:
Csvde –f Win2008.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)(!OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName

Windows Server 2003 exportieren

# Alle Windows Server 2003 aus der Domäne exportieren:
Csvde –f Win2003.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Server 2003 mit Service Pack 1 aus der Domäne exportieren:
Csvde –f Win2003.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" -l name,dNSHostName

# Alle Windows Server 2003 aus einer OU exportieren:
Csvde -f Win2003.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Server 2003 mit Service Pack 1 aus einer OU exportieren:
Csvde –f Win2003.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" -l name,dNSHostName

Windows 2000 Clients und Server exportieren

# Alle Windows 2000 Clients und Server aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000*))" -l name,dNSHostName,OperatingSystemServicePack

# Nur Windows 2000 Clients und Server mit Service Pack 3 aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000*)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName

# Alle Windows 2000 Clients und Server aus einer OU exportieren:
Csvde –f Win2000.csv –s <DC> –d "OU=<OU>,DC=Domäne,DC=TLD" –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000*))" -l name,dNSHostName,OperatingSystemServicePack

# Nur Windows 2000 Clients und Server mit Service Pack 3 aus einer OU exportieren:
Csvde –f Win2000.csv –s <DC> –d "OU=<OU>,DC=Domäne,DC=TLD" –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000*)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName

# Nur Windows 2000 Server aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows 2000 Server mit Service Pack 3 aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName

# Alle Windows 2000 Server aus einer OU exportieren:
Csvde -f Win2000.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows 2000 Server mit Service Pack 3 aus einer OU exportieren:
Csvde –f Win2000.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName

# Nur Windows 2000 Clients aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional))" -l name,dNSHostName,OperatingSystemServicePack

# Nur Windows 2000 Clients mit Service Pack 3 aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName

# Alle Windows 2000 Clients aus einer OU exportieren:
Csvde -f Win2000.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows 2000 Clients mit Service Pack 3 aus einer OU exportieren:
Csvde –f Win2000.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName

Windows XP Clients exportieren

# Alle Windows XP Clients aus der Domäne exportieren:
Csvde –f WinXP.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows XP*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows XP Clients mit einem bestimmten Service Pack aus der Domäne exportieren:
Csvde -f WinXP.csv -s <DC> -r "(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" -l name,dNSHostName

# Alle Windows XP Clients aus einer OU exportieren:
Csvde -f WinXP.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows XP*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows XP Clients mit Service Pack 2 aus einer OU exportieren:
Csvde –f WinXP.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" -l name,dNSHostName

Windows Vista Clients exportieren

# Alle Windows Vista Clients aus der Domäne exportieren:
Csvde –f Vista.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Vista*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Vista Ultimate Clients aus der Domäne exportieren:
Csvde –f Vista.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Vista* Ultimate))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Vista Clients mit Service Pack 1 aus der Domäne exportieren:
Csvde –f Vista.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" -l name,dNSHostName

# Alle Windows Vista Clients aus einer OU exportieren:
Csvde -f Vista.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows Vista*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows Vista Clients mit Service Pack 1 aus einer OU exportieren:
Csvde –f Vista.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" -l name,dNSHostName

Windows 7 Clients exportieren

# Alle Windows 7 Clients aus der Domäne exportieren:
Csvde –f Win7.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 7*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows 7 Ultimate Clients aus der Domäne exportieren:
Csvde –f Win7.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 7 Ultimate))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows 7 Clients mit einem bestimmten Service Pack aus der Domäne exportieren:
Csvde –f Win7.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" -l name,dNSHostName

# Alle Windows 7 Clients aus einer OU exportieren:
Csvde -f Win7.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows 7*))" -l name,dNSHostName,OperatingSystemServicePack

# Alle Windows 7 Clients mit einem bestimmten Service Pack aus einer OU exportieren:
Csvde -f Win7.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" -l name,dNSHostName

REPADMIN

Die Suche nach Computerobjekten lässt sich auch mit REPADMIN durchführen. Unter Windows 2000 und Windows Server 2003 müssen vorher die Windows Support Tools installiert werden. Ab Windows Server 2008 ist das REPADMIN bereits „on Bord“.

# Das Betriebsystem sowie das Service Pack aller DCs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(primaryGroupID=516))" /subtree /atts:name,OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack

# Das Betriebssystem sowie das Service Pack aller Clients und Mitgliedsserver einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(primaryGroupID=515))" /subtree /atts:name,OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack

Windows Server 2008 R2

# Alle Windows Server 2008 R2 mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows Server 2008 R2 mit einem bestimmten SP einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" /subtree /atts:name

# Sollen die Computerobjekte aus einer bestimmten OU angezeigt werden, so muss anstelle von „ncobj:domain:“ der Distinguished Name der entsprechenden OU angegeben werden. Mit dem folgenden Befehl werden alle Windows Server 2008 R2 mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows Server 2008 R2 mit einem bestimmten SP aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" /subtree /atts:name

Windows Server 2008

# Alle Windows Server 2008 mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

Oder:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0*))" /subtree /atts:name,OperatingSystemServicePack

# Alle Windows Server 2008 mit Service Pack 1 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)(!OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name

# Alle Windows Server 2008 mit ihren installierten SPs aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows Server 2008 mit Service Pack 1 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)(!OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name

Windows Server 2003

# Alle Windows Server 2003 mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows Server 2003 mit Service Pack 1 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" /subtree /atts:name

# Mit dem folgenden Befehl werden alle Windows Server 2003 mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows Server 2003 mit Service Pack 1 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" /subtree /atts:name

Windows 2000 Server

# Alle Windows 2000 Server mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows 2000 Server mit Service Pack 3 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3))" /subtree /atts:name

# Mit dem folgenden Befehl werden alle Windows 2000 Server mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows 2000 Server mit Service Pack 4 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 4))" /subtree /atts:name

Windows 7

# Alle Windows 7 Clients mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows 7 Enterprise Clients mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7 Enterprise))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows 7 Clients mit einem bestimmten Service Pack einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" /subtree /atts:name

# Mit dem folgenden Befehl werden alle Windows 7 Clients mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7*))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows 7 Clients mit einem bestimmten Service Pack aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" /subtree /atts:name

Windows Vista

# Alle Windows Vista Clients mit ihren installierten SPs einer Domäne anzeigen
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Vista*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows Vista Clients mit Service Pack 1 einer Domäne anzeigen
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" /subtree /atts:name

# Mit dem folgenden Befehl werden alle Vista Clients aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows Vista*))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows Vista Clients mit Service Pack 1 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" /subtree /atts:name

Windows XP

# Alle Windows XP Clients mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows XP*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows XP Clients mit Service Pack 2 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" /subtree /atts:name

# Mit dem folgenden Befehl werden alle Windows XP Clients mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows XP*))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows XP Clients mit Service Pack 2 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" /subtree /atts:name

Windows 2000 Professional

# Alle Windows 2000 Clients mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows 2000 Clients mit Service Pack 4 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 4))" /subtree /atts:name

# Mit dem folgenden Befehl werden alle Windows 2000 Clients mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack

# Alle Windows 2000 Clients mit Service Pack 4 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 4))" /subtree /atts:name

DSQUERY

Mit dsquery das erst ab Windows Server 2003 “on Bord” ist, lassen sich ebenfalls die gesuchten Computerobjekte ausfindig machen und zeitgleich auch exportieren.

Windows Server 2008 R2

# Alle Windows Server 2008 R2 einer Domäne exportieren:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0 > C:\dsquery.txt

# Alle Windows Server 2008 R2 mit einem bestimmten Service Pack einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" -attr name distinguishedname –Limit 0

# Alle Windows Server 2008 R2 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server 2008 R2*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0

# Alle Windows Server 2008 R2 mit einem bestimmten Serice Pack aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" -attr name distinguishedName -Limit 0

Windows Server 2008

# Alle Windows Server 2008 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0

# Alle Windows Server 2008 mit Service Pack 1 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0 (6001)))" -attr name distinguishedname –Limit 0

# Alle Windows Server 2008 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0

# Alle Windows Server 2008 mit Serice Pack 1 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0 (6001)))" -attr name distinguishedName -Limit 0

Windows Server 2003

# Alle Windows Server 2003 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))" -attr name OperatingSystemServicePack distinguishedname –Limit 0

# Alle Windows Server 2003 mit Service Pack 1 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" -attr name distinguishedname –Limit 0

# Alle Windows Server 2003 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server 2003))" -attr name OperatingSystemServicePack distinguishedName -Limit 0

# Alle Windows Server 2003 mit Serice Pack 1 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server 2003) (OperatingSystemServicePack=Service Pack 1))" -attr name distinguishedName -Limit 0

Windows 2000

# Alle Windows 2000 Server und Clients einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 2000*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0

# Alle Windows 2000 Server und Clients mit dem Service Pack 3 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 2000*)(OperatingSystemServicePack=Service Pack 3))" -attr name distinguishedname –Limit 0

# Alle Windows 2000 Server und Clients aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows 2000*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0

# Nur Windows 2000 Server mit dem Service Pack 3 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3))" -attr name distinguishedname –Limit 0

# Nur Windows 2000 Clients mit dem Service Pack 3 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 3))" -attr name distinguishedname –Limit 0

Windows XP

# Alle Windows XP Clients einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows XP*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0

# Alle Windows XP Clients mit Service Pack 2 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" -attr name distinguishedname –Limit 0

# Alle Windows XP Clients aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows XP*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0

# Alle Windows XP Clients mit Serice Pack 2 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" -attr name distinguishedName -Limit 0

Windows Vista

# Alle Windows Vista Clients einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Vista*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0

# Alle Windows Vista Clients mit Service Pack 1 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" -attr name distinguishedname –Limit 0

# Alle Windows Vista Clients aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Vista*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0

# Alle Windows Vista Clients mit Serice Pack 1 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" -attr name distinguishedName -Limit 0

Windows 7

# Alle Windows 7 Clients einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 7*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0

# Alle Windows 7 Clients mit einem bestimmten Service Pack einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" -attr name distinguishedname –Limit 0

# Alle Windows 7 Clients aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows 7*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0

# Alle Windows 7 Clients mit einem bestimmten Serice Pack aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" -attr name distinguishedName -Limit 0

Die Active Directory-Suche

Auch in der grafischen Oberfläche kann man nach den gewünschten Computerobjekten suchen. In der MMC Active Directory-Benutzer und -Computer klickt man mit rechts entweder auf den Domänennamen um über alle Container hinweg zu suchen oder auf eine OU, um lediglich in dieser OU zu suchen. Danach ruft man mit einem Klick auf Suchen… das Suchfenster auf.

Im Übrigen ist es auch möglich die AD-Suche direkt aufzurufen, ohne die MMC Active Directory-Benutzer und -Computer zu öffnen. Dazu gilt es mit einem Rechtsklick auf einer freien Fläche auf dem Desktop die Option Neu und anschließend Verknüpfung auszuwählen. Als "Speicherort des Elements" gilt es diesen Eintrag hinzuzufügen: %windir%\System32\rundll32.exe dsquery.dll,OpenQueryWindow (<-- ACHTUNG: Die Schreibweise von "OpenQueryWindow" ist - warum auch immer - "case sensitive"). Im nächsten Schritt gilt es lediglich noch einen Namen für die Verknüpfung zu vergeben und fertig ist die direkte Verknüpfung zur AD-Suche.

Im Suchfenster wählt man als erstes im Feld „Suchen:“ den Eintrag Computer aus. Danach wählt man im Reiter Erweitert mit einem Klick auf Feld z.B. die Option Betriebssystem aus. Anschließend behält man im Feld Bedingung: die Option „Beginnt mit“ bei und gibt im Feld Wert: das gesuchte Betriebssystem ein.

Als Werte könnte man z.B. folgendes eintragen:

- Windows Server 2008 R2*
- Windows Server* 2008*
- Windows Server 2003
- Windows 2000 Server

- Windows 7*
- Windows Vista*
- Windows XP*
- Windows 2000 Professional

Ist die AD-Suche abgeschlossen, sollte man unter Ansicht – Spalten auswählen… die Spalte „Veröffentlicht auf“ hinzufügen. Denn dadurch lässt sich der Container in dem sich das jeweilige Computerobjekt befindet ableiten.

Der Nachteil bei der AD-Suche ist, dass die Ergebnisse nicht exportiert werden können. Wer darauf Wert legt, sollte seine Suche über die „gespeicherte Abfrage“ durchführen.

Die gespeicherte Abfrage

Ab Windows Server 2003 besteht die Möglichkeit die Suche nach bestimmten Computerobjekten, in der MMC Active Directory-Benutzer und -Computer durch eine „gespeichert Abfrage“ durchzuführen.

Weitere Details über die gespeicherten Abfragen erhält man im folgenden Artikel:

Gespeicherte Abfragen

Neben der gleichen Suchmöglichkeit wie bei der AD-Suche, kann man hier eine benutzerdefinierte Suche in der Domäne durchführen. Bei der benutzerdefinierten Suche könnte man z.B. solche LDAP-Filter verwenden:

- (objectCategory=computer)(OperatingSystem=Windows Server 2008 R2*)
- (objectCategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x)
- (objectCategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)
- (objectCategory=computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0*)
- (objectCategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1)
- (objectCategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3)

- (objectCategory=computer)(OperatingSystem=Windows 7*)
- (objectCategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1)
- (objectCategory=computer)(OperatingSystem=Windows XP*)
- (objectCategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 3)

Ist die Suche abgeschlossen, lässt sich das Ergebnis im Menü über Aktion -> Liste exportieren in eine TXT- oder CSV-Datei speichern.

Weitere Informationen:
AD-PowerShell Befehle
Wie finde ich heraus wo sich ein Objekt befindet?

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Wie finde ich heraus wo sich ein Objekt befindet?

Yusuf Dikmenoglu — Wed, 09 Sep 2009 16:16:47 GMT

In kleineren AD-Umgebungen wie sie in „kleineren und mittleren Unternehmen (kurz KMU)“ existieren, weiß der Administrator in welchen Containern im AD sich die entsprechenden AD-Objekte befinden. Doch in größeren und verteilten AD-Umgebungen mit mehreren AD-Administratoren lässt sich das nicht jederzeit sagen.

Um ein AD-Objekt ausfindig zu machen gibt es je nach Betriebssystem verschiedene Möglichkeiten den Distinguished Name (DN) und somit den LDAP-Pfad des gesuchten Objekts mit Bordmitteln anzuzeigen. Der DN gibt dabei den Speicherort des Objekts im AD an.

Die Active Directory Suche in der MMC Active Directory-Benutzer und -Computer (dsa.msc)

Bei der AD-Suche hat man zwei Möglichkeiten den Speicherort des Objekts herauszufinden.

Erste Möglichkeit

In der MMC dsa.msc ruft man mit einem Rechtsklick auf den Domänennamen das Suchfenster auf und gibt z.B. den Common Name (CN) oder sAMAccountName (falls bekannt) des Objekts ein. Es reichen bereits die Anfangsbuchstaben aus wie z.B. „Yus“, um Objekte aufzufinden die mit "Yus" anfangen, da bei der Suche die Ambiguous Name Resolution (ANR) angewendet wird. Die ANR durchforstet bei der Suche unter anderem die folgenden Felder: Vorname, Nachname, Anzeigename sowie den Benutzeranmeldename (Prä-Windows 2000).

Ist die Suche beendet, gilt es im Suchfenster unter Ansicht - Spalten auswählen… eine weitere Spalte hinzuzufügen. Der Name dieser Spalte unterscheidet sich jedoch zwischen den Betriebssystemen.

Unter Windows 2000 und Windows Server 2003 heißt die Spalte X500-definierter Name, unter Windows Server 2008 Definierter Name und unter Windows Server 2008 R2 Distinguished Name. Nach dem hinzufügen der Spalte erscheint im Suchergebnis der DN des Objekts.

Es ist auch möglich die AD-Suche direkt aufzurufen, ohne die MMC Active Directory-Benutzer und -Computer zu öffnen. Dazu gilt es mit einem Rechtsklick auf einer freien Fläche auf dem Desktop die Option Neu und anschließend Verknüpfung auszuwählen. Als "Speicherort des Elements" gilt es diesen Eintrag hinzuzufügen: %windir%\System32\rundll32.exe dsquery.dll,OpenQueryWindow (<-- ACHTUNG: Die Schreibweise von "OpenQueryWindow" ist "case sensitive"). Im nächsten Schritt gilt es lediglich noch einen Namen für die Verknüpfung zu vergeben und fertig ist die direkte Verknüpfung zur AD-Suche.

Zweite Möglichkeit

Im ersten Schritt ist in der MMC dsa.msc unter Ansicht die Option Erweiterte Funktionen zu aktivieren. Danach gilt es wie in der ersten Möglichkeit im Suchfenster nach dem gewünschten Objekt zu suchen. Ist die Suche beendet, ruft man im zweiten Schritt mit einem Doppelklick auf das Objekt die Eigenschaften auf und wechselt zum Reiter Objekt. Dort wird der kanonische Name des Objekts angezeigt. Liest man diesen in umgekehrter Reihenfolge (von rechts nach links), so lässt sich der DN des Objekts ableiten.

Das Kommandozeilentool: DSQUERY

Mit dsquery das erst ab Windows Server 2003 „on Bord“ zur Verfügung steht, lässt sich der DN eines Objekts wie folgt anzeigen:

dsquery computer -name <CN des Computers>

dsquery user -name <CN des Benutzers>
dsquery group -name <CN der Gruppe>

dsquery contact -name <CN des Kontaktobjekts>

Auch bei dsquery können Wildcards verwendet werden.

Lautet der Common Name (CN) eines Benutzerobjekts “Yusuf Dikmenoglu”, so kann der Befehl folgendermaßen aussehen:

dsquery user -name *us*f*

Standardmäßig durchsucht das dsquery die Domäne in der man den Befehl ausführt. Gibt man den folgenden Befehl an, so durchsucht das dsquery mit Hilfe eines globalen Katalogs (GC) nach dem gewünschten Objekt innerhalb der Gesamtstruktur, also über alle Domänen hinweg:

dsquery user Forestroot -name Yusuf*

Wenn der sAMAccountName des gesuchten Benutzerobjekts bekannt ist (Benutzeranmeldename Prä-Windows 2000), lautet die Abfrage wie folgt:

dsquery user -samid Yusuf

Ist der userPrincipalName (UPN) eines Benutzerkontos bekannt, so gilt es diese Abfrage durchzuführen um den DN anzuzeigen:

dsquery user -upn Yusuf@blog.dikmenoglu.de

Die AD-PowerShell unter Windows Server 2008 R2

In der AD-PowerShell die ab Windows Server 2008 R2 on Bord ist, lässt sich der DN des gesuchten Objekts mit diesem Befehl anzeigen:

Get-ADComputer <Computername>
Get-ADUser <sAMAccountName>
Get-ADGroup <Gruppe>

Die AD-PowerShell steht auch auf einem Windows 7 zur Verfügung, aber erst nach der Installation der Remote Server Administration Tools (RSAT).

Das Active Directory-Verwaltungscenter unter Windows Server 2008 R2

Führt man im AD-Verwaltungscenter (ADAC) eine globale Suche nach einem Objekt durch, wird im Suchergebnis ebenfalls direkt der DN mit angezeigt. Auch im ADAC kann man eine Suche mit Hilfe eines GC durchführen und so nach einem Objekt innerhalb der Gesamtstruktur suchen.

Weitere Informationen:
Gespeicherte Abfragen
Active Directory - Abfrage
AD-PowerShell Befehle
Das Active Directory-Verwaltungscenter
Die Active Directory-Attribute hinter den Feldnamen
Ambiguous Name Resolution for LDAP in Windows 2000
Remoteserver-Verwaltungstools für Windows 7

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

AD-PowerShell Befehle

Yusuf Dikmenoglu — Sun, 09 Aug 2009 19:14:18 GMT

Neben den grafischen Werkzeugen wie z.B. Active Directory-Benutzer und -Computer (dsa.msc), Active Directory-Standorte und -Dienste (dssite.msc) etc. oder den ds*-Kommandozeilentools (dsadd, dsget, dsquery…) steht im Windows Server 2008 R2 erstmals die AD-PowerShell zur Verfügung. In der AD-PowerShell werden dem Administrator 76 AD-Cmdlets mit geliefert.

Die AD-PowerShell ist nicht von der RPC- oder LDAP-Schnittstelle abhängig, sondern von dem Dienst Active Directory-Webdienste (ADWS) (wie auch das AD-Verwaltungscenter), das erst ab Windows Server 2008 R2 zur Verfügung steht.

Mit der AD-PowerShell lässt sich eine Active Directory-Umgebung unter Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 administrieren. Des Weiteren kann man AD LDS-Instanzen oder „configuration sets“ und AD-Snapshots mit der AD-PowerShell verwalten.

Doch bevor eine Windows Server 2003 oder Windows Server 2008 Domäne mit der AD-PowerShell von einem Windows 7 Client oder Windows Server 2008 R2 worauf jeweils das RSAT installiert ist, administriert werden kann, muss vorher das Active Directory Management Gateway Service (AD MGS) auf einem Windows Server 2003 DC oder Windows Server 2008 DC installiert werden. Das AD MGS ist das ADWS für Windows Server 2003 und Windows Server 2008.

Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008

Zu finden ist die AD-PowerShell unter Start – Verwaltung – Active Directory Module for Windows PowerShell. Für die Freunde der grafischen Oberfläche hat Redmond ebenfalls vorgesorgt. Im Server Manager existiert das Feature Windows PowerShell Integrated Scripting Environment (ISE), mit dem dem Administrator eine PowerShell-Entwicklungsumgebung zur Verfügung steht. Nach der Installation steht die Powershell-Entwicklungsumgebung unter Start - Alle Programme - Zubehör - Windows Powershell zur Verfügung. Doch bevor mit dem ISE auf das AD zugegriffen werden kann, müssen vorher mit dem Befehl import-module activedirectory die AD-Cmdlets geladen werden. Anschließend kann der Administrator im ISE seine AD-PowerShell-Skripte erstellen, die mit der Endung „.ps1“ zu speichern sind.

Dadurch das die AD-PowerShell pipeline-fähig ist und sich so verschiedene Cmdlets miteinander verbinden lassen, stellt die AD-PowerShell ein mächtiges Werkzeug dar. Sei es zur täglichen Administration oder bei immer wiederkehrenden Automatisierungsaufgaben, die AD-PowerShell eignet sich in jedem Fall. Mit der AD-PowerShell können in einer einzigen Konsole viele Aufgaben durchgeführt werden, wozu in früheren Betriebssystemversionen mehrere Werkzeuge bzw. MMCs notwendig waren.

Mit der AD-PowerShell ist es auch möglich, wie in einer Kommandozeile (CMD) in der man durch die Verzeichnisse navigiert, durch das AD zu navigieren. In der AD-PowerShell wechselt man mit cd AD: in die AD-Ebene. Dort kann man dann mit dem Befehl cd „DC=blog,DC=dikmenoglu,DC=de“ auf die Domänenpartitionsebene wechseln und mit dir sich die Container die sich darunter befinden anzeigen lassen. Natürlich kann man auch auf jede andere Verzeichnispartition wie z.B. die Konfigurations- oder Schemapartition durch die Angabe des Distinguished Names (DN) der entsprechenden Verzeichnispartition wechseln.

Auch kann man auf diesem Weg z.B. eine neue OU erstellen. Mit dem Befehl md „OU=Neue OU“ kann man auf der Ebene auf der man sich befindet eine neue OU erstellen.

>

Wenn man in der AD-PowerShell Skripte einsetzen möchte, wird das unter Umständen fehlschlagen. Denn das Ausführen von Skripten wird von der Ausführungsrichtlinie, der sogenannten Execution Policy bestimmt. Damit Skripte ausgeführt werden dürfen, muss mit dem PowerShell-Befehl Set-ExecutionPolicy Remotesigned die Ausführungsrichtlinie angepasst werden. Mit dem Parameter Remotesigned wird definiert, dass Skripte die aus dem Internet oder von anderen öffentlichen Orten stammen, signiert sein müssen. Jedoch dürfen lokal gespeicherte Skripte ohne Signatur ausgeführt werden.

Weitere Informationen zum digitalen signieren von Skripten werden im folgenden Artikel beschrieben:

http://technet.microsoft.com/en-us/magazine/2008.04.powershell.aspx?pr=blog

Weitere Informationen zur AD-PowerShell:

Die AD-Powershell im Windows Server 2008 R2

Die AD-Commandlets (kurz Cmdlets) die zur Verfügung stehen

Die Cmdlets sind durch ihre Namen weitestgehend selbsterklärend. Die unten aufgeführten Cmdlets kann man sich mit dem Befehl get-command anzeigen lassen, wie z.B. get-command get-ad*, get-command new-ad* oder get-command remove-ad* usw. Alle AD-Cmdlets werden mit diesem Befehl angezeigt: Get-Command *-ad*

Eine ausführliche und detaillierte Hilfe zu den folgenden Cmdlets lässt sich wie folgt anzeigen:

- Get-Help <Cmdlet Name> -Detailed (z.B. Get-Help Search-ADAccount -Detailed)
- Get-Help <Cmdlet Name> -Examples
- Get-Help <Cmdlet Name> -Full

Die Hilfe zu den Filtermöglichkeiten lässt sich mit diesem Befehl aufrufen:
get-help about_ActiveDirectory_Filter

AD-Objekte abrufen (22 Cmdlets)

- Get-ADAccountAuthorizationGroup
- Get-ADAccountResultantPasswordReplicationPolicy
- Get-ADComputer
- Get-ADComputerServiceAccount
- Get-ADDefaultDomainPasswordPolicy
- Get-ADDomain
- Get-ADDomainController
- Get-ADDomainControllerPasswordReplicationPolicy
- Get-ADDomainControllerPasswordReplicationPolicyUsage
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADForest
- Get-ADGroup
- Get-ADGroupMember
- Get-ADObject
- Get-ADOptionalFeature
- Get-ADOrganizationalUnit
- Get-ADPrincipalGroupMembership
- Get-ADRootDSE
- Get-ADServiceAccount
- Get-ADUser
- Get-ADUserResultantPasswordPolicy

AD-Objekte erstellen (7 Cmdlets)

- New-ADComputer
- New-ADFineGrainedPasswordPolicy
- New-ADGroup
- New-ADObject
- New-ADOrganizationalUnit
- New-ADServiceAccount
- New-ADUser

AD-Objekte entfernen (12 Cmdlets)

- Remove-ADComputer
- Remove-ADComputerServiceAccount
- Remove-ADDomainControllerPasswordReplicationPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Remove-ADGroup
- Remove-ADGroupMember
- Remove-ADObject
- Remove-ADOrganizationalUnit
- Remove-ADPrincipalGroupMembership
- Remove-ADServiceAccount
- Remove-ADUser

AD-Schreibvorgänge durchführen (15 Cmdlets)

- Set-ADAccountControl
- Set-ADAccountExpiration
- Set-ADAccountPassword
- Set-ADComputer
- Set-ADDefaultDomainPasswordPolicy
- Set-ADDomain
- Set-ADDomainMode
- Set-ADFineGrainedPasswordPolicy
- Set-ADForest
- Set-ADForestMode
- Set-ADGroup
- Set-ADObject
- Set-ADOrganizationalUnit
- Set-ADServiceAccount
- Set-ADUser

AD-Objekte hinzufügen (5 Cmdlets)

- Add-ADComputerServiceAccount
- Add-ADDomainControllerPasswordReplicationPolicy
- Add-ADFineGrainedPasswordPolicySubject
- Add-ADGroupMember
- Add-ADPrincipalGroupMembership

AD-Objekte und optionale AD-Funktionen deaktivieren (2 Cmdlets)

- Disable-ADAccount
- Disable-ADOptionalFeature

AD-Objekte und optionale AD-Funktionen aktivieren (2 Cmdlets)

- Enable-ADAccount
- Enable-ADOptionalFeature

AD-Objekte verschieben (3 Cmdlets)

- Move-ADDirectoryServer
- Move-ADDirectoryServerOperationMasterRole
- Move-ADObject

AD-Objekte umbenennen (1 Cmdlet)

- Rename-ADObject

AD-Dienstkontenkennwörter zurücksetzen (1 Cmdlet)

- Reset-ADServiceAccountPassword

AD-Objekte wiederherstellen (1 Cmdlet)

- Restore-ADObject

AD-Objekte suchen (1 Cmdlet)

- Search-ADAccount

AD-Dienstkonto deinstallieren (1 Cmdlet)

- Uninstall-ADServiceAccount

AD-Objekt entsperren (1 Cmdlet)

- Unlock-ADAccount

AD-Kontoablaufdatum zurücksetzen (1 Cmdlet)

- Clear-ADAccountExpiration

AD-Dienstkonto installieren (1 Cmdlet)

- Install-ADServiceAccount

AD-PowerShell „Benutzerobjekt“ Befehle

Mit dem Cmdlet Get-ADUser lassen sich Benutzerinformationen abfragen. Je nach Angabe der Suchkriterien werden bei der Abfrage ein oder mehrere Benutzerobjekte mit den gewünschten Attributen angezeigt. Mit dem Befehl Get-ADUser Yusuf werden standardmäßig die folgenden Werte angezeigt: DistinguishedName, Enabled, givenName, Name, ObjectClass, ObjectGUID, SamAccountName, ObjectSID, Surname, userPrincipalName

Bei allen PowerShell-Befehlen kann bei der Angabe von <Benutzer> zwischen den folgenden Angaben gewählt werden:

- sAMAccountName
- Distinguished Name (DN)
- ObjectSID
- ObjectGUID

Die Abfrage Get-ADUser „CN=Yusuf,OU=IT,DC=blog,DC=dikmenoglu,DC=de“, Get-ADUser S-1-5-21-2225156702-1871195563-4034089934-1101 oder Get-ADUser 6e90b6c6-0fc6-4aab-af7f-73b74f937980 liefern alle das gleiche Ergebnis.

Hinweis: Um die Funktion der Befehle sicherzustellen, ist es empfehlenswert die Befehle händisch einzutippen anstatt sie zu kopieren!

# Soll sich die Abfrage auf eine bestimmte OU (samt Unter-OUs) beschränken, so kann das mit dem Parameter –Searchbase und der Angabe des DN der OU durchgeführt werden.
Get-ADUser –LDAPFilter „(givenName=Yusuf)“ –SearchBase „OU=IT,DC=Domäne,DC=de“

# Zum Erhöhen der Suchleistung sollte man den Suchbereich auf ein einziges Objekt oder auf eine Objektteilmenge beschränken. Für diese Aufgabe stellt die DirectorySearcher-Klasse die SearchScope-Eigenschaft bereit. Der Suchbereich lässt sich auf eine der folgenden drei Einstellungen festlegen:

- Base: Hier wird das Objekt durchsucht, mit dem man verbunden ist. Wenn man sich z.B. mit einer OU verbunden hat, wird nur diese eine OU durchsucht und nicht noch zusätzlich die evtl. bestehenden Unter-OUs.

- OneLevel: Mit dieser Option werden alle Objekte die sich direkt, also eine Ebene tiefer, unter der Suchbasis befinden durchsucht.

- Subtree: Durchsucht alle Objekte, die in der Teilstruktur des verbundenen Objekts enthalten sind. Dabei werden alle Container im aktuellen Pfad und unterhalb der Suchbasis durchsucht.

Mit der Angabe des Parameters –SearchScope, lässt sich die Abfrage im vorherigen Beispiel ausschließlich auf die angegebene OU beschränken:
Get-ADUser –LDAPFilter „(givenName=Yusuf)“ –SearchBase „OU=IT,DC=Domäne,DC=de“ –SearchScope OneLevel

# Welche Benutzerkontoeigenschaften angezeigt werden, lässt sich mit dem Parameter –Properties beeinflussen. Wird beim Parameter –Properties als Wert ein Wildcard „*“ verwendet, so lassen sich alle Benutzerkontoeigenschaften anzeigen die im Benutzerobjekt enthalten sind:
Get-ADuser <Benutzer> -Properties *

# Möchte man sich bei einem bestimmten Benutzer neben den standardmäßig angezeigten Werten lediglich als weitere Benutzereigenschaft die Personalnummer, die Attribute employeeID und employeeNumber anzeigen lassen, so lautet der Befehl
Get-ADUser <Benutzer> –Properties employeeID,employeeNumber

# Alle Benutzerkonten in der Domäne anzeigen
Get-ADUser –Filter *

# Alle AD-Objekte anzeigen
Get-ADObject –Filter { ObjectClass –Like „*“ }

# Alle Benutzerkonten einer bestimmten OU im Spaltenformat anzeigen
Get-ADUser –Filter * -Searchbase „OU=<OU>,DC=Domäne,DC=de“ | FT

# Alle Benutzer in der Domäne mit dem Vornamen „Yusuf“ anzeigen
Get-ADUser –LDAPFilter „(givenName=Yusuf)“

# Alle Benutzerkonten in der Domäne mit der Personalnummer im Spaltenformat anzeigen
Get-ADUser -Filter * -Properties employeeID,employeeNumber | FT

# Mit einer Ambiguous Name Resolution (kurz ANR) die Benutzer anzeigen, die im Vornamen, Nachnamen oder sAMAccountName den Eintrag „Yus“ enthalten
Get-ADUser –Filter { ANR –eq „Yus“ }

# Alle Benutzerkonten aus „Mainz“ anzeigen
Get-ADUser –Filter {City –Like „Mainz“}

# Alle Benutzerkonten mit dem Vornamen „Yusuf“ anzeigen
Get-ADUser –Filter {givenName –Like „Yusuf“} | FT

# Alle Benutzerkonten mit dem Nachnamen „Dikmenoglu“ anzeigen
Get-ADUser –Filter {Surname –Like „Dikmenoglu“}

# Alle Benutzerkonten aus der Abteilung „EDV“ anzeigen
Get-ADUser –Filter {Department –Like „EDV“}

# Alle Benutzerkonten anzeigen die in ihrem „Common Name“ irgendwo den Eintrag „Yus“ haben
Get-ADUser –Filter { CN –Like „*Yus*“ }

# Alle Benutzer die einen Wert im Attribut mail eingetragen haben anzeigen
Get-ADUser –Filter { mail –Like „*“ }

oder

Get-ADObject –Filter { mail –Like „*“ –and ObjectClass –eq “user” }

# Alle Benutzer die einen Wert im Attribut mail eingetragen haben und mit Nachname „Dikmenoglu“ lauten anzeigen
Get-ADUser –Filter { mail –Like „*“ –and Surname –eq „dikmenoglu“ }

oder

Get-ADUser –Filter { mail –Like „*“ –and sn –eq „dikmenoglu“ }

# Alle Benutzerkonten die keinen Wert im Attribut mail eingetragen haben anzeigen
Get-ADUser –Filter { mail –notlike „*“ }

Oder
Get-ADUser –LDAPFilter „(!(email=*))“

# Alle Benutzerkonten die im Common Name mit „Yusuf“ oder „Kaan“ beginnen anzeigen
Get-ADUser -Filter { CN -like "Yusuf*" -or CN -eq "Kaan"

oder

Get-ADObject -Filter { objectClass -eq "user" -and (CN -like "Yusuf*" -or CN -eq "Kaan") }

# Die Gruppenmitgliedschaften eines Benutzers anzeigen
Get-ADPrincipalGroupMembership Yusuf

# Alle Benutzerkonten anzeigen, die als Vorgesetzten „Yusuf“ eingetragen haben
Get-ADUser -Filter { Manager -eq "Yusuf" }

# Die direkten Gruppenmitgliedschaften samt der „primären Gruppe“ eines Benutzers anzeigen
Get-ADUser Yusuf –Properties primarygroupID,memberof

# Den Benutzer aus einer Gruppe entfernen
Remove-ADPrincipalGroupMembership Yusuf –MemberOf „Gruppe“

# Den Benutzer bis auf die primäre Gruppe, aus allen Gruppen entfernen
Get-ADPrincipalGroupMembership Yusuf | % {Remove-ADPrincipalGroupMembership Yusuf -MemberOf $_}

# Den Benutzer Kaan zu den gleichen Gruppen hinzufügen, in denen Yusuf Mitglied ist
Get-ADPrincipalGroupMembership Yusuf | % {Add-ADPrincipalGroupMembership Kaan -MemberOf $_}

# Alle Benutzerkonten anzeigen, die sich in den letzten 10 Tagen angemeldet haben
$date = (get-date) – (new-timespan –days 10)
Get-ADUser –Filter { lastlogon –gt $date }

Ein anderer Befehl mit dem die Benutzer angezeigt werden, die sich in den letzten 5 Tagen an der Domäne angemeldet haben ist dieser:
Get-ADUser –LDAPFilter „(&(LastLogon>=128812906535515110)(objectCategory=user))“

# Alle Benutzer anzeigen die sich in den letzten 50 Tagen nicht angemeldet haben
$Vorvielentagen = (Get-Date).AddDays(-50)
Get-ADUser -Filter { lastLogonTimeStamp -notlike "*" -or lastLogonTimeStamp -le $Vorvielentagen }

# Alle Benutzerkonten die mehr als vier Mal ihr Kennwort falsch eingegeben haben anzeigen
Get-ADUser –LDAPFilter „(badPwdCount>=4)“

Oder
Get-ADUser –Filter {badPwdCount –ge 4}

# Einen Benutzer deaktivieren
Disable-ADAccount Yusuf

# Einen Benutzer aktivieren
Enable-ADAccount Yusuf

# Einen deaktivierten Benutzer im Container USERS erstellen
New-ADUser Yusuf

# Einen aktivierten Benutzer in der angegebenen OU mit mehreren Werten erstellen
New-ADUser –sAMAccountName „Yusuf“ –UserPrincipalName Yusuf@ad.dikmenoglu.de –givenname “Yusuf” –Surname “Dikmenoglu” –displayName “Yusuf Dikmenoglu” –Name “Yusuf Dikmenoglu” –scriptpath “login.bat” –Enabled $true –Path “OU=<OU>,DC=Domäne,DC=DE” –AccountPassword (ConvertTo-Securestring “Pa$$w0rd!” –asplaintext –Force)

# Ein Benutzerkonto mit allen Eigenschaften kopieren und im Container USERS erstellen
PS C:\> $Groups = Get-ADPrincipalGroupMembership "Yusuf"
PS C:\> Get-ADUser "Yusuf" -Properties * | New-ADUser -Name "Benutzer2" -Displayname "Benutzer2" -samaccountname "Benutzer2" -accountpassword (ConvertTo-SecureString "Pa$$w0rd!" -AsPlainText –Force)
PS C:\>Add-ADPrincipalGroupMembership "Benutzer2" -memberOf $Groups

# Ein Benutzerkonto nur mit bestimmten Attributen kopieren und im Container USERS erstellen
PS C:\> $Groups = Get-ADPrincipalGroupMembership "Yusuf"
PS C:\> Get-ADUser "Yusuf" -Properties profilPath, scriptPath, accountExpires | New-ADUser -Name "Benutzer2" -Displayname "Benutzer2" -samaccountname "Benutzer2" -accountpassword (ConvertTo-SecureString "Pa$$w0rd!" -AsPlainText –Force)
PS C:\>Add-ADPrincipalGroupMembership "Benutzer2" -memberOf $Groups

# 50 aktivierte Benutzerkonten in einer bestimmten OU erstellen
(1..50) | Foreach-Object {New-ADUser –sAMAccountname "Benutzer$_" -Name "Benutzer$_" -AccountPassword (ConvertTo-SecureString -AsPlainText "Pa$$w0rd!" -Force) –Enabled $true –Path „OU=<OU>,DC=Domäne,DC=de“}

# Allen Benutzern einer bestimmten OU einen Wert im Feld „Beschreibung“ setzen
Get-ADUser –Filter * -Searchbase „OU=<OU>,DC=Domäne,DC=DE“ | Set-ADUser –description „Wert“

# Die Option „Konto läuft ab am:“ auf den 31. Oktober 2009 setzen
Set-ADUser Yusuf –AccountExpirationDate 01/11/2009

# Die Option „Konto läuft ab“ auf „Nie“ setzen
Clear-ADAccountExpiration Yusuf

# Den Profilpfad, das Anmeldeskript und ein Homelaufwerk für einen bestimmten Benutzer eintragen
Set-ADUser „Yusuf“ –ProfilePath \\Server01\Profiles\%username% -Scriptpath „Login.bat“ –Homedrive „X“ –HomeDirectory „\\Server01\home\Yusuf“

# Einen Benutzer in eine andere OU verschieben
Get-ADUser Yusuf | Move-ADObject –TargetPath „OU=NeueOU,DC=Domäne,DC=de“

# Den relative distinguished name (RDN) eines Benutzers ändern
Rename-ADObject „CN=Yusuf Dikmenoglu,OU=IT,DC=Domäne,DC=de“ –NewName „Yusuf Cool“

# Einen Benutzer löschen
Remove-ADUser Yusuf

# Einen Benutzer ohne Sicherheitsabfrage löschen
Remove-ADUser Yusuf -Confirm:$False

# Mehrere Benutzer anhand eines gemeinsamen Kriteriums löschen
Get-ADUser –Filter {Name –Like „*Dikmenoglu*“} | Remove-ADUser >

# Mit dem folgenden Befehl wird die Voreinstellung für neue Benutzer auf einem deutschen DC (auf einem englischen System lautet der LDAP-Pfad ...,CN=409,...) auf „Nachname, Vorname“ geändert (die Ansicht im Attribut name). Bestehende Objekte sind davon nicht betroffen.
Set-ADObject "CN=user-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=Domäne,DC=de" -Partition „CN=Configuration,DC=Domäne,DC=de“ -Replace @{CreateDialog="%<sn>, %<givenName>"}

Die Voreinstellung für Kontakte wird wie folgt geändert:
Set-ADObject "CN=contact-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=Domäne,DC=de" -Partition „CN=Configuration,DC=Domäne,DC=de“ -Replace @{CreateDialog="%<sn>, %<givenName>"}

# Benutzer muss Kennwort bei der nächsten Anmeldung ändern
>Set-ADUser –identity Yusuf –ChangePasswordAtLogon $true

# Die Kontooption „Benutzer kann Kennwort nicht ändern“ setzen
Set-ADAccountControl Yusuf -CannotChangePassword $true

Achtung: Ist die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ aktiviert, kann über dsa.msc nicht zusätzlich die Kontooption „Benutzer kann Kennwort nicht ändern“ aktiviert werden. Was auch verständlich ist, denn diese beiden Optionen widersprechen sich. Ist jedoch die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ aktiviert und die Kontooption „Benutzer kann Kennwort nicht ändern“ wird über die AD-PowerShell aktiviert, sind anschließend beide Optionen aktiviert!

# Einem Benutzer ein neues Kennwort vergeben
Set-ADAccountPassword –Identity Yusuf -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "Pa$$w0rd!" –Force)

# Die Kontooption „Kennwort läuft nie ab“ bei einem Benutzer- oder Dienstkonto aktivieren
Set-ADAccountControl Yusuf -PasswordNeverExpires $true

# Alle Benutzerkonten innerhalb einer bestimmten OU anzeigen, die die Kontooption „Kennwort läuft nie ab“ aktiviert haben
Search-ADAccount -PasswordNeverExpires -SearchBase “OU=EDV,DC=blog,DC=dikmenoglu,DC=de”

Hinweis: Bei Nutzung des Cmdlets Search-ADAccount kann durch die Angabe des Parameters –UsersOnly oder –ComputersOnly die Abfrage entweder nur auf Benutzer- oder Computerkonten beschränkt werden.

# Liefert alle Konten die ein abgelaufenes Kennwort besitzen
Search-ADAccount -PasswordExpired | FT Name,ObjectClass

# Alle Benutzer-, Computer- und Dienstkonten anzeigen, die deaktiviert sind
Search-ADAccount -AccountDisabled | FT Name

# Nur deaktivierte Benutzerkonten einer Domäne anzeigen
Search-ADAccount –AccountDisabled –Usersonly | FT Name

# Lediglich deaktivierte Computerkonten anzeigen. Wenn Clients aus der Domäne entfernt und in eine Arbeitsgruppe hinzugefügt werden, wird das Computerkonto im AD deaktiviert und nicht gelöscht.
Search-ADAccount -AccountDisabled -ComputersOnly | FT Name

# Alle deaktivierten Benutzer einer bestimmten Organisationseinheit (OU) anzeigen
Search-ADAccount -AccountDisabled –Searchbase „OU=<OU>,DC=Domäne,DC=DE | where {$_.ObjectClass -eq 'user'} | FT Name

# Abgelaufene Benutzerkonten anzeigen
Search-ADAccount –AccountExpired | FT Name

# Alle Benutzerkonten anzeigen, die in den nächsten 60 Tagen ablaufen
Search-ADAccount –AccountExpiring -TimeSpan 60.00:00:00 | FT Name

# Alle Konten anzeigen (auch Computer) die sich in den letzten 60 Tagen nicht angemeldet haben. Bei dieser Abfrage muss sich der Domänenfunktionsmodus mindestens auf der Ebene „Windows Server 2003“ befinden
Search-ADAccount -AccountInactive -TimeSpan 60.00:00:00 | FT Name

# Alle gesperrten Benutzer anzeigen
Search-ADAccount -LockedOut –Usersonly | FT Name

# Einen bestimmten Benutzer entsperren
Unlock-ADAccount –identity <DN des Benutzers>

# Alle Benutzerkonten anzeigen die am 30.08.2009 ablaufen
Search-ADAccount -AccountExpiring -Usersonly -DateTime "8/30/2009" | FT Name

AD-PowerShell „Gruppenobjekt“ Befehle

Bei der Angabe des <Gruppennamen> können folgende Werte verwendet werden:

- sAMAccountName
- Distinguished Name (DN)
- ObjectSID
- ObjectGUID

Mit dem Cmdlet Get-ADGroup werden standardmäßig folgende Werte angezeigt: DistinguishedName, GroupCategory, GroupScope, Name, ObjectClass, ObjectGUID, sAMAccountName, ObjectSID. Sollen neben diesen Werten noch weitere angezeigt werden, müssen diese mit dem Parameter –Properties angegeben werden. Z.B.: Get-ADGroup <Gruppe> -Properties groupType,member,memberOf,whenCreated,whenchanged

# Alle Eigenschaften einer Gruppe werden mit der Angabe von dem Stern (Wildcard) angezeigt
Get-ADGroup <Gruppe> -Properties *

# Eine globale Sicherheitsgruppe im Container Users erstellen
New-ADGroup -Name "Neue Gruppe" -sAMAccountName NeueGruppe -GroupCategory Security -GroupScope Global -DisplayName "Neue Gruppe" -Path "CN=Users,DC=Domäne,DC=de"

# Eine domänenlokale Sicherheitsgruppe in einer OU erstellen
New-ADGroup -Name "Gruppe" -sAMAccountName Gruppe -GroupCategory Security -GroupScope DomainLocal -DisplayName "Gruppe" -Path "OU=<OU>,DC=Domäne,DC=de"

# Eine universelle Sicherheitsgruppe in einer OU erstellen
New-ADGroup -Name "Gruppe" -sAMAccountName Gruppe -GroupCategory Security -GroupScope Universal -DisplayName "Gruppe" -Path "OU=<OU>,DC=Domäne,DC=de"

# Eine globale Verteilergruppe in der angegebenen OU erstellen

New-ADGroup -Name <Gruppe> -sAMAccountName <Gruppe> -GroupScope Global -GroupCategory Distribution –DisplayName <Gruppe> –Path “OU=<OU>,DC=Domäne,DC=de”

# Alle Gruppen mit dem Gruppentyp “Sicherheit” anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))“

Oder
Get-ADGroup –Filter „groupType –band 0x80000000“

# Alle Gruppen mit dem Gruppentyp “Verteiler” anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(!groupType:1.2.840.113556.1.4.803:=2147483648))“

# Nur universelle Sicherheitsgruppen anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483640))“

# Nur domänenlokale Sicherheitsgruppen anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483644))“

# Nur globale Sicherheitsgruppen anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=-2147483646))“

# Globale Sicherheits- und Verteilergruppen werden mit diesem Befehl angezeigt
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2))“

# Domänenlokale Sicherheits- und Verteilergruppen zeigt dieser Befehl an
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=4))“

# Universelle Sicherheits- und Verteilergruppen anzeigen
Get-ADGroup –LDAPFilter „(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=8))“

# Alle Benutzer anzeigen die als primäre Gruppe „Domänen-Benutzer“ eingetragen haben
Get-ADUser –LDAPFilter „(&(objectCategory=person)(objectClass=user)(primaryGroupID=513))“

# Alle Benutzer anzeigen die als primäre Gruppe NICHT „Domänen-Benutzer“ eingetragen haben
Get-ADUser –LDAPFilter „(&(objectCategory=person)(objectClass=user)(!primaryGroupID=513))“

# Alle direkten und verschachtelten Gruppenmitgliedschaften eines Benutzers anzeigen
Get-ADAccountAuthorizationGroup Yusuf

# Alle direkten Mitglieder einer Gruppe anzeigen
Get-ADGroupMember <Gruppe> | FT Name

# Alle direkten und verschachtelten Mitglieder einer Gruppe anzeigen
Get-ADGroupMember <Gruppe> -Recursive | FT Name -A

# Alle für das System wichtigen Gruppen anzeigen
Get-ADGroup -Filter { isCriticalSystemObject -eq $true }

# Eine Gruppe verschieben
Move-ADObject "CN=Gruppe,OU=Techniker,DC=Domäne,DC=de" -TargetPath "OU=NeueOU,DC=Domäne,DC=de"

# Eine Beschreibung für eine Gruppe setzen
Set-ADGroup <Gruppe> -Description "Diese Gruppe darf Benutzer im AD erstellen"

# Eine Verteilergruppe in eine Sicherheitsgruppe ändern
Set-ADGroup <Gruppe> -groupCategory Security

# Den Gruppenbereich einer Gruppe auf Global ändern
Set-ADGroup <Gruppe> –groupScope Global

# Den Gruppenbereich und den Gruppentyp einer Gruppe ändern
Set-ADGroup <Gruppe> –groupScope Universal -groupCategory Security

Anstatt Universal kann Global oder DomainLocal angegeben werden.

# Mitglieder zu einer Gruppe hinzufügen
Add-ADGroupmember <Gruppe> -Member Yusuf,Kaan

# Eine Gruppe löschen
Remove-ADGroup <Gruppe>

# Einen Benutzer aus einer Gruppe entfernen
Remove-ADGroupMember <Gruppe> -Member Yusuf

# Alle direkten Gruppenmitgliedschaften eines Sicherheitsprinzipals (Benutzer, Gruppe, Computer) anzeigen
Get-ADPrincipalGroupMembership <Objekt>

AD-PowerShell „Organisationseinheit“ Befehle

# Mit dem Cmdlet Get-ADOrganizationalUnit werden folgende Werte angezeigt: City, Country, DistinguishedName, LinkedGroupPolicyObjects, ManagedBy, Name, ObjectClass, ObjectGUID, PostalCode, State, StreetAddress. Alle Eigenschaften einer OU lassen sich mit dem Parameter –Properties * anzeigen.

# Alle OUs in einer Domäne anzeigen
Get-ADOrganizationalUnit -Filter {Name -like „*“} | FT Name, DistinguishedName -A

# Den Inhalt einer bestimmten OU anzeigen
Get-ADObject -Filter {Name -Like "*"} -Searchbase „OU=<OU>,DC=Domäne,DC=de“

# Eine OU erstellen. Dabei ist die Option Objekt vor zufälligem Löschen schützen automatisch aktiviert.
New-ADOrganizationalUnit -Name Techniker -Path "OU=IT,DC=Domäne,DC=de"

# Die Option Objekt vor zufälligem Löschen schützen von einer OU entfernen
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentialDeletion $false

# Die Option Objekt vor zufälligem Löschen schützen auf einer OU aktivieren
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentialDeletion $true

# Die Option Objekt vor zufälligem Löschen schützen auf allen OUs einer Domäne aktivieren
Get-ADOrganizationalUnit -Filter 'Name -like "*"' | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

# Eine OU verschieben
Move-ADObject "aktuelle DN der OU" -TargetPath "Ziel-DN"

Ist die Option Objekt vor zufälligem Löschen schützen aktiviert, erhält man eine Fehlermeldung.

# Eine OU samt dem kompletten Inhalt löschen
Remove-ADOrganizationalUnit Test -Recursive

Ist die Option Objekt vor zufälligem Löschen schützen aktiviert, erhält man eine Fehlermeldung.

# Einen Benutzer aus einer OU löschen
Remove-ADObject „CN=Yusuf Dikmenoglu,OU=IT,DC=Domäne,DC=de“

# Alle Objekte innerhalb einer OU in eine andere OU verschieben
Get-ADObject -Filter {Name -Like "*"} -Searchbase „OU=AlteOU,DC=Domäne,DC=de“ -SearchScope OneLevel | Move-ADObject -TargetPath "OU=NeueOU,DC=Domäne,DC=de"

# Eine OU umbenennen
Rename-ADObject "OU=AlterName,DC=Domäne,DC=de" -NewName <Neuername>

# Eine Beschreibung für eine OU vergeben
Set-ADOrganizationalUnit <DN zur OU> -description <Beschreibung>

AD-PowerShell „Computerobjekt“ Befehle

# Mit dem Cmdlet Get-ADComputer werden diese Werte angezeigt: DistinguishedName, DNSHostName, Enabled, Name, ObjectClass, ObjectGUID, sAMAccountName, ObjectSID, userPrincipalName.

# Alle Computerkonten innerhalb einer Domäne auflisten
Get-ADComputer –Filter {Name –Like “*”}

# Ein Computerobjekt in eine andere OU verschieben
Get-ADComputer <Computername> | Move-ADObject -TargetPath „DN von Ziel-OU“

# Alle Computer anzeigen, die sich seit 180 Tagen nicht am AD angemeldet haben:
Search-ADaccount -AccountInactive -Timespan 180 -ComputersOnly

# Mit dem folgenden Befehl wird die maximale Anzahl an Clients die ein Domänen-Benutzer zur Domäne hinzufügen kann erhöht
Set-ADDomain blog.dikmenoglu.de -Replace @{"ms-ds-MachineAccountQuota"="333"} >

Siehe auch:>

Clients in die Domäne hinzufügen

Weitere Informationen:
Active Directory Administration with Windows PowerShell
Die Active Directory-Attribute hinter den Feldnamen

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die Active Directory-Attribute hinter den Feldnamen

Yusuf Dikmenoglu — Wed, 24 Jun 2009 07:04:25 GMT

Möchte der Administrator eine LDAP-Abfrage durchführen oder eine Objektdelegierung im Active Directory (AD) einrichten, so muss er wissen welches Attribut hinter dem Feld z.B. in der MMC Active Directory-Benutzer und –Computer (dsa.msc) dahinter steckt, damit er seine Aufgabe durchführen kann.

Die Attribute die hier aufgezeigt werden beziehen sich auf die Felder in der MMC dsa.msc.

Die Attribute hinter den Feldern eines Benutzerkontos >

Die Registerkarte: Allgemein

Die Registerkarte: Adresse

Die Registerkarte: Konto

Die Registerkarte: Profil

Die Registerkarte: Rufnummern

Die Registerkarte: Organisation

Die Registerkarte: Mitglied von

Die Übersicht in der MMC "dsa.msc"

Die Attribute hinter den Feldern eines Gruppenkontos

Die Registerkarte: Allgemein

Die Registerkarte: Mitglieder

Die Registerkarte: Mitglied von

Die Registerkarte: Verwaltet von

Die Attribute hinter den Feldern einer Organisationseinheit (OU)

Die Registerkarte: Allgemein

Die Registerkarte: Verwaltet von

Die Attribute in der Registerkarte "Objekt"

Diese Registerkarte kommt in den Eingenschaften einer OU, eines Benutzer-, Gruppen- oder Computerkontos erst dann zum Vorschein, wenn im Snap-In Active Directory-Benutzer und -Computer unter Ansicht die Option Erweiterte Funktionen aktiviert wurde.

Die Attribute hinter den Feldern eines Computerkontos

Die Registerkarte: Allgemein

Die Registerkarte: Betriebssystem

Die Registerkarte: Mitglied von

Die Registerkarte: Standort

Die Attribute hinter den Feldern eines Druckers

Die Registerkarte: Allgemein

Die Attribute hinter den Feldern eines "Kontakts"

Die Registerkarte: Allgemein

Die Registerkarte: Adresse

Die Registerkarte: Rufnummern

Die Registerkarte: Organisation

Weitere Informationen:
Gespeicherte Abfragen
Active Directory - Abfrage
All Attributes (Windows)
All Classes (Windows)
Mappings for the Active Directory Users and Computers Snap-in (Windows)

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die AD-Powershell im Windows Server 2008 R2

Yusuf Dikmenoglu — Sun, 08 Feb 2009 12:31:33 GMT

Im Windows Server 2008 R2 ist erstmals die Active Directory-Powershell in der Version 2.0 Out-of-the-Box für AD DS sowie AD LDS (ehemals ADAM) im Betriebssystem integriert. Es stehen die AD-Powershell Kommandozeile sowie das Snap-In Windows PowerShell Integrated Scripting Environment (ISE) zur Verfügung. Die Powershell-Entwicklungsumgebung ISE muss im Server Manager unter den Features installiert werden, ehe diese unter Start - Alle Programme - Zubehör - Windows Powershell genutzt werden kann. Hinter der AD-Powershell verbirgt sich nichts anderes als ein Powershell-Modul Namens „ActiveDirectory“, worin bereits die AD-Cmdlets zur Verfügung stehen. Denn unter der Windows Powershell V2 sowie ISE müssen zuerst die AD-Cmdlets mit dem Befehl import-module activedirectory importiert werden. Die Bestandteile der AD-Powershell ist der AD-Powershell Provider und die insgesamt 76 AD-Powershell Commandlets (kurz Cmdlets).

Vor Windows Server 2008 R2 mussten AD-Administratoren mehrere Kommandozeilentools und AD Snap-Ins verwenden, um ihre Active Directory-Umgebung sowie die AD LDS „configuration sets“ (eine Gruppe von Replikationspartnern) zu administrieren und zu konfigurieren. Diese Vielfalt an Werkzeugen können sie zwar auch unter Windows Server 2008 R2 weiterhin nutzen, doch wer seine AD DS/AD LDS-Umgebung zentralisiert aus nur einem Werkzeug heraus administrieren bzw. konfigurieren möchte, der kann dies mit der Active Directory-Powershell realisieren.

Dadurch lassen sich viele AD-Administrations- und -Konfigurationsaufgaben nun auch über die AD-Powershell ausführen. Doch bevor die AD-Powershell genutzt werden kann, muss diese zuerst installiert werden. Die Installation der AD-Powershell kann ausschließlich auf den Betriebssystemen Windows Server 2008 R2 Vollinstallation, Server Core R2 und Windows 7 Client durchgeführt werden. >

Dabei kann die Installation der AD-Powershell auf verschiedene Weise erfolgen. Diese wären:

Die Installation der Serverrolle AD DS oder AD LDS unter Windows Server 2008 R2.
Das Heraufstufen eines Windows Server 2008 R2 zu einem Domänencontroller (DC) mit dem Dcpromo-Assistenten.
Bei der Installation der Remote Server Administration Tools (kurz RSAT) auf einem Windows Server 2008 R2 Servers.
Mit der Installation der RSAT auf Windows 7 Clients.

Mit der Installation der AD-Powershell werden standardmäßig die Komponenten „Windows Powershell“ und „.NET Framework 3.5.1“ mit installiert. Diese beiden Komponenten sind die Voraussetzung ehe die AD-Powershell installiert und genutzt werden kann.

Wenn die AD-Powershell auf einem Windows 7 Client genutzt werden soll, um eine AD DS-Domäne oder AD LDS-Umgebung zu administrieren, dann ist das erst möglich wenn sich mindestens ein Windows Server 2008 R2 DC oder mindestens eine Instanz in einem AD LDS „configuration set“ auf einem Windows Server 2008 R2 läuft. Das ist notwendig, da die AD-Powershell von dem Dienst Active Directory-Webdienste abhängig ist und nicht von der RPC- bzw. LDAP-Schnittstelle. Nur wenn dieser Dienst in der Umgebung zur Verfügung steht, kann die AD-Powershell eingesetzt werden.

Damit eine Windows Server 2003 oder Windows Server 2008 Umgebung oder AD LDS-Instanzen die auf Windows Server 2008 laufen von einem Windows 7 Client oder Windows Server 2008 R2 Mitgliedsserver bzw. DC administrert werden können, muss vorher das Active Directory Management Gateway Service installiert werden:

Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008

Nach der Installation der AD-Powershell stehen alle 76 verfügbaren AD-Cmdlets zur Verfügung und man kann sich mit dem Befehl Get-Command *-ad* die Cmdlets anzeigen lassen. Mit den folgenden Powershell-Befehlen lässt sich zu dem jeweils angegebenen AD-Cmdlet eine detailierte und ausführliche Hilfe anzeigen:

Get-Help <Cmdlet Name> -Detailed (z.B. Get-Help Disable-ADAccount -Detailed)

Get-Help <Cmdlet Name> -Examples

Get-Help <Cmdlet Name> -Full >>

Die Cmdlets lassen sich auch durch das Pipelining miteinander verbinden. Dadurch können die Daten von einem Cmdlet zum anderen weitergegeben werden. Z.B.: Search-ADAccount <Parameter/alle deaktivierten Benutzer> | Enable-ADAccount

Die AD-Cmdlets die zur Verfügung stehen sind:

ADAccount (4 Cmdlets)
- Disable-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
  Deaktiviert das angegebene Benutzer-, Dienst- oder Computerkonto.
- Enable-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
  Aktiviert das angegebene Benutzer-, Dienst- oder Computerkonto.
- Search-ADAccount
  Die Suche zeigt Benutzer- oder Computerkonten anhand der angegebenen Parameter an.
- Unlock-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
  Entsperrt ein Domänen-Benutzerkonto.
ADAccountAuthorizationGroup (1 Cmdlet)>

Get-ADAccountAuthorizationGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Zeigt die Sicherheitsgruppen mit detailierten Informationen im AD an, in denen das angegebene Benutzer-, Dienst- oder Computerkonto Mitglied ist. Mit diesem Cmdlet wird auch die „primäre Gruppe“ eines Benutzers angezeigt!

ADAccountControl (1 Cmdlet)

Set-ADAccountControl (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet lassen sich die Kontooptionen eines Benutzer- oder Computerkontos bearbeiten. Das Attribut „userAccountControl“ das sich aus einer Bitmaske zusammensetzt, lässt sich somit auch in der AD-Powershell bearbeiten.

ADAccountExpiration (2 Cmdlet)

Clear-ADAccountExpiration (Dieses Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet lässt sich in den Eigenschaften eines Benutzerkontos, im Reiter Konto die Option “Konto läuft ab” auf „Nie“ einstellen.

Set-ADAccountExpiration (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das Ablaufdatum eines Benutzerkontos lässt sich mit diesem Cmdlet konfigurieren.

ADAccountPassword (1 Cmdlet)

Set-ADAccountPassword (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das Kennwort eines Benutzer- oder Dienstkonto kann mit diesem Cmdlet bearbeitet bzw. ein neues vergeben werden.

ADAccountResultantPasswordReplicationPolicy (1 Cmdlet)

Get-ADAccountResultantPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Mit diesem Cmdlet kann man sich die Kennwortreplikationsrichtlinie eines Benutzer-, Dienst- oder Computerkontos, an dem angegebenen RODC anzeigen lassen.

ADComputer (4 Cmdlet)

Get-ADComputer (Das Cmdlet funktioniert nicht bei den AD LDS)
Eine Abfrage über Computerkonten anhand bestimmter Kriterien lässt sich mir diesem Cmdlet durchführen.

New-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Hiermit können Computerkonten im AD erstellt werden. Darunter fällt auch die neue Funktion „Offline Domain Join“ oder ein RODC-Computerkonto.

Remove-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet entfernt Computerkonten aus dem AD.

Set-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Die Eigenschaften eines Computerkontos lassen sich mit diesem Cmdlet bearbeiten.

ADComputerServiceAccount (3 Cmdlets)

Add-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein oder mehrere Computer-Dienstkonten werden mit diesem Cmdlet auf einem Server hinzugefügt.

Get-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei den AD LDS)
Die auf einem Server verfügbaren Computer-Dienstkonten zeigt dieses Cmdlet an.

Remove-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen lassen sich ein oder mehrere Computer-Dienstkonten mit diesem Cmdlet.

ADDefaultDomainPasswordPolicy (2 Cmdlets)

Get-ADDefaultDomainPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Dieses Cmdlet zeigt die Domänen-Kennwortrichtlinie an und nicht die “Password Settings Objects (PSO)”.
Set-ADDefaultDomainPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet lassen sich die Kennwortvorgaben (minimales und maximales Kennwortalter usw.) in der Domänen-Kennwortrichtlinie konfigurieren.

ADDirectoryServer (1 Cmdlet)

Move-ADDirectoryServer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Domänencontroller kann mit diesem Cmdlet an einen anderen AD-Standort verschoben werden.

ADDirectoryServerOperationMasterRole (1 Cmdlet)

Move-ADDirectoryServerOperationMasterRole (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet lässt sich zum Verschieben der FSMO-Rollen einsetzen.

ADDomain(2 Cmdlets)

Get-ADDomain (Das Cmdlet funktioniert nicht bei den AD LDS)
Mit diesem Cmdlet und den entsprechenden Parametern lassen sich Domäneninformationen ausgeben.

Set-ADDomain (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet lässt sich zum Bearbeiten diverser Domäneninformationen verwenden.

ADDomainController (1 Cmdlet)

Get-ADDomainController (Das Cmdlet funktioniert nicht bei den AD LDS)
Ausführliche Informationen über einen Domänencontroller erhält man mit diesem Cmdlet.

ADDomainControllerPasswordReplicationPolicy (3 Cmdlets)

Add-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein oder mehrere Benutzer, Gruppen oder Computer können mit diesem Cmdlet in die Sicherheitsgruppe „Abgelehnte RODC-Kennwortreplikationsgruppe” oder „Zulässige RODC-Kennwortreplikationsgruppe” hinzugefügt werden.

Get-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Die Mitglieder (Benutzer, Gruppen oder Computer) der Sicherheitsgruppe „Zulässige RODC-Kennwortreplikationsgruppe” oder „Abgelehnte RODC-Kennwortreplikationsgruppe” werden mit diesem Cmdlet angezeigt.

Remove-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet entfernt einzelne oder mehrere Benutzer, Gruppen oder Computer von der Sicherheitsgruppe „Abgelehnte RODC-Kennwortreplikationsgruppe” oder „Zulässige RODC-Kennwortreplikationsgruppe”.

ADDomainControllerPasswordReplicationPolicyUsage(1 Cmdlet)

Get-ADDomainControllerPasswordReplicationPolicyUsage (Das Cmdlet funktioniert nicht bei den AD LDS)
In welcher RODC-Kennwortreplikationsgruppe (zulässige oder abgelehnte) der angegebene Benutzer auf dem angegebenen RODC Mitglied ist, zeigt dieses Cmdlet.

ADDomainMode (1 Cmdlet)

Set-ADDomainMode (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Das Heraufstufen des Domänenfunktionsmodus lässt sich auch mit diesem Cmdlet festlegen.

ADFineGrainedPasswordPolicy (4 Cmdlets)

Get-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Dieses Cmdlet zeigt die konfigurierten Optionen einer oder mehrerer “Password Settings Objects (PSO)” an.

New-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Neue PSOs können mit diesem Cmdlet erstellt werden.

Remove-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen lässt sich ein PSO mit diesem Cmdlet.

Set-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Die konfigurierten Optionen einer PSO können mit diesem Cmdlet überarbeitet werden.

ADFineGrainedPasswordPolicySubject (3 Cmdlets)

Add-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet wird eine bereits bestehende PSO mit einem oder mehreren Benutzern bzw. einer Gruppe verknüpft.

Get-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei den AD LDS)
Welche Benutzer oder Gruppen mit einem bestimmten PSO verknüpft sind, zeigt dieses Cmdlet.

Remove-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Eine oder mehre Benutzer bzw. Gruppen werden mit diesem Cmdlet von einer PSO entfernt.

ADForest (2 Cmdlets)

Get-ADForest (Das Cmdlet funktioniert nicht bei den AD LDS)
Weiterreichende Informationen über die Gesamtstruktur erhält man durch dieses Cmdlet.

Set-ADForest (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet lässt sich zum Hochstufen des Gesamtstrukturfunktionsmodus oder zum Bearbeiten gesamtstrukturweiter Informationen (z.B. Hinzufügen oder Bearbeiten des UPNSuffix) verwenden.

ADForestMode (1 Cmdlet)

Set-ADForestMode (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Der Gesamtstrukturfunktionsmodus lässt sich mit diesem Cmdlet Hochstufen.

ADGroup (4 Cmdlets)

Get-ADGroup
Sollen die Benutzer einer speziellen Gruppe ermittelt werden, eine Gruppe mit detailierten Informationen angezeigt oder alle Gruppen anhand bestimmter Kriterien ermittelt werden, so kann man dieses Cmdlet dafür verwenden.

New-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Sicherheit- oder Verteilergruppen können in der AD-Powershell mit diesem Cmdlet erstellen werden.

Remove-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Gruppentypen der Kategorie „Sicherheit“ oder „Verteilung“ werden mit diesem Cmdlet entfernt.

Set-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Bestehende Gruppen lassen sich mit diesem Cmdlet bearbeiten.

ADGroupMember (3 Cmdlets)

Add-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein oder mehrere Benutzer-, Gruppen-, Dienst- oder Computerkonten können mit diesem Cmdlet einer bestimmten Gruppe hinzugefügt werden.

Get-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Die Mitglieder (Benutzer, Gruppen, Clients) einer bestimmten Gruppe werden mit diesem Cmdlet angezeigt.

Remove-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet ist es möglich, ein oder mehrere Benutzer, Gruppen oder Clients aus einer bestimmten Gruppe zu entfernen.

ADObject (7 Cmdlets)

Get-ADObject
Jegliche Active Directory-Abfrage kann anhand der angegebenen Parameter mit diesem Cmdlet durchgeführt werden.

Move-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Active Directory-Objekte oder OUs können entweder innerhalb oder zwischen Domänen mit diesem Cmdlet verschieben werden.

New-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Neue Active Directory-Objekte jeder Art, sei es z.B. neue Benutzer, OUs oder Subnetze werden mit diesem Cmdlet erstellt.

Remove-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Jede Art von Active Directory-Objekten, wie z.B. Benutzer oder OUs, können mit diesem Cmdlet entfernt werden.

Rename-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das umbenennen von AD-Objekten kann mit diesem Cmdlet durchgeführt werden.

Restore-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet stellt ein gelöschtes ADObjekt aus dem Container „Deleted Objects“ wieder her.

Set-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Jegliche Art von AD-Objekten lassen sich mit diesem Cmdlet bearbeiten.

ADOptionalFeature (3 Cmdlets)

Disable-ADOptionalFeature (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Active Directory „Optional Feature“ lässt sich mit diesem Cmdlet deaktivieren.

Enable-ADOptionalFeature (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Aktivieren lässt sich ein „Optional Feature“, wie z.B. der AD-Papierkorb, mit diesem Cmdlet.

Get-ADOptionalFeature
Die optionalen Features innerhalb einer Gesamtstruktur werden mit diesem Cmdlet angezeigt.

ADOrganizationalUnit (4 Cmdlets)

Get-ADOrganizationalUnit
Eine oder mehrere Organisationseinheiten (OU) können anhand der angegebenen Parameter, mit diesem Cmdlet ermittelt werden.

New-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Erstellen lässt sich eine neue OU mit diesem Cmdlet.

Remove-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Soll eine OU (ohne oder mit Objekten) entfernt werden, so lässt sich das Löschen mit dieser Cmdlet durchführen. Ist allerdings die OU vor dem „versehentlichen“ löschen geschützt, so erscheint eine Fehlermeldung.

Set-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Die Eigenschaften einer OU (Adressinformationen oder die Einstellung „Objekt vor zufälligem Löschen schützen“ etc.) lassen sich mit diesem Cmdlet bearbeiten.

ADPrincipalGroupMembership (3 Cmdlets)

Add-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet fügt einen oder mehrere Benutzer, Gruppen oder Computer zu einer oder mehreren Gruppen hinzu.

Get-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Alle Gruppenmitgliedschaften eines Benutzers, einer Gruppe oder eines Clients werden mit diesem Cmdlet angezeigt.

Remove-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein oder mehrere Benutzer, Gruppen oder Clients werden mit diesem Cmdlet aus einer oder mehreren Gruppen entfernt.

ADRootDSE (1 Cmdlet)

Get-ADRootDSE
Die Informationen des Einstiegpunkts eines Active Directory (RootDSE) zeigt dieses Cmdlet an.

ADServiceAccount (6 Cmdlets)

Get-ADServiceAccount (Das Cmdlet funktioniert nicht bei den AD LDS)
Die im Windows Server 2008 R2 eingeführten AD-Dienstkonten („Managed Service Account“) lassen sich anhand der angegeben Parameter, mit diesem Cmdlet anzeigen.

Install-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein neues AD-Dienstkonto lässt sich mit diesem Cmdlet installieren.

New-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet erstellt ein neues AD-Dienstkonto.

Remove-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen kann man ein AD-Dienstkonto mit diesem Cmdlet.

Set-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet lässt sich ein bestehendes AD-Dienstkonto bearbeiten.

Uninstall-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Deinstallieren lässt sich ein AD-Dienstkonto mit diesem Cmdlet.

ADServiceAccountPassword (1 Cmdlet)

Reset-ADServiceAccountPassword (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Das Kennwort eines AD-Dienstkontos kann mit diesem Cmdlet zurückgesetzt werden.

ADUser (4 Cmdlets)

Get-ADUser
Ist man auf der Suche nach einem bestimmten oder nach mehreren Benutzern die alle ein bestimmtes Kriterium erfüllen, so lässt sich die Abfrage mit diesem Cmdlet durchführen.

New-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Benutzerkonto (samt Kennwort) lässt sich mit diesem Cmdlet erstellen.

Remove-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet entfernt ein oder mehrere Benutzerkonten.

Set-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Bearbeiten kann man ein Benutzerkonto mit diesem Cmdlet.

ADUserResultantPasswordPolicy (1 Cmdlet)

Get-ADUserResultantPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Die mit einem Benutzer- oder Gruppenkonto verknüpften “Password Settings Objects“ (PSO) werden mit diesem Cmdlet angezeigt.

>
Weitere Informationen:
AD-PowerShell Befehle
Active Directory Powershell Overview
Active Directory Module for Windows PowerShell Cookbook
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Der Active Directory-Papierkorb im Windows Server 2008 R2 >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Der Active Directory-Papierkorb im Windows Server 2008 R2

Yusuf Dikmenoglu — Sun, 01 Feb 2009 12:03:55 GMT

Das versehentliche Löschen von Active Directory-Objekten ist in Active Directory (AD) bzw. Active Directory Domain Services (AD DS), als auch in Active Directory Lightweight Directory Services (AD LDS, ehemals Active Directory Application Mode, kurz ADAM) Umgebungen mehr als ärgerlich. Denn schnell sind mit zwei Mausklicks ein oder mehrere Objekte gelöscht. Hoffentlich existiert in so einem Fall eine aktuelle und vor allem funktionierende Sicherung, mit dem das verlorene Objekt wiederhergestellt werden kann. Bis jedoch das passende Sicherungsband gefunden, eingelegt und das Objekt letztenendes wiederhergestellt ist, können diese Arbeiten sehr zeitintensiv und aufwändig sein.

Die Möglichkeiten die einem bei der Wiederherstellung zur Verfügung stehen, sind unter:

Windows 2000 = Autoritative Wiederherstellung
Windows Server 2003 = Autoritative Wiederherstellung, Tombstone reanimieren
Windows Server 2003 R2 = Autoritative Wiederherstellung, Tombstone reanimieren
Windows Server 2008 = Autoritative Wiederherstellung, Tombstone reanimieren
Windows Server 2008 R2 = AD-Papierkorb, Autoritative Wiederherstellung, Tombstone reanimieren (bei deaktiviertem und aktiviertem AD-Papierkorb)

Die autoritative Wiederherstellung

Existiert eine aktuelle und funktionierende System State-Sicherung, kann mit einer autoritativen Wiederherstellung das Objekt mit all seinen Informationen die es zum Zeitpunkt der Sicherung hatte, wiederhergestellt werden. Dabei darf die Systemstatus-Sicherung (auf englisch: System State) nicht älter als die Tombstone-Lifetime (TSL) sein, denn ansonsten entstehen Lingering Objects. Die TSL einer Gesamtstruktur gibt das maximale Alter einer Systemstatus-Sicherung an, die für eine Rücksicherung verwendet werden darf.

Ein AD-Objekt wird in der Kommandozeile mit dem Befehl Ntdsutil-authoritative restorehergestellt. Dabei wird die Versionsnummer um 100.000 erhöht, damit das rückgesicherte Objekt nach der AD-Replikation auf die Replikationspartner erhalten bleibt und nicht von einem anderen DC direkt wieder gelöscht wird.

Problematisch ist allerdings die Wiederherstellung der Gruppenmitgliedschaften eines gelöschten Benutzers, die sogenannten Backlinks. Zur Wiederherstellung von Gruppenmitgliedschaften sind weitere aufwändige Schritte notwendig. Das hat sich zwar mit Windows Server 2003 SP1 etwas entschärft, jedoch ist weiterhin der Aufwand zum Rücksichern dieser Backlinks recht hoch.

Der Nachteil einer autoritativen Wiederherstellung wäre, dass der Domänencontroller (DC) im Modus Verzeichnisdienste wiederherstellen gestartet werden muss und dadurch zwei Neustarts notwendig sind. Somit würde der DC während der ganzen Zeit der Wiederherstellung nicht zur Verfügung stehen.

Diese Vorgehensweise ist seit der Einführung des Active Directory mit Windows 2000 gleich geblieben.

Weitere Details stehen in dem Artikel:

Active Directory Wiederherstellung

Ist eine Wiederherstellung in einer AD LDS-Umgebung notwendig, so ist es erforderlich die AD LDS-Instanz vorher zu stoppen. Allerdings muss für die Wiederherstellung der Server nicht im Modus Verzeichnisdienste wiederherstellen gestartet werden.

Wiederherstellen von AD LDS-Instanzdaten

Die Tombstone-Reanimierung

Eine andere Variante die seit Windows Server 2003 zur Verfügung steht, ist das reanimieren des Tombstones (zu Deutsch: Grabstein). Diese Art der Wiederherstellung hat den Vorteil, dass das Tombstone online ohne, dass der DC neu gestartet werden muss, jederzeit wiederhergestellt werden kann. Auch in einer AD LDS-Umgebung muss dazu die AD LDS-Instanz nicht offline genommen werden. Das gelöschte Objekt (das Tombstone) kann natürlich nur reanimiert werden, solange die Tombstone Lifetime nicht abgelaufen ist. Der Nachteil dieser Variante wiederum wäre, dass beim Wiederbeleben des Tombstones nicht alle Informationen eines Objekts automatisch wiederhergestellt werden.

Denn wenn ein Objekt gelöscht wird, verschwindet es nicht sofort aus der Active Directory-Datenbank (NTDS.dit). Das Objekt wird stattdessen vom Active Directory als gelöscht markiert, indem das Attribut Is-Deleted des Objekts auf den Wert True gesetzt wird. Aber es werden die meisten Attribute von dem Objekt für immer entfernt. Danach wird das Objekt in den versteckten Container Deleted Objects (der in jeder Verzeichnispartitionen existiert) verschoben und wird ab diesem Zeitpunkt als Tombstone bezeichnet. Wird also ein Benutzer gelöscht, so landet das Benutzerkonto mit wenigen Werten im Container „Deleted Objects“ der Domänenpartition und wird erst nach Ablauf der TSL vom Garbage Collection Prozess ein für allemal aus dem AD entfernt.

Landet das Tombstone im Container „Deleted Objects“, erhält es einen speziellen Relative Distinguished Name (RDN) der so aussieht: „CN=<Alter RDN>\0ADEL:<Object-GUID>“. Beim Wiederbeleben des Tombstone wird das Objekt dann nur noch mit einigen wenigen Werten (z.B. ObjectGUID oder ObjectSID) wiederhergestellt.

Der Container „Deleted Objects“ wird aber nicht in den AD Snap-Ins oder im ADSIEdit angezeigt. Stattdessen können die Tombstones mit ADRestore.Net, ADRestore oder LDP.exe angezeigt sowie wiederhergestellt werden.

ADRestore.NET

ADRestore

Die restlichen Werte die in einem wiederhergestellten Tombstone fehlen, könnten mit einem der folgenden Tools, von einem zuvor erstellten AD-Snapshot unter Windows Server 2008 bzw. Windows Server 2008 R2 wiederhergestellt werden.

Directory Service Comparison Tool 1.3.2.X

AD Explorer

Die Grabstein-Lebenszeit (Tombstone Lifetime)

Die Tombstone Lifetime wird mit dem Installieren des allerersten DCs für die komplette Gesamtstruktur festgelegt. Dabei ist es entscheidend welches Server-Betriebssystem mit welchem Service-Pack auf dem Server installiert ist, mit dem die Gesamtstruktur erstellt wird. Das Installieren eines Service-Packs auf bestehenden DCs, verändert niemals die Tombstone Lifetime. Es müsste schon die Gesamtstruktur neu installiert werden.

Wie und wo man die TSL überprüfen kann, steht neben weiteren Details in dem folgenden Artikel.

Die Tombstone Lifetime

Die Tombstone-Lifetime beträgt unter den Betriebssystemen:

Windows 2000 (mit allen SPs) = 60 Tage
Windows Server 2003 ohne SP = 60 Tage
Windows Server 2003 ab Service Pack 1 = 180 Tage
Windows Server 2003 R2 mit Service Pack 1, installiert mit beiden R2-CDs = 60 Tage
Windows Server 2003 R2 mit Service Pack 1, installiert nur mit der ersten R2-CD = 180 Tage
Windows Server 2003 R2 ab Service Pack 2 (installiert mit der ersten oder beiden R2-CDs) = 180 Tage
Windows Server 2008 (mit allen SPs) = 180 Tage
Windows Server 2008 R2 (mit allen SPs) = 180 Tage

Der Vorgang eines gelöschten AD-Objekts sowie seine Wiederherstellung unter Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2, bei deaktiviertem AD-Papierkorb

Der Active Directory-Papierkorb unter Windows Server 2008 R2

Ein absolutes Highlight im Windows Server 2008 R2 ist der Papierkorb für gelöschte Active Directory-Objekte. Wird ein Active Directory-Objekt in den Active Directory Domain Services (AD DS) oder Active Directory Lightweight Directory Services (AD LDS) gelöscht, kann es Dank des AD-Papierkorbs schnell wiederhergestellt werden. Der AD-Papierkorb steht in AD DS und AD LDS-Umgebungen zur Verfügung. Der große Vorteil des AD-Papierkorbs ist, dass das Objekt mit all seinen Informationen die es zum Zeitpunkt der Löschung hatte wiederhergestellt wird. Das bedeutet, alle Attribute samt allen Backlinks und somit z.B. den Gruppenmitgliedschaften eines Benutzers, werden hergestellt. Nach der Wiederherstellung ist auch der Zugriff auf die bestehenden Objekte und Ressourcen wieder gegeben.

Dafür wird weder eine System-State Sicherung benötigt, noch muss der DC im Verzeichnisdienste wiederherstellen Modus gestartet werden. Die Wiederherstellung findet im laufenden Betrieb statt.

Diese neue Technik steht ausschließlich in den folgenden Server-Versionen zur Verfügung:

Windows Server 2008 R2 Standard
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Datacenter

Der AD-Papierkorb steht in den folgenden Versionen nicht zur Verfügung:

Windows Server 2008 R2 für Itanium basierte Systeme
Windows Web Server 2008 R2

Jedoch ersetzt diese Funktion niemals eine regelmäßige System State-Sicherung!

Die Voraussetzungen um den Active Directory-Papierkorb unter Windows Server 2008 R2 zu nutzen

Die Voraussetzungen um den AD-Papierkorb zu nutzen sind:

Der AD-Papierkorb steht in den AD DS und AD LDS-Umgebungen erst im Gesamtstrukturfunktionsmodus Windows Server 2008 R2 zur Verfügung. Es müssen also alle Domänencontroller aus allen Domänen der Gesamtstruktur oder alle Server auf denen eine AD LDS-Instanz konfiguriert ist, unter Windows Server 2008 R2 laufen!

Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Der AD-Papierkorb ist standardmäßig deaktiviert, sowohl bei einer Domänenaktualisierung oder dem neu Aufsetzen einer Windows Server 2008 R2 Gesamtstruktur im Gesamtstrukturfunktionsmodus „Windows Server 2008 R2“. Der AD-Papierkorb muss explizit in der AD-Powershell aktiviert werden. Dieser Schritt ist ein irreversibler Vorgang und kann danach nicht mehr rückgängig gemacht werden!

Nach dem Aktivieren des AD-Papierkorbs lässt sich dieses Feature mit Bordmitteln über die AD-Powershell und LDP.exe nutzen. Es existiert keine grafische Oberfläche in der man mit der Maus die Funktion aktivieren kann. Jedoch lassen sich mit dem Tool LDP oder den beiden Tools ADRestore.Net und ADRestore, ebenfalls die gelöschten Objekte im AD-Papierkorb anzeigen sowie wiederherstellen.

Kann der AD-Papierkorb für eine einzige Domäne in der Gesamtstruktur aktiviert werden?

So wie bei der Tombstone Lifetime ist es nicht möglich, den AD-Papierkorb „pro Domäne“ zu aktivieren. Wenn die Voraussetzungen erfüllt sind, kann diese Funktion nur auf der Gesamtstrukturebene mit „Organisations-Admin“ Rechten für alle Domänen aktiviert werden. Anschließend steht jeder Domäne sein eigener AD-Papierkorb zur Verfügung. Der AD-Papierkorb existiert also "pro Domäne" und nicht "pro Gesamtstruktur"!

Die Funktionsweise des Active Directory-Papierkorbs unter Windows Server 2008 R2

Der AD-Papierkorb baut auf der Technik der Tombstone-Reanimierung auf. Jedoch werden vom gelöschten Objekt dafür keine Attribute vom System entfernt und es bleiben alle Attribute erhalten. Das Objekt wird logisch gelöscht bzw. inaktiv gesetzt, was ein neues Stadium eines gelöschten Objekts ist, das mit Windows Server 2008 R2 eingeführt wurde. In der AD-Datenbank wurde dazu das Speicherformat der Objektlinks geändert. Wird ein Objekt gelöscht, so erhält das Attribut isDeleted im Objekt den Wert TRUE. Das gelöschte Objekt wird nach wie vor in den versteckten Container Deleted Objects verschoben und sein Distinguished Name (DN) erhält dadurch einen neuen Wert. Das Objekt in „Deleted Objects“ behält seinen logischen Löschzustand solange bei, bis die Deleted Object Lifetime (DOL) abgelaufen ist. Nach Ablauf der DOL wandelt sich das gelöschte Objekt zu einem "recycled Objekt". Das recycled Objekt wird dann endgültig vom Garbage Collection Prozess nach Ablauf der Recycled Object Lifetime (ROL) aus der AD-Datenbank entfernt. Unter Windows Server 2008 R2 gibt es nun neben der Tombstone Lifetime zusätzlich die Deleted Object Lifetime (kurz DOL) und Recycled Object Lifetime (kurz ROL).

Die Deleted Object Lifetime wird durch den Wert im neuen Attribut msDS-DeletedObjectLifetime bestimmt. Denn bei einer Domänenaktualisierung auf Windows Server 2008 R2 ist eines der Schema-Aktualisierungen mit Adprep /Forestprep (von der Windows Server 2008 R2 DVD) das Hinzufügen des neuen Attributs msDS-DeletedObjectLifetime. Wenn jedoch eine Gesamtstruktur auf Basis von Windows Server 2008 R2 erstellt wird, befinden sich bereits alle benötigten Attribute im Schema und das Adprep muss in keinster Weise ausgeführt werden. Die Recycled Object Lifetime hingegen, erhält seinen Wert aus dem Attribut tombstoneLifetime.

Ist die Zeit des im Attribut msDS-DeletedObjectLifetime definierten Werts abgelaufen, wandelt sich das logisch gelöschte Objekt zum „recycled Objekt“. Zusätzlich erhält das Attribut isRecycled im Objekt den Wert TRUE. Dabei werden die gleichen Attribute vom Objekt entfernt, wie es seit Windows Server 2003 bei einem Tombstone der Fall ist. Oder anders ausgedrückt, im recycled Objekt bleiben standardmäßig die gleichen Attribute erhalten wie bei einem Tombstone unter Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 bei deaktiviertem AD-Papierkorb. Von der Begrifflichkeit her entspricht ein „recycled Objekt“ einem klassischen Tombstone.

Auch können in einem recycled Objekt durch das vierte Bit im searchFlags (in Dezimal 8) des gewünschten Attributs, weitere Attribute gespeichert werden. Daher das ein "recycled Object" nichts anderes als ein Tombstone ist, lässt es sich natürlich auch mit wenigen Attributen mit z.B. LDP, ADRestore oder ADRestore.NET reanimieren. Des Weiteren kann ein gelöschtes Objekt das sich nach Ablauf der DOL zu einem recycled Objekt gewandelt hat, auch nicht mehr aus dem AD-Papierkorb mit allen Werten wiederhergestellt sondern lediglich als Tombstone reanimiert werden.

Das recycled Objekt bleibt weiterhin in dem Container Deleted Objects, bis die im Attribut tombstoneLifetime definierte Zeit abläuft. Anschließend wird das Objekt vom Garbage Collection Prozess unwiderruflich aus dem AD entfernt.

Das bedeutet im Klartext, bei aktiviertem AD-Papierkorb lässt sich ein gelöschtes Objekt nur während der DOL mit allen Werten wiederherstellen. Die Möglichkeiten zum Wiederherstellen sind dabei:

Das Wiederherstellen aus dem AD-Papierkorb mit der AD-Powershell, LDP, ADRestore.NET oder ADRestore.
Eine autoritative Wiederherstellung.

Achtung: Wird der AD-Papierkorb aktiviert, wandeln sich alle AD-Objekte die bis zum Aktivieren des AD-Papierkorbs gelöscht wurden (also alle Tombstones), zu recycled Objekten. Diese Objekte können in der AD-Powershell mit einem bestimmten Befehl angezeigt werden (siehe unten). Jedoch können diese Objekte nicht mit Hilfe des AD-Papierkorbs bzw. der Tombstone-Reanimierung wiederhergestellt werden. Die beiden Tools ADRestore.NET und ADRestore zeigen ebenfalls diese Tombstones nicht an. Das Tool LDP zeigt zwar ebenfalls die Objekte an, ist aber auch nicht in der Lage die Objekte wiederherzustellen. Der einzige Weg diese Objekte herzustellen, ist eine autoritative Wiederherstellung von einer Systemstatus-Sicherung, die vor dem aktivieren des AD-Papierkorbs durchgeführt wurde.

Die Deleted Object Lifetime (DOL) und Recycled Object Lifetime (ROL)

Standardmäßig enthält das Attribut msDS-DeletedObjectLifetime keinen Wert. Es ist <Nicht festgelegt>. In diesem Fall wird der Wert aus der Recycled Object Lifetime festgelegt. Man kann aber natürlich auch jederzeit manuell einen Wert im Attribut msDS-DeletedObjectLifetime definieren.

Die ROL wiederum erhält seinen Wert aus dem Attribut tombstoneLifetime, denn die ROL hat kein eigenes Attribut wie die DOL. Das bedeutet, wenn ein Objekt gelöscht wird und im Attribut msDS-DeletedObjectLifetime ist kein Wert definiert, behält das Objekt für 60/180 Tage seinen logischen Löschzustand bei und wird anschließend zum recycled Objekt umgewandelt. Nach weiteren 60/180 Tagen (nach Ablauf der Tombstone Lifetime) wird es dann endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Das Objekt bleibt somit über den gesamten Zeitraum der DOL und ROL im AD erhalten, ehe es definitiv aus dem AD gelöscht wird.

Ist hingegen im Attribut msDS-DeletedObjectLifetime ein Wert definiert, so beträgt die DOL den eingetragenen Wert in Tagen und es wird nicht der Wert aus dem Attribut tombstoneLifetime angenommen. Wenn daher der Bedarf besteht, ein gelöschtes Objekt länger als die Zeit das im Attribut tombstoneLifetime eingetragen ist aus dem AD-Papierkorb wiederherzustellen, so gilt es einen eigenen Wert im Attribut msDS-DeletedObjectLifetime zu definieren.

Enthält z.B. das Attribut tombstoneLifetime als Wert 180 und ist im Attribut msDS-DeletedObjectLifetime kein Wert eingetragen, so wird ein gelöschtes Objekt erst nach 360 Tagen vom Garbage Collection Prozess für immer aus dem AD entfernt. >

Der Vorgang eines gelöschten AD-Objekts sowie seine Wiederherstellung, bei aktiviertem AD-Papierkorb unter Windows Server 2008 R2

Die Deleted Object Lifetime (DOL) und Recycled Object Lifetime (ROL) überprüfen und bearbeiten

Das Attribut msDS-DeletedObjectLifetime befindet sich im gleichen Container wie das Attribut tombstoneLifetime, nämlich in den Eigenschaften des Containers:
CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Kontrollieren kann man das Attribut msDS-DeletedObjectLifetime z.B. mit Dsquery.

Der Befehl lautet:

Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne" -attr msDS-DeletedObjectLifetime

Falls kein Wert angezeigt wird, gilt der Standardwert aus dem Attribut tombstoneLifetime von 60/180 Tagen (sofern nicht manuell geändert). Ansonsten gilt der angezeigte Wert in Tagen.
Das Attribut tombstoneLifetime lässt sich mit Dsquery folgendermaßen abfragen:
Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" -attr tombstoneLifetime

Falls kein Wert angezeigt wird, gilt als Wert 60 Tage. Ansonsten gilt auch hier der angezeigte Wert in Tagen.

>
Die DOL und das Attribut tombstoneLifetime lassen sich auch mit ADSIEdit überprüfen und bearbeiten. Dazu gilt es zuerst zum folgenden Container zu navigieren:

CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne

Dort befindet sich in den Eigenschaften des Containers zum einen das Attribut msDS-DeletedObjectLifetime und zum anderen das Attribut tombstoneLifetime. Ist im Attribut msDS-DeletedObjectLifetime ein Wert gesetzt, beträgt die DOL den eingetragenen Wert in Tagen. Steht im Attribut als Wert hingegen <Nicht festgelegt>, so beträgt die DOL den Wert aus dem Attribut tombstoneLifetime. Wenn im Attribut tombstoneLifetime als Wert <Nicht festgelegt> ist, so gilt als Wert 60 Tage. Ansonsten beträgt die Zeit den eingetragenen Wert in Tagen.

>
Die DOL lässt sich auch über die AD-Powershell bearbeiten. Dazu ist die AD-Powershell explizit als Administrator aufzurufen und der folgende Befehl einzugeben:

Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“msDS-DeletedObjectLifetime” = Wert}

Das Attribut tombstoneLifetime lässt sich im Übrigen auch auf die gleiche Weise verändern:
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“tombstoneLifetime” = Wert}

Aktivieren und nutzen des AD-Papierkorbs in der Active Directory-Powershell

Nach Ausführen von Dcpromo steht die Active Directore-Powershell mit 76 AD-Cmdlets auf dem DC zur Verfügung. Mit den beiden AD-Powershell Cmdlets Get-ADObject und Restore-ADObject ist es möglich, gelöschte AD-Objekte anzuzeigen sowie wiederherzustellen. Dabei ruft man mit Get-ADObject das gelöschte Objekt auf und übergibt es durch die Pipeline dem Restore-ADObject Cmdlet.

Zum Aktivieren des AD-Papierkorbs ist die folgende Vorgehensweise notwendig:

Im ersten Schritt muss mit „Organisations-Admin“ Rechten der AD-Papierkorb in der Root-Domäne und zwar für alle Domänen in der Gesamtstruktur aktiviert werden. Der Befehl dazu lautet:

Enable-ADOptionalFeature „Recycle Bin Feature“ -Scope ForestorConfigurationset -Target “Root-Domäne*” (*DNS- oder NetBIOS-Name der Root-Domäne)

Es folgt eine Warnung die besagt, dass bei Bestätigen der Meldung dieser Vorgang irreversibel ist. Nach dem Aktivieren des AD-Papierkorbs, lässt es sich nicht mehr deaktivieren!
Wenn der AD-Papierkorb aktiviert wurde, wird im Attribut msDS-EnabledFeature das sich in den Eigenschaften des Containers "CN=Partitions,CN=Configuration,DC=Root-Domäne" befindet, als Wert "CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" eingetragen.
Der folgende Befehl zeigt detaillierte Informationen über die zur Verfügung stehenden Optional Feature im Active Directory an:
Get-ADOptionalFeature -Filter * oder Get-ADOptionalFeature -Filter {Name -Like "*"}
Wurde ein Benutzerkonto aus Versehen gelöscht, so kann man sich das Konto wenn der sAMAccountName bekannt ist, auf diese Art anzeigen lassen:
Get-ADObject -Filter {sAMAccountname –eq „Yusuf“} -Includedeletedobjects

Wiederherstellen lässt sich das Benutzerkonto dann mit diesem Befehl:

Get-ADObject -Filter {sAMAccountname –eq „Yusuf“} –Includedeletedobjects | Restore-ADObject
Ist der „Anzeigename“ eines Benutzerkontos bekannt, so lautet die Abfrage wie folgt. Aber Vorsicht, der „Anzeigename“ ist nicht der Name, der in der MMC Active Directory-Benutzer und -Computer in der Spalte „Name“ angezeigt wird. Denn dieser Wert wiederum, wird im Attribut name gespeichert.

Get-AdObject –Filter {displayname –eq “Yusuf Dikmenoglu”} –Includedeletedobjects

Wiederherstellen lässt sich das Benutzerkonto dann so:

Get-AdObject –Filter {displayname –eq “Yusuf Dikmenoglu”} –Includedeletedobjects | Restore-ADObject
Ein bestimmtes Benutzerkonto wird auf diese Weise angezeigt:

Get-ADObject -Filter {Name -Like “*Name*”} –Includedeletedobjects

Oder so:
Get-ADOject -Filter 'Name -Like "Yusuf*"' -Searchscope Subtree -Includedeletedobjects | ft -a

Wiederherstellen kann man dann das Benutzerkonto so:
Get-ADObject -Filter {Name -Like “*Name*”} –Includedeletedobjects | Restore-ADObject

>
>>
Dieser Befehl zeigt die gelöschten Objekte im Container "Deleted Objects" an:
Get-ADObject -ldapFilter:”(msDS-LastKnownRDN=*)" -Includedeletedobjects

Wiederherstellen kann man ein Benutzerkonto auch wie folgt:
Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=<Benutzer>)" -Includedeletedobjects | Restore-ADObject
Der nachfolgende Befehl zeigt die gelöschten sowie recycelten Objekte mit detailierten Informationen an, die in einer bestimmten OU waren. Mit diesem Befehl können auch die recycelten Objekte angezeigt werden, die vor dem aktivieren des AD-Papierkorbs gelöscht wurden:
Get-ADObject -Filter {Lastknownparent -eq "OU=<OU>,DC=Domäne,DC=de"} -Searchbase "CN=Deleted Objects,DC=Domäne,DC=de" -includedeletedobjects -properties *
Mit dem folgenden Befehl kann man sich alle gelöschten Objekte, egal welcher Klasse, aus dem versteckten Container „Deleted Objects“ der Domänenpartition anzeigen lassen:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=*)“ –Includedeletedobjects | Format-List

>
>>
Oder wer die Objekte jeglicher Klassen im schnellen Überblick haben möchte, verwendet diesen Befehl:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=*)“ –Includedeletedobjects
Die gelöschten AD-Objekte der Klasse „User“ (z.B. Benutzerkonten) lassen sich wie folgt anzeigen:

Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=User)“ –IncludedeletedObjects
Wurde ausversehen eine OU mit etlichen Benutzern gelöscht, so muss zuerst die OU wiederhergestellt werden, ehe dann die Benutzer wiederhergestellt werden können. Doch bevor die OU wiederhergestellt werden kann, wird die GUID der gelöschten OU benötigt. Diese erfährt man durch das Attribut lastknownparent eines Benutzers, das sich in der OU befand. Der Befehl würde so aussehen:
Get-ADOject -filter 'name -like "Yusuf*"' -searchscope subtree -Includedeletedobjects -properties lastknownparent

Dann kann mit diesem Befehl zuerst die OU wiederhergestellt werden:
Restore-ADObject -identity <GUID der OU>

Alle Objekte die sich in der OU befanden, können mit diesem Befehl wiederhergestellt werden:
Get-ADObject -ldapfilter "(lastknownparent=OU=<OU>,DC=Domäne,DC=TLD)" -Includedeletedobjects | Restore-ADObject>
>>>> >>>

Die AD-Powershell im Windows Server 2008 R2

Anzeigen und Wiederherstellen der gelöschten Objekte aus dem AD-Papierkorb mit ADRestore.NET und ADRestore

Das Tool ADRestore.NET muss zuerst installiert werden, lässt sich dann aber sehr simpel mit der Maus bedienen und ist vor allem selbsterklärend. Die gelöschten Objekte lassen sich mit einem Mausklick anzeigen und mit einem weiteren wiederherstellen.

ADRestore.NET
Das Kommandozeilentool ADRestore lässt sich nach dem Download ohne eine Installation in einer Kommandozeile ausführen. Auch dieses Tool ist selbsterklärend.

ADRestore
Ein weiteres kostenloses Tool ist das ADRecycleBin. Es zeigt die gelöschten Objekte an und stellt diese wieder her.

ADRecycleBin

Anzeigen und Wiederherstellen der gelöschten Objekte aus dem AD-Papierkorb mit LDP

>>>>>>

>>>> >

Die gelöschten Objekte im Container Deleted Objects lassen sich ebenfalls mit dem im Betriebssystem integrierten LDAP-Tool LDP anzeigen sowie wiederherstellen lassen.

Die Vorgehensweise wäre wie folgt:

Zuerst gilt es auf dem DC unter Start-Ausführen-LDP.exe das Tool aufzurufen.
Unter Optionen ist dann in den Steuerelementen im Feld Vordefiniert laden die Option Return deleted objects auszuwählen. Wählt man an dieser Stelle stattdessen die Option Return recycled objects aus, kann man sich bei gleicher Vorgehensweise die „recycelten Objekte“ anzeigen lassen.
Danach wählt man unter Remotedesktopverbindung den Punkt Gebunden... aus. Grandiose Bezeichnungen.
Anschließend gibt man unter Ansicht-Struktur den Distinguished Name (DN) der entsprechenden (meistens) Domänenpartition an, z.B. DC=blog,DC=dikmenoglu,DC=de
Nun erweitert man zuerst auf der linken Seite die entsprechende Verzeichnispartition und erweitert auch den Eintrag Deleted Objects mit einem Doppelklick. Jetzt erscheinen die gelöschten Objekte.
Mit einem Rechtsklick auf das wiederzuherstellende Objekt, wählt man den Punkt Ändern aus.
Unter Eingabe bearbeiten gibt man im Feld Attribut isDeleted ein.
Das Feld Werte bleibt leer.
Unter Vorgang wählt man Löschen und klickt auf Eingabe.
Jetzt müssen die gleichen Schritte mit dem Attribut distinguishedName durchgeführt werden.
Im Feld Werte ist nun der original DN des Objekts einzugeben. Daher ist es stets sinnvoll, eine Liste mit allen Objekten und deren DN zu besitzen.
Unter Vorgang wählt man Ersetzen und klickt auf Eingabe.
Nach dem aktivieren von Erweitert führt man die Wiederherstellung mit einem Klick auf Ausführen durch.

Fallbeispiele

Wenn z.B. ein Benutzer Mitglied der Gruppe1 ist, beide Objekte nacheinander gelöscht werden, aber nur das Benutzerkonto aus dem AD-Papierkorb wiederhergestellt wird, befindet sich anschließend das Benutzerkonto logischerweise nicht mehr in der Gruppe1. Wird jedoch die Gruppe1 ebenfalls aus dem AD-Papierkorb wiederhergestellt, werden automatisch Forward- und Back-Link wiederhergestellt. Das Benutzerkonto ist wieder Mitglied der Gruppe1.
Existiert eine Gruppenverschachtelung, so das also GG1 Mitglied von GG2, diese wiederum Mitglied in GG3 ist und GG2 gelöscht wird, verschwinden ebenfalls die Gruppenzugehörigkeiten. Auch hier werden beim wiederherstellen der GG2 aus dem AD-Papierkorb, die Gruppenzugehörigkeiten und somit das Forward- und Back-Link automatisch wiederhergestellt.

Weitere Informationen:

2.175 Attribute msDS-DeletedObjectLifetime
2.109 Attribute isDeleted
2.112 Attribute isRecycled
2.179 Attribute msDS-EnabledFeature
The Active Directory database garbage collection process
Useful shelf life of a system-state backup of Active Directory
Viewing deleted objects in Active Directory

>>> >>> >>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Account Info DLL Version 2

Yusuf Dikmenoglu — Sun, 16 Dec 2007 22:21:46 GMT

Jeder der mit der Additional Account Info DLL (acctinfo.dll) schon einmal gearbeitet hat, weiß diese zusätzlichen Angaben zu schätzen.
Die zusätzlichen Angaben werden in einem weiteren Reiter, in den Benutzereigenschaften angezeigt. Diese DLL befindet sich in den
Account Lockout and Management Tools. Dort ist sie mit der Versionsnummer 1.0.0.1111 vorhanden. Nach dem registrieren dieser DLL,
taucht in den Eigenschaften eines Benutzerobjekts eine weitere Registerkarte auf. Dieser Reiter erscheint nur auf der Maschine,
auf dem diese DLL registriert wurde (und steht somit nicht domänenweit auf jedem Client/Server zur Verfügung). Dort steht z.B.
wann die letzte Benutzeranmeldung erfolgt ist oder wann das Kennwort des Benutzers ausläuft.

Siehe: Die letzte Benutzeranmeldung herausfinden

Der Reiter taucht aber nur dann auf, wenn das Benutzerobjekt direkt (Doppelklick auf das Benutzerobjekt) oder über eine
gespeicherte Abfrage aufgerufen wird. Wird hingegen die Active Directory Suche verwendet, erscheint dieser Reiter nicht.
Das kommt daher, da die Version 1.x lediglich eine Erweiterung in Form einer weiteren Registerkarte in den Eigenschaften des Benutzerobjekts ist.

Die Suche im Active Directory erfolgt z.B. im Snap-In Active Directory-Benutzer und -Computer mit einem Rechtklick auf einer OU oder auf den FQDN.

Des Weiteren ist in der Version 1.x ein Fehler enthalten, denn es zeigt einen Wert im Last-Logon-Timestamp an, obwohl sich die
Domäne nicht im Domänenfunktionsmodus Windows Server 2003 befindet.

Es existiert mittlerweile eine neuere Version dieser DLL und trägt den Namen Acctinfo2.dll (beachtet unten stehende Anmerkung).
In der neueren Version ist die acctinfo2.dll nicht nur ein weiterer Reiter, sondern ein Display Specifier. Dadurch taucht nun auch bei
einer Suche der Reiter auf. Mit dieser Version der DLL, wird desweiteren nicht mehr der Last-Logon-Timestamp im Reiter angezeigt,
sondern erst, wenn sich die Domäne tatsächlich im Domänenfunktionsmodus Windows Server 2003 befindet. Außerdem werden
zusätzliche Informationen bereitgestellt.

Installation

Die Acctinfo2.dll muss zuerst ins Verzeichnis %windir% verschoben werden.
Im nächsten Schritt ist diese DLL, entweder unter Start - Ausführen oder in einer Kommandozeile mit dem Befehl
regsvr32 acctinfo2.dll zu registrieren.

Als nächstes ruft man ADSIEdit (aus den Windows Support Tools) auf und navigiert in der Konfigurationspartition zu folgendem Pfad:
CN=user-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=Domäne,DC=TLD

Hinweis: Läuft der Windows Server mit einer englischen Betriebssystem Version, so lautet die Länderkennung nicht CN=407 sondern CN=409.

Dort angelangt, sind die Eigenschaften von CN=user-Display aufzurufen.
Anschließend gilt es im Attribut adminPropertyPages den folgenden Eintrag hinzuzufügen:
2,{5969F63F-CACF-40bf-8891-CA580EB589E9}

Am Anfang des Eintrags (2,..) ist ein freier oder der nächst höhere Wert zu wählen, gefolgt von einem Komma und der GUID
der Acctinfo2.dll (in geschweiften Klammern).

Danach steht ab sofort der neue Reiter in den Benutzereigenschaften zur Verfügung.
Weiterhin ist es möglich, dass beide Versionen (1.x sowie 2.x) nebeneinander existieren.

Anmerkung: Die aktuelle und von Microsoft unterstütze AcctInfo.dll ist in den Account Lockout and Management Tools enthalten und kann
kostenlos heruntergeladen werden. Wann und ob Microsoft die Version 2.x veröffentlichen wird (zum Download bereitstellt), ist zum jetzigen
Zeitpunkt nicht bekannt. Sobald es Nähere Informationen darüber geben wird, werde ich es hier veröffentlichen.

Update: 27.04.2010>>

Es gibt mittlerweile auch eine (nicht supportete!) x64Bit Version der acctinfo2.dll.

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Computerkonto löschen

Yusuf Dikmenoglu — Mon, 10 Sep 2007 11:56:34 GMT

Eines der vielen Aufgaben eines Administrators ist, Ordnung in seinem Netzwerk zu halten. Dazu gehört unter anderem,
Mitarbeiter die das Unternehmen verlassen haben aus dem Active Directory zu löschen (oder mindestens zu deaktivieren).
Ebenso bei ausgemusterten Clients, die Computerobjekte aus dem Active Directory zu entfernen.

Möchte man nun ein Computerkonto aus dem Active Directory entfernen, könnte es zu folgender Meldung kommen:

Object <Computername> is a container and contains other objects. Are you sure you want to delete object <Computername> and
the objects it contains? This operation could take a long time if <Computername> contains a large number of objects.

Diese Meldung bedeutet, dass das Computerkonto Unterobjekte enthält.
Der eine oder andere wird sich vielleicht fragen, wie das sein kann. Ein Computerkonto das sich etwa wie eine OU verhält?

Es reicht zum Beispiel auf dem XP-Client den Message Queuing Dienst (genauer: Integration in das Active Directory) zu installieren,
um ein neues Objekt unter dem Computerobjekt zu erhalten.

Oftmals ist es aber lediglich ein im Verzeichnis freigegebener Drucker an dem Client.
Um das zu überprüfen muss man nicht unbedingt ADSIEdit, einen LDAP-Browser oder den Active Directory Explorer verwenden, sondern,
im Snap-In Active Directory-Benutzer und -Computer einfach unter ANSICHT die Option Benutzer, Gruppen und Computer als Container aktivieren.
Danach werden die Computerobjekte als Container dargestellt und falls diese weitere Objekte enthalten, kommen diese somit zum Vorschein.

Wenn nun also die o.g. Meldung erscheint, gilt es zuerst wie in diesen beiden Fällen genannt,
zuerst den Message Queuing Dienst (unter Systemsteuerung – Software) zu deinstallieren oder die Druckerfreigabe zu entfernen.

Die Objekte lassen sich auch mit ADSIEdit oder dem Active Directory Explorer löschen.
Danach lässt sich das Computerkonto ohne eine Meldung entfernen.

Wie lassen sich veraltete Computerkonten aufspüren?

Clients die sich seit dem Zeitraum x nicht mehr an der Domäne angemeldet haben, lassen sich im Domänenfunktionsmodus
Windows Server 2003 mit DSQUERY aufspüren. Bei der Abfrage mit DSQUERY, werden die Computerkonten die ihr Kennwort
seit dem angegebenen Wert nicht geändert haben ermittelt. Standardmäßig wird das Computerkontokennwort ab Windows 2000
alle 30 Tage geändert (unter NT sind es 7 Tage), daher sollte ein höherer Wert für die Abfrage gewählt werden.

Mit dem folgenden Befehl werden alle Computerkonten angezeigt, die seit 70 Tagen ihr Kennwort nicht geändert haben:
dsquery computer -stalepwd 70

Zusammen mit DSRM lassen sich die ermittelten Computerkonten automatisch löschen. Der Befehl lautet wie folgt:
dsquery computer -stalepwd 70 | dsrm -noprompt -c

Das Computerkontokennwort wird aber nur geändert, wenn der Client Verbindung zur Domäne hat. Ist der Client wie es
z.B. bei Laptops der Fall sein kann monatelang unterwegs und hat somit keine Verbindung zur Domäne, ändert sich
das Kennwort nicht automatisch nach 30 Tagen. Erst wenn sich der Client das nächste Mal an der Domäne authentifiziert,
erhält der Client ein neues Computerkontokennwort.

Wie lassen sich veraltete Computerkonten entfernen?

Wie bereits oben erwähnt, lassen sich veraltete Computerkonten mit DSQUERY in Verbindung mit DSRM entfernen.
Microsoft bietet ein Skript an, um veraltete Computerkonten zu entdecken sowie zu entfernen.
How to detect and remove inactive machine accounts

Mit dem Tool von Joe Richard OldCMP lassen sich ebenfalls veraltete Computerkonten entfernen.

Richard Mueller bietet dazu folgendes Skript an Move Old Computers.

Mit der AD-PowerShell lassen sich deaktivierte und alte Computerkonten wie folgt aufspüren bzw. löschen

>>>>>>

Alte oder deaktivierte Computerkonten mit der AD-PowerShell löschen

>>>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Die letzte Benutzeranmeldung herausfinden

Yusuf Dikmenoglu — Sun, 19 Aug 2007 08:21:05 GMT

Möchte man die letzte Anmeldung eines Benutzers herausfinden, so führen zu diesem Vorhaben mehrere Wege zum Ziel.
Die benötigte Information lässt sich wie vieles (aufwändig) über das ADSI auslesen.
Das Attribut in dem die letzte Anmeldung gespeichert wird, lautet Last-Logon.
Der Nachteil an diesem Attribut ist, dass es nicht zwischen den Domänencontrollern repliziert wird.
Es gilt also das Attribut Last-Logon auf jedem Domänencontroller in der Domäne abzufragen um das aktuellste Datum herauszufinden.

Additional Account Info - AcctInfo.dll

Eine recht einfache Möglichkeit wäre (unter Windows 2000/2003/2008), sich die Account Lockout and Management Tools herunterzuladen
und die AcctInfo.dll zu nutzen. Diese DLL muss vorher registriert werden. Dazu extrahiert man zuerst die heruntergeladene Datei in ein
Verzeichnis (z.B. C:\Tools), öffnet eine Kommandozeile (CMD) und navigiert zu den entpackten Dateien. Anschließend registriert man mit
folgendem Befehl die DLL: regsvr32 acctinfo.dll. Danach erscheint im Snap-In Active Directory-Benutzer und -Computer in den
Eigenschaften der Benutzer ein weiterer Reiter. Dieser neue Reiter zeigt unter anderem die letzte Benutzeranmeldung an:

Hinweis: Wenn ein Benutzer in der MMC über eine Suche aufgerufen wird, ist dieser Reiter nicht zu sehen.

Dieser Reiter erscheint lediglich auf dem Arbeitsplatz/Server, auf dem die DLL registriert wurde. Um den Reiter zu entfernen,
muss der Befehl (über Start – Ausführen) regsvr32 /u <Pad zur AcctInfo.dll> ausgeführt werden.

Das Attribut Last-Logon-Timestamp>

Wie vieles andere wurde auch dieses Verhalten in Windows Server 2003 verbessert.
Im Schema des Windows Server 2003 wurde ein neues Attribut namens Last-Logon-Timestamp dem Benutzer-Objekt hinzugefügt.
Wenn sich die Domäne mindestens im Domänenfunktionsmodus Windows Server 2003 befindet, kann man das Attribut Last-Logon-Timestamp nutzen.
Dieses Attribut ist aber vom Attribut Last-Logon abhängig. Würde z.B. bei einer Benutzer-Anmeldung das Attribut Last-Logon nicht gesetzt,
wird auch das Attribut Last-Logon-Timestamp nicht aktualisiert. Es bietet allerdings den Vorteil, dass es auf andere DCs repliziert wird und somit
einem das durchsuchen aller DCs erspart bleibt. Jedoch wird Last-Logon-Timestamp (um die Replikationslast gering zu halten) standardmäßig alle 14 Tage,
abzüglich einer zufällig gewählten Differenz von bis zu 5 Tagen aktualisiert. Das Attribut wird also zwischen zehn und vierzehn Tagen repliziert.
Wird nun das Attribut Last-Logon aktualisiert, überprüft der DC ob das Aktualisierungsintervall das in dem Attribut ms-DS-Logon-Time-Sync-Interval
angegeben ist, erreicht wurde, um dann Last-Logon-Timestamp zu aktualisieren.

Das Aktualisierungsintervall von Last-Logon-Timestamp wird im Attribut ms-DS-Logon-Time-Sync-Interval gesteuert.
Dieses Attribut befindet sich in den Eigenschaften der Domänenpartition und lässt sich z.B. mit ADSIEdit bearbeiten.
Der Wert dieses Attributs ist standardmäßig <Not Set> und bedeutet einen Standardwert von 14 Tagen.
Dieser Wert kann zwischen 1 und 100.000 Tage betragen. Trägt man als Wert 0 ein, wird das Attribut Last-Logon-Timestamp nicht mehr aktualisiert.

Ein zweimonatiger Test mit 50 Benutzerkonten in einer produktiven Umgebung hat ergeben, dass die Aktualisierung von Last-Logon-Timestamp
(mit einem Standardwert im Attribut ms-DS-Logon-Time-Sync-Interval) bei 80% der Benutzerkonten, ausgeglichen zwischen zehn und elf Tagen lag.

Wenn ein DC unter Windows Server 2003 (ohne SP1) läuft, kann es unter Umständen vorkommen, dass dieses Attribut nicht aktualisiert wird:
A network logon that uses NTLM authentication does not update the lastLogonTimestamp attribute in the Active Directory schema of a Windows Server 2003-based domain controller

Sowohl das Attribut Last-Logon, als auch Last-Logon-Timestamp, sind Integer8 Datentypen.
Diese haben eine Länge von 8 Byte bzw. 64 Bit. Die Zeit wird ab dem 1. Januar 1601 12:00 AM im 100 Nanosekunden Intervall berechnet.
Der Wert aus Last-Logon oder Last-Logon-Timestamp wird in der Greenwich Mean Time (GMT) Zone im Active Directory gespeichert und muss
in ein leserliches Datumsformat konvertiert werden, da man ansonsten mit dem Wert (der in etwa so aussieht: 128362271633877741) nicht
sonderlich viel anfangen kann. Zum konvertieren gibt man in der Kommandozeile den Befehl w32tm /ntte <Wert> ein.

Benutzer die sich länger nicht an der Domäne angemeldet haben

Benutzerkonten die sich seit längerem an der Domäne nicht authentifiziert haben, lassen sich recht schnell auf verschiedene Weise herausfinden.

Hinweis: Die folgenden Beispiele benötigen die Domänenfunktionsebene Windows Server 2003!

1. Das Snap-In Active Directory-Benutzer und –Computer (ADBuC)

In der MMC ADBuC kann man sich eine Allgemeine Abfrage durch eine Suche (Rechtsklick auf die Domäne) oder durch eine Gespeicherte Abfrage erstellen.
Dort gilt es die Auswahl bei der Option Tage seit der letzten Anmeldung zwischen 30, 60, 90, 120 oder 180 zu treffen.
Der Wert ist nicht frei definierbar sondern fest vorgegeben:

2. Dsquery

Mit einem der DS*-Tools die standardmäßig ab Windows Server 2003 integriert sind, lässt sich eine einfache Abfrage erstellen.
Die Rede ist von DSQUERY. Die Abfrage z.B. in einer Kommandozeile, könnte wie folgt aussehen:

dsquery user domainroot –inactive <Anzahl der Wochen>

Damit werden alle Benutzerkonten der Domäne, die während der angegebenen Anzahl an Wochen (oder länger) nicht angemeldet waren angezeigt.

Hinweis: Die Abfrage in ADBuC sowie Dsquery nutzen bei der Abfrage das Attribut Last-Logon-Timestamp.

3. Ab Windows Server 2008 und Windows Vista steht eine weitere Option zur Verfügung, um die letzte interaktive Domänenanmeldung herauszufinden:

Die letzte interaktive Domänenanmeldung anzeigen

4. Mit der AD-PowerShell kann man sich ebenfalls das letzte Anmeldedatum der Benutzer ausgeben lassen. Dazu muss eine Abfrage nach "LastLogonDate" durchgeführt werden. Diese Eigenschaft liest den Wert aus dem Attribut LastLogonTimeStamp aus. Der Befehl lautet:

Get-ADUser -Filter * -Properties LastLogonDate | Sort-Object -Property LastLogonDate -descending | FT -Property Name, LastLogonDate -A

AD-PowerShell Befehle

Weitere Beispiele

Wie bekomme ich heraus, wann ein User sich zuletzt ans AD angemeldet hat?

Die Scipting-Guys haben dazu zwei Artikel veröffentlicht:
http://www.microsoft.com/technet/technetmag/issues/2006/01/ScriptingGuy/default.aspx
http://www.microsoft.com/technet/scriptcenter/topics/win2003/lastlogon.mspx>

How can I report all inactive user accounts, and optionally disable them?
TRUELAST.EXE freeware outputs the last logon time a particular user logged onto the current or a specified domain
The Windows Server 2003 Active Directory lastLogonTimeStamp attribute is replicated across all domain controllers
Using the lastLogonTimestamp attribute in Windows Server 2003

Weitere Informationen:
Account Info DLL Version 2
Einen Large Integer Wert umrechnen
The lastLogon attribute is not updated when a client computer runs an LDAP simple bind operation against a Windows Server 2003-based domain controller

>> >>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Gespeicherte Abfragen

Yusuf Dikmenoglu — Sun, 25 Mar 2007 21:42:00 GMT

Dem Administrator steht seit Windows Server 2003 in der Microsoft Management Console (MMC) Active Directory-Benutzer und –Computer (dsa.msc)
die Funktion Gespeicherte Abfragen zur Verfügung. In diesem Ordner hat man die Möglichkeit Abfragen zu erstellen, bearbeiten und zu speichern.
Dabei ist es auch möglich, eigene benutzerdefinierte Abfragen zu erstellen. Abfragen wurden früher aufwändig mit ADSI-Skripten erstellt.
Heute lässt es sich „recht einfach“ in dem Snap-In „Active Directory-Benutzer und –Computer“ definieren.
Somit hat der Administrator die Möglichkeit, wiederkehrende Abfragen nicht jedes Mal neu zu erstellen,
sondern die bereits getätigten Abfragen erneut zu nutzen.

Die durchgeführten Abfragen werden unter dem angemeldeten Benutzerkonto automatisch nur in der MMC gespeichert, in der sie durchgeführt wurden.
Auch wenn man sich mehrere MMCs mit dem Snap-In „Active Directory-Benutzer und –Computer“ erstellt, wird die Abfrage nur in der einen MMC gespeichert,
in der sie durchgeführt wurde. Man könnte aber eine MMC erstellen (Start-Ausführen-MMC), in dieser das Snap-In „Active Directory-Benutzer und –Computer“
hinzufügen, die gewünschten Abfragen tätigen und die MMC (als MSC-Datei) auf einem Netzlaufwerk speichern, damit andere Kollegen diese nutzen können.
Des Weiteren besteht die Möglichkeit, die Abfragen im XML-Format zu exportieren und in einer anderen MMC bzw. auf einem anderen Client, zu importieren.

Eine Abfrage erstellt man folgendermaßen:

Zuerst gilt es das Snap-In Active Directory-Benutzer und –Computer zu starten.
Mit einem Rechtsklick auf Gespeicherte Abfragen gilt es das Kontextmenü aufzurufen.
Anschließend wählt man den Punkt Neu und bekommt die Auswahl zwischen Abfrage und Ordner.
Durch erstellen von Ordnern kann man sich eine eigene Abfrage-Struktur aufbauen und lässt sich dadurch, besser verwalten.
Wurde der Punkt Abfrage ausgewählt, öffnet sich als nächstes ein Fenster das Neue Abfrage lautet.
Dort ist es möglich, der zu erstellenden Abfrage einen Namen und eine Beschreibung, die die eigentliche Abfrage evtl. etwas erläutert, einzugeben.
Im Feld Abfragestamm gilt es den Container auszuwählen (mit Durchsuchen), im dem die Suche starten soll.
Möchte man alle untergeordneten Container des ausgewählten Containers in die Suche mit einbeziehen, so ist es notwendig das Kontrollkästchen
Untergeordnete Container miteinbeziehen zu aktivieren.
Als nächstes gilt es mit einem Klick auf Festlegen… die gewünschte Abfrage zu definieren.

Der Vorteil an dieser Aufgabe ist, dass keinerlei administrative Rechte notwendig sind. Daher bietet es sich an, das Adminpak (von einem
Windows Server 2003 DC oder Mitgliedsserver aus dem Verzeichnis %windir%\system32\adminpak.msi) auf einer Admin-Workstation
zu installieren und die Abfrage mit Benutzerrechten auszuführen. Möchte man z.B. nur die Active Directory Snap-Ins installieren,
so lässt sich das auf folgende Art realisieren:

msiexec /i adminpak.msi ADDLOCAL=FeADTools /qb

>>>

How to use Adminpak.msi to install a specific server administration tool in Windows

Beispiel LDAP-Abfragen

Möchte man z.B. eine eigene Abfrage definieren, so vergibt man der Abfrage einen Namen und wenn gewünscht eine Beschreibung,
wählt anschließend den Abfragestamm und klickt auf Festlegen… Im darauf erscheinenden Fenster gilt es im Feld Suchen:
die Benutzerdefinierte Suche auszuwählen. Anschließend muss im Reiter Erweitert der LDAP-Filter eingegeben werden.
Im folgenden sind einige LDAP-Filter aufgeführt.

Benutzer Filter

Alle Benutzer die eine E-Mail Adresse in den Benutzereigenschaften eingetragen haben, können mit diesem LDAP-Filter angezeigt werden:
(objectCategory=person)(mail=*)

Möchte man nur die Benutzer angezeigt bekommen, die keine E-Mail Adresse eingetragen haben, so wäre dieser Filter zu verwenden:

(objectCategory=person)(!mail=*)

Alle gesperrten Benutzer anzeigen (zu oft falsch eingegebenes Kennwort):
(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))

Benutzerkonten die ab dem 01.01.2010 erstellt wurden, kann man sich mit folgendem Filter anzeigen lassen:

(objectCategory=person)(whenCreated>=20100101000000.0Z)

Alle aktiven Benutzerkonten (also keine deaktivierten Benutzer) anzeigen, die ab dem 01.01.2010 erstellt wurden

(&(sAMAccountType=805306368)(whenCreated>=20100101000000.0Z)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Alle Benutzerkonten anzeigen, die nach dem 01.01.2010 geändert wurden:
(&(sAMAccountType=805306368)(whenChanged>=20100101000000.0Z))

Alle Benutzer anzeigen, die sich seit dem 10.01.2010 nicht mehr angemeldet haben:
(&(&(objectCategory=person)(objectClass=user)(LastLogonTimeStamp<=129076122047040000)))

Alle "aktivierten" (und keine deaktivierten) Benutzer anzeigen, die bei der nächsten Anmeldung ihr Kennwort ändern müssen:
(objectCategory=person)(objectClass=user)(pwdLastSet=0)(!useraccountcontrol:1.2.840.113556.1.4.803:=2)

Alle Benutzer die bei ihrer nächsten Anmeldung ihr Kennwort ändern müssen, lassen sich auf diese Art anzeigen:
(&(objectCategory=person)(pwdLastSet=0))

Der LDAP-Filter der alle deaktivierten Benutzerkonten anzeigt, wäre dieser:
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2)) >

Der Filter zum anzeigen von nicht deaktivierten Benutzerkonten (also lediglich aktive Benutzerkonten), sieht wie folgt aus:
(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Die Abfrage würde mit Dsquery zusammen mit Dsget wie folgt aussehen:
Dsquery User <DN des Containers> | Dsget User -samid -disabled

Um sich alle Benutzer anzuzeigen, die Mitglied einer bestimmten Gruppe sind, wäre dieser LDAP-Filter anzuwenden:

(objectCategory=user)(memberOf=CN=Techniker,CN=Users,DC=intra,DC=dikmenoglu,DC=de)

In diesem Beispiel befindet sich die Gruppe Techniker im Standard-Container Users und die Domäne lautet intra.dikmenoglu.de.

Damit alle Benutzer angezeigt werden, die nicht in einer bestimmten Gruppe Mitglied sind, gilt es diesen Filter zu verwenden:
(&(objectCategory=person)(objectClass=user)(!memberof=CN=GRUPPE,CN=Users,DC=DOMÄNE,DC=TLD))

Mit Dsquery würde die Abfrage folgendermaßen aussehen:
dsquery * domainroot -filter "(&(objectCategory=person)(objectClass=user)(!memberof=CN=GRUPPE,CN=Users,DC=DOMÄNE,DC=TLD))" -limit 1000

Die Benutzerkonten bei denen in den Benutzereigenschaften das Kontrollkästchen Kennwort läuft nie ab (z.B. bei Dienstkonten) aktiviert sind, lassen sich auf diese Weise anzeigen:

(&(objectcategory=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))

Alle Benutzer anzeigen, die nichts im Profilpfad eingetragen haben:
(&(objectCategory=person)(!profilepath=*))

Alle Benutzer anzeigen, die KEIN LoginSkript eingetragen haben:
(&(objectcategory=person)(!scriptPath=*))

Alle Benutzer anzeigen, die ein bestimmtes LoginSkript eingetragen haben:
(&(objectCategory=person)(scriptPath=Login.bat))

Alle Benutzer anzeigen, die sich noch NIE angemeldet haben:
(&(objectCategory=person)(objectClass=user))(|(lastLogon=0)(!(lastLogon=*)))

Alle Benutzer anzeigen, die KEINEN Vorgesetzten eingetragen haben:
(&(objectCategory=person)(!directreports=*))

Alle Objekte anzeigen, in im Feld Abteilung, Beschreibung oder Firma "AD" eingetragen haben:
(|(department=AD)(company=AD)(description=AD))

Alle Benutzerkonten anzeigen, die keine Beschreibung haben:
(&(objectCategory=person)(!description=*))

Alle Benutzerkonten anzeigen, die am 01.01.2010 abgelaufen sind:
(&(objectCategory=person)(accountExpires=129068604000000000))

Alle Benutzer die eine Handynummer beginnend mit 0151 oder 0171 anzeigen:
(&(objectCategory=person)(|(mobile=0151*)(mobile=0171*)))

Alle Benutzer mit dem Vornamen "Yusuf" anzeigen:

(&(objectCategory=person)(CN=Yusuf*))

Alle Benutzer mit dem Vornamen Yusuf oder Kaan anzeigen:
(objectCategory=person)(|(CN=Yusuf*)(CN=Kaan*))

Alle Benutzer anzeigen, die sich einwählen dürfen:
(&(objectCategory=person)(msNPAllowDialin=TRUE))

Alle Benutzer anzeigen die 2 Mal (oder mehr) ihr Kennwort falsch eingegeben haben:
(&(objectCategory=person)(badPwdCount>=2))

Alle Benutzer anzeigen, ausser Fritz:
(&(objectCategory=person)(!cn=Fritz*))

Gruppen Filter

Alle domänenlokale-, globale- und universelle Sicherheitsgruppen werden hiermit angezeigt:
(groupType:1.2.840.113556.1.4.803:=2147483648)

Alle domänenlokale Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483644))

Alle globale Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483646))

Alle universellen Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483640))

Alle domänenlokale Verteilergruppen anzeigen:
(&(objectCategory=group)(groupType=4))

Alle Verteilergruppen anzeigen:
(&(objectCategory=group)(!groupType:1.2.840.113556.1.4.803:=2147483648))

Alle globale Verteilergruppen anzeigen:

(&(objectCategory=group)(groupType=2))

Alle universelle Verteilergruppen anzeigen:
(&(objectCategory=group)(groupType=8))

Alle Gruppen anzeigen, die keine Mitglieder enthalten (also leere Gruppen):

(&(objectClass=group)(!member=*))

Möchte man sich alle Gruppen anzeigen, in denen ein bestimmter Benutzer (direkt, nicht verschachtelt) Mitglied ist, so würde der Filter wie folgt aussehen:

(&(objectCategory=group)(member=CN=Yusuf,CN=Users,DC=intra,DC=dikmenoglu,DC=de))

In diesem Beispiel befindet sich der Benutzer Yusuf im Standard-Container Users und die Domäne lautet intra.dikmenoglu.de.

Alle Gruppenkonten anzeigen, die keine Beschreibung eingetragen haben:
(&(objectCategory=group)(!description=*))

Alle Gruppen anzeigen die mit "AD" oder "LDAP" anfangen:
(objectCategory=group)(|(CN=AD*)(CN=LDAP*))

Computer Filter

> >

Alle NT4 Computer anzeigen:
(&(objectCategory=computer)(operatingSystemVersion=4*))

Alle Windows 2000 Computer in der Domäne anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 2000*))

Alle Windows Server 2003 mit Service Pack 1 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))

Alle Windows Server 2008 (aber kein 2008 R2) anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))

Alle Windows Server 2008 R2 (alle Editionen) anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))

Alle deaktivierten Computer-Konten in der Domäne, lassen sich mit diesem Filter anzeigen:
(&(objectclass=computer)(userAccountControl:1.2.840.113556.1.4.803:=2))

Die Benutzer- sowie Computerkonten die eine Beschreibung enthalten, können mit diesem Filter aufgelistet werden:

(&(description=*)(|(objectCategory=computer)(objectCategory=user)))

Alle Domänencontroller anzeigen:
(&(objectCategory=Computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))

Nur Windows Server 2003 DCs anzeigen:
(&(primaryGroupId=516)(objectCategory=computer)(operatingSystem=Windows Server 2003*))

Nur Windows Server 2003 Mitgliedsserver anzeigen, aber KEINE DCs:
(&(samAccountType=805306369)(!(primaryGroupId=516))(objectCategory=computer)(operatingSystem=Windows Server 2003*))

Nur Windows Server 2008 DCs anzeigen:
(&(primaryGroupId=516)(objectCategory=computer)(operatingSystem=Windows Server* 2008*))

Nur Windows Server 2008 Mitgliedsserver anzeigen, aber KEINE DCs:
(&(samAccountType=805306369)(!(primaryGroupId=516))(objectCategory=computer)(operatingSystem=Windows Server* 2008*))

Alle Windows XP Clients mit Service Pack 2 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))

Alle Windows Vista Clients mit Service Pack 1 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))

Alle Windows 7 Clients anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 7*))

Alle Windows 7 "Ultimate" Clients anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 7 Ultimate))

Alle globalen Kataloge (GCs) in der Gesamtstruktur anzeigen:

(&(objectCategory=nTDSDSA)(options:1.2.840.113556.1.4.803:=1))

Exchange Abfragen

Alle Kontakte einer Domäne die keiner Gruppe zugeordnet sind, werden mit dem folgenden Filter angezeigt:
(objectclass=contact)(!(memberof=*))

Alle Benutzer anzeigen, die nicht den Standardwert für ihre Exchange-Postfachgröße verwenden:
(&(objectCategory=user)(mDBUseDefaults=FALSE))

Alle Konten anzeigen die eine bestimmte Exchange Mailadresse eingetragen haben:
(&(objectClass=user)(proxyAddresses=SMTP:mail@blog.dikmenoglu.de))

Benutzer, Kontakte und Verteilergruppen die nicht in der GAL auftauchen (ausgenommen Public Folder):
(&(msExchHideFromAddressLists=TRUE)(!objectClass=publicFolder))

Alle Benutzer anzeigen, die keine Exchange Mailadresse (proxyAddresses) haben:
(&(objectCategory=person)(objectClass=user)(!proxyAddresses=*))

Weitere Informationen:
Gespeicherte Abfragen für dsa.msc
Search Filter Syntax

How to use the PrimaryGroupID attribute to find the primary group for a user
How to query Active Directory by using a bitwise filter
>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Erstellungsdatum eines Benutzerobjekts

Yusuf Dikmenoglu — Sun, 25 Feb 2007 22:45:41 GMT

Das Erstellungsdatum eines Benutzerobjekts, kann aus dem Active Directory abgefragt werden.

Das Attribut in dem das Datum gespeichert wird, nennt sich When-Created und wird auf andere Domänencontroller,
sowie in den globalen Katalog (Global Catalog, GC) repliziert.
When-Created

Eine Abfrage per Skript könnte folgendermaßen aussehen:
How Can I Get a List of All the Objects that have been Added to Active Directory Since a Specified Date?

Ein ähnliches Attribut ist Create-Time-Stamp (RFC 2251). Es ist zwar im Schema definiert, aber es enthält selbst keinen Wert.
Die Attributwerte werden allerdings im Moment der Abfrage errechnet. Diese Art von Attribut wird „Operational Attribute“ oder
auch „Constructed Attribute“ genannt. Da das Attribut Create-Time-Stamp „constructed“ ist, kann es nicht repliziert werden.
Sein Wert wird auch nicht in den GC übertragen.
Um die Kompatibilität mit X.500/LDAP herzustellen, erhält man bei einer Abfrage des Attributs Create-Time-Stamp,
den Wert von When-Created zurück. Möchte man dieses Attribut per Skript abfragen, so muss dies explizit über die GetInfoEx Methode erfolgen.>

Create-Time-Stamp

Operational Attributes

MMC Snap-In „Active Directory-Benutzer und –Computer“

Recht einfach lässt sich das Erstellungsdatum eines Benutzerobjekts über die grafische Benutzerverwaltung anzeigen.
Im Snap-In „Active Directory-Benutzer und –Computer“ ist es notwendig, unter Ansicht die Option Erweiterte Funktionen zu aktivieren um somit,
weitere Registerkarten im Benutzerobjekt anzeigen zu lassen. Danach navigiert man zum Container Users
(worin standardmäßig die Benutzerobjekte gespeichert werden) bzw. zur Organisationseinheit (Organizational Unit, OU), in dem sich die Benutzerobjekte befinden. Anschließend ruft man, mit einem Rechtsklick auf das Benutzerobjekt, die Eigenschaften des Benutzers auf.

Im Reiter Objekt befindet sich der Eintrag "Erstellt am:".

>> >>>>

MMC Active Directory Service Interface Editor - ADSIEdit

Es ist ebenfalls möglich, mit ADSIEdit.msc (aus den Windows Support Tools) sich das Attribut anzeigen zu lassen. Dazu gilt es,
ADSIEdit.msc über Start – Ausführen – ADSIEdit.msc aufzurufen und sich mit der Domain-Partition zu verbinden (falls noch keine Verbindung besteht).
Als nächstes erweitert man die Einträge Domain [DC-Name.<Domäne>.<TLD>] sowie den Container DC=<Domäne>,DC=<TLD>.
Im Anschluss navigiert man zum Container CN=Users bzw. OU=<OU-Name> in dem sich die Benutzerobjekte befinden und wählt mit einem Rechtsklick
auf das Benutzerobjekt CN=<Benutzername>, die Eigenschaften aus. Nun kann man im Eigenschaften-Fenster des Benutzers,
dass Attribut whenCreated kontrollieren.

Befehlszeilen-Abfrage mit DSQUERY

Neben der grafischen Oberfläche, lässt sich das Attribut auch über die Befehlszeile abfragen.

Dazu bietet sich eines der DS-Tools, dass im Windows Server 2003 Betriebssystem integriert ist an. Das Tool das sich dazu eignet, lautet dsquery.

Der Befehl für die Abfrage, könnte folgendermaßen lauten (alles in einer Zeile):

dsquery * domainroot -filter "(&(objectClass=User)(objectCategory=Person))" -attr distinguishedName sAMAccountName whenCreated -Limit 0

Dsquery
How do I know what attribute names to use when performing a 'DSQUERY *'?>>

Hinweis: Möchte man ausschließlich Benutzerobjekte angezeigt bekommen, so ist neben dem Attribut „ObjectClass=User”,
zusätzlich das Attribut „ObjectCategory=Person“ bzw. „ObjectCategory=User“ abzufragen.

Befehlszeilen-Abfrage mit ADFind

Ein weiteres Befehlszeilenprogramm, das auf keinem administrativen PC fehlen sollte, ist das von Joe Richards entwickelte Tool – ADFind.

Die Abfrage könnte z.B. folgendermaßen lauten:

Adfind -b DC=<Domäne>,DC=<TLD> -f “&(objectclass=user)(objectcategory=person)" sAMAccountName whencreated

Download: AdFind

Wie die Abfrage mit der AD-PowerShell aussieht, wird im folgenden Artikel beschrieben

Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Active Directory - Abfrage

Yusuf Dikmenoglu — Wed, 26 Jul 2006 16:10:25 GMT

Wie kann man das Active Directory fragen, welche Benutzer Mitglied einer Gruppe sind ?

Wenn man wissen möchte, welche Benutzer Mitglied einer bestimmten Gruppe sind, kann man dies mit folgendem Befehl abfragen:

DSGET GROUP "Distinguished Name (DN)-DER-GRUPPE" -members -expand

Wenn man beispielsweise eine Gruppe mit dem Namen „Verkauf“ hat, die sich in der Organisationseinheit „Newsgroup“ befindet und die
Domäne „intra.dikmenoglu.de" heißt, würde der Befehl wie folgt lauten:

DSGET GROUP „CN=Verkauf,OU=Newsgroup,DC=intra,DC=dikmenoglu,DC=de” -members -expand

Wenn sich die User sowie die Gruppen im Standard-Container USERS befinden (im Snap-In „Active Directory-Benutzer und -Computer“), so würde der Befehl folgendermaßen lauten:

DSGET GROUP „CN=<Gruppenname>,CN=Users,DC=intra,DC=dikmenoglu,DC=de“ -members -expand

Der Schalter -members zeigt eine Liste der Gruppenmitglieder an. Der Schalter -expand bewirkt im Falle des „-members“-Parameters,
dass die rekursiv (umgekehrt) expandierte (also „auseinander gezogene" im Sinne von vollständig angezeigte) Liste der Mitglieder der Gruppe
angezeigt wird. Dieser Parameter übernimmt die unmittelbare Liste der Mitglieder der Gruppe und expandiert rekursiv jede Gruppe in dieser Liste,
um sowohl die Gruppenzugehörigkeit festzustellen als auch ein komplettes „closure set“ der Mitglieder zu erhalten.

Wenn dieser Befehl nun noch mit dem Befehl „> C:\dsget.txt“ erweitert wird, kann man sich das Ergebnis in eine Textdatei exportieren lassen.
Die Syntax lautet für das angegebene Beispiel:
DSGET GROUP „CN=Verkauf,OU=Newsgroup,DC=intra,DC=dikmenoglu,DC=de” -members –expand > C:\dsget.txt

Eine weitere Alternative wäre:
dsquery group -samid <Gruppe> | dsget group -members

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

Es gibt aber noch eine recht einfache Variante: Net Group <Gruppenname> /Domain

Es ist auch möglich, die Mitglieder einer Gruppe, mit LDIFDE zu exportieren.

Der Befehl könnte z.B. folgendermaßen aussehen:

Ldifde -m -f "C:\Ldifde.txt" -r "(sAMAccountname=<Gruppenname>)" -l name,member

Des Weiteren bekommt man die gewünschten Informationen auch über ein Skript:
List All the Members of a Group

Man kann sich auch über eine gespeicherte Abfrage die Mitglieder einer Gruppe anzeigen lassen.
Der Filter dazu könnte folgendermaßen aussehen:

(objectCategory=user)(memberOf=CN=Gruppe,CN=Users,DC=intra,DC=dikmenoglu,DC=de)

Oder in Verbindung mit den ds*-Tools, würde der Filter so aussehen:
(&(objectCategory=user)(memberOf=CN=Gruppe,CN=Users,DC=intra,DC=dikmenoglu,DC=de))

In welchen Gruppen ist ein bestimmter Benutzer?

Möchte man die direkten Gruppenmitgliedschaften bestimmter Benutzer ermitteln, so kann der folgende Befehl verwendet werden:

dsquery user -samid <Benutzername> | dsget user -memberof

oder:

dsget user "DN des Benutzerobjekts" -memberof

Sollen hingegen auch die verschachtelten Gruppenmitgliedschaften angezeigt werden, dann gilt es diesen Befehl auszuführen:

dsget user "DN des Benutzerobjekts" -memberof -expand

bzw.

dsquery user -samid <Benutzername> | dsget user -memberof -expand

Wie können die Mitglieder einer lokalen Gruppe auf einem Arbeitsgruppen-Server angezeigt werden?
Net Localgroup <Gruppe>

Die Mitglieder der Gruppe "Domänen-Benutzer" auflisten

Die Mitglieder der Gruppe Domänen-Benutzer lässt sich nicht auf die herkömmliche Weise Abfragen.
Die Gruppe Domänen-Benutzer (auf englisch: Domain Users), in der standardmäßig jeder Benutzer Mitglied ist
(sofern es nicht manuell geändert wurde), ist eine eher etwas speziellere Gruppe. Denn weder das member Attribut
im Gruppenobjekt, noch das memberof Attribut im Benutzerobjekt enthüllt die Grupenmitgliedschaft der primären Gruppe.
Bei jedem Domänen-Benutzer ist jedoch standardmäßig die Gruppe Domänen-Benutzer als ihre primäre Gruppe gekennzeichnet.
Überprüfen kann man das in den Eigenschaften der Benutzerkonten, im Reiter Mitglied von.

Damit die Mitglieder der Gruppe Domänen-Benutzer aufgelistet werden, muss das Attribut primaryGroupID mit dem Wert 513 abgefragt werden.
Der Gruppe "Domänen-Benutzer" ist nämlich im Attribut primaryGroupToken der Wert 513 zugewiesen.

Um die Mitglieder der Gruppe "Domänen-Benutzer" mit dsquery aufzulisten, muss der folgende Befehl ausgeführt werden:
Dsquery * -Filter "(&(objectCategory=Person)(primaryGroupID=513))" -Limit 0

Mit einer benutzerdefinierten gespeicherten Abfrage, lassen sich die Mitglieder mit folgendem Filter auflisten:
(&(objectCategory=person)(objectClass=user)(primaryGroupID=513))

Weitere Informationen:
How to use native ADSI components to find the primary group
Setting Primary Group Excludes the User from the Group Membership in Active Directory

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.