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

Bevor der erste Server, der mit einem neueren Serverbetriebssystem installiert ist als die bereits bestehenden Domänencontroller (DCs) einer Gesamtstruktur, als DC zur Gesamtstruktur hinzugefügt werden kann, muss vorher zwingend mit dem Active Directory Preparation Tool (ADPREP) das Active Directory-Schema aktualisiert werden. Erst nachdem ADPREP ausgeführt wurde, kann der neue Server als DC zur Gesamtstruktur hinzugefügt werden. Dabei muss ADPREP stets von der CD/DVD ausgeführt werden, mit dem der neue Server installiert wurde. Möchte man also einen Windows Server 2008 oder Windows Server 2008 R2 in eine Windows 2000 bzw. Windows Server 2003 Gesamtstruktur hinzufügen, so muss das ADPREP von der Windows Server 2008 bzw. Windows Server 2008 R2 DVD ausgeführt werden.

ADPREP muss aber nur dann ausgeführt werden, wenn der Server mit dem neueren Serverbetriebssystem zum DC gestuft werden soll! Wird der neue Server lediglich als Mitgliedsserver zur Domäne hinzugefügt, so muss das ADPREP nicht ausgeführt werden.

Soll der Server, der mit einem neuerem OS (Operating System = Betriebssystem) installiert ist als die existierenden DCs, zu einer bestehenden Domäne als zusätzlicher DC hinzugefügt werden, muss zuerst ADPREP /FORESTPREP auf dem Schemamaster und anschließend ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster in der Domäne ausgeführt werden, zu der der neue Server als DC hinzugefügt werden soll.

Wird jedoch mit dem neuen Server eine neue Subdomäne in einer bestehenden Gesamtstruktur erstellt, muss lediglich das ADPREP /FORESTPREP ausgeführt werden. Das ADPREP /DOMAINPREP /GPPREP muss und kann in diesem Szenario nicht ausgeführt werden, da es keine zu aktualisierende Domäne gibt. Schließlich wird mit dem neuen DC erst eine (weitere) Subdomäne erstellt.

Weitere Details beschreibt der folgende Artikel:

Das Active Directory Preparation Tool - ADPREP

 

Fehler die beim Ausführen von ADPREP auftreten können

• Wenn das Ausführen von ADPREP aus welchen Gründen auch immer fehl schlagen sollte, ist es empfehlenswert als erstes immer ins ADPREP-Protokoll zu schauen. Das ADPREP-Log wird im Verzeichnis %windir%\System32\Debug\Adprep\Logs erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
  
  
  

• Bevor der erste Server mit neuerem OS als die bereits existierenden DCs, als DC zur Gesamtstruktur hinzugefügt werden kann, muss zuerst das ADPREP /FORESTPREP in der Kommandozeile auf dem Schemamaster ausgeführt werden. Das Benutzerkonto mit dem dieser Befehl ausgeführt wird, muss Mitglied in den Gruppen Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet.

  Wenn ADPREP /FORESTPREP auf dem Schemamaster mit den notwendigen Rechten ausgeführt wurde und es trotzdem zu einem Fehler führt, weil ADPREP keinen Kontakt zum Schemamaster herstellen konnte (in seltenen Fällen), sollte der Schemamaster zuerst auf einen anderen DC und erneut zurück verschoben werden. Anschließend ist der Befehl ADPREP /FORESTPREP nochmals auszuführen.
  
  
  

• Befindet sich das Benutzerkonto beim ausführen von ADPREP hingegen nicht in den entsprechenden Gruppen, kommt es zu diesem Fehler:

  Adprep encountered a Win32 error.
  Error code: 0x5 Error message: Access is denied

  Das Benutzerkonto muss zum ausführen von ADPREP /FORESTPREP Mitglied in den folgenden Gruppen sein:

  - Schema-Admins
  - Organisations-Admins
  - Domänen-Admin in der Domäne, in der sich der Schemamaster befindet.

  Zum ausführen von ADPREP /DOMAINPREP /GPPREP muss das Benutzerkonto Mitglied in der Gruppe Domänen-Admins in der Domäne sein, in der dieser Befehl auf dem Infrastrukturmaster ausgeführt wird.
  
  
  

• Kommt es beim ausführen von ADPREP /FORESTPREP zu diesem Fehler:

  Es war Adprep nicht möglich, das Schema zu erweitern.

  [Status/Folgen]

  Der Schemamaster schloss einen Replikationszyklus nach dem letzten Neu-Start nicht ab. Der Schemamaster muss mindestens einen Replikationszyklus, bevor das Schema erweitert werden kann, abschließen.

  [Benutzeraktion]

  Überprüfen Sie, dass der Schemamaster mit dem Netzwerk verbunden ist, und mit anderen Domäne-Controllern kommunizieren kann…

  liegt ein AD-Replikationsproblem vor. Es ist zwingend, dass zuerst das Replikationsproblem behoben wird, bevor das Ausführen von ADPREP erfolgreich durchgeführt werden kann. Einen ersten Ansatz zur Fehlersuche bei der AD-Replikation sollte neben dem Eventlog, auch das Schweizer Messer der AD-Replikation REPADMIN zum Vorschein bringen. Mit ausführen von Repadmin /Showreps bzw. Repadmin /Showrepl auf dem Schemamaster sieht man recht schnell, mit welchen DCs der Schemamaster nicht replizieren kann.

  Wenn die DCs identifiziert wurden mit denen der Schemamaster nicht replizieren kann, sollte man versuchen sich per UNC auf die DCs zu verbinden. Bekommt man auf dem Schemamaster mit \\DC-Computername und \\FQDNdesDCs keine Verbindung zu den betroffenen DCs hin, liegt entweder ein Netzwerkproblem, ein DNS Problem, ein gebrochener sicherer Kanal (secure channel) oder ein Zeitunterschied von mindestens fünf Minuten zwischen den DCs vor. Gerade das DNS ist für eine AD-Umgebung von großer Bedeutung! Ein Ping sowohl auf die IP-Adresse als auch auf den Computernamen sollte von und zu den betroffenen DCs erfolgreich sein. Funktioniert ein Ping auf die IP-Adresse nicht, liegt höchstwahrscheinlich ein Netzwerkproblem vor. Es sollte der Weg vom Schemamaster zum betroffenen DC untersucht werden.

  Funktioniert hingegen ein Ping auf den Computernamen oder FQDN des DCs nicht, liegt höchstwahrscheinlich ein DNS-Problem vor. In den TCP/IP-Einstellungen des DCs sollte ein zentraler DNS-Server als primärer DNS-Server eingetragen werden. Des Weiteren sollte in der Forward Lookup Zone überprüft werden, ob die SRV-Einträge existieren.

  Mit Repadmin /KCC <DC> sollte anschließend die eingehende Replikationstopologie auf den DCs neu berechnet werden.
  
  
  

• Auch durch Schemakonflikte kann ADPREP Fehler verursachen. Wurden benutzerdefinierte Schemaänderungen vorgenommen oder Schemaänderungen durch Drittanbieterlösungen durchgeführt die mit einer Schemaaktualisierung durch ADPREP in Konflikt stehen, kann es ebenfalls zu Fehlern kommen. Die Fehler die angezeigt werden können darauf hindeuten, dass der Object Identifier (OID) nicht geändert wurde und somit keine neuen Klassen dem AD-Schema hinzugefügt werden können. Das Konfliktobjekt wird im ADPREP-Protokoll protokolliert. Wenn das Objekt das den Konflikt verursacht hat durch eine Drittanbieterlösung ins AD-Schema hinzugefügt wurde, sollte man sich für eine Lösung des Problems an den Hersteller wenden. Andernfalls sollte man sich an den (kostenpflichtigen) Microsoft Produkt Support Service (MS PSS) wenden.

  Ein weiterer Schemakonflikt könnte entstehen, wenn eine Verknüpfungskennung (Link Identifier) für ein Attribut durch eine Drittanbieterlösung bereits vergeben ist und ADPREP beim aktualisieren von bestehenden Attributen oder beim hinzufügen von neuen, dieselbe Verknüpfungskennung ebenfalls vergeben möchte. In diesem Fall sollte der MS PSS kontaktiert werden.
  
  
  
• Wenn beim ausführen von ADPREP /FORESTPREP der Fehler Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden erscheint, ist der Schuldige der Virenscanner. Der Echtzeitscanner (On-Access) agiert im Hintergrund als Systemdienst und scannt unsichtbar alle Dateien, Programme und den Arbeitsspeicher. Hat der Echtzeitscanner eine Datei oder ein Verzeichnis im Zugriff worauf ebenfalls beim ausführen von ADPREP /FORESTPREP der Zugriff auf dieselben Dateien oder Verzeichnisse benötigt wird, erscheint diese Fehlermeldung. Wenn dieser Fehler erscheint, muss der Virenscanner deaktiviert und anschließend erneut ADPREP /FORESTPREP ausgeführt werden. Danach kann der Virenscanner aktiviert werden.
  
  
  

• Die Fehlermeldung Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden kann auch erscheinen, wenn ADPREP /DOMAINPREP /GPPREP ausgeführt wurde. Dann muss der Virenscanner zuerst deaktiviert und anschließend ADPREP /DOMAINPREP /GPPREP erneut ausgeführt werden. Oder wenn im ADPREP-Protokoll der Fehler Error 0x80070020 (Error_sharing_Violation) protokolliert wird, liegt das ebenso am Virenscanner. Das Deaktivieren des Virenscanners sollte auch in diesem Fall zum Erfolg führen.

  Führt das deaktivieren des Virenscanners nicht zum Ziel, könnte es noch an den folgenden Ursachen liegen:

  1. Der Registry-Eintrag HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SYSVOL ist nicht vorhanden oder zeigt nicht auf das echte SYSVOL Verzeichnis %windir%\SYSVOL\sysvol. Wenn der Eintrag fehlt, muss ein REG_SZ Eintrag mit dem Pfad zum SYSVOL-Verzeichnis erstellt werden.

  2. Die Default Domain Policy (die GUID ist {31B2F340-016D-11D2-945F-00C04FB984F9} ) und Default Domain Controllers Policy (die GUID ist {6AC1786C-016F-11D2-945F-00C04fB984F9} ) fehlen im SYSVOL Verzeichnis.

  3. Im SYSVOL Verzeichnis fehlt das SCRIPTS Verzeichnis.

  4. Der NTFS-Bereitstellungspunkt und/oder die Bereitstellungspunkte zwischen %windir%\SYSVOL\sysvol\domain und %windir%\SYSVOL existieren nicht (mehr). Sollten die Bereitstellungspunkte fehlen, so können diese mit dem Tool LINKD erneut gesetzt werden.
  
  Die Befehle lauten:
  
  LINKD %windir%\SYSVOL\SYSVOL\<DNS-Domänenname> %windir%\sysvol\domain
  LINKD %windir%\SYSVOL\staging areas\<DNS-Domänenname> %windir%\SYSVOL\staging\domain
  LINKD %windir%\SYSVOL\sysvol\<FQDN>
  
  
  
• Wenn ADPREP /FORESTPREP ausgeführt wurde, müssen die Änderungen zuerst auf den Infrastrukturmaster in der Domäne repliziert werden, in der der neue Server als zusätzlicher DC hinzugefügt werden soll. Erst dann kann mit Domänen-Admin Rechten der Befehl ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster ausgeführt werden. Wurden die Änderungen noch nicht auf den Infrastrukturmaster repliziert oder wenn ADPREP /FORESTPREP nicht ausgeführt wurde, meldet das ADPREP /DOMAINPREP /GPPREP einen Fehler der darauf hinweist, dass die Gesamtstrukturweiten Informationen zuerst aktualisiert werden müssen.
  
  
  
• Der Domänenfunktionsmodus muss sich im einheitlichen Modus (Windows 2000 pur, Windows Server 2003 oder Windows Server 2008) befinden. Ansonsten schlägt das Ausführen von ADPREP /DOMAINPREP /GPPREP fehl!
  
  Domänen- und Gesamtstrukturfunktionsmodus
  
  
  

• Wenn ADPREP /RODCPREP mit Organisations- und Domänen-Admin Rechten auf einem Infrastrukturmaster ausgeführt wird, kann es zu folgendem Fehler kommen:

  Adprep konnte kein Replikat für Partition DC=ForestDnsZones,DC=Root-Domäne erreichen.
  ADPREP hat einen LDAP-Fehler festgestellt.
  Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).

  und

  Adprep konnte kein Replikat für Partition DC=DomainDnsZones,DC=Domäne,DC=de erreichen.
  ADPREP hat einen LDAP-Fehler festgestellt.
  Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).

  Dann muss der Infrastrukturmaster den entsprechenden DNS-Anwendungsverzeichnispartition idealerweise auf den aktuellen Infrastrukturmaster der Domäne verschoben werden. Wie das vonstattengeht, beschreibt der folgende Artikel:
  
  Die Infrastrukturmaster der Anwendungsverzeichnispartitionen

 

Weitere Informationen:
Die FSMO-Rollen verschieben

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

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

Den Security Descriptor (SD - die erweiterten Sicherheitseinstellungen) vom Container Deleted Objects, den es in der Domänen-, Konfigurations- sowie den beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones sowie ForestDNSZones gibt, kann man nicht so ohne weiteres abfragen bzw. auslesen.

Doch ab Windows Vista und Windows Server 2008 können mit LDP, das sich in den Remote Server Administration Tools (kurz RSAT) befindet, die Access Control Entries (ACEs) vom Deleted Objects Container angezeigt werden.

Nach dem man sich in LDP mit einem Domänencontroller verbunden und mit dem AD gebinded hat, trägt man unter Ansicht – Struktur entweder den Distinguished Name (DN) der Verzeichnispartition ein oder gibt direkt den LDAP-Pfad des Deleted Objects Container aus der gewünschten Verzeichnispartition an.

Anschließend ruft man mit einem Rechtsklick den Security Descriptor von Deleted Objects auf. Wie im Screenshot dargestellt muss man dazu auf Schwer – Sicherheitsbeschreibung klicken.

 

Im darauffolgenden Fenster muss bestätigt werden, dass man den SD von Deleted Objects aufrufen möchte.

 

Als Besitzer wird <null> angezeigt, was ein gewünschtes Verhalten ist. Denn bevor man sich die ACEs anzeigen lassen kann, muss man vorher die Besitzrechte von Deleted Objects übernehmen.

 

Gibt man im Feld „Besitzer“ z.B. nicht explizit den „Administrator“ (also den Domänen-Admin) an, wird als Besitzer die Gruppe „Domäne\Domänen-Admins“ für den Deleted Objects Container in der Domänenpartition eingetragen.

 

Nach der Besitzübernahme sieht man die eingetragenen ACEs. Es gibt lediglich zwei ACEs. Die Gruppe Builtin\Administratoren die das Leserecht besitzt und NT-AUTORITÄT\System, das den Vollzugriff besitzt.

 

 

Da in der Builtin\Administratoren Gruppe standardmäßig der Administrator und die beiden Gruppen „Domänen-Admins“ sowie „Organisations-Admins“ Mitglied sind, haben automatisch diese Konten das Leserecht auf den Container Deleted Objects. Selbstverständlich sollten nicht nur die bestehenden ACEs nicht verändert werden, sondern die gesamte Zugriffssteuerungsliste sollte nicht verändert und die Standardeinträge beibehalten werden.

 

Weitere Informationen:
Der Container Deleted Objects
Der Active Directory-Papierkorb im Windows Server 2008 R2

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

 

 

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

Wenn ein Administrator ein Objekt im AD löscht, sollte er das bewusst tun und ein versehentliches löschen sollte nie vorkommen. Jedoch passieren die meisten Missgeschicke gerade im Alltag versehentlich, obwohl die Microsoft Werkzeuge (z.B. die MMCs Active Directory-Benutzer und -Computer sowie Active Directory-Standorte und -Dienste, dsrm, AD-PowerShell etc.) eine Sicherheitsabfrage stellen, ob man das Objekt auch wirklich löschen möchte. Handelt es sich bei dem zu löschenden Objekt um eine OU in dem weitere Objekte enthalten sind (Benutzer, Gruppen, OUs etc.), wird sogar noch eine weitere Sicherheitsabfrage gestellt.

Ein Objekt vor dem versehentlichen Löschen schützen

Damit ein Objekt nicht ausversehen gelöscht werden kann, sollte man ab Windows Server 2008 von der Option Objekt vor zufälligem Löschen schützen (auf Englisch: Protect object from accidental deletion) regen Gebrauch machen. Es ist empfehlenswert diesen Schutz mindestens auf OU-Ebene anzuwenden, sie vererbt sich aber nicht auf die untergeordneten Objekte wie z.B. auf untergeordnete OUs oder auf Benutzer-, Gruppen oder Computerobjekte die sich innerhalb der OU befinden. Einzelne Objekte wie Benutzerobjekte, Sicherheits- sowie Verteilergruppen- und Computerobjekte lassen sich ebenfalls vor dem versehentlichen Löschen schützen. Auch die Objekte in der MMC Active Directory-Standorte und -Dienste (AD-Standorte, Subnetze) lassen sich vor dem versehentlichen Löschen schützen.

Die Option Objekt vor zufälligem Löschen schützen lässt sich in den Eigenschaften eines Objekts im Reiter „Objekt“ aktivieren. Dieser Reiter kommt aber in der MMC „Active Directory-Benutzer und -Computer“ erst dann zum Vorschein, wenn unter „Ansicht“ die Option „Erweiterte Features“ aktiviert wurde.

 

Unter Windows 2000 und Windows Server 2003 existiert zwar die Möglichkeit zum aktivieren der Option „Objekt vor zufälligem Löschen schützen“ nicht, doch man kann natürlich auch unter Windows 2000 und Windows Server 2003 ein Objekt vor dem versehentlichen löschen schützen. Denn das aktivieren der Option „Objekt vor zufälligem Löschen schützen“ bewirkt nichts anderes, als das im Security-Descriptor des Objekts das "Verweigerungsrecht" zum "Löschen" für "Jeder" gesetzt wird. Genau das kann man auch unter Windows 2000 und Windows Server 2003 z.B. auf einer OU oder einem Benutzerobjekt konfigurieren.

Mit DSACLS, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich eine OU folgendermaßen vor dem versehentlichen Löschen schützen:

Dsacls „<DN der OU>“ /D Jeder:SDDT



In der Kommandozeile (CMD) lässt sich mit einer FOR-Schleife und den ds*-Tools die ab Windows Server 2003 "on Bord" sind, eine OU samt den untergeordneten OUs vor dem versehentlichen Löschen wie folgt schützen. Die Objekte wie z.B. Benutzer-, Gruppen- oder Computerobjekte die sich innerhalb dieser OUs befinden, werden dabei aber nicht vor dem versehentlichen Löschen geschützt:

FOR /F "tokens=*" %i in ('Dsquery OU "<DN der OU>" -Limit 0') do Dsacls %i /D "Jeder:SDDCDT"



Alle OUs innerhalb einer Domäne lassen sich in einer CMD mit dieser FOR-Schleife vor dem versehentlichen Löschen schützen:

FOR /F "tokens=*" %i in ('Dsquery OU -Limit 0') do Dsacls %i /D "Jeder:SDDCDT"



Über die AD-Powershell lässt sich diese Option auf einer OU wie folgt aktivieren:

Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentialDeletion 1

bzw.

Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentialDeletion $true



Auf allen bestehenden OUs lässt sich die Option wie folgt aktivieren:

Get-ADOrganizationalUnit -Filter * | Set-ADOrganizationalUnit –ProtectedFromAccidentialDeletion 1

 

Deaktivieren lässt sich die Option „Objekt vor zufälligem Löschen schützen“ in der AD-PowerShell wie folgt:

Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentialDeletion 0

oder

Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentialDeletion $false

 

Wird eine bestehende Domäne auf mindestens „Windows Server 2008“ aktualisiert, wird bei bestehenden Objekten diese Option nicht automatisch aktiviert. Auch nach dem installieren einer neuen Windows Server 2008 Domäne ist auf den bestehenden Objekten die Option „Objekt vor zufälligem Löschen schützen“ nicht aktiv. Der Schutz ist standardmäßig nur beim erstellen von neuen OUs ab Windows Server 2008 aktiviert, nicht jedoch beim erstellen von Benutzer-, Gruppen- oder Computerkonten bzw. AD-Standorten und Subnetzen.

Ist hingegen dieser Schutz auf einer OU aktiviert und man möchte diese OU verschieben, erhält man folgende Fehlermeldung. Denn zum Verschieben einer OU benötigt man das Löschrecht am Quell- und Schreibrecht am Zielort. Das Verschieben der OU ist erst dann möglich, wenn die Option deaktiviert wurde.

 

Das gilt natürlich auch beim löschen einer OU. Erst wenn die Option deaktiviert ist, kann die OU nach bestätigen der Sicherheitsabfrage gelöscht werden. Spätestens mit dieser Option gehört das versehentliche Löschen eines Objekts endlich der Vergangenheit an.

 

Wer hat den Benutzer gelöscht?

Wenn nun doch mal ausversehen z.B. das Benutzerobjekt des GFs gelöscht wurde, möchte man evtl. aufklären wer das Benutzerobjekt auf welchem DC gelöscht hat. Im Sicherheitsprotokoll des DCs auf dem das Objekt gelöscht wurde, wird unter Windows Server 2003 die EventID 630 und unter Windows Server 2008 sowie Windows Server 2008 R2 die EventID 4726 protokolliert. Denn standardmäßig wird unter Windows Server 2003 und Windows Server 2008 R2 beim Löschen eines Benutzerkontos ein Eventlogeintrag generiert, nicht jedoch unter Windows Server 2008.

Unter Windows Server 2008 muss zuerst die Unterkategorie Verzeichnisdienständerungen mit der Option Erfolgreich durch den folgenden Befehl aktiviert werden:

Auditpol /set /subcategory:Verzeichnisdienständerungen /success:enable

Erst danach wird das Löschen eines Objekts auch unter Windows Server 2008 protokolliert.

Active Directory Domain Services (AD DS) - Protokollierung

Achtung: Eine Protokollierung ist vom Betriebsrat bzw. Datenschutzbeauftragten zu genehmigen!

Die Information auf welchem DC das Objekt gelöscht wurde, wird aber nicht zwischen den DCs repliziert. Die Aufgabe besteht also darin, herauszufinden wann das Benutzerkonto auf welchem DC gelöscht wurde, um anschließend den Eventlogeintrag ausfindig zu machen. Sofern der Eventlogeintrag natürlich noch auf dem betroffenen DC existiert und nicht überschrieben wurde.

Auch das Löschen von Gruppen wird standardmäßig mit folgenden EventIDs protokolliert:

Unter Windows Server 2003

- Domänenlokale Sicherheitsgruppe = EventID 638
- Globale Sicherheitsgruppe = EventID 634
- Universelle Sicherheitsgruppe = EventID 662

- Domänenlokale Verteilergruppe = EventID 652
- Globale Verteilergruppe = EventID 657
- Universelle Verteilergruppe = EventID 667

Unter Windows Server 2008 und Windows Server 2008 R2

- Domänenlokale Sicherheitsgruppe = EventID 4734
- Globale Sicherheitsgruppe = EventID 4730
- Universelle Sicherheitsgruppe = EventID 4758

In kleineren AD-Umgebungen lassen sich die Eventlogs auf den DCs vielleicht noch schnell und vor allem manuell durchforsten, doch in großen bzw. weltweiten AD-Umgebungen ist das schier eine unmögliche Aufgabe. Zumindest nicht ohne Zusatzwerkzeuge wie z.B. SCOM, Log Parser oder EventComb.

Doch es gibt auch eine einfache Methode, um den Übeltäter ausfindig zu machen. Mit Hilfe von LDP und REPADMIN kann man in Erfahrung bringen, auf welchem DC das Objekt wann zu welcher Uhrzeit gelöscht wurde. Anschließend öffnet man das Sicherheitsprotokoll des betroffenen DCs und kann anschließend in der Beschreibung des Eventlogeintrags erkennen, wer das Objekt gelöscht hat. Es spielt auch keine Rolle ob unter Windows Server 2008 R2 der AD-Papierkorb aktiviert ist oder nicht.

Dazu sind die folgenden Schritte notwendig.

 

In LDP

Mit LDP gilt es zuerst herauszufinden, wie der Distinguished Name (DN) des gelöschten Objekts im Deleted Objects Container das sich in der Domänenpartition befindet lautet.

• Im ersten Schritt verbindet man sich mit einem DC aus der Domäne, in der das Objekt gelöscht wurde. Unter Windows 2000 und Windows Server 2003 wählt man im Menü „Connection – Connect…“ und unter Windows Server 2008 sowie Windows Sever 2008 R2 „Remotedesktopverbindung – Verbinden…“ und gibt den DC an, mit dem man sich verbinden möchte.
  
  
• Im zweiten Schritt binded man sich mit dem AD. Unter Windows 2000 und Windows Server 2003 wählt man dazu im Menü „Connection – Bind“ und unter Windows Server 2008 und Windows Server 2008 R2 „Remotedesktopverbindung – Gebunden…“.
  
  
• Danach wählt man im Menü unter Windows 2000 und Windows Server 2003 „Options – Controls“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Optionen – Steuerelemente“. Im darauf erscheinenden Fenster „Controls“ bzw. „Steuerelemente” fügt man das LDAP-Control „Return deleted objects“ mit der OID (Object Identifier) 1.2.840.113556.1.4.417 hinzu.
  
  
  
  
  
  

• Als nächstes ruft man unter Windows 2000 und Windows Server 2003 im Menü „Browse - Search“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Durchsuchen - Suchen“ das Suchfenster auf. Dort gibt man als Basis-DN den „Deleted Objects“ Container in der Domänenpartition an. Dieser lautet: CN=Deleted Objects,DC=<Domäne>,DC=<de>
  
  Im Feld Filter gibt man die Kriterien an, nach denen man die Suche im Container “Deleted Objects” durchführen möchte. Ist der Benutzeranmeldename (Prä-Windows 2000), also das Attribut sAMAccountName bekannt, trägt man in dem Feld sAMAccountName=<Benutzeranmeldename> ein. Es kann natürlich auch ein anderes Attribut angegeben werden, dass das gewünschte Benutzerobjekt identifiziert.

  Als Scope/Bereich wählt man OneLevel/Eine Ebene aus. Wählt man als Suchbereich Subtree/Unterstruktur aus, funktioniert das ebenfalls.

  Unter Windows Server 2008 und Windows Server 2008 R2 gibt man im Feld „Attribute“ die Attribute an, die in der rechten Hälfte von LDP, im Suchergebnis zusätzlich zum DN angezeigt werden sollen. Gibt man keine Attribute an, werden alle Attribute des gelöschten Objekts angezeigt.
  
  
  
  
  
  
• Anschließend ruft man mit einem Klick auf Optionen die Suchoptionen auf und konfiguriert die Einstellungen wie folgt. Mit einem Klick auf OK übernimmt man die vorgenommenen Einstellungen.
  
  
  
  
  
  
• Unter Windows 2000 und Windows Server 2003 muss man vorher auf Options klicken, um die gewünschten Attribute und die weiteren Einstellungen vornehmen zu können.
  
  
  
  
  
  

• Führt man die Suche nun mit einem Klick auf Run/Ausführen aus, erscheint in der rechten Hälfte von LDP unter anderem der gesuchte DN des gelöschten Benutzerobjekts. Dieser sieht z.B. so aus:

  Dn: CN=Yusuf Dikmenoglu\0ADEL:3e9e243e-8ba9-473a-a1ee-f1b001337923,CN=Deleted Objects,DC=ad2008R2,DC=dikmenoglu,DC=de

 

In REPADMIN

Da nun bekannt ist wie der DN des gelöschten Benutzerobjekts lautet, gilt es auf einem DC in der Domäne in der das Benutzerobjekt gelöscht wurde, den folgenden REPADMIN-Befehl in der Kommandozeile auszuführen. Die Ausgabe von REPADMIN wird zur besseren Übersicht in eine Textdatei exportiert.

Repadmin /showobjmeta <DC> "CN=Yusuf Dikmenoglu\0ADEL:2ffa7423-7b00-4962-96f6-69d052e08c51,CN=Deleted Objects,DC=ad2008r2,DC=dikmenoglu,DC=de" > C:\Repadmin.txt

Entscheidend in der Ausgabe ist das Attribut isDeleted.

 

 

Daraus kann man erkennen, dass das Benutzerobjekt am 14.11.2009 um 23:05:08 Uhr auf dem DC R2DCON01 gelöscht wurde. Nun kann man hoffen, dass auf dem DC der erwähnte Zeitpunkt im Sicherheitsprotokoll noch nicht überschrieben wurde. Wenn der Eintrag noch existiert, findet man in der Beschreibung des Eventlogeintrags den Übeltäter.

 

Weitere Informationen:
Der Container Deleted Objects
Repadmin /showobjmeta

In einigen Attributen wie z.B. badPasswordTime, Last-Logon, Last-Logon-TimeStamp oder pwdLastSet wird ein Large Integer Wert (im Integer8 Format) gespeichert. Da man mit solch einem Wert herzlich wenig anfangen kann, muss dieser in unser Zeitformat umgerechnet werden. Das geht mit den Windows Support Tools oder mit Bordmitteln wie folgt.

 

LDP

In LDP das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, werden Large Integer Werte bereits in unserem Zeitformat angezeigt, ohne diese umrechnen zu müssen.

 

REPADMIN

Eine weitere Möglichkeit einen Large Integer Wert umzurechnen, ist das Schweizer Messer Werkzeug für die AD-Replikation REPADMIN. Unter Windows 2000 und Windows Server 2003 befindet sich REPADMIN in den Windows Support Tools und ist ab Windows Server 2008 bereits „on Bord“. Bei dem REPADMIN-Befehl müssen jedoch die letzten sieben Zeichen des Integer Wert entfernt werden. Der Befehl lautet wie folgt: REPADMIN /SHOWTIME 12903275725

 

 

 

NLTEST

Auch mit NLTEST, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich ein Large Integer Wert umrechnen. Doch dazu muss zuerst der Large Integer Wert im Taschenrechner von Windows („Start-Programme-Zubehör-Rechner“ oder „Start-Ausführen-CALC“) in einen Hexadezimal Wert umgerechnet werden. Um das zu tun, wechselt man die Ansicht des Taschenrechners unter dem Menüpunkt „Ansicht“ von „Standard“ auf „Wissenschaftlich“. Anschließend fügt man per Copy&Paste den Integer Wert hinzu. Man muss nur darauf achten, dass der Wert als „Dezimal“ (Dez) hinzugefügt wird.

 

Anschließend wandelt man den eingetragenen Wert mit einem Klick auf Hex in einen Hexadezimal Wert um.

 

 

Nun gibt man in einer Kommandozeile den Befehl NLTEST /TIME:<HEX> ein. Bei dem Hexadezimal Wert gilt es zu beachten, mit einem Leerzeichen dazwischen, die rechten acht Zeichen voranzustellen. Der Befehl sieht dann so aus: NLTEST /TIME:EC821F4A 1CA6A9B

 

 

W32tm

In der Kommandozeile (CMD) lässt sich ein Large Integer Wert, ab Windows Server 2003, mit dem Befehl w32tm /ntte <Wert> in ein lesbares Format umrechnen.

 

 

Der Attribut-Editor

Ab Windows Server 2008 und Windows Vista (mit installiertem RSAT) werden die Large Integer Werte im Attribut-Editor, der in den Eigenschaften eines Benutzerobjekts in der MMC Active Directory-Benutzer und -Computer oder in ADSIEdit zu finden ist, in der Übersicht bereits in unserem Zeitformat angezeigt. Der Reiter „Attribut-Editor“ erscheint aber erst dann, wenn unter „Ansicht“ die „erweiterten Features“ aktiviert wurden.

Möchte man Rechte an ein Sicherheitsprinzipal wie z.B. an einen Benutzer oder besser an eine Gruppe im Active Directory (AD) delegieren, kann man das über den Objektdelegierungsassistenten, die Discretionary Access Control List (kurz DACL) oder mit dem Kommandozeilentool DSACLS durchführen.

Objektdelegierungen einrichten

Führt man die Delegierung über die grafische Oberfläche (GUI) mit dem Delegierungsassistenten oder über die DACL durch, ist es durchaus möglich, dass das gewünschte Attribut auf das man die entsprechenden Rechte erteilen möchte in der GUI nicht angezeigt wird. Denn standardmäßig wird nicht jedes Attribut in der GUI angezeigt, um die Liste der angezeigten Attribute übersichtlich zu halten.

Das ist aber auch nicht weiter tragisch, da es ohnehin empfohlen ist die Delegierung mit DSACLS durchzuführen. Denn somit hat man es zum einen mit der Dokumentation einfacher und zum anderen, lassen sich die erteilten Rechte im AD schnell wieder entfernen. Im Gegensatz zur GUI existieren in der Kommandozeile keine Beschränkungen und in Verbindung mit einem Skript, können Delegierungen einfach durchgeführt werden. Bei der Delegierung mit dem Kommandozeilentool muss man natürlich das Attribut kennen, auf das man Rechte erteilen möchte.

Siehe auch:

Die Active Directory-Attribute hinter den Feldnamen

Wer die Delegierung doch lieber über die GUI durchführen möchte, der kann die gefilterten Attribute die standardmäßig nicht angezeigt werden zum Vorschein bringen. Dazu muss die Datei „dssec.dat“ die sich seit Windows 2000 im Verzeichnis „%systemroot%\System32\“ befindet bearbeitet werden.

Möchte man z.B. die Attribute physicalDeliveryOfficeName (das Feld “Büro” in den Eigenschaften eines Benutzerobjekts) oder sn (Nachname eines Benutzers) zum Vorschein bringen, muss in der Datei „dssec.dat“ im Abschnitt [User] hinter den jeweiligen Attributen die Zahl 7 auf 0, 1 oder 2 geändert werden.

Die Zahlen bedeuten:

7 = Das Attribut wird in der GUI nicht angezeigt.
0 = Es werden die Eigenschaften „lesen“ und „schreiben“ für das Attribut angezeigt.
1 = Es wird nur die Schreib-Eigenschaft eines Attributs angezeigt.
2 = Es wird nur die Lese-Eigenschaft eines Attributs angezeigt.

Wurde die Datei dssec.dat bearbeitet, muss anschließend die MMC Active Directory-Benutzer und -Computer neu gestartet werden, damit das gewünschte Attribut angezeigt wird.

Eine andere Variante ist, dass man bei der Objektdelegierung über die GUI beim erstellen eines benutzerdefinierten Tasks nicht beim "Zuweisen der Verwaltung von" die Option "Benutzer"-Objekte auswählt, sondern die Objektklasse "InetOrgPerson"-Objekte. Danach hat man auch Zugriff und die standardmäßig nicht eingeblendeten Attribute und kann diese an die entsprechende Gruppe delegieren.

Mit DSACLS könnte man das Schreibrecht auf das Attribut physicalDeliveryOfficeName (Feldname: Büro) einer Gruppe wie folgt erteilen:

DSACLS "<DN der OU>" /G "<Gruppe>:WP;physicalDeliveryOfficeName;user" /I:S

Das Schreibrecht auf die Nachnamen aller Benutzer die sich in einer OU befinden, lässt sich einer Gruppe folgendermaßen delegieren:

DSACLS "<DN der OU>" /G "<Gruppe>:WP;sn;user" /I:S

 

Weitere Informationen:
Der Objektdelegierungsassistent
Das aktivieren/deaktivieren eines Benutzerkontos delegieren
Delegierte AD-Berechtigungen anzeigen und entfernen
How to modify the filtered properties of an object

Mit dem Kommandozeilentool Whoami das sich unter Windows 2000 im Ressource Kit befindet und ab Windows Server 2003 on Bord ist, lässt sich der komplette Inhalt des Access-Tokens des aktuell angemeldeten Benutzers anzeigen und exportieren. Im Accesss-Token ist die SID des Benutzers, die SIDs der SID-History (ab Windows Server 2003) und die SID's aller Gruppen in denen der angemeldete Benutzer innerhalb der Domäne direkt oder verschachtelt Mitglied ist enthalten. Whoami zeigt auch direkte oder verschachtelte domänenübergreifende universelle Gruppenmitgliedschaften an.

Führt man in einer CMD den Befehl Whoami /all > C:\Temp\Whoami.txt aus, wird solch eine Datei im angegebenen Pfad erstellt:

 

Die Hilfe zu Whoami lässt sich in gewohnter Windows-Manier mit Whoami /? anzeigen.

 

In welcher Situation ist es sinnvoll Whoami auszuführen?

Wenn ein Benutzer zu einer Gruppe hinzugefügt und dieser Gruppe die entsprechenden Rechte auf eine Ressource (Dateien, Drucker etc.) erteilt wurde, der Benutzer aber immer noch keinen Zugriff auf die Ressource hat, sollten zwei Punkte sichergestellt werden:

• Hat sich der Benutzer nach dem hinzufügen zur Gruppen erneut an seinem Client angemeldet? Denn Gruppenmitgliedschaften werden nicht während einer Benutzersitzung ausgewertet, sondern nur bei der Anmeldung.
• Hat sich der Benutzer bereits neu angemeldet, kann mit Whoami /all das Access-Token ausgewertet werden. Damit kann man überprüfen, ob sich der Benutzer auch tatsächlich in der entsprechenden Gruppe befindet.

 

Die Gruppenmitgliedschaften eines Benutzers mit der AD-PowerShell exportieren

Das Pendant zu Whoami stellt mit „Windows Server 2008 R2“ und Windows 7 die „Active Directory-PowerShell“ dar. Wird auf einem „Windows Server 2008 R2“ DC oder auf einem Windows 7 Client mit installiertem RSAT (Remote Server Administration Tools) das Cmdlet Get-ADAccountAuthorizationGroup ausgeführt, werden ebenfalls die direkten und verschachtelten Gruppenmitgliedschaften des angegebenen Benutzerkontos angezeigt. Domänenübergreifende „domänenlokale“ Gruppenmitgliedschaften werden nicht angezeigt, aber domänenübergreifende „universelle“ Gruppenmitgliedschaften schon. Domänenübergreifende globale Gruppen sind aus technischen Gründen ohnehin nicht möglich, da eine globale Gruppe nur Mitglieder aus der eigenen Domäne enthalten kann.

Ein DC kann „domänenlokale“, „globale“ und „universelle“ Gruppenmitgliedschaften eines Benutzers, nur innerhalb seiner Domäne ermitteln. Domänenlokale- und globale Gruppen werden zwar (neben den universellen Gruppen) auch in den globalen Katalog (GC) repliziert, allerdings nicht die Mitglieder dieser Gruppen! Deshalb findet auch bei Gruppenveränderungen in domänenlokalen und globalen Gruppen keine GC-Replikation statt. Da aber ein Benutzer Mitglied einer universellen Gruppe in unterschiedlichen Domänen sein kann, ist für die Abfrage von domänenübergreifenden universellen Gruppenmitgliedschaften ein GC notwendig. Denn nur der GC kennt die domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers, da das member Attribut von universellen Gruppen auf den GC repliziert wird. Wenn sich ein Benutzer in einer Gesamtstruktur mit mehreren Domänen an einer Domäne anmeldet, muss der DC einen GC kontaktieren um die universellen Gruppenmitgliedschaften abzurufen, in denen der Benutzer evtl. in anderen Domänen Mitglied ist. Oder es ist ab Windows Server 2003 das „zwischenspeichern der universellen Gruppenmitgliedschaften“ auf einem AD-Standort aktiviert.

In einer Multidomänen-Gesamtstruktur ist es zwingend erforderlich, dass zum Zeitpunkt der Abfrage mit dem Cmdlet Get-ADAccountAuthorizationGroup ein GC erreichbar ist. Denn schließlich wird für die Auswertung der domänenübergreifenden universellen Gruppenmitgliedschaften ein GC benötigt. Wenn zum Zeitpunkt der Abfrage kein GC erreicht werden kann schlägt die Abfrage fehl. Allerdings schlägt die Abfrage nur dann fehl, wenn es sich um eine Multidomänen-Gesamtstruktur handelt!

Die Option „Das zwischenspeichern von universellen Gruppenmitgliedschaften“ bringt nicht den gewünschten Erfolg. Die Abfrage mit dem Cmdlet in einer Gesamtstruktur mit mehreren Domänen schlägt auch in diesem Fall fehl.

Ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften ist für die Benutzeranmeldung nur in einer Gesamtstruktur mit mehreren Domänen notwendig. Handelt es sich um eine Einzeldomänen-Gesamtstruktur (Single-Domänen Forest), wird weder ein GC, noch das zwischenspeichern von universellen Gruppenmitgliedschaften benötigt. Es existieren ohnehin keine domänenübergreifenden Gruppenmitgliedschaften, wozu ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften notwendig wäre.

In einer Einzeldomänen-Gesamtstruktur benötigt das Cmdlet deshalb auch keinen GC. Schließlich kennt in einer Einzeldomänen-Gesamtstruktur der DC alle Gruppenmitgliedschaften eines Benutzers. Auch der Benutzer kann sich in einer Einzeldomänen-Gesamtstruktur ohne einen GC erfolgreich an der Domäne anmelden.

In einer Windows Server 2003 oder Windows Server 2008 Umgebung lässt sich die AD-PowerShell ebenfalls z.B. von einem Windows 7 Client nutzen. Dazu muss jedoch das „AD MGS“ auf mindestens einem DC installiert werden:

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

Das Cmdlet Get-ADAccountAuthorizationGroup liest das Attribut tokenGroups des angegebenen Sicherheitsprinzipals aus. Dabei kann ein Benutzer oder Computer angegeben werden, aber keine Gruppe! Es werden zum einen alle direkten und verschachtelten Sicherheits-Gruppenmitgliedschaften (domänenlokale, globale und universelle Gruppen) innerhalb der Domäne und zum anderen die direkten und verschachtelten domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers angezeigt. Es werden jedoch keine Verteilergruppen angezeigt!

Das mehrwertige Attribut tokenGroups ist zwar im Schema definiert, es enthält jedoch selbst keinen Wert. Die Attributwerte werden erst im Moment der Abfrage errechnet. Diese Art von Attribut bezeichnet man als Constructed Attribute oder auch Computed Attribute. Da das Attribut tokenGroups "constructed" ist, kann es nicht repliziert werden. Sein Wert wird auch nicht in den GC übertragen.

Siehe auch:
Die konstruierten Attribute abfragen

Die Gruppenmitgliedschaften eines Benutzers werden wie folgt in eine CSV-Datei exportiert:
Get-ADAccountAuthorizationGroup Yusuf | Export-CSV C:\Yusuf.csv -NoTypeInformation

Soll die Ausgabe bis auf wenige Attribute gekürzt werden, lautet der Befehl wie folgt:
Get-ADAccountAuthorizationGroup Yusuf | Select distinguishedName,sAMAccountName,GroupCategory,GroupScope,objectClass | Export-CSV C:\Yusuf.csv -NoTypeInformation

 

Die Ausgabe sieht wie folgt aus:

 

Die Hilfe zu dem Cmdlet lässt sich mit diesem Befehl anzeigen:
Get-Help Get-ADAccountAuthorizationGroup -Full

 

 

Weitere Informationen:
Delegierte Berechtigungen im AD verstehen
Active Directory – Abfrage
AD-PowerShell Befehle
Token-Groups Attribute (Windows)
How to enumerate a user's security group membership using Visual Basic or Visual Basic Script

Im Active Directory-Schema sind verschiedene Arten von Attribute definiert. Die meisten davon sind in der Active Directory-Datenbank (NTDS.dit) gespeichert und können einen festen Wert enthalten.

 

Aber längst nicht alle Attribute für ein Objekt sind in der AD-Datenbank gespeichert. Diese Art von Attribut bezeichnet man als Constructed Attribute, auch bekannt als Computed Attribute.

 

Die Merkmale eines solchen Attributs sind:

• Constructed Attribute, zu Deutsch „konstruierte Attribute“ sind zwar im Schema definiert, sie enthalten jedoch selbst keinen Wert. Die Attributwerte werden erst von einem Domänencontroller im Moment der LDAP-Anfrage gebildet.
  
  
• Da diese Attribute "constructed" sind, können sie auch nicht repliziert werden. Die Werte können auch nicht in den globalen Katalog (GC) übertragen werden.
  
  
• Wird eine Abfrage nach solch einem Attribut durchgeführt, bildet jeder DC eigenständig den Wert.
  
  
• Ein Wert eines konstruierten Attributs kann nicht vergeben bzw. geschrieben werden. Diese Art von Attribut wird lediglich für eine gezielte Abfrage vom DC zusammengesetzt.
  
  
• Konstruierte Attribute können in der Regel nicht für Abfragen verwendet werden (die Ausnahme stellt das Attribut aNR oder memberOf dar).
  
  
• In einigen Fällen muss bei der Abfrage im Parameter -Scope die Option BASE angegeben werden, wie z.B. für das Attribut tokenGroups. Mit dieser Option wird auf ein einziges Objekt zugegriffen.
  
  
• Eine Abfrage nach allen Objekten in einem Container, die ein konstruiertes Attribut der Objekte die sich in dem Container befinden anzeigt, bringt kein Ergebnis.

 

 

Ein konstruiertes Attribut wird durch das dritte Bit im System-Flags Attribut definiert. Verbindet man sich in LDP z.B. mit dem konstruierten Attribut CN=Token-Groups,CN=Schema,CN=Configuration,DC=Root-Domäne lässt sich das System-Flag folgendermaßen kontrollieren:

 

 

 

 

 

 

 

Die konstruierten Attribute einer Gesamtstruktur anzeigen

 

In der AD-Powershell

 

Get-ADObject -LDAPFilter “(&(objectClass=attributeSchema)(systemflags:1.2.840.113556.1.4.803:=4))” -Searchbase “CN=Schema,CN=Configuration,DC=Root-Domäne” | Select Name

 

 

Oder:

 

Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties Systemflags | Where {$_.Systemflags -band 4} | Select Name

 

 

 

 

Mit LDP

•  Nach dem Starten von LDP gilt es zuerst eine Verbindung zu einem DC herzustellen.
  
  
• Im zweiten Schritt muss man sich mit dem AD binden.
  
  
• Anschließend gibt man im Suchfenster (unter Browse/Durchsuchen-Search/Suchen) als Basis-DN CN=Schema,CN=Configuration,DC=Root-Domäne ein und verwendet als Filter (&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4)).
  
  
• Als Scope/Bereich gilt es One Level/Eine Ebene zu wählen.
  
  
• Im Feld Attribute können dann die gewünschten Attribute angegeben werden.
  
  
  

 

 

 

In der Kommandozeile mit Dsquery, ab Windows Server 2003

 

dsquery * “CN=Schema,CN=Configuration,DC=Root-Domäne” -Scope Onelevel -attr Name -Filter "(&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4))"

 

 

 

 

Weitere Informationen:
AD-PowerShell Befehle

Microsoft Windows 2000 Scripting Guide - Operational Attributes

How to query Active Directory by using a bitwise filter

System-Flags Attribute

 

Der RID-Master ist neben der Rolle des PDC-Emulators und Infrastrukturmasters die Rolle, die in jeder Domäne einer Gesamtstruktur existiert. Diese Betriebsmasterrolle weist einen eindeutigen Pool von 500 „relative identifier“ (RIDs) an jeden Domänencontroller innerhalb einer Domäne, für das Erstellen von Objekten zu. Der RID-Master kann keine RIDs domänenübergreifend verteilen. Wozu auch? Denn jede Domäne hat schließlich seinen eigenen RID-Master.

Jeder Domänencontroller (DC) verwendet RIDs um Sicherheitsprinzipale wie z.B. Benutzer-, Gruppen- oder Computerkonten (also SIDs) etc. zu erstellen. Ein „security identifier“ (kurz SID) setzt sich aus der Domänen-SID, diese SID ist für alle Objekte innerhalb einer Domäne identisch und einer eindeutigen „relativen ID“ (kurz RID) zusammen.

 

SIDs müssen in der Domäne (und in der Gesamtstruktur) eindeutig sein, um die Zugriffe auf die Netzwerkressourcen (Dateien, Drucker etc.) klar zu definieren. Da Sicherheitsprinzipale von jedem DC erstellt werden können, stellt der RID-Master sicher, dass ein RID nicht von zwei DCs gleichzeitig ausgestellt werden kann, in dem jeder DC einen eindeutigen RID-Pool erhält.

 

Wann fordert ein DC einen neuen RID-Pool an?

Hat ein DC bis einschließlich „Windows 2000 SP3“ 80% (also 400 RIDs) seines RID-Pools aufgebraucht, fordert der DC vom RID-Master aus seiner Domäne einen neuen Block von 500 RIDs an. Das bedeutet, dass jeder DC stets einen RID-Pool zwischen 100 und 600 RIDs zur Verfügung hat.

Ab „Windows 2000 SP4“ fordern die DCs bereits bei 50% (250 RIDs) verbrauchten RIDs einen neuen RID-Pool an. Das bietet eine bessere Flexibilität, wenn der RID-Master für eine gewisse Zeit offline sein sollte. Daher stehen einem DC ab „Windows 2000 SP4“ stets zwischen 250 und 750 RIDs zur Verfügung.

Ein DC fordert einen neuen RID-Pool an wenn:

• der Schwellenwert von 80% bzw. 50% erreicht wurde.
• der Vorgang des Zuweisen eines neuen RID-Pools manuell durchgeführt wird.
  
  Allocate-Rids Extended Right (Windows)
• der DC von einer Sicherung wiederhergestellt wurde.

 

Wenn ein DC seinen RID-Pool aufgebraucht hat und bzgl. eines etwaigen Problems vom RID-Master keinen neuen RID-Pool erhalten konnte, kann der DC keine Objekte im AD mehr erstellen. Im Verzeichnisdienstprotokoll des DCs werden die EventIDs 16645 sowie 16651 protokolliert die darauf hinweisen, dass der RID-Pool des DCs aufgebraucht ist und kein neuer RID-Pool angefordert werden konnte (z.B. weil der RID-Master offline ist oder Netzwerkprobleme bestehen).

RID Pool Request

 

Wo wird der RID-Master definiert?

Der RID-Master wird im Attribut fSMORoleOwner festgelegt, dass sich in den Eigenschaften des folgenden Objekts befindet:
CN=RID Manager$,CN=System,DC=Domäne,DC=de

Im Attribut fSMORoleOwner wird als Wert der LDAP-Pfad zum „NTDS Settings“ Objekt des RID-Masters gespeichert:
CN=NTDS Settings,CN=MZDCON01,CN=Servers,CN=Mainz,CN=Sites,CN=Configuration,DC=ad2008R2,DC=Dikmenoglu,DC=de

Verbindet man sich nun in LDP, das sich bis einschließlich „Windows Server 2003“ in den Windows Support Tools befindet und ab „Windows Server 2008“ bereits „on Bord“ ist, mit dem Objekt „CN=RID Manager$,CN=System,DC=Domäne,DC=de“ werden einem diese Informationen angezeigt:

 

Das Interessante an diesem Screenshot ist das Attribut rIDAvailablePool. In diesem Attribut ist ein Large Integer Wert mit einem „hohen“ und „niedrigen“ Wert gespeichert. Nur wie lässt sich der Wert 4611686014132422208 umrechnen und somit die beiden Bereiche zum Vorschein bringen? LDP schafft Abhilfe. In LDP hat Redmond ein Tool eingebaut, das einem das Umrechnen abnimmt. Unter Windows 2000 und Windows Server 2003 findet man das Umrechnungstool in LDP unter Utilities – Large Integer Converter. Ab Windows Server 2008 heißt es in LDP Dienstprogramme - Konvertierung großer Ganzzahlen. Wenn man dort den Wert aus dem Attribut rIDAvailablePool eingibt und umrechnen lässt, erhält man solch eine ähnliche Ausgabe:

 

Der „hohe Bereich“ gibt die maximale Anzahl der RIDs und somit der Sicherheitsprinzipale innerhalb einer Domäne an, die erstellt werden können. Es können in einer Domäne also 1 Milliarde Sicherheitsprinzipale erstellt werden. Dieser Wert lässt sich nicht ändern und ist auch einer der maximalen Limits des Active Directory!

Siehe auch:
Die Grenzen des Active Directory

Der niedrige Bereich gibt den Anfang des nächsten RID-Pools an. Der nächste DC der vom RID-Master einen neuen RID-Pool anfordert, erhält einen RID-Pool von 1600 bis 2099. Der erste RID-Pool einer Domäne ist von 1100 bis 1599 (+/- zwei-drei RIDs, abhängig von der Serverversion).

Die noch zur Verfügung stehenden RIDs innerhalb einer Domäne, lassen sich auch in der Kommandozeile mit DCDIAG anzeigen. Der Befehl mit dem man den hohen und niedrigen Bereich anzeigen kann, lautet: DCDIAG /Test:RIDManager /v | Find /i „Available RID“

 

Ein weiterer Befehl mit dem man den bereits umgerechneten Wert aus dem Attribut rIDAvailablePool in der Kommandozeile sich anzeigen lassen kann, ist: DCDIAG /Test:RIDManager /v

 

 

 

Was passiert mit den ungenutzten RIDs?

Das Limit von einer Milliarde Sicherheitsprinzipalen werden die meisten Unternehmen nicht erreichen. Doch man sollte sich folgendem bewusst sein:

• RIDs werden niemals an den RID-Master zurückgegeben. Wird ein Benutzer gelöscht, wird somit auch der SID gelöscht. Wenn z.B. der Benutzer „Yusuf“ gelöscht und ein neuer Benutzer mit dem gleichen Namen erstellt wird, so ist es nicht der identische Benutzer denn das neue Benutzerkonto erhält eine neue SID (und somit auch eine neue RID). Der gelöschte RID wandert nicht in den RID-Pool zurück.
• Wenn ein DC heruntergestuft wird, ist sein RID-Pool egal wie viele RIDs verbraucht wurden, ebenfalls verloren.
• Crasht ein DC, ist der RID-Pool auf dem DC auch dahin.

Neigt sich innerhalb einer Domäne die maximale Anzahl an RIDs dem Ende zu, muss entweder eine zusätzliche Domäne erstellt oder migriert werden!

 

Die RID-Attribute

In den Eigenschaften aller DC-Objekte befindet sich das Attribut rIDSetReferences. Darin ist als Wert der Distinguished Name des Objekts RID Set gespeichert. Jeder DC speichert seine RID-Pool Informationen in diesem Objekt:
CN=RID Set,CN=<DC>,OU=Domain Controllers,DC=Domäne,DC=de

Diese kann man sich mit Bordmitteln in LDP oder ADSIEdit ansehen. Ab Windows Server 2008 kann man auch zuerst in der MMC Active Directory-Benutzer und Computer unter Ansicht die Optionen „Benutzer, Kontakte, Gruppen und Computer als Container“ und die „erweiterten Features“ aktivieren. Anschließend erscheint nach Auswahl des DC-Objekts das Objekt RID Set. Mit einem Doppelklick auf das Objekt kann man sich die RID-Pool Informationen im Reiter Attribut-Editor anzeigen lassen.

In den Eigenschaften des Objekts RID Set findet man die Attribute rIDAllocationPool, rIDNextRID, rIDPreviousAllocationPool und rIDUsedPool.

 

Jeder DC verfügt über zwei RID-Pools. Der RID-Pool den die DCs aktuell zum erstellen von Sicherheitsprinzipalen nutzen ist im Attribut rIDPreviousAllocationPool gespeichert. Im Attribut rIDAllocationPool wird ein neuer RID-Pool gespeichert den ein DC anfordert, wenn der aktuelle Pool den o.g. Schwellenwert erreicht hat. Ist in beiden Attributen der gleiche Wert gespeichert, hat der DC im Attribut rIDPreviousAllocationPool noch nicht den Schwellenwert erreicht. Rechnet man den Integer Wert im Attribut rIDPreviousAllocationPool mit dem Umrechnungstool in LDP um, erhält man den aktuellen RID-Pool der zurzeit genutzt wird:

Im Attribut rIDNextRID wird nicht wie es der Name erwarten lässt, der „nächste“ RID der beim erstellen des nächsten Sicherheitsprinzipals dem neuen Objekt zugewiesen wird gespeichert. Stattdessen ist im Attribut der letzte RID der dem „zuletzt“ erstellten Objekt vergeben wurde gespeichert.

 

Da die RID-Pool Informationen DC-spezifisch sind, werden die Attribute rIDAllocationPool, rIDNextRID und rIDPreviousAllocationPool logischerweise nicht repliziert. Jeder DC hat seine eigenen Werte in den Attributen gespeichert.

Das Attribut rIDUsedPool hingegen wird nicht verwendet.

 

 

Den RID-Pool erhöhen

Der RID-Pool von 500 RIDs, der vom RID-Master an die DCs und an sich selbst verteilt wird kann erhöht werden. Dazu gilt es auf dem RID-Master im folgenden Registry-Schlüssel, der seit Windows 2000 existiert, den entsprechenden Wert einzutragen:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values\RID Block Size

Wurde ein gewünschter Wert (in Dezimal, z.B. 10000) konfiguriert, muss zwingend der RID-Master neu gestartet werden ehe der neue Wert aktiv wird. Das verteilen eines größeren RID-Pools durch den RID-Master ist nur durch diese Registry-Änderung möglich. Trägt man dort einen kleineren Wert als 500 ein, wird der Wert ignoriert und stattdessen der Standardwert von 500 weiter verwendet.

Doch das vergrößern des RID-Pools ist in der Praxis in den allermeisten Fällen nicht notwendig! Wenn der RID-Pool auf einem DC den o.g. Schwellenwert erreicht, wird automatisch vom RID-Master ein neuer Pool angefordert. Ist dies nicht möglich, besteht ein Problem mit dem RID-Master oder es besteht ein Netzwerk bzw. Konnektivitätsproblem. Dies können DNS-, AD-Replikations- oder Netzwerkprobleme sein.

 

Die doppelte Vergabe einer SID

Es gibt Situationen in denen es zur doppelten Vergabe einer SID kommen kann. In Situationen wo der RID-Master „mit Gewalt“ von einem anderen DC übernommen wurde, ein DC von einem Image rückgesichert wurde oder zwei RID-Master in der Domäne existieren, kann es beim erstellen eines Sicherheitsprinzipals zur erneuten Vergabe einer bereits vergebenen RID kommen.

Um die Möglichkeit das zwei RID-Master in der Domäne existieren können zu minimieren, werden folgende Überprüfungen durchgeführt:

• Es findet eine Replikation statt bevor der RID-Master „mit Gewalt“ von einem anderen DC übernommen wird.
• Das Attribut rIDAvailablePool wird über die „dringende Replikation“ (urgent replication) repliziert, um den zukünftigen RID-Master möglichst auf dem aktuellsten Stand zu bringen.
• Wenn der RID-Master einen RID-Pool einem DC zuweist und dieser sich mit einem anderen Pool auf einem anderen DC überschneidet, verwirft der DC den neuen RID-Pool den er erhalten hat und fordert einen neuen Pool an. Das macht der DC erst dann, wenn er die Information der Überschneidung über die AD-Replikation erfahren hat. Diese Vorgehensweise hindert die DCs eine bereits vergebene SID erneut zu vergeben und sorgt dafür, dass die DCs die einen RID-Pool haben der sich mit einem anderen Pool überschneidet, vom RID-Master einen neuen RID-Pool anfordern.

Wenn der Fall doch einmal eintreffen sollte und doppelte SIDs (aus welchen Gründen auch immer) vergeben wurden, kann man diese mit NTDSUTIL aufspüren und entfernen. Die Vorgehensweise ist wie folgt:

• Zuerst gilt es unter Start – Ausführen das NTDSUTIL zu starten.
• Danach muss man sich mit einem DC verbinden. Dazu gibt man den folgenden Befehl ein: connect to server <Computername>
• Mit dem Befehl check duplicate sid wird nach doppelten SIDs in der Domäne gesucht. Ist die Suche beendet, wird die Log-Datei dupsid.log auf der Ebene erstellt, in der auch das NTDSUTIL aufgerufen wurde. In der Log-Datei sind die doppelten SIDs (falls vorhanden) protokolliert.
• Wurden doppelte SIDs gefunden, kann man auf der gleichen NTDSUTIL-Ebene mit dem Befehl cleanup duplicate sid die duplizierten SIDs entfernen.
• Anschließend kann man mit „q“ oder „quit“ (zwei mal) das NTDSUTIL verlassen.

Das erstellen der Log-Datei kann auch mit einem Einzeiler in der CMD erstellt werden. Der Befehl dazu lautet:
C:\Users\Administrator> NTDSUTIL "sec acc man" "co to se DCNAME" "check dup sid" q q

Doppelte SIDs können mit diesem Einzeiler entfernt werden:
C:\Users\Administrator> NTDSUTIL "sec acc man" "co to se DCNAME" "clean dup sid" q q

 

Weitere Informationen:
Die FSMO-Rollen verschieben
Event ID 16650: The account-identifier allocator failed to initialize in Windows 2000 and in Windows Server 2003
Description of RID Attributes in Active Directory
"Domain controller has failed to obtain a new identifier pool" error event in Windows 2000 Server SP3 and earlier
Active Directory attributes that refer to a prefix may not be stored in the local copy of Active Directory on a computer that is running Microsoft Windows Server 2003
FSMOs
HOW TO: Find and Clean Up Duplicate Security Identifiers with Ntdsutil in Windows Server 2003
How To Find and Clean Up Duplicate Security Identifiers with Ntdsutil in Windows 2000

Bisher konnte der Domänen- sowie Gesamtstrukturfunktionsmodus über die grafische Oberfläche, zum einen über die MMC Active Directory-Benutzer und -Computer und zum anderen über die MMC Active Directory-Domänen und -Vertrauensstellung hochgestuft werden. Der Domänenfunktionsmodus lässt sich entweder in der MMC Active Directory-Benutzer und -Computer oder Active Directory-Domänen und -Vertrauensstellung hochstufen. Der Gesamtstrukturfunktionsmodus hingegen lässt sich ausschließlich in der MMC Active Directory-Domänen und -Vertrauensstellung hochstufen.

Beide Funktionsebenen lassen sich (neben LDIFDE und VBSkript) auch mit LDP und ADSIEdit heraufstufen. Dazu muss für den Domänenfunktionsmodus im Attribut msDS-Behavior-Version, das sich in der Domänenpartition in den Eigenschaften des Containers <DC=Domäne,DC=TLD> befindet, der entsprechende Wert eingetragen werden.

Für den Gesamtstrukturfunktionsmodus ist ebenfalls im Attribut msDS-Behavior-Version, das sich in der Konfigurationspartition in den Eigenschaften des Containers <CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=TLD> befindet, der entsprechende Wert einzutragen.

Die MMCs oder die AD-PowerShell machen auch nichts anderes, als den Wert im Attribut msDS-Behavior-Version an entsprechender Stelle zu ändern.

Der Wert im Attribut msDS-Behavior-Version das sich in den Eigenschaften der Domänenpartition befindet, entspricht dem folgenden Domänenfunktionsmodus:

0 = Domänenfunktionsmodus: Windows 2000 gemischt und Windows 2000 pur
1 = Domänenfunktionsmodus: Windows Server 2003 Interim
2 = Domänenfunktionsmodus: Windows Server 2003
3 = Domänenfunktionsmodus: Windows Server 2008
4 = Domänenfunktionsmodus: Windows Server 2008 R2

Der Wert im Attribut msDS-Behavior-Version das sich in der Konfigurationspartition in den Eigenschaften des Objekts CN=Partitions befindet, entspricht dem folgenden Gesamtstrukturfunktionsmodus:

0 = Gesamtstrukturfunktionsmodus: Windows 2000
1 = Gesamtstrukturfunktionsmodus: Windows Server 2003 Interim
2 = Gesamtstrukturfunktionsmodus: Windows Server 2003
3 = Gesamtstrukturfunktionsmodus: Windows Server 2008
4 = Gesamtstrukturfunktionsmodus: Windows Server 2008 R2

 

Weitere Details werden im folgenden Artikel erläutert:

Domänen- und Gesamtstrukturfunktionsmodus

 

Mit der Einführung des Windows Server 2008 R2 und der AD-PowerShell lässt sich der Domänen- und Gesamtstrukturfunktionsmodus nun auch über die AD-PowerShell hochstufen.

 

Den Domänenfunktionsmodus mit der AD-PowerShell heraufstufen

Der Domänenfunktionsmodus lässt sich mit Domänen-Admin Rechten mit diesem Befehl heraufstufen:

Set-ADDomainMode -Identity <Domäne> -DomainMode <Modus>

Der Identity-Parameter gibt die AD-Domäne an, die in den höheren Modus gestuft werden soll. Die Domäne kann dabei durch den:

• definierten Namen (Distinguished Name, kurz DN)
• die objectGUID
• die ObjectSID
• DNS-Domänennamen
• NETBIOS-Domänennamen angegeben werden.

Mit der Angabe des definierten Namen der Domäne sieht der Befehl so aus:
Set-ADDomainMode -Identity „DC=blog,DC=dikmenoglu,DC=de“ -DomainMode <Modus>


Durch die Angabe der ObjectGUID der Domäne sieht der Befehl wie folgt aus:
Set-ADDomainMode -Identity e7057501-108f-4320-9f55-d40a400acbe7 -DomainMode <Modus>


Der Befehl zum Heraufstufen in einen höheren Domänenfunktionsmodus mit der Angabe der Object-SID ist folgender:
Set-ADDomainMode -Identity S-1-5-21-4256209546-3580370902-1950063504 -DomainMode <Modus>

Mit der Angabe des DNS-Domänennamen lautet der Befehl so:
Set-ADDomainMode -Identity „blog.dikmenoglu.de“ -DomainMode <Modus>


Zum Heraufstufen des Domänenfunktionsmodus mit der Angabe des NetBIOS-Domänennamen gilt es diesen Befehl anzugeben:
Set-ADDomainMode -Identity „blog-dikmenoglu“ -DomainMode <Modus>

Da die AD-PowerShell Pipeline-fähig ist, kann ein Domänenobjekt über die Pipeline an den Identity-Parameter übergeben werden. Z. B. kann mit dem Cmdlet Get-ADDomain ein Domänenobjekt abgerufen und dieses anschließend über die Pipeline an das Cmdlet Set-ADDomainMode übergeben werden. Der Befehl würde so aussehen:

Get-ADDomain | Set-ADDomainMode -Identity <Domäne> -DomainMode <Modus>

 

Der Parameter -DomainMode gibt den Domänenfunktionsmodus an, auf den die angegebene Domäne hochgestuft werden soll. Bei der Angabe von <Modus> können folgende Werte angegeben werden:

- Windows2000Domain oder 0
- Windows2003InterimDomain oder 1
- Windows2003Domain oder 2
- Windows2008Domain oder 3
- Windows2008R2Domain oder 4

Die Domäne “blog.dikmenoglu.de” lässt sich wie folgt auf den Domänenfunktionsmodus “Windows Server 2008 R2” heraufstufen:
Set-ADDomainMode -Identity blog.dikmenoglu.de -DomainMode 4

Das Heraufstufen einer Domäne kann auch z.B. von einem Windows 7 Client worauf die RSAT installiert sind erfolgen, das Mitglied einer anderen Domäne ist. Natürlich funktioniert das nur, wenn das Benutzerkonto mit dem das Heraufstufen durchgeführt wird, Domänen-Admin Rechte in der Zieldomäne hat oder dem Benutzer die entsprechenden Rechte delegiert wurden.

 

Den Gesamtstrukturfunktionsmodus mit der AD-PowerShell heraufstufen

Der Gesamtstrukturfunktionsmodus lässt sich mit Organisations-Admin Rechten mit diesem Befehl heraufstufen:

Set-ADForestMode -Identity <Wert> -ForestMode <Modus>

Der -identity Parameter gibt die Root-Domäne der Gesamtstruktur an. Als Wert kann der:

• vollqualifizierte Domänenname
• ObjectGUID
• NetBIOS-Name
• DNS-Hostname (FQDN) angegeben werden.

Verwendet man den vollqualifizierten Domänennamen, sieht der Befehl so aus:
Set-ADForestMode -Identity „Root-Domäne.de“ -ForestMode <Modus>

Die Gesamtstruktur kann durch die Angabe der ObjectGUID der Root-Domäne wie folgt heraufgestuft werden:
Set-ADForestMode -Identity e7057501-108f-4320-9f55-d40a400acbe7 -ForestMode <Modus>

Mit der Angabe des NetBIOS-Namen der Root-Domäne wird die Gesamtstruktur folgendermaßen heraufgestuft:
Set-ADForestMode -Identity „Root-Domäne“ -ForestMode <Modus>

Mit Angabe des DNS-Hostnamen (FQDN) wird die Gesamtstruktur so heraufgestuft:
Set-ADForestMode –Identity “DCON01.Root-Domäne.de” -ForestMode <Modus>

Eine weitere Möglichkeit die Gesamtstruktur in den höheren Modus zu stufen, ist durch die Pipeline-Fähigkeit der AD-PowerShell möglich. Mit dem Cmdlet Get-ADForest können zuerst die Gesamtstrukturinformationen abgerufen und anschließend über die Pipeline an das Cmdlet Set-ADForestMode übergeben werden:

Get-ADForest | Set-ADForestMode -Identity <Wert> -ForestMode <Modus>

Der Parameter -ForestMode gibt den Gesamtstrukturfunktionsmodus an, auf den die angegebene Gesamtstruktur hochgestuft werden soll. Bei der Angabe von <Modus> können folgende Werte angegeben werden:

- Windows2000Forest oder 0
- Windows2003InterimForest oder 1
- Windows2003Forest oder 2
- Windows2008Forest oder 3
- Windows2008R2Forest oder 4

Der Gesamtstrukturfunktionsmodus lässt sich wie folgt auf „Windows Server 2008 R2“ heraufstufen:
Set-ADForestMode -Identity „root.dikmenoglu.de“ -ForestMode Windows2008R2Forest

 

Erstmals kann der Domänen- sowie Gesamtstrukturfunktionsmodus unter gewissen Umständen sogar zurückgestuft werden. Was das genau auf sich hat, wird in diesem Artikel beschrieben:

Den Domänen- und Gesamtstrukturfunktionsmodus zurückstufen

 

Den Domänen- und Gesamtstrukturfunktionsmodus anzeigen

Neben den MMCs Active Directory-Benutzer und -Computer sowie Active Directory-Domänen und -Vertrauensstellung lässt sich der Domänen- und Gesamtstrukturfunktionsmodus unter anderem mit der AD-PowerShell, LDP und Dsquery wie folgt anzeigen.

Die Funktionsebenen in der AD-PowerShell anzeigen

• Den Domänenfunktionsmodus kann man sich mit diesem Befehl anzeigen lassen:
  Get-ADDomain | Select DomainMode | FL
• Der Gesamtstrukturfunktionsmodus lässt sich mit diesem Befehl anzeigen:
  Get-ADForest | Select ForestMode | FL
• Man kann sich aber auch mit dem RootDSE-Objekt verbinden und die Informationen aus den beiden Attributen ForestFunctionality und DomainFunctionality entnehmen. Der Befehl lautet so (alles in einer Zeile):
  [ADSI]"LDAP://RootDSE" | Select ForestFunctionality,DomainFunctionality

 

 

LDP

Startet man das LDP und verbindet sich mit einem DC, werden die Attribute vom RootDSE-Objekt angezeigt. Dort kann man ebenfalls den Domänen- sowie Gesamtstrukturfunktionsmodus entnehmen.

 

 

Dsquery

• Das Attribut msDS-Behavior-Version lässt sich für den Domänenfunktionsmodus wie folgt abfragen:
  dsquery * “DC=Domäne,DC=de” -Scope Base -attr msDS-Behavior-Version
  
  
• Die Abfrage für den Gesamtstrukturfunktionsmodus lautet folgendermaßen:
  dsquery * “CN=Partitions,CN=Configuration,DC=Root-Domäne” -Scope Base -attr msDS-Behavior-Version

 

 

Weitere Informationen:
How to raise domain and forest functional levels in Windows Server 2003
3.1.1.3.2 rootDSE Attributes

Was bis Windows Server 2003 möglich ist, funktioniert ab Windows Server 2008 nicht mehr. Bis Windows Server 2003 ist es möglich einen zusätzlichen Server in einer Subdomäne zum Domänencontroller (DC) zu stufen, ohne das eine Verbindung zwischen der Sub- und Root-Domäne besteht.

Ab Windows Server 2008 ist das nicht mehr möglich. Existiert zum Zeitpunkt des Heraufstufens zwischen der Sub- und Root-Domäne keine (VPN-) Verbindung, kann ein Server nicht als zusätzlicher DC in einer Subdomäne heraufgestuft werden. Dabei spielt es keine Rolle, ob es sich um einen Standalone- oder Mitgliedsserver handelt!

Das Heraufstufen eines zusätzlichen DCs schlägt über die grafische Oberfläche mit dem DCPROMO-Assistenten und in der Kommandozeile (CMD) mit der Unattendedvariante (unbeaufsichtigte DC-Installation) fehl. Es schlägt auch dann fehl, wenn lediglich die DNS- und LDAP-Kommunikation zwischen der Sub- und Root-Domäne gestört ist.

Die irreführende Fehlermeldung über den DCPROMO-Assistenten lautet wie folgt:

 

Auch die Fehlermeldung mit der Unattendedvariante in der Kommandozeile ist nicht Aufschlussreich:

 

Die Ursache für dieses Fehlverhalten ab Windows Server 2008 liegt darin begründet, dass das DCPROMO versucht einen DC aus der Root-Domäne zu erreichen, um Gesamtstrukturinformationen abzurufen. Leider weisen die Fehlermeldungen keineswegs darauf hin. Die Gesamtstrukturinformationen können aber von jedem DC egal aus welcher Domäne geliefert werden.

 

Nun hat Microsoft reagiert und einen Hotfix veröffentlicht. Der Hotfix kann von diesem KB-Artikel aus angefordert werden:

You cannot install Active Directory Domain Services on a member server that is running Windows Server 2008 in a branch office if the DNS and LDAP communication between the branch office and the forest root domain is blocked

Nach der Installation des Hotfixes ist kein Neustart notwendig.
Anschließend ist das Heraufstufen über die grafische Oberfläche und in der CMD möglich, ohne das eine Verbindung zwischen der Sub- und Root-Domäne existiert.

Das Problem besteht leider auch unter Windows Server 2008 R2!
Auch für die „2008 R2“ Version wird Microsoft einen Hotfix veröffentlichen. Sobald dieser verfügbar ist, wird ein entsprechender Hinweis an dieser Stelle erfolgen.

16.10.2009: Leider gibt es zur Zeit mit der x32Bit Version des Hotfixes ein Problem. Microsoft ist bereits informiert und wird es schnellstmöglich beheben. Die x64 Version funktioniert ohne Probleme.

Seit Windows Server 2008 gibt es ein neues Feature, das bei der Domänenanmeldung den Zeitpunkt der letzten interaktiven Anmeldung anzeigt.

Bisher hat man seit der Einführung des Active Directory mit Windows 2000 die Möglichkeit den Zeitpunkt der letzten Domänenanmeldung eines Benutzers, durch das Attribut Last-Logon herauszufinden. Der Nachteil an diesem Attribut ist, dass es nicht zwischen den Domänencontrollern (DCs) repliziert wird. Somit muss man jeden DC in der Domäne einzeln abfragen um das aktuellste Datum zu erhalten. Mit Windows Server 2003 hat Microsoft dann das Attribut Last-Logon-Timestamp eingeführt, das sogar zwischen den DCs repliziert wird. Weitere Einzelheiten werden im folgenden Artikel erläutert:

Die letzte Benutzeranmeldung herausfinden

Für das Anzeigen der „letzten interaktiven Domänenanmeldung“ wurden dem AD-Schema ab Windows Server 2008 vier Attribute hinzugefügt, als die wären:

1. msDS-FailedInteractiveLogonCount: In diesem Attribut wird die Anzahl der fehlgeschlagenen Anmeldeversuche seit der Aktivierung dieser Funktion gespeichert.
   
   
2. msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon: Die Anzahl der fehlgeschlagenen interaktiven Anmeldeversuche bis zur letzten erfolgreichen Anmeldung werden in diesem Attribut gespeichert.
   
   
3. msDS-LastFailedInteractiveLogonTime: Der Zeitpunkt des letzten fehlgeschlagenen Anmeldeversuchs wird in diesem Attribut gespeichert.
   
   
4. msDS-LastSuccessfulInteractiveLogonTime: Wann die letzte erfolgreiche Anmeldung und somit die korrekte Kombination aus Benutzername und Kennwort eingegeben wurde, wird in diesem Attribut gespeichert.

 

Mit dieser neuen Funktion kann der Mitarbeiter einfach erkennen, ob evtl. sein Benutzerkonto kompromittiert wurde oder dieser ein Opfer einer Brute-Force Attacke ist.

Ist diese Funktion aktiviert, kann man die letzte erfolgreiche Benutzeranmeldung neben dem Attribut Last-Logon und Last-Logon-TimeStamp, auch durch das Attribut msDS-LastSuccessfulInteractiveLogonTime herausfinden.

Die letzte erfolgreiche Anmeldung aller Benutzer einer bestimmten OU kann man z.B. mit diesem Befehl abfragen:

dsquery * "OU=<OU>,DC=Domäne,DC=de" -attr name msDS-LastSuccessfulInteractiveLogonTime

Als Ergebnis wird ein 8 Byte bzw. 64 Bit Integer8 Wert geliefert. Diesen kann man dann in der Kommandozeile mit dem folgenden Befehl in ein leserliches Datumsformat konvertieren: w32tm /ntte <Wert>.

Falls die Daten einer bestimmten OU z.B. in Excel weiterverarbeitet werden sollen, könnte mit CSVDE ein Export der Werte mit diesem Befehl durchgeführt werden:

CSVDE -f Benutzer.csv -r "(&(objectClass=user)(objectCategory=person))" –d "OU=<OU>,DC=Domäne,DC=de" –p onelevel -l "name,sAMAccountName,msDS-LastSuccessfulInteractiveLogonTime"

Wo wird dieses Feature aktiviert?

Diese neue Funktion steht in Form einer neuen GPO zur Verfügung:

Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Windows-Anmeldeoptionen\Informationen zu vorherigen Anmeldungen bei der Benutzeranmeldung anzeigen

Sollen die Informationen nur beim anmelden an DCs angezeigt werden, gilt es diese Richtlinie nur auf die DCs zu verlinken (genauer: Auf die OU „Domain Controllers“). Dazu kann man entweder die Default Domain Controllers Richtlinie oder eine neu erstellte GPO verwenden. Ist es hingegen gewünscht die Infos auch auf den Clients z.B. der Finanzbuchabteilung anzuzeigen, gilt es zusätzlich die GPO auf die Clients der Finanzbuchabteilung (auf einer eigenen OU) zu verlinken.

Wie es unschwer zu erkennen ist, handelt es sich dabei um eine Computerrichtlinie die auf Clients, Mitgliedsserver und DCs verlinkt werden muss und nicht auf OUs, in denen sich ausschließlich Benutzer oder Gruppen befinden!

Die Voraussetzungen

1. Der Domänenfunktionsmodus muss sich auf Windows Server 2008 oder höher befinden.
   
   
2. Auf der Client Seite wird diese Funktion erst ab Windows Vista unterstützt. Ältere Betriebssysteme ignorieren diese Funktion.
   
   
3. Möchte man die Infos auf den Clients einer bestimmten OU angezeigt bekommen (z.B. auf den Clients der Finanzbuchabteilung), muss die GPO zwingend auch auf die DCs angewendet werden. Somit bekommt man dann die Infos auch bei der Anmeldung an den DCs angezeigt. Das die Infos nur auf den Clients und nicht noch zusätzlich auf den DCs angezeigt werden, ist leider nicht möglich.

 

 

Die Funktionsweise der „letzten interaktiven Anmeldung“

Ist das Anzeigen der letzten interaktiven Domänenanmeldung aktiviert, erhält der Domänenbenutzer bei seiner ersten Domänenanmeldung nach Aktivierung dieser Funktion zuerst folgende Information angezeigt, ehe er den Desktop zu Gesicht bekommt:

Ab der zweiten Anmeldung werden dem Benutzer dann die folgenden Informationen angezeigt:

1. Den Zeitpunkt der letzten erfolgreichen interaktiven Anmeldung.
2. Den Zeitpunkt des letzten fehlgeschlagenen interaktiven Anmeldeversuchs.
3. Die Anzahl der fehlgeschlagenen Anmeldeversuche seit der letzten erfolgreichen interaktiven Anmeldung.

 

Die o.g. vier Attribute werden zwischen den DCs innerhalb einer Domäne repliziert. Sie werden jedoch nicht in den globalen Katalog repliziert und werden auch nicht indiziert (was sich beides in den jeweiligen Attributen ändern lässt).

Hat sich der Benutzer „einmal“ an einem Computer angemeldet auf dem die GPO angewendet wird, werden die Werte in den o.g. Attributen auch dann aktualisiert, wenn sich der Benutzer an Computern anmeldet auf denen die GPO nicht wirkt. Aber die Informationen über die letzte interaktive Anmeldung und über die letzten Anmeldeversuche werden logischerweise dann nicht angezeigt.

Bei der letzten interaktiven Anmeldung wird auch kein Hinweis angezeigt, von welchem Computer aus der Anmeldeversuch durchgeführt wurde. Schließlich sind die Informationen in den Eigenschaften des Benutzer- und nicht Computerobjekts hinterlegt. Um festzustellen von welchem Computer der Anmeldeversuch durchgeführt wurde, müssen dazu die Sicherheitsprotokolle aller DCs innerhalb der Domäne überprüft werden.

 

 

Die Besonderheiten bei diesem Feature

Wenn die Voraussetzungen für dieses Feature nicht erfüllt sind, erhält man bei der Anmeldung folgende Meldung:

Aufgrund der Sicherheitsrichtlinien auf diesem Computer werden Informationen über die letzte interaktive Anmeldung angezeigt. Die Informationen konnten nicht ermittelt werden. Wenden Sie sich an den Netzwerkadministrator, um weitere Unterstützung zu erhalten.

Anschließend gelangt man erneut zum Anmeldebildschirm. Eine interaktive Anmeldung (STRG+ALT+ENTF) lokal an dem Computer ist nicht möglich!

Das nicht Erfüllen der Voraussetzungen sind:

1. Ist der Domänenfunktionsmodus nicht auf mindestens „Windows Server 2008“ und die GPO wird aktiviert und auf eine OU verlinkt, können sich die Benutzer an den Computern die sich in dieser OU befinden nicht anmelden. Das bedeutet, wenn die GPO z.B. auf die OU „Domain Controllers“ verlinkt wird, kann man sich anschließend nicht mehr interaktiv (STRG+ALT+ENTF) an den DCs anmelden!
   
   
2. Wird die GPO nur auf eine OU verlinkt in der sich Windows Server 2008 Mitgliedsserver, Windows Vista oder Windows 7 Clients befinden und nicht noch zusätzlich auf die OU „Domain Controllers“, so bleibt den Benutzern ebenfalls die Anmeldung an den betroffenen Computern verwehrt.

 

Es sollte unbedingt vor dem Einsatz dieser Funktion ein ausgiebiger Test in einer Testumgebung durchgeführt werden!

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?

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

Die FSMO-Rollen lassen sich ab Windows Server 2008 R2 neben der grafischen Oberfläche (GUI) und neben der Kommandozeile (CMD) mit NTDSUTIL, auch über die AD-Powershell auf einen anderen DC verschieben.

Das Verschieben der FSMO-Rollen mit der AD-Powershell hat folgende Vorteile:

• Es muss nicht wie in der GUI oder in der Kommandozeile mit NTDSUTIL zuerst eine Verbindung zum zukünftigen Rolleninhaber hergestellt werden.
  
  
• Mit dem gleichen AD-Powershell Befehl, lediglich beim „seizen“ (Rolleninhaber ist offline) der FSMO-Rollen wird ein zusätzlicher Parameter benötigt, können die FSMO-Rollen „online“ sowie „offline“ an einen anderen DC übergeben werden.
  
  
• Das verschieben der FSMO-Rollen muss nicht zwingend vom Rolleninhaber oder dem zukünftigen Rolleninhaber durchgeführt werden. Stattdessen kann das Verschieben der Rollen von einem Windows 7 Client oder Windows Server 2008 R2 Mitgliedsserver durchgeführt werden, worauf das RSAT installiert ist.

Die FSMO-Rollen werden mit dem Cmdlet Move-ADDirectoryServerOperationMasterRole auf einen anderen DC verschoben.

Wenn der Rolleninhaber funktionstüchtig und online ist, können die FSMO-Rollen mit dem folgenden AD-Powershell Befehl an den angegebenen DC übertragen werden. Übertragen bedeutet in diesem Zusammenhang, dass der ursprüngliche Rolleninhaber funktionsfähig und online ist.

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator

Bei der Angabe des Ziel-DCs muss ausschließlich der Computername angegeben werden.
Anstatt die Namen der Betriebsmasterrollen einzugeben, können auch Zahlen angegeben werden. Also entweder:

PDCEmulator oder 0
RIDMaster oder 1
InfrastructureMaster oder 2
SchemaMaster oder 3
DomainNamingMaster oder 4

Demnach kann man auch mit diesem Befehl alle FSMO-Rollen auf einen anderen DC übertragen:

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 0,1,2,3,4

Falls jedoch der aktuelle Rolleninhaber ausfällt und das Übertragen der FSMO-Rollen „online“ nicht mehr durchgeführt werden kann, können mit der AD-Powershell die ausgefallenen Betriebsmasterrollen ebenfalls mit dem gleichen Powershell-Befehl, nur zusätzlich mit dem Parameter /Force (sprich „mit Gewalt“) von einem anderen DC übernommen werden. Mit einem der folgenden Befehle werden alle FSMO-Rollen von dem angegebenen DC übernommen:

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator -Force

Bzw.:

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 0,1,2,3,4 -Force

Die beiden Gesamtstrukturmasterrollen „Schemamaster“ sowie „Domänennamenmaster“ können auch auf einen DC einer Subdomäne übertragen oder von einem DC einer Subdomäne übernommen werden. Zum verschieben der FSMO-Rollen muss das Benutzerkonto Mitglied in den folgenden Gruppen sein:

- Schemamasterrolle: Mitglied in der Gruppe „Schema-Admins“
- Domänennamenmaster: Mitglied in der Gruppe „Organisations-Admins“.
- RID-Master: Mitglied in der Gruppe „Domänen-Admins“.
- PDC-Emulator: Mitglied in der Gruppe „Domänen-Admins“.
- Infrastrukturmaster: Mitglied in der Gruppe „Domänen-Admins“.

Den PDC-Emulator über die AD-Powershell verschieben

- Ist der Rolleninhaber online, so kann die Rolle des PDC-Emulators wie folgt verschoben werden:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole PDCEmulator

Oder mit:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 0

- Wenn jedoch der Rolleninhaber nicht mehr zur Verfügung steht (z.B. bei einem DC-Crash), so kann die PDC-Emulatorrolle folgendermaßen von dem angegebenen DC übernommen werden:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole PDCEmulator -Force

Bzw. mit:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 0 -Force

Den RID-Master über die AD-Powershell verschieben

- Die Betriebsmasterrolle „RID-Master“ wird mit einem der folgenden Befehle auf einen anderen DC übertragen, sofern der aktuelle Rolleninhaber online ist:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole RIDMaster

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 1

- Ist dagegen der aktuelle Rolleninhaber offline, so wird die Rolle des RID-Masters mit einem dieser Befehle von einem anderen DC übernommen:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole RIDMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 1 –Force

 

Den Infrastrukturmaster über die AD-Powershell verschieben

- Die Infrastrukturmasterrolle  kann mit einem der folgenden Befehle online auf einen anderen DC übertragen werden:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole InfrastructureMaster

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 2

- Offline kann der Infrastrukturmaster wie folgt von einem anderen DC mit einem dieser Befehle übernommen werden:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole InfrastructureMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 2 -Force

Der Infrastrukturmaster der Anwendungsverzeichnispartitionen muss zusätzlich noch auf einen anderen DC verschoben oder von einem anderen DC übernommen werden.

Die Infrastrukturmaster der Anwendungsverzeichnispartitionen




Den Schemamaster über die AD-Powershell verschieben

- Der Schemamaster wird mit einem dieser Befehle auf einen anderen DC übertragen:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole SchemaMaster

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 3

- Steht der Rolleninhaber nicht mehr zur Verfügung, übernimmt ein anderer DC die Schemamasterrolle mit einem dieser Befehle:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole SchemaMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 3 -Force

 

Den Domänennamenmaster über die AD-Powershell verschieben

Die Rolle „Domänennamenmaster“ wird online mit einem dieser Befehle auf einen anderen DC übertragen:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole DomainNamingMaster

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 4

- Der Domänennamenmaster wird mit einem dieser Befehle von einem anderen DC übernommen, wenn der aktuelle Rollenträger ausgefallen ist:
Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole DomainNamingMaster -Force

Move-ADDirectoryServerOperationMasterRole -Identity <ZielDC> -OperationMasterRole 4 -Force

 

Ist auf einem Windows Server 2003 DC oder Windows Server 2008 DC das AD MGS installiert, können die FSMO-Rollen auch auf diese DCs übertragen bzw. von diesen übernommen werden.

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

 

Die FSMO-Rollenträger in der AD-Powershell lassen sich mit diesen Befehlen anzeigen:

Get-ADForest | select SchemaMaster,DomainNamingMaster

Get-ADDomain | select PDCEmulator,RIDMaster,Infrastructuremaster

 

Weitere Informationen:
Die FSMO-Rollen verschieben
Die FSMO-Rollen mit DCPROMO verschieben
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen
Active Directory Administration with Windows PowerShell

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 Objekte 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>"}

# 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