Active Directory (AD) basierte Gruppenrichtlinienobjekte (auf Englisch: Group Policy Object, kurz GPO) bestehen hauptsächlich aus zwei Komponenten, bestehend aus der logischen und physikalischen Struktur. Der logische Teil einer GPO wird in der AD-Datenbank (NTDS.dit) gespeichert und wird als Gruppenrichtliniencontainer (auf Englisch: Group Policy Container, kurz GPC) bezeichnet. Die physikalische Komponente einer GPO wird im Dateisystem, im replizierten Verzeichnis SYSVOL gespeichert und lautet Gruppenrichtlinienvorlage (auf Englisch: Group Policy Template, kurz GPT).
In den Eigenschaften eines GPC werden alle AD relevanten Konfigurationsdaten einer GPO gespeichert, wie beispielsweise der Pfad zur Gruppenrichtlinienvorlage (das Attribut gPCFileSysPath im entsprechenden GPC, also der Pfad zum GPT), der Status von Gruppenrichtlinienobjekten (das Attribut flags) oder die Zugriffsteuerungsliste (Access Control List, kurz ACL) die bestimmt, welcher Benutzer bzw. Gruppe die Einstellungen eines GPOs verwalten darf. Den GPC selbst findet man in der Domänenpartition im Container CN=Policies,CN=System,DC=<Domäne>. Diesen Container kann man in der MMC Active Directory-Benutzer und –Computer (dsa.msc) zum Vorschein bringen. Dazu muss man jedoch zuerst in der MMC dsa.msc unter Ansicht die „Erweiterte Features“ aktivieren. Die GPC werden im AD-Container Policies mit ihrer {GUID} dargestellt und ist derselbe, wie er auch im GPT angezeigt wird.
Im GPT befinden sich die meisten Einstellungen eines GPOs sowie verschiedene Verzeichnisse und Konfigurationsdateien. Im GPT werden also alle aktuellen GPO-Einstellungen eines GPOs gespeichert. Die GPTs werden im Dateisystem tatsächlich unter %windir%\SYSVOL\domain\Policies, jeweils dargestellt mit ihrer {GUID}, gespeichert. Nicht zu verwechseln mit den Junction Points unter %windir%\SYSVOL\sysvol\<Domäne>\Policies. Tools für die Verwaltung von GPOs (z.B. die GPMC) verwenden die Junction Points und nicht den echten Speicherort der GPTs.
Wichtig für das Troubleshooting ist zu wissen, dass die hauptsächlichen Komponenten einer GPO, nämlich der GPC und das GPT, auf unterschiedliche Weise repliziert werden. Der GPC wird im Rahmen der AD-Replikation repliziert. Das GPT wird je nach Domänenfunktionsmodus entweder vom FRS (File Replication Service) oder vom DFS-R (Distributed File System Replication) repliziert. Liegen die Wurzeln einer Domäne im Domänenfunktionsmodus „Windows Server 2003“ oder niedriger, wird das GPT durch den FRS repliziert. Wurde die Domäne mindestens im Domänenfunktionsmodus „Windows Server 2008“ installiert, kommt DFS-R für die Replikation des GPT und somit des SYSVOLs zum Einsatz.
Die Performance bei der Abarbeitung von GPOs erhöhen
Für die Performance des Clients bei der Abarbeitung von GPOs (die auf ihn wirken) ist es empfehlenswert, den nicht konfigurierten Teil einer GPO stets zu deaktivieren. Das bedeutet, wenn in einer GPO lediglich Einstellungen im Benutzerkonfigurationsteil vorgenommen wurden, sollte der Computerkonfigurationsteil deaktiviert werden und vice versa.
Deaktivieren lässt sich ein Teil oder die gesamte GPO in der GPMC (Group Policy Management Console, zu Deutsch: Gruppenrichtlinienverwaltungskonsole). Mit einem Rechtsklick auf der entsprechenden GPO wählt man die Option Objektstatus aus und kann dann den gewünschten Teil oder die gesamte GPO deaktivieren. Das funktioniert auch wenn man die entsprechende GPO in der GPMC ausgewählt hat und danach zum Reiter Details wechselt.
Den Status der GPOs abfragen
Den Status einer GPO veranschaulicht das Attribut flags, das sich in den Eigenschaften jedes GPCs befindet.
Dabei kann das Attribut flags folgende Werte enthalten:
- Der Wert 0 im Attribut flags bedeutet, das gesamte Gruppenrichtlinienobjekt, also der Benutzerkonfigurations- und Computerkonfigurationsteil ist aktiviert.
- Der Wert 1 bedeutet, der Benutzerkonfigurationsteil einer GPO ist deaktiviert.
- Ist der Wert 2, wurde der Computerkonfigurationsteil einer GPO deaktiviert.
- Beim Wert 3 ist das gesamte GPO deaktiviert.
State of the Art kann man den Status der GPOs in der AD-PowerShell mit folgenden Einzeilern abfragen:
# Alle GPOs mit ihrem Status anzeigen lassen:
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs anzeigen, die beide Teile (Benutzer- und Computerkonfiguration) aktiviert haben:
Get-ADObject -Server <DC> -LDAPFilter "(flags=0)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs die den Teil der Benutzerkonfiguration deaktiviert haben, werden folgendermaßen angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=1)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle GPOs die den Computerkonfigurationsteil deaktiviert haben, werden wie folgt angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=2)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
# Alle komplett deaktivierten GPOs (beide Teile Benutzer- und Computerkonfigurationsteil sind deaktiviert) werden so angezeigt:
Get-ADObject -Server <DC> -LDAPFilter "(flags=3)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | Select displayName,flags | FT -A
Das Attribut flags automatisiert mit einem AD-PowerShellskript abfragen
Man kann die Abfrage auch automatisiert mit folgendem AD-PowerShellskript durchführen.
######################################################
#
# AD-PowerShellskript zur Statusabfrage von GPOs
#
# Von: Yusuf Dikmenoglu 05/2011
#
# http://blog.dikmenoglu.de
#
######################################################
$auswahl = Read-Host "Welcher GPO-Status soll angezeigt werden (0... Alle komplett aktiven GPOs anzeigen 1...Benutzerkonfiguration ist deaktiviert 2...Computerkonfiguration ist deaktiviert 3...GPOs die komplett deaktiviert sind):"
switch ($auswahl){
0 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 0){
write-host "Gesamte GPO aktiviert: " $_.displayName
}
}
}
1 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 1){
write-host "Benutzerkonfiguration des GPO ist deaktiviert: " $_.displayName
}
}
}
2 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 2){
write-host "Computerkonfiguration des GPO ist deaktiviert: " $_.displayName
}
}
}
3 {
Get-ADObject -Server <DC> -LDAPFilter "(flags=*)" -SearchBase "CN=Policies,CN=System,DC=<Domäne>" -SearchScope Subtree -Properties displayName,flags | ForEach-Object {
if ($_.flags -eq 3){
write-host "Gesamte GPO deaktiviert: " $_.displayName
}
}
}
default{
Write-Host "Ungültige Eingabe"
}
}
In Active Directory-Umgebungen mit komplexen Gruppenstrukturen kann es zu Problemen bei der Benutzeranmeldung, genauer mit dem Access Token kommen.
Der KDC (Key Distribution Center) der standardmäßig auf jedem DC läuft, sendet nach der erfolgreichen Benutzerauthentisierung (erfolgreiche Eingabe von Benutzername und Kennwort) ein PAC (Privilege Attribute Certificate) im Ticket Granting Ticket (TGT) mit. Wenn der Client ein TGT erhält, wird das PAC vom Local Security Authority (LSA) Prozess auf dem Client dazu verwendet, um das Access Token zu erstellen. Im Access Token ist die SID des Benutzerobjekts, die SIDs der SIDHistory sowie die direkten und verschachtelten Sicherheits-Gruppenmitgliedschaften des Benutzers enthalten. Im Access Token werden ausschließlich die Mitgliedschaften in Sicherheitsgruppen und nicht in Verteilergruppen berücksichtigt! Das Access Token hat aber ein Limit von maximal 1024 Einträgen und dieser Wert lässt sich nicht verändern!
In bestimmten Szenarien kann die Kerberos-Authentifizierung fehlschlagen, wenn ein Benutzer bereits Mitglied in 70 bzw. 120 Gruppen ist.
Authentication Fails Due to User PAC: Logon and Authentication; Security Services
New resolution for problems with Kerberos authentication when users belong to many groups
Um dem Problem einer fehlgeschlagenen Benutzerauthentisierung auf die Schliche zu kommen, kann man das Kommandozeilenbefehl Whoami mit dem Parameter /all oder das Cmdlet Get-ADAccountAuthorizationGroup in der AD-PowerShell dazu verwenden. Durch beide Varianten wird das Access Token ausgewertet.
Alle Gruppenmitgliedschaften eines Benutzers exportieren
Der Nachteil von Whoami /all ist jedoch, dass man den Inhalt des Access Token nur dann auswerten kann, wenn man als der entsprechende Benutzer schon angemeldet ist. Wenn man sich allerdings erst gar nicht anmelden kann, bringt einem das Whoami /all herzlichst wenig. Die Alternative ist die AD-PowerShell. Denn damit kann man von einem x-beliebigen Rechner die Gruppenmitgliedschaften eines Benutzers auswerten, sofern die AD-PowerShell installiert ist.
Es gibt aber noch eine weitere Alternative, nämlich NTDSUTIL! Auch mit NTDSUTIL ist es so wie mit der AD-PowerShell möglich, die Gruppenmitgliedschaften eines Benutzers auszuwerten.
Unter Windows Server 2003 RTM und Windows Server 2003 SP1 steht die „Evaluierung der Gruppenmitgliedschaften“ in NTDSUTIL erst nach der Installation des Hotfix 906208 zur Verfügung.
When you try to log on to a Windows Server 2003-based domain by using a domain user account, the logon request fails
Erstmalig wurde das Problem in NTDSUTIL unter Windows Server 2003 SP2 behoben!
Die Gruppenmitgliedschaften eines Benutzers lassen sich mit NTDSUTIL wie folgt Anzeigen:
-
Im ersten Schritt gilt es in einer Kommandozeile oder unter „Ausführen“ (Windows-Taste + R) das NTDSUTIL aufzurufen.
-
Danach muss man mit group membership evaluation auf die Ebene Evaluierung der Gruppenmitgliedschaft wechseln.
-
Anschließend wird mit dem Befehl run <Domäne.Tld> <Benutzer> unter Windows Server 2003 im Verzeichnis C:\Dokumente und Einstellungen\<Benutzername> und ab Windows Server 2008 unter C:\Users\<Benutzername> eine Datei Namens <Benutzername>-<Datum/Uhrzeit>.tsv erstellt, in der alle Gruppenmitgliedschaften des angegebenen Benutzers aufgelistet sind. Die Datei lässt sich mit Notepad oder dem Editor öffnen.
-
Die Datei mit den Gruppenmitgliedschaften vom angegebenen Benutzer, sieht wie folgt aus:
Weitere Informationen:
Output is incomplete when you use the Group Membership Evaluation feature of the Ntdsutil.exe tool in Windows Server 2003
Alle Mitglieder einer Gruppe in eine neue Gruppe kopieren
AD-PowerShell Befehle
Gespeicherte Abfragen
Active Directory – Abfrage
Der Distinguished Name (DN) der einzelnen Verzeichnispartitionen die auf einem Domänencontroller (DC) gespeichert sind, werden in den folgenden Attributen gespeichert. Diese Attribute gehören zur nTDSDSA-Objektklasse und befinden sich in den Eigenschaften des „NTDS Settings“ Objekts des jeweiligen DCs. Zu finden ist das Objekt in diesem LDAP-Pfad: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne.
Die im Verlauf dieses Artikels verwendeten Abfragen werden unter anderem über alle AD-Standorte hinweg durchgeführt. Möchte man die Abfrage auf einen bestimmten AD-Standort eingrenzen, so muss im Filter der gewünschte AD-Standort mit angegeben werden. Also anstatt "CN=Sites,CN=Configuration,DC=Root-Domäne" muss es dann so lauten: "CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne".
In welchen Attributen ist die Information gespeichert, welche Verzeichnispartitionen sich auf einem DC befinden?
hasMasterNCs = In diesem mehrwertigen (multivalue) Attribut werden die DNs der beschreibbaren Verzeichnispartitionen die sich auf einem DC befinden gespeichert. Diese sind standardmäßig die Schema-, Konfigurations- und Domänenpartition. In diesem Attribut werden aber keine Anwendungsverzeichnispartitionen gespeichert, wie z.B. die beiden DNS-Partitionen ForestDNSZones sowie DomainDNSZones. Auf RODCs enthält dieses Attribut logischerweise keinen Wert, da auf einem RODC keine beschreibbaren Verzeichnispartitionen gespeichert sind da der RODC auf alle Verzeichnispartitionen lediglich das Leserecht besitzt!
hasPartialReplicaNC = In diesem mehrwertigen Attribut werden die DNs der Domänenpartitionen aus den anderen Domänen innerhalb einer Gesamtstruktur gespeichert, die sich auf einem DC befinden. Das Attribut enthält nur dann einen Wert, wenn zum einen mehr als eine Domäne in der Gesamtstruktur existiert und zum anderen, auf dem DC der globale Katalog (GC) aktiviert wurde! Da ein GC lediglich das Leserecht auf die Domänenpartitionen aus anderen Domänen hat, sind in diesem Attribut die DNs der Domänenpartitionen worauf ausschließlich das Leserecht besteht gespeichert. Da man auf einem RODC auch den GC aktivieren kann, werden bei der Abfrage nach diesem Attribut auch RODCs angezeigt.
msDS-HasDomainNCs = In diesem einwertigen (single-value) Attribut das erst ab Windows Server 2003 existiert, wird der DN der Domänenpartition die sich auf einem DC befindet gespeichert. RODCs verwenden ebenfalls dieses Attribut und werden demzufolge auch bei Abfragen mit angezeigt.
msDS-hasFullReplicaNCs = In diesem mehrwertigen Attribut das nur von einem RODC genutzt wird, sind die DNs der Verzeichnispartitionen: Schemapartition, Konfigurationspartition, Domänenpartition (in der sich der RODC befindet) sowie den beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones gespeichert.
msDS-hasMasterNCs = In diesem mehrwertigen Attribut werden sämtliche DNs der beschreibbaren Verzeichnispartitionen die sich auf einem DC befinden gespeichert. Standardmäßig enthält das Attribut ab Windows Server 2003 die DNs der folgenden Verzeichnispartitionen: Schemapartition, Konfigurationspartition, Domänenpartition sowie die beiden Anwendungsverzeichnispartitionen DomainDNSZones (der eigenen Domäne) und ForestDNSZones. Da ein RODC keine beschreibbaren Verzeichnispartitionen vorhält, erscheinen bei der Abfrage nach diesem Attribut demzufolge auch keine RODCs!
msDS-NC-Replica-Locations = In diesem mehrwertigen Attribut, das sich im Container CN=Partitions,CN=Configuration,DC=Root-Domäne in den Eigenschaften der Cross-Reference (crossRef) Objekte befindet, sind in den crossRef Objekten der Anwendungsverzeichnispartitionen der DN der NTDS Settings-Objekte aller DCs gespeichert, die eine Replik der entsprechenden Anwendungsverzeichnispartition gespeichert haben. Ab Windows Server 2003 sind es mindestens die beiden DNS-Partitionen "DomainDNSZones" und "ForestDNSZones".
Welche beschreibbaren Verzeichnispartitionen sind auf einem DC gespeichert?
Um herauszufinden welche beschreibbaren Verzeichnispartitionen auf einem DC gespeichert sind, sollte eine Abfrage nach dem Attribut msDS-hasMasterNCs erfolgen.
Mit der AD-PowerShell
$ADSI = [ADSI]"LDAP://<DC>:389/CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne"
$ADSI."msDS-hasMasterNCs"
Oder mit diesem AD-PowerShell Befehl:
Get-ADObject -LDAPFilter “(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=*))“ -Searchbase "CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne" -Properties msDS-hasMasterNCs -SearchScope Subtree | Select msDS-hasMasterNCs | % {write $_."msDS-hasMasterNCs"}
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN das „NTDS Settings“ Objekt des entsprechenden DCs in der Konfigurationspartition angeben. Also: CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=*)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute msDS-hasMasterNCs angegeben werden.
Mit Dsquery
dsquery * "CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne" -attr msDS-hasMasterNCs
Alle Verzeichnispartitionen einer Gesamtstruktur anzeigen
Die Verzeichnispartitionen einer Gesamtstruktur sind standardmäßig:
-
die Schemapartition (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).
-
die Konfigurationspartition (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).
-
die jeweilige Domänenpartition (wird auf alle DCs innerhalb der jeweiligen Domäne repliziert). Wenn sich mehrere Domänen in der Gesamtstruktur befinden, werden alle Domänenpartitionen aufgelistet.
-
die Anwendungsverzeichnispartition ForestDNSZones (wird auf alle DCs innerhalb einer Gesamtstruktur repliziert, egal in welcher Domäne sie sich befinden).
-
die Anwendungsverzeichnispartition DomainDNSZones der jeweiligen Domäne (wird auf alle DCs innerhalb der jeweiligen Domäne repliziert). Existieren mehrere Domänen in einer Gesamtstruktur und wurde die Forward Lookup Zone der entsprechenden Domäne in der DomainDNSZones-Partition gespeichert, werden alle DomainDNSZones-Anwendungsverzeichnispartitionen aufgelistet.
Alle Verzeichnispartitionen einer Gesamtstruktur mit der AD-PowerShell abfragen
Get-ADObject -LDAPFilter "(objectCategory=crossRef)" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" | ? {$_.systemFlags -band 5} –SearchScope OneLevel | Select ncName
Oder mit dieser AD-PowerShell Abfrage
Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(systemflags:1.2.840.113556.1.4.804:=5))" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -SearchScope OneLevel | Select ncName
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectCategory=crossRef)(systemFlags:.12.840.113556.1.4.803:=5)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute ncName angegeben werden.
Mit Dsquery
dsquery partition
Oder mit:
dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectCategory=crossRef)(systemFlags:1.2.840.113556.1.4.804:=5))" -Scope OneLevel -attr ncName
Alle beschreibbaren DCs und die Verzeichnispartitionen anzeigen, die jeweils auf den DCs gespeichert sind
Mit der AD-PowerShell
Get-ADObject -LDAPFilter "(objectClass=nTDSDSA)" -Properties msds-hasMasterNCs -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" | Select distinguishedName,msDS-hasMasterNCs | FT –A -Wrap
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (objectClass=nTDSDSA). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName;msDS-hasMasterNCs angegeben werden.
Mit Dsquery
dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(ob jectclass=nTDSDSA)" -attr distinguishedName msds-hasMasterNCs -Limit 0 > C:\Temp\dsquery.txt
Alle Anwendungsverzeichnispartitionen einer Gesamtstruktur anzeigen
Alle Anwendungsverzeichnispartitionen die in einer Gesamtstruktur existieren, standardmäßig sind das ab Windows Server 2003 die beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones, werden mit der folgenden AD-PowerShell Abfrage angezeigt. Existieren mehrere Domänen in der Gesamtstruktur die mindestens unter Windows Server 2003 betrieben werden, wird für jede Domäne die DNS-Anwendungsverzeichnispartition DomainDNSZones angezeigt.
AD-PowerShell
Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(systemflags:1.2.84 0.113556.1.4.803:=5))" -Properties * -Searchbase "CN=Partitions,CN=Configuration ,DC=Root-Domäne" -SearchScope OneLevel | Select dnsRoot | FT
Auch mit diesem AD-PowerShell Befehl lassen sich alle Anwendungsverzeichnispartitionen einer Gesamtstruktur Anzeigen:
Get-ADObject -LDAPFilter "(objectCategory=crossRef)" -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Properties * -SearchScope OneLevel | Where {$_.systemFlags -band 4} | Select dnsRoot
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectCategory=crossRef)(systemFlags:.12.840.113556.1.4.803:=5)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute dnsRoot angegeben werden.
Mit Dsquery
Mit Dsquery werden alle Anwendungsverzeichnispartitionen einer Gesamtstruktur mit dieser Kommandozeilenabfrage angezeigt:
dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectCategory=crossRef)(systemflags:1.2.840.113556.1.4.803:=5))" -Scope OneLevel -attr dnsRoot
Welche Anwendungsverzeichnispartitionen sind auf einem DC gespeichert?
Um sich die Anwendungsverzeichnispartitionen die auf einem bestimmten DC gespeichert sind anzuzeigen, gilt es eines der folgenden Abfragen durchzuführen. Standardmäßig werden ab Windows Server 2003 die beiden DNS-Partitionen ForestDNSZones und DomainDNSZones (der jeweiligen Domänen) angezeigt.
Mit der AD-PowerShell
Get-ADObject -LDAPFilter "(&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msDS-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))" –Properties * -Searchbase "CN=Partitions,CN=Configuration,DC=Root-Domäne" -SearchScope OneLevel | Select dnsRoot
Oder mit diesem AD-PowerShell Befehl:
Get-ADObject -LDAPFilter "(&(objectCategory=crossRef)(msDS-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))" -Properties * -Searchbase "CN=Partitions,CN=Configuration,DC= Root-Domäne" -SearchScope OneLevel | Where {$_.systemFlags -band 5} | Select dnsRoot
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Partitions Container in der Konfigurationspartition angeben. Also: CN=Partitions,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msDS-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne)). Als Suchbereich sollte die Option „Eine Ebene“ ausgewählt und im Feld Attribute dnsRoot angegeben werden.
Mit Dsquery
dsquery * "CN=Partitions,CN=Configuration,DC=Root-Domäne" -Scope OneLevel -attr dnsRoot -Filter "(&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5)(msDS-NC-Replica-Locations=CN=NTDS Settings,CN=<DC>,CN=Servers,CN=<AD-Standort>,CN=Sites,CN=Configuration,DC=Root-Domäne))"
Auf welchen beschreibbaren DCs ist die Anwendungsverzeichnispartition ForestDNSZones gespeichert?
Mit dem folgenden AD-PowerShell Befehl werden alle DCs angezeigt, auf denen die ForestDNSZones-Partition gespeichert ist. Dabei spielt es auch keine Rolle, an welchem AD-Standort sich die DCs befinden.
Get-ADObject -LDAPFilter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne))" -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Select distinguishedName | FT
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName angegeben werden.
Mit Dsquery
dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=ForestDNSZones,DC=Root-Domäne))" -Scope Subtree -attr distinguishedName
Auf welchen beschreibbaren DCs ist die Anwendungsverzeichnispartition DomainDNSZones gespeichert?
Um die DCs abzufragen auf denen die DNS-Partition DomainDNSZones gespeichert ist, gilt es den folgenden AD-PowerShell Befehl auszuführen. Die DomainDNSZones Verzeichnispartition wird jeweils nur innerhalb der Domäne repliziert.
Get-ADObject -LDAPFilter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne))" –Properties * -Searchbase "CN=Sites,CN=Configuration,DC=Root-Domäne" -SearchScope Subtree | Select distinguishedName | FT -A –Wrap
Mit LDP
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN den Sites Container in der Konfigurationspartition angeben. Also: CN=Sites,CN=Configuration,DC=Root-Domäne. Als Filter gilt es diesen zu verwenden: (&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne)). Als Suchbereich sollte die Option „Unterstruktur“ ausgewählt und im Feld Attribute distinguishedName angegeben werden.
Mit Dsquery
dsquery * "CN=Sites,CN=Configuration,DC=Root-Domäne" -Filter "(&(objectClass=nTDSDSA)(msDS-hasMasterNCs=DC=DomainDNSZones,DC=Domäne))" -Scope Subtree -attr distinguishedName
Einfache Abfrage mit DNSCMD
Eine andere einfache Variante um zu überprüfen ob auf einem bestimmten DC die beiden DNS-Anwendungsverzeichnispartitionen gespeichert sind, stellt das DNS-Kommandozeilentool dnscmd dar. Die Abfrage in einer Kommandozeile die auch domänenübergreifend funktioniert lautet so:
Dnscmd <DC> /EnumDirectoryPartitions
Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen
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:
-
-
Zwingende- und Mindestangaben für den Import von Benutzern und Gruppen sind: DN, objectClass und sAMAccountName. Für den Import von Organisationseinheiten (OUs) sind es die beiden Attribute DN und objectClass.
-
Die Reihenfolge in der die Attribute in der ersten Zeile angegeben werden, spielt keine Rolle.
-
Die Reihenfolge der Werte bzw. Feldinhalte ab der zweiten Zeile in der Datendatei, müssen allerdings mit der ersten übereinstimmen.
-
Sollen neben Benutzern auch Gruppen importiert werden, in denen die zu importierenden Benutzer Mitglied sein sollen, so müssen die Benutzereinträge vor den Gruppeneinträgen in der Datendatei enthalten sein. Oder wenn auch die OU importiert werden soll, in der die Benutzer und Gruppen erstellt werden sollen, so muss der Eintrag zum erstellen der OU ebenfalls vor den Benutzer- und Gruppenobjekten zuerst in der Datendatei enthalten sein. Beide Fälle sind in diesem Beispiel aufgeführt.
-
Wird ein Wert für ein angegebenes Attribut nicht eingetragen, muss es dennoch in der Datendatei durch ein Komma angegeben werden.
-
Systemattribute wie z.B. die ObjectSID oder ObjectGUID können nicht importiert werden. Wie es der Name „Systemattribute“ schon verrät, sind das Attribute die vom System vergeben werden.
-
Die Exceldatei könnte z.B. so aussehen:
-
Ist die Exceldatei fertiggestellt, muss diese als CSV-Datei abgespeichert werden. Dazu klickt man in Excel in der Menüleiste auf das Diskettensymbol oder verwendet das Tastaturkürzel „STRG + S“. Das Fenster „Speichern unter“ öffnet sich. Als Dateityp wählt man die Option „CSV (Trennzeichen-getrennt)(*.csv)“ aus und vergibt einen Dateinamen. Mit einem Klick auf Speichern folgt eine Warnung die darauf hinweist, dass der gewählte Dateityp keine Arbeitsmappen mit mehreren Blättern unterstützt und deshalb nur das aktuelle Blatt gespeichert wird. Mit einem Klick auf OK erscheint eine weitere Information die darauf hinweist, dass in der CSV-Datei Merkmale enthalten sein können, die mit „CSV (Trennzeichen-getrennt)“ nicht kompatibel sind. Mit einem Klick auf „Ja“ wird nun endlich die CSV-Datei gespeichert.
-
Nun muss die CSV-Datei mit dem „Editor“ (Notepad) noch bearbeitet werden. Mit einem Rechtsklick auf die CSV-Datei wählt man à Öffnen mit à Editor. Danach öffnet sich die CSV-Datei im Editor.
-
Als Trennzeichen verwendet Excel das Semikolon (;), das durch das Komma (,) ersetzt werden muss. Dies kann man am einfachsten, wenn man im Editor auf Bearbeiten – Ersetzen… klickt. Dort gibt man dann im Feld „Suchen nach“ das Semikolon an und im Feld „Ersetzen durch“ das Komma. Anschließend werden mit einem Klick auf „Alle ersetzen“ die Änderungen durchgeführt.
-
Werte die selbst ein Komma enthalten, müssen in Anführungszeichen (im Volksmund auch als „Gänsefüßchen“ bekannt) gesetzt werden. Das kann man ebenfalls durch die Ersetzen-Funktion im Editor durchführen. In diesem Beispiel müssen die Werte von DN, displayName und Member in Anführungszeichen gesetzt werden.
Vorsicht: Importiert man so wie in diesem Beispiel auch eine Gruppe in der ebenfalls die zu importierenden Benutzer Mitglied sein sollen, müssen die DNs der Benutzer zwingend durch eine Semikolon getrennt werden. Des Weiteren darf das Anführungszeichen nur am Anfang und am Ende der Einträge stehen. Also: „<DN Benutzer1>;<DN Benutzer2>;<DN Benutzer3>“.
-
Die fertige Datendatei sieht dann wie folgt aus:
-
Die gelben Markierungen in dem Beispiel kennzeichnen die Werte die Kommas enthalten und somit in Anführungszeichen gesetzt werden müssen und die roten Markierungen kennzeichnen die nicht enthaltenen Werte, die trotzdem durch ein Komma gesetzt werden müssen.
-
Zur Vollständigkeit, hier der komplette Inhalt der Datendatei:
DN,objectClass,givenname,sn,displayname,description,sAMAccountName,userPrincipalName,Member,groupType,userAccountControl
"OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",organizationalUnit,,,,,,,,,
"CN=Sabine Mueller,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Sabine,Mueller,"Mueller, Sabine",Festangestellte,sabine,sabine@ad2008r2.dikmenoglu.de,,,544
"CN=Klara Tolle,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Klara,Tolle,"Tolle, Klara",,Klara,Klara@ad2008r2.dikmenoglu.de,,,544
"CN=Simone Wagner,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Simone,Wagner,"Wagner, Simone",Aushilfe,Simone,Simone@ad2008r2.dikmenoglu.de,,,544
"CN=Maria Schmitt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Maria,Schmitt,"Schmitt, Maria",,Maria,Maria@ad2008r2.dikmenoglu.de,,,544
"CN=Bettina Bauer,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Bettina,Bauer,"Bauer, Bettina",Befristet,Bettina,Bettina@ad2008r2.dikmenoglu.de,,,544
"CN=Andrea Schmidt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Andrea,Schmitt,"Schmitt, Andrea",,Andrea,Andrea@ad2008r2.dikmenoglu.de,,,544
"CN=Sonja Neu,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Sonja,Neu,"Neu, Sonja",Praktikant,Sonja,Sonja@ad2008r2.dikmenoglu.de,,,544
"CN=Silke Vogt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Silke,Vogt,"Vogt, Silke",Festangestellte,Silke,Silke@ad2008r2.dikmenoglu.de,,,544
"CN=AD-Consultants,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",group,,,,,AD-Consultants,,"CN=Sabine Mueller,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de;CN=Silke Vogt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",-2147483644,
-
Die Datendatei kann dann mit diesem Befehl importiert werden:
Csvde -i -f C:\Datendatei.txt Wenn beim Import ein Fehler auftritt, sollte man den Parameter -j verwenden damit die beiden Protokolldateien erstellt werden, um dann dem Fehler auf die Schliche zu kommen. Der Befehl würde dann so aussehen:
Csvde -i –v -f C:\Datendatei.txt –j C:\
Mit dem Attribut userAccountControl den Kennwortstatus der zu importierenden Benutzer steuern
Gibt man beim Import von Benutzern das Attribut userAccountControl in der Datendatei nicht oder mit dem Wert 514 an, erhält man anschließend deaktivierte Benutzer im AD. Denn wie bereits anfangs in diesem Artikel erwähnt, kann CSVDE keine Kennwörter setzen, was zwingend notwendig ist um hinterher aktive Benutzer zu erhalten. Der Wert 512 im userAccountControl würde zwar aktive Benutzer erstellen, jedoch reicht dass alleine nicht aus, da auch hierbei kein Kennwort vergeben wird. Das Deaktivieren der Kennwortrichtlinie würde zwar den gewünschten Erfolg bringen, nämlich nach dem Import aktivierte Benutzer im AD zu erhalten, jedoch ist das in einer produktiven Umgebung keineswegs empfohlen! Das ist höchstens für eine Testumgebung zulässig!
Aber das Abschalten der Kennwortrichtlinie ist auch nicht notwendig. Bekanntlich besteht das userAccountControl aus einer Bitmaske, bestehend aus mehreren Flags. Kombiniert man zwei davon, erhält man nach dem Import aktivierte Benutzer ohne ein Kennwort vergeben zu haben!
Kombiniert man die beiden Flags:
|
NORMAL_ACCOUNT |
512 |
|
PASSWD_NOTREQD |
32 |
und trägt in der Datendatei als Wert für userAccountControl 544 ein (wie im o.g. Beispiel), erhält man aktive Benutzerkonten im AD!
Die Benutzer melden sich ohne ein Kennwort an und werden direkt aufgefordert ein neues Kennwort zu vergeben. Denn das userAccountControl mit dem Wert 544 in den Benutzerobjekten aktiviert die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“.
How to use the UserAccountControl flags to manipulate user account properties
Gruppen mit CSVDE importieren
Die Werte die in der Datendatei für einen Import von Gruppen zwingend angegeben werden müssen sind: DN,objectClass und sAMAccountName. Somit werden aber lediglich „globale Sicherheitsgruppen“ erstellt. Daher ist es ratsam noch das Attribut groupType anzugeben, um den „Gruppenbereich“ und „Gruppentyp“ zu bestimmen.
Der Import der Datendatei erfolgt mit diesem Befehl:
Csvde -i -f C:\Gruppen.txt
Beispiele einer Datendatei zum Import von Gruppen
# Eine domänenlokale Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=DLSG,OU=<OU>,DC=Domäne,DC=de",group,DLSG,-2147483644
# Eine globale Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName
„CN=GG1,OU=<OU>,DC=Domäne,DC=de“,group,GG1
Oder:
DN,objectClass,sAMAccountName,groupType
„CN=GG1,OU=<OU>,DC=Domäne,DC=de“,group,GG1,-2147483646
# Eine universelle Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=USG,OU=<OU>,DC= Domäne,DC=de ",group,USG,-2147483640
# Eine domänenlokale Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=DLVG,OU=<OU>,DC= Domäne,DC=de ",group,DLVG,4
# Eine globale Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=GVG,OU=<OU>,DC= Domäne,DC=de ",group,GVG,2
# Eine universelle Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=UVG,OU=<OU>,DC= Domäne,DC=de ",group,UVG,8
Einen Export mit CSVDE durchführen
CSVDE wird standardmäßig ohne die Angabe eines Parameters im Export-Modus ausgeführt. Die Kunst beim Export ist es, lediglich die Informationen zu exportieren die von Interesse sind. Daher ist das entscheidende beim Export der Filter, der mit dem Parameter -r eingeleitet wird und die Attribute, die mit dem Parameter –l angegeben werden.
Beispiel Exportbefehle:
# Alle Benutzer mit den Attributen sAMAccountName und name exportieren:
Csvde -m -n -u -f C:\AlleBenutzer.txt -r "(&(objectclass=user)(objectcategory=person))" -l sAMAccountName,name
# Alle Benutzer aus einer OU mit den Attributen sAMAccountName und name exportieren:
Csvde -m -n -u -f C:\ExportBenutzer.txt -s DCON01 -d "OU=<OU>,DC=Domäne,DC=TLD" –p OneLevel –r "(&(objectClass=user)(objectcategory=person))" -l sAMAccountName,name
# Alle Kontakte mit den angegebenen Attributen exportieren:
Csvde -m -n -u -r "(objectClass=Contact)" -d "OU=<OU>,DC=Domäne,DC=de" -l displayname,telephoneNumber,othertelephone,mobile,homePhone,Pager,facsimileTelephoneNumber,ipPhone,otherHomePhone,otherPager,otherMobile,otherFacsimileTelephoneNumber,otherIpPhone -f C:\Kontakte.txt
# Mitglieder einer bestimmten Gruppe exportieren:
Csvde -m -n -u -f C:\Benutzer.txt -r "(&(objectcategory=user)(memberof=CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de))" -l samaccountname,name
# Alle Benutzer anzeigen, die NICHT Mitglied einer bestimmten Gruppe sind:
Csvde –m –n –u –f C:\Benutzer.txt -r „(&(objectCategory=person)(objectClass=user)(!memberof=CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de))“ –l name,sAMAccountName
# Alle Benutzer mit ihrem DN und dem LastLogon exportieren:
Csvde -m -n -u -f C:\Benutzer.txt -r "(&(objectClass=user)(objectCategory=person))" -l DN,LastLogon
Der Wert von LastLogon kann dann folgendermaßen in unsere Zeitangabe umgerechnet werden:
Einen Large Integer Wert umrechnen
# Alle Benutzer mit ihrem Anmeldenamen und dem eingetragenen Anmeldeskript exportieren:
Csvde -f C:\BenutzermitAnmeldeskript.txt -r "(&(objectClass=user)(scriptPath=*))" -l sAMAccountName,scriptPath
# Alle Benutzerobjekte exportieren, die NICHT deaktiviert sind (also aktive Benutzer):
Csvde -m -n -u -f C:\AktiveBenutzer.txt -r "(&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" –l sAMAccountName,name
# Alle Benutzer exportieren und überprüfen, bei wem die Option „Zugriff gestatten“ im Reiter „Einwählen“ aktiviert ist. Steht als Wert TRUE, ist die Option aktiviert:
Csvde -f C:\Ras.txt -u -r "(&(objectClass=user)(objectCategory=person))" -l name,sAMAccountName,msNPAllowDialin
# Alle deaktivierten Computerkonten exportieren:
Csvde –f C:\DeaktiviertePCs.txt –r „(&(objectclass=computer)(userAccountControl:1.2.840.113556.1.4.803:=2))“ –l DN
# Alle Public Folder exportieren:
Csvde -m -n -u -f C:\PublicFolders.txt -r "(objectClass=publicFolder)" -l name
# Alle SMTP-Adressen exportieren:
Csvde -m -n -u -f C:\SMTPList.txt -d "DC=Domäne,DC=de" -L proxyaddresses –r "(proxyaddresses=*smtp:*@*)"
Weitere Filter können aus diesem Artikel entnommen werden:
Gespeicherte Abfragen
Eine Datendatei mit Excel, zum Import mit der AD-PowerShell erstellen
Auch mit der AD-PowerShell können beliebige Objekte, wie beispielsweise Organisationseinheiten (OU), Benutzer-, Gruppen- und Computerkonten ins AD importiert werden. Für den erfolgreichen Import mit der AD-PowerShell wird zum einen eine Datendatei mit den korrekten Angaben benötigt und zum zweiten, der AD-PowerShell Befehl mit dem der Import durchgeführt wird.
Für das Erstellen einer Datendatei um Benutzerobjekte in Verbindung mit der AD-PowerShell zu importieren, gilt es folgendes zu beachten:
-
In der ersten Zeile müssen die Felder stehen, für die man einen Wert eintragen möchte. Möchte man Benutzer importieren, ist es hilfreich sich in der AD-PowerShell mit dem Befehl Get-Help New-ADUser -detailed die Syntax des Cmdlets anzuschauen. Dort werden die genauen Feldbezeichnungen genannt, wie es die AD-PowerShell in der Datendatei gerne hätte. Die Angaben unterscheiden sich teilweise von den unter CSVDE, da die AD-PowerShell nicht den LDAP-Display-Name eines Attributs verwendet (anstatt „sn“ für Nachname möchte die AD-PowerShell die Angabe „surname“)
-
Zwingend notwendige und die Mindestangaben für den Import von Benutzerobjekten sind: Path, Name und sAMAccountName. Für Gruppenobjekte sind es die Werte: Path, GroupScope, Name und sAMAccountName.
-
Im Gegensatz zu CSVDE darf es nicht DN (für Distinguished Name) heißen, sondern muss Path lauten. Dabei darf auch nicht das eigentliche Objekt (sprich der RDN) mit angegeben werden. Des Weiteren ist auch die Angabe von objectClass (oder userAccountControl) nicht notwendig, da durch das Cmdlet New-ADUser die Information bereits mitgegeben wird.
-
In welcher Reihenfolge die Felder in der ersten Zeile angegeben werden, spielt keine Rolle. Die Reihenfolge der Werte bzw. Feldinhalte ab der zweiten Zeile müssen jedoch mit der ersten übereinstimmen.
-
Wird ein Wert für ein angegebenes Feld nicht eingetragen, muss es dennoch in der Datendatei durch ein Komma angegeben werden.
-
Systemattribute wie z.B. die ObjectSID oder ObjectGUID können nicht importiert werden. Wie es der Name „Systemattribute“ schon verrät, sind das Attribute die vom System vergeben werden.
-
Beispielsweise könnte die Excel-Datei wie folgt aussehen:
-
Ist die Exceldatei fertiggestellt, gilt es diese als CSV-Datei abzuspeichern. Dazu klickt man in Excel in der Menüleiste auf das Diskettensymbol oder verwendet das Tastaturkürzel „STRG + S“. Das Fenster „Speichern unter“ öffnet sich. Als Dateityp wählt man die Option „CSV (Trennzeichen-getrennt)(*.csv)“ aus und vergibt einen Dateinamen. Es folgt eine Warnung die darauf hinweist, dass der gewählte Dateityp keine Arbeitsmappen mit mehreren Blättern unterstützt und deshalb nur das aktuelle Blatt gespeichert wird. Mit einem Klick auf OK erscheint eine weitere Information die darauf hinweist, dass in der CSV-Datei Merkmale enthalten sein können, die mit „CSV (Trennzeichen-getrennt)“ nicht kompatibel sind. Mit einem Klick auf „Ja“ wird nun endlich die CSV-Datei gespeichert.
-
Nun muss die CSV-Datei mit dem „Editor“ (Notepad) noch bearbeitet werden. Mit einem Rechtsklick auf die CSV-Datei wählt man à Öffnen mit à Editor. Danach öffnet sich die CSV-Datei im Editor.
-
Excel verwendet nämlich als Trennzeichen das Semikolon (;), das durch das Komma (,) ersetzt werden muss. Dies kann man am einfachsten, wenn man im Editor auf Bearbeiten – Ersetzen… klickt. Dort gibt man dann im Feld „Suchen nach“ das Semikolon an und im Feld „Ersetzen durch“ das Komma. Anschließend werden mit einem Klick auf „Alle ersetzen“ die Änderungen durchgeführt.
-
Werte die selbst ein Komma enthalten, müssen in Anführungszeichen (im Volksmund auch als „Gänsefüßchen“ bekannt) gesetzt werden. Das kann man ebenfalls durch die Ersetzen-Funktion im Editor durchführen. In diesem Beispiel müssen die Werte von „Path“ sowie „Name“ in Anführungszeichen gesetzt werden.
-
Die fertige Datendatei sieht dann wie folgt aus:
-
Die gelben Markierungen in dem Beispiel kennzeichnen die Werte die Kommas enthalten und somit in Anführungszeichen gesetzt werden müssen und die roten Markierungen kennzeichnen die nicht enthaltenen Werte, die trotzdem durch ein Komma gesetzt werden müssen. In diesem Fall sind es die Felder „description“ und „HomePage“.
-
Zur Vollständigkeit, hier der komplette Inhalt der Datendatei:
Path,name,givenname,surname,displayname,description,Office,emailaddress,HomePage,streetAddress,pobox,city,state,postalCode,country,userPrincipalName,sAMAccountName,profilePath,scriptPath,title,department,company
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Mueller, Sabine",Sabine,Mueller,Sabine Mueller,Festangestellte,Buero Mainz,s.mueller@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sab@ad2008r2.dikmenoglu.de,sab,\\Server\Profile\smueller,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Tolle, Klara",Klara,Tolle,Klara Tolle,,Buero Frankfurt,k.tolle@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,kla@ad2008r2.dikmenoglu.de,kla,\\Server\Profile\ktolle,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Wagner, Simone",Simone,Wagner,Simone Wagner,Aushilfe,Buero Istanbul,s.wagner@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sim@ad2008r2.dikmenoglu.de,sim,\\Server\Profile\swagner,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Schmitt, Maria",Maria,Schmitt,Maria Schmitt,,Buero Berlin,m.schmitt@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,mar@ad2008r2.dikmenoglu.de,mar,\\Server\Profile\mschmitt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Bauer, Bettina",Bettina,Bauer,Bettina Bauer,Befristet,Buero Muenchen,b.bauer@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,bet@ad2008r2.dikmenoglu.de,bet,\\Server\Profile\bbauer,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Schmidt, Andrea",Andrea,Schmidt,Andrea Schmidt,,Buero Hamburg,a.schmidt@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,and@ad2008r2.dikmenoglu.de,and,\\Server\Profile\aschmidt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Neu, Sonja",Sonja,Neu,Sonja Neu,Praktikantin,Buero Stuttgart,s.neu@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,son@ad2008r2.dikmenoglu.de,son,\\Server\Profile\sneu,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Vogt, Silke",Silke,Vogt,Silke Vogt,Festangestellte,Buero Dresden,s.vogt@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sil@ad2008r2.dikmenoglu.de,sil,\\Server\Profile\svogt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
Das Importieren der Datendatei mit der AD-PowerShell
Zum importieren von Benutzerobjekten mit der AD-PowerShell hat man folgende Möglichkeiten.
Variante 1
Der AD-PowerShell Befehl mit dem die Datendatei ins AD importiert wird sieht so aus:
Import-CSV C:\Massenimport.csv | New-ADUser -AccountPassword (ConvertTo-SecureString –AsPlainText “Pa$$w0rd!” -Force) -Enabled:$true -ChangePasswordAtLogon:$true
Wie unschwer aus dem Befehl zu erkennen ist, wird mit dem Cmdlet Import-CSV der Inhalt der Datendatei Massenimport.csv durch die Pipeline-Funktion (|) der AD-PowerShell, in das Cmdlet New-ADUser gepiped. Der Vorteil der AD-PowerShell gegenüber CSVDE ist, dass mit CSVDE keine Kennwörter gesetzt werden können, mit der AD-PowerShell aber sehr wohl! Mit diesem AD-PowerShell Befehl erhält jeder Benutzer das Startkennwort Pa$$w0rd!. Durch die Angabe von -Enabled:$true erhält man nach dem Import aktivierte Benutzer (wozu zwingend ein Kennwort vergeben werden muss). Die Angabe von -ChangePasswordAtLogon:$true aktiviert bei allen importierten Benutzern die Kontooption Benutzer muss Kennwort bei der nächsten Anmeldung ändern.
Variante 2
Eine andere Variante zum importieren von Benutzerobjekten mit dem gleichen Ergebnis, ist dieser Befehl:
Import-Csv C:\Massenimport.csv | Foreach { New-ADUser -Path $_.path -Name $_.name -givenname $_.givenname -surname $_.surname -displayname $_.displayname -office $_.office -emailaddress $_.emailaddress -HomePage $_.HomePage -streetaddress $_.streetaddress -pobox $_.pobox -city $_.city -state $_.state -postalCode $_.postalCode -userPrincipalName $_.userPrincipalName -sAMAccountName $_.sAMAccountName -profilePath $_.profilePath -scriptPath $_.scriptPath -title $_.title -department $_.department -company $_.company -PasswordNotRequired:$true -Enabled:$true }
Die Parameter wie z.B. „-Path $_.path“ entsprechen den Angaben aus der ersten Zeile der Datendatei. Dabei spielt die Reihenfolge bei der Angabe der Werte keine Rolle. Z.B. könnte die erste Zeile in der Datendatei so aussehen: sAMAccountName,Path,Name,… und der Befehl wie folgt:
Import-Csv C:\Massenimport.csv | Foreach { New-ADUser -Name $_.name –sAMAccountName $_.sAMAccountName -Path $_.path …
Die Hauptsache ist, es werden alle Felder im Befehl angegeben, die auch in der Datendatei enthalten sind.
Auch mit diesem Befehl erhält man nach dem Import aktivierte Benutzerkonten im AD! Denn der Parameter -PasswordNotRequired:$true bewirkt nichts anderes, als das im Attribut userAccountControl im Benutzerobjekt als Wert 544 eingetragen wird. Das userAccountControl besteht nämlich aus einer Bitmaske, bestehend aus mehreren Flags.
Der Parameter -PasswordNotRequired mit dem Wert $true kombiniert diese beiden Flags:
|
NORMAL_ACCOUNT |
512 |
|
PASSWD_NOTREQD |
32 |
Doch der Eintrag -PasswordNotRequired:$true alleine reicht nicht aus, um aktivierte Benutzerkonten zu erhalten. Es muss zwingend noch der Parameter mit dem Wert -Enabled:$true eingegeben werden. Erst dadurch sind die Benutzerkonten aktiv.
Die Benutzer melden sich dann ohne ein Kennwort an und werden direkt aufgefordert ein neues Kennwort zu vergeben. Denn der Wert 544 im userAccountControl aktiviert bei jedem importierten Benutzerobjekt die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“.
How to use the UserAccountControl flags to manipulate user account properties
Variante 3
Eine weitere Möglichkeit und recht simpel noch dazu, stellt dieser Befehl zum importieren von Benutzerobjekten dar:
Import-Csv -Path C:\Massenimport.txt | New-ADUser -PasswordNotRequired:$true -Enabled:$true
Auch bei diesem Befehl erhält man anschließend aktive Benutzerkonten im AD. Die Benutzer melden sich dann ohne ein Kennwort an der Domäne an und werden direkt aufgefordert
ein neues Kennwort zu vergeben.
Gruppen mit der AD-PowerShell importieren
Die Werte die in der Datendatei für einen Import von Gruppen zwingend angegeben werden müssen sind: Path, GroupScope, Name und sAMAccountName. Somit werden lediglich Sicherheitsgruppen erstellt. Daher ist es ratsam noch GroupCategory anzugeben, um den „Gruppentyp“ zu bestimmen.
Der Import der Datendatei erfolgt mit diesem Befehl:
Import-CSV C:\Gruppen.csv | New-ADGroup
Beispiele einer Datendatei zum Import von Gruppen:
# Eine domänenlokale Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,domainlocal,DLSG1,DLSG1,Vertrieb
# Eine globale Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,global,GSG1,GSG1,Buchhaltung
# Eine universelle Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,universal,USG1,USG1,Einkauf
# Eine domänenlokale Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,domainlocal,DLVG1,DLVG1,Key Account
# Eine globale Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,global,GVG1,GVG1,Techniker
# Eine universelle Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,universal,UVG1,UVG1,Support
Einen Export mit der AD-PowerShell durchführen
Wie mit jedem Werkzeug mit dem man einen Export durchführt, kommt es auch bei der AD-PowerShell auf die gewünschten Informationen und somit auf den Filter an. Wird ein „falscher“ Filter genutzt, bekommt man unter Umständen gar keine Informationen exportiert. Nutzt man hingegen einen „ungenauen“ Filter, erhält man diesmal ggf. zu viele Informationen die es dann mühselig zu durchforsten gilt. Die wichtigste Aufgabe beim Export ist es zu definieren, welche Informationen benötigt werden und dann den Filter (sofern möglich) zu bauen.
Die folgenden Beispiele zeigen jeweils eine LDAP-Abfrage, die dann durch die Pipeline-Funktion der AD-PowerShell an das Cmdlet Export-Csv übergeben und somit die Ausgabe exportiert wird.
Export Beispiele
# Alle Benutzer aus einer OU mit allen Eigenschaften exportieren:
Get-ADUser -Filter * -Searchbase "OU=<OU>,DC=Domäne,DC=de" -Properties * | Export-Csv C:\Export.txt -NoTypeInformation
Hinweis: Nutzt man das Cmdlet Get-ADUser um Benutzerinformationen zu exportieren, werden in jedem Fall diese Attribute ausgegeben: DistinguishedName, Enabled, givenName, Name, ObjectClass, ObjectGUID, SamAccountName, ObjectSID, Surname, userPrincipalName. Gibt man beim Parameter -Properties eigene Attribute an, werden diese zusätzlich zu den bereits genannten Attributen mit ausgegeben.
# Alle Benutzerkonten exportieren, die als Vorgesetzten „Yusuf“ eingetragen haben:
Get-ADUser -Filter { Manager -eq "Yusuf" } | Export-Csv C:\Export.txt -NoTypeInformation
# Alle Organisationseinheiten (OU) der Domäne exportieren:
Get-ADOrganizationalUnit -Filter {Name -Like „*“} | Export-Csv C:\OUs.txt -NoTypeInformation
# Alle Objekte einer OU exportieren:
Get-ADObject -Filter { Name -Like "*" } -Searchbase "OU=<OU>,DC=Domäne,DC=de” | Export-Csv -NoTypeInformation C:\AlleObjekte.txt
# Alle Attribute und Klassen eines Active Directory exportieren:
Get-ADObject -Filter { Name -Like “*” } -SearchBase “CN=Schema,CN=Configuration,DC=Domäne,DC=de” | Export-Csv -NoTypeInformation C:\Schema.txt
AD-PowerShell Befehle
Eine Datendatei in Excel importieren
In Excel lässt sich eine Datendatei wie folgt importieren:
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>“ –ProtectedFromAccidentalDeletion 1
bzw.
Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentalDeletion $true
Auf allen bestehenden OUs lässt sich die Option wie folgt aktivieren:
Get-ADOrganizationalUnit -Filter * | Set-ADOrganizationalUnit –ProtectedFromAccidentalDeletion 1
Deaktivieren lässt sich die Option „Objekt vor zufälligem Löschen schützen“ in der AD-PowerShell wie folgt:
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentalDeletion 0
oder
Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentalDeletion $false
Wird eine bestehende Domäne auf mindestens „Windows Server 2008“ aktualisiert, wird bei bestehenden Objekten diese Option nicht automatisch aktiviert. Auch nach dem installieren einer neuen Windows Server 2008 Domäne ist auf den bestehenden Objekten die Option „Objekt vor zufälligem Löschen schützen“ nicht aktiv. Der Schutz ist standardmäßig nur beim erstellen von neuen OUs ab Windows Server 2008 aktiviert, nicht jedoch beim erstellen von Benutzer-, Gruppen- oder Computerkonten bzw. AD-Standorten und Subnetzen.
Ist hingegen dieser Schutz auf einer OU aktiviert und man möchte diese OU verschieben, erhält man folgende Fehlermeldung. Denn zum Verschieben einer OU benötigt man das Löschrecht am Quell- und Schreibrecht am Zielort. Das Verschieben der OU ist erst dann möglich, wenn die Option deaktiviert wurde.
Das gilt natürlich auch beim löschen einer OU. Erst wenn die Option deaktiviert ist, kann die OU nach bestätigen der Sicherheitsabfrage gelöscht werden. Spätestens mit dieser Option gehört das versehentliche Löschen eines Objekts endlich der Vergangenheit an.
Wer hat den Benutzer gelöscht?
Wenn nun doch mal ausversehen z.B. das Benutzerobjekt des GFs gelöscht wurde, möchte man evtl. aufklären wer das Benutzerobjekt auf welchem DC gelöscht hat. Im Sicherheitsprotokoll des DCs auf dem das Objekt gelöscht wurde, wird unter Windows Server 2003 die EventID 630 und unter Windows Server 2008 sowie Windows Server 2008 R2 die EventID 4726 protokolliert. Denn standardmäßig wird unter Windows Server 2003 und Windows Server 2008 R2 beim Löschen eines Benutzerkontos ein Eventlogeintrag generiert, nicht jedoch unter Windows Server 2008.
Unter Windows Server 2008 muss zuerst die Unterkategorie Verzeichnisdienständerungen mit der Option Erfolgreich durch den folgenden Befehl aktiviert werden:
Auditpol /set /subcategory:Verzeichnisdienständerungen /success:enable
Erst danach wird das Löschen eines Objekts auch unter Windows Server 2008 protokolliert.
Active Directory Domain Services (AD DS) - Protokollierung
Achtung: Eine Protokollierung ist vom Betriebsrat bzw. Datenschutzbeauftragten zu genehmigen!
Die Information auf welchem DC das Objekt gelöscht wurde, wird aber nicht zwischen den DCs repliziert. Die Aufgabe besteht also darin, herauszufinden wann das Benutzerkonto auf welchem DC gelöscht wurde, um anschließend den Eventlogeintrag ausfindig zu machen. Sofern der Eventlogeintrag natürlich noch auf dem betroffenen DC existiert und nicht überschrieben wurde.
Auch das Löschen von Gruppen wird standardmäßig mit folgenden EventIDs protokolliert:
Unter Windows Server 2003
- Domänenlokale Sicherheitsgruppe = EventID 638
- Globale Sicherheitsgruppe = EventID 634
- Universelle Sicherheitsgruppe = EventID 662
- Domänenlokale Verteilergruppe = EventID 652
- Globale Verteilergruppe = EventID 657
- Universelle Verteilergruppe = EventID 667
Unter Windows Server 2008 und Windows Server 2008 R2
- Domänenlokale Sicherheitsgruppe = EventID 4734
- Globale Sicherheitsgruppe = EventID 4730
- Universelle Sicherheitsgruppe = EventID 4758
In kleineren AD-Umgebungen lassen sich die Eventlogs auf den DCs vielleicht noch schnell und vor allem manuell durchforsten, doch in großen bzw. weltweiten AD-Umgebungen ist das schier eine unmögliche Aufgabe. Zumindest nicht ohne Zusatzwerkzeuge wie z.B. SCOM, Log Parser oder EventComb.
Doch es gibt auch eine einfache Methode, um den Übeltäter ausfindig zu machen. Mit Hilfe von LDP und REPADMIN kann man in Erfahrung bringen, auf welchem DC das Objekt wann zu welcher Uhrzeit gelöscht wurde. Anschließend öffnet man das Sicherheitsprotokoll des betroffenen DCs und kann anschließend in der Beschreibung des Eventlogeintrags erkennen, wer das Objekt gelöscht hat. Es spielt auch keine Rolle ob unter Windows Server 2008 R2 der AD-Papierkorb aktiviert ist oder nicht.
Dazu sind die folgenden Schritte notwendig.
In LDP
Mit LDP gilt es zuerst herauszufinden, wie der Distinguished Name (DN) des gelöschten Objekts im Deleted Objects Container das sich in der Domänenpartition befindet lautet.
- Im ersten Schritt verbindet man sich mit einem DC aus der Domäne, in der das Objekt gelöscht wurde. Unter Windows 2000 und Windows Server 2003 wählt man im Menü „Connection – Connect…“ und unter Windows Server 2008 sowie Windows Sever 2008 R2 „Remotedesktopverbindung – Verbinden…“ und gibt den DC an, mit dem man sich verbinden möchte.
- Im zweiten Schritt binded man sich mit dem AD. Unter Windows 2000 und Windows Server 2003 wählt man dazu im Menü „Connection – Bind“ und unter Windows Server 2008 und Windows Server 2008 R2 „Remotedesktopverbindung – Gebunden…“.
- Danach wählt man im Menü unter Windows 2000 und Windows Server 2003 „Options – Controls“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Optionen – Steuerelemente“. Im darauf erscheinenden Fenster „Controls“ bzw. „Steuerelemente” fügt man das LDAP-Control „Return deleted objects“ mit der OID (Object Identifier) 1.2.840.113556.1.4.417 hinzu.
-
Als nächstes ruft man unter Windows 2000 und Windows Server 2003 im Menü „Browse - Search“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Durchsuchen - Suchen“ das Suchfenster auf. Dort gibt man als Basis-DN den „Deleted Objects“ Container in der Domänenpartition an. Dieser lautet: CN=Deleted Objects,DC=<Domäne>,DC=<de>
Im Feld Filter gibt man die Kriterien an, nach denen man die Suche im Container “Deleted Objects” durchführen möchte. Ist der Benutzeranmeldename (Prä-Windows 2000), also das Attribut sAMAccountName bekannt, trägt man in dem Feld sAMAccountName=<Benutzeranmeldename> ein. Es kann natürlich auch ein anderes Attribut angegeben werden, dass das gewünschte Benutzerobjekt identifiziert.
Als Scope/Bereich wählt man OneLevel/Eine Ebene aus. Wählt man als Suchbereich Subtree/Unterstruktur aus, funktioniert das ebenfalls. Unter Windows Server 2008 und Windows Server 2008 R2 gibt man im Feld „Attribute“ die Attribute an, die in der rechten Hälfte von LDP, im Suchergebnis zusätzlich zum DN angezeigt werden sollen. Gibt man keine Attribute an, werden alle Attribute des gelöschten Objekts angezeigt.
- Anschließend ruft man mit einem Klick auf Optionen die Suchoptionen auf und konfiguriert die Einstellungen wie folgt. Mit einem Klick auf OK übernimmt man die vorgenommenen Einstellungen.
- Unter Windows 2000 und Windows Server 2003 muss man vorher auf Options klicken, um die gewünschten Attribute und die weiteren Einstellungen vornehmen zu können.
-
Führt man die Suche nun mit einem Klick auf Run/Ausführen aus, erscheint in der rechten Hälfte von LDP unter anderem der gesuchte DN des gelöschten Benutzerobjekts. Dieser sieht z.B. so aus: Dn: CN=Yusuf Dikmenoglu\0ADEL:3e9e243e-8ba9-473a-a1ee-f1b001337923,CN=Deleted Objects,DC=ad2008R2,DC=dikmenoglu,DC=de
In REPADMIN
Da nun bekannt ist wie der DN des gelöschten Benutzerobjekts lautet, gilt es auf einem DC in der Domäne in der das Benutzerobjekt gelöscht wurde, den folgenden REPADMIN-Befehl in der Kommandozeile auszuführen. Die Ausgabe von REPADMIN wird zur besseren Übersicht in eine Textdatei exportiert.
Repadmin /showobjmeta <DC> "CN=Yusuf Dikmenoglu\0ADEL:2ffa7423-7b00-4962-96f6-69d052e08c51,CN=Deleted Objects,DC=ad2008r2,DC=dikmenoglu,DC=de" > C:\Repadmin.txt
Entscheidend in der Ausgabe ist das Attribut isDeleted.
Daraus kann man erkennen, dass das Benutzerobjekt am 14.11.2009 um 23:05:08 Uhr auf dem DC R2DCON01 gelöscht wurde. Nun kann man hoffen, dass auf dem DC der erwähnte Zeitpunkt im Sicherheitsprotokoll noch nicht überschrieben wurde. Wenn der Eintrag noch existiert, findet man in der Beschreibung des Eventlogeintrags den Übeltäter.
Weitere Informationen:
Der Container Deleted Objects
Repadmin /showobjmeta
In einigen Attributen wie z.B. badPasswordTime, Last-Logon, Last-Logon-TimeStamp oder pwdLastSet wird ein Large Integer Wert (im Integer8 Format) gespeichert. Da man mit solch einem Wert herzlich wenig anfangen kann, muss dieser in unser Zeitformat umgerechnet werden. Das geht mit den Windows Support Tools oder mit Bordmitteln wie folgt.
LDP
In LDP das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, werden Large Integer Werte bereits in unserem Zeitformat angezeigt, ohne diese umrechnen zu müssen.
REPADMIN
Eine weitere Möglichkeit einen Large Integer Wert umzurechnen, ist das Schweizer Messer Werkzeug für die AD-Replikation REPADMIN. Unter Windows 2000 und Windows Server 2003 befindet sich REPADMIN in den Windows Support Tools und ist ab Windows Server 2008 bereits „on Bord“. Bei dem REPADMIN-Befehl müssen jedoch die letzten sieben Zeichen des Integer Wert entfernt werden. Der Befehl lautet wie folgt: REPADMIN /SHOWTIME 12903275725
NLTEST
Auch mit NLTEST, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich ein Large Integer Wert umrechnen. Doch dazu muss zuerst der Large Integer Wert im Taschenrechner von Windows („Start-Programme-Zubehör-Rechner“ oder „Start-Ausführen-CALC“) in einen Hexadezimal Wert umgerechnet werden. Um das zu tun, wechselt man die Ansicht des Taschenrechners unter dem Menüpunkt „Ansicht“ von „Standard“ auf „Wissenschaftlich“. Anschließend fügt man per Copy&Paste den Integer Wert hinzu. Man muss nur darauf achten, dass der Wert als „Dezimal“ (Dez) hinzugefügt wird.
Anschließend wandelt man den eingetragenen Wert mit einem Klick auf Hex in einen Hexadezimal Wert um.
Nun gibt man in einer Kommandozeile den Befehl NLTEST /TIME:<HEX> ein. Bei dem Hexadezimal Wert gilt es zu beachten, mit einem Leerzeichen dazwischen, die rechten acht Zeichen voranzustellen. Der Befehl sieht dann so aus: NLTEST /TIME:EC821F4A 1CA6A9B
W32tm
In der Kommandozeile (CMD) lässt sich ein Large Integer Wert, ab Windows Server 2003, mit dem Befehl w32tm /ntte <Wert> in ein lesbares Format umrechnen.
Der Attribut-Editor
Ab Windows Server 2008 und Windows Vista (mit installiertem RSAT) werden die Large Integer Werte im Attribut-Editor, der in den Eigenschaften eines Benutzerobjekts in der MMC Active Directory-Benutzer und -Computer oder in ADSIEdit zu finden ist, in der Übersicht bereits in unserem Zeitformat angezeigt. Der Reiter „Attribut-Editor“ erscheint aber erst dann, wenn unter „Ansicht“ die „erweiterten Features“ aktiviert wurden.
Mit dem Kommandozeilentool Whoami das sich unter Windows 2000 im Ressource Kit befindet und ab Windows Server 2003 on Bord ist, lässt sich der komplette Inhalt des Access-Tokens des aktuell angemeldeten Benutzers anzeigen und exportieren. Im Accesss-Token ist die SID des Benutzers, die SIDs der SID-History (ab Windows Server 2003) und die SID's aller Gruppen in denen der angemeldete Benutzer innerhalb der Domäne direkt oder verschachtelt Mitglied ist enthalten. Whoami zeigt auch direkte oder verschachtelte domänenübergreifende universelle Gruppenmitgliedschaften an.
Führt man in einer CMD den Befehl Whoami /all > C:\Temp\Whoami.txt aus, wird solch eine Datei im angegebenen Pfad erstellt:
Die Hilfe zu Whoami lässt sich in gewohnter Windows-Manier mit Whoami /? anzeigen.
In welcher Situation ist es sinnvoll Whoami auszuführen?
Wenn ein Benutzer zu einer Gruppe hinzugefügt und dieser Gruppe die entsprechenden Rechte auf eine Ressource (Dateien, Drucker etc.) erteilt wurde, der Benutzer aber immer noch keinen Zugriff auf die Ressource hat, sollten zwei Punkte sichergestellt werden:
-
Hat sich der Benutzer nach dem hinzufügen zur Gruppen erneut an seinem Client angemeldet? Denn Gruppenmitgliedschaften werden nicht während einer Benutzersitzung ausgewertet, sondern nur bei der Anmeldung.
-
Hat sich der Benutzer bereits neu angemeldet, kann mit Whoami /all das Access-Token ausgewertet werden. Damit kann man überprüfen, ob sich der Benutzer auch tatsächlich in der entsprechenden Gruppe befindet.
Die Gruppenmitgliedschaften eines Benutzers mit der AD-PowerShell exportieren
Das Pendant zu Whoami stellt mit „Windows Server 2008 R2“ und Windows 7 die „Active Directory-PowerShell“ dar. Wird auf einem „Windows Server 2008 R2“ DC oder auf einem Windows 7 Client mit installiertem RSAT (Remote Server Administration Tools) das Cmdlet Get-ADAccountAuthorizationGroup ausgeführt, werden ebenfalls die direkten und verschachtelten Gruppenmitgliedschaften des angegebenen Benutzerkontos angezeigt. Domänenübergreifende „domänenlokale“ Gruppenmitgliedschaften werden nicht angezeigt, aber domänenübergreifende „universelle“ Gruppenmitgliedschaften schon. Domänenübergreifende globale Gruppen sind aus technischen Gründen ohnehin nicht möglich, da eine globale Gruppe nur Mitglieder aus der eigenen Domäne enthalten kann.
Ein DC kann „domänenlokale“, „globale“ und „universelle“ Gruppenmitgliedschaften eines Benutzers, nur innerhalb seiner Domäne ermitteln. Domänenlokale- und globale Gruppen werden zwar (neben den universellen Gruppen) auch in den globalen Katalog (GC) repliziert, allerdings nicht die Mitglieder dieser Gruppen! Deshalb findet auch bei Gruppenveränderungen in domänenlokalen und globalen Gruppen keine GC-Replikation statt. Da aber ein Benutzer Mitglied einer universellen Gruppe in unterschiedlichen Domänen sein kann, ist für die Abfrage von domänenübergreifenden universellen Gruppenmitgliedschaften ein GC notwendig. Denn nur der GC kennt die domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers, da das member Attribut von universellen Gruppen auf den GC repliziert wird. Wenn sich ein Benutzer in einer Gesamtstruktur mit mehreren Domänen an einer Domäne anmeldet, muss der DC einen GC kontaktieren um die universellen Gruppenmitgliedschaften abzurufen, in denen der Benutzer evtl. in anderen Domänen Mitglied ist. Oder es ist ab Windows Server 2003 das „zwischenspeichern der universellen Gruppenmitgliedschaften“ auf einem AD-Standort aktiviert.
In einer Multidomänen-Gesamtstruktur ist es zwingend erforderlich, dass zum Zeitpunkt der Abfrage mit dem Cmdlet Get-ADAccountAuthorizationGroup ein GC erreichbar ist. Denn schließlich wird für die Auswertung der domänenübergreifenden universellen Gruppenmitgliedschaften ein GC benötigt. Wenn zum Zeitpunkt der Abfrage kein GC erreicht werden kann schlägt die Abfrage fehl. Allerdings schlägt die Abfrage nur dann fehl, wenn es sich um eine Multidomänen-Gesamtstruktur handelt!
Die Option „Das zwischenspeichern von universellen Gruppenmitgliedschaften“ bringt nicht den gewünschten Erfolg. Die Abfrage mit dem Cmdlet in einer Gesamtstruktur mit mehreren Domänen schlägt auch in diesem Fall fehl.
Ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften ist für die Benutzeranmeldung nur in einer Gesamtstruktur mit mehreren Domänen notwendig. Handelt es sich um eine Einzeldomänen-Gesamtstruktur (Single-Domänen Forest), wird weder ein GC, noch das zwischenspeichern von universellen Gruppenmitgliedschaften benötigt. Es existieren ohnehin keine domänenübergreifenden Gruppenmitgliedschaften, wozu ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften notwendig wäre.
In einer Einzeldomänen-Gesamtstruktur benötigt das Cmdlet deshalb auch keinen GC. Schließlich kennt in einer Einzeldomänen-Gesamtstruktur der DC alle Gruppenmitgliedschaften eines Benutzers. Auch der Benutzer kann sich in einer Einzeldomänen-Gesamtstruktur ohne einen GC erfolgreich an der Domäne anmelden.
In einer Windows Server 2003 oder Windows Server 2008 Umgebung lässt sich die AD-PowerShell ebenfalls z.B. von einem Windows 7 Client nutzen. Dazu muss jedoch das „AD MGS“ auf mindestens einem DC installiert werden:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Das Cmdlet Get-ADAccountAuthorizationGroup liest das Attribut tokenGroups des angegebenen Sicherheitsprinzipals aus. Dabei kann ein Benutzer oder Computer angegeben werden, aber keine Gruppe! Es werden zum einen alle direkten und verschachtelten Sicherheits-Gruppenmitgliedschaften (domänenlokale, globale und universelle Gruppen) innerhalb der Domäne und zum anderen die direkten und verschachtelten domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers angezeigt. Es werden jedoch keine Verteilergruppen angezeigt!
Das mehrwertige Attribut tokenGroups ist zwar im Schema definiert, es enthält jedoch selbst keinen Wert. Die Attributwerte werden erst im Moment der Abfrage errechnet. Diese Art von Attribut bezeichnet man als Constructed Attribute oder auch Computed Attribute. Da das Attribut tokenGroups "constructed" ist, kann es nicht repliziert werden. Sein Wert wird auch nicht in den GC übertragen.
Siehe auch:
Die konstruierten Attribute abfragen
Die Gruppenmitgliedschaften eines Benutzers werden wie folgt in eine CSV-Datei exportiert:
Get-ADAccountAuthorizationGroup Yusuf | Export-CSV C:\Yusuf.csv -NoTypeInformation
Soll die Ausgabe bis auf wenige Attribute gekürzt werden, lautet der Befehl wie folgt:
Get-ADAccountAuthorizationGroup Yusuf | Select distinguishedName,sAMAccountName,GroupCategory,GroupScope,objectClass | Export-CSV C:\Yusuf.csv -NoTypeInformation
Die Ausgabe sieht wie folgt aus:
Die Hilfe zu dem Cmdlet lässt sich mit diesem Befehl anzeigen:
Get-Help Get-ADAccountAuthorizationGroup -Full
Die Gruppenmitgliedschaften eines Benutzers mit den ds*-Tools exportieren
Mit den beiden Kommandozeilentools dsquery und dsget die sich seit Windows Server 2003 "on Bord" befinden, lassen sich ebenfalls die Gruppenmitgliedschaften eines Benutzers exportieren.
Möchte man die direkten Gruppenmitgliedschaften eines Benutzers exportieren, so kann dazu der folgende Befehl verwendet werden:
dsquery user -samid <Benutzername> | dsget user -memberof > C:\Temp\Gruppenmitgliedschaften.txt
oder:
dsget user "DN des Benutzerobjekts" -memberof > C:\Temp\Gruppenmitgliedschaften.txt
Sollen hingegen auch die verschachtelten Gruppenmitgliedschaften angezeigt werden, dann gilt es diesen Befehl auszuführen:
dsget user "DN des Benutzerobjekts" -memberof -expand > C:\Temp\Gruppenmitgliedschaften.txt
bzw.
dsquery user -samid <Benutzername> | dsget user -memberof -expand > C:\Temp\Gruppenmitgliedschaften.txt
Hinweis: Unter Windows Server 2008 R2 und Windows 7 liefert dsget nicht die korrekten Daten.
Das lässt sich jedoch durch einen Hotfix beheben:
The "dsget user -memberof -expand" command returns incorrect results in Windows Server 2008 R2 and in Windows 7
Die Gruppenmitgliedschaften eines Benutzers mit "Net User" exportieren
Auch mit dem Kommandozeilentool NET kann man die Gruppenmitgliedschaften eines Benutzer wie folgt exportieren:
Net User <sAMAccountName> /Domain > C:\Temp\Gruppenmitgliedschaften.txt
Weitere Informationen:
Delegierte Berechtigungen im AD verstehen
Active Directory – Abfrage
AD-PowerShell Befehle
Token-Groups Attribute (Windows)
How to enumerate a user's security group membership using Visual Basic or Visual Basic Script
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:
- msDS-FailedInteractiveLogonCount: In diesem Attribut wird die Anzahl der fehlgeschlagenen Anmeldeversuche seit der Aktivierung dieser Funktion gespeichert.
- msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon: Die Anzahl der fehlgeschlagenen interaktiven Anmeldeversuche bis zur letzten erfolgreichen Anmeldung werden in diesem Attribut gespeichert.
- msDS-LastFailedInteractiveLogonTime: Der Zeitpunkt des letzten fehlgeschlagenen Anmeldeversuchs wird in diesem Attribut gespeichert.
- 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
- Der Domänenfunktionsmodus muss sich auf Windows Server 2008 oder höher befinden.
- Auf der Client Seite wird diese Funktion erst ab Windows Vista unterstützt. Ältere Betriebssysteme ignorieren diese Funktion.
- 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:
- Den Zeitpunkt der letzten erfolgreichen interaktiven Anmeldung.
- Den Zeitpunkt des letzten fehlgeschlagenen interaktiven Anmeldeversuchs.
- 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:
- 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!
- 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?
Microsoft hat in den vergangenen Tagen ein überarbeitetes Tool veröffentlicht.
Die Rede ist vom Microsoft Active Directory Topology Diagrammer.
Dieses Tool ist genau das richtige Werkzeug für den Administrator, der quasi auf Knopfdruck ein Diagramm über seine
Active Directory Gesamtstruktur erstellt haben möchte. Das Tool erstellt auf einem Arbeitsplatz, auf dem das Visio 2003
oder 2007 installiert ist, ein Diagramm mit den wichtigen Details einer Active Directory Umgebung.
Die Systemvorrausetzungen um das ADTD zu installieren, wären:
Das Tool liest die Informationen aus dem Active Directory über die ActiveX Data Objects (ADO) Schnittstelle aus und erstellt
automatisch ein Visio-Diagramm. Es bleiben lediglich wenige Handgriffe im Nachhinein notwendig, um das Diagramm fertig zu stellen.
In diesem Diagramm werden Domänen, Standorte, Domänencontroller, OUs, Standortverknüpfungen, GPO-Links, Replikationsverbindungen,
Subnetze, Exchange-Organisation und einiges mehr dargestellt.
Die Installation des ADTD lässt sich recht schnell und einfach durchführen.
Anschließend steht das Tool unter Start – Programme zur Verfügung.
Nach Aufruf des Tools muss zuerst ein Domänencontroller, auf dem der globale Katalog (GC) aktiviert ist eingegeben werden.
Idealerweise wählt man einen GC aus, der sich am gleichen Standort befindet, wie der Arbeitsplatz von dem aus das ADTD ausgeführt wird.
Wenn die Option Use DNS and connect to each Domain im Reiter Domains gewählt wird, bedeutet dies,
dass in jeder vertrauten Domäne ein DC kontaktiert wird.
Auf den einzelnen Reitern gilt es die gewünschten Optionen zu aktivieren.
Wenn die Auswahl der gewünschten Optionen getroffen wurde, gilt es anschließend mit einem Klick auf Discover! die Abfrage zu starten.
Die Abfrage die an den GC gesendet wird, dauert lediglich wenige Sekunden. Dabei entsteht auch keine größere Ressourcen-Beanspruchung
an den GC. Erst beim erstellen des Visio-Diagramms auf der Arbeitsstation, worauf die eigentliche Arbeit durchgeführt wird,
entsteht je nach Größe der Gesamtstruktur einiges an Last.
Wurde die Abfrage abgeschlossen, so wird das Visio-Diagramm mit einem Klick auf Draw! erstellt.
Im fertig gestellten Diagramm bleiben kleinere Handgriffe wie z.B. das verschieben der einzelnen Bilder
oder die farbliche Kennzeichnung der einzelnen Domänen übrig.
Das verschieben sowie die farbliche Kennzeichnung der einzelnen Bilder dieses Diagramms, dass aus einer produktiven Umgebung stammt,
hat weniger als fünf Minuten gedauert. Dabei wandern die Standortverknüpfungen sowie die standortübergreifende Replikationsverbindungen automatisch mit.
Die einzelnen Bilder stellen hier jeweils eine Domäne dar.
Je nachdem welche Optionen bei der Abfrage eingestellt wurden, werden mehr oder weniger Werte angezeigt.
Sei es der Domänenfunktionsmodus, die Anzahl der Benutzer-Objekte, die Anzahl der DCs oder den/die Träger der FSMO-Rollen oder die Schema-Version usw.
Alle diese Informationen können angezeigt werden und decken evtl. den einen oder anderen Konfigurationsfehler auf.
Es lassen sich auch die GPO-Verknüpfungen anzeigen. Man sieht auf welche OU eine GPO verlinkt wurde.
Nur leider fehlt an dieser Stelle, welche GPO an die jeweilige OU verlinkt wurde.
Als besonderes Bonbon werden beim installieren vom ADTD auch noch weitere Visio-Shapes mit installiert,
die später für eigene Diagramme verwendet werden können.
Alles in allem ist das kostenlose Tool eine echte Dokumentationshilfe für den Administrator.
Weitere nützliche Tools:
José: Active-Directory-Dokumentation
Borg: AD-Standorte dokumentieren
Das Erstellungsdatum eines Benutzerobjekts, kann aus dem Active Directory abgefragt werden.
Das Attribut in dem das Datum gespeichert wird, nennt sich When-Created und wird auf andere Domänencontroller,
sowie in den globalen Katalog (Global Catalog, GC) repliziert.
When-Created
Eine Abfrage per Skript könnte folgendermaßen aussehen:
How Can I Get a List of All the Objects that have been Added to Active Directory Since a Specified Date?
Ein ähnliches Attribut ist Create-Time-Stamp (RFC 2251). Es ist zwar im Schema definiert, aber es enthält selbst keinen Wert.
Die Attributwerte werden allerdings im Moment der Abfrage errechnet. Diese Art von Attribut wird „Operational Attribute“ oder
auch „Constructed Attribute“ genannt. Da das Attribut Create-Time-Stamp „constructed“ ist, kann es nicht repliziert werden.
Sein Wert wird auch nicht in den GC übertragen.
Um die Kompatibilität mit X.500/LDAP herzustellen, erhält man bei einer Abfrage des Attributs Create-Time-Stamp,
den Wert von When-Created zurück. Möchte man dieses Attribut per Skript abfragen, so muss dies explizit über die GetInfoEx Methode erfolgen.
Create-Time-Stamp
Operational Attributes
MMC Snap-In „Active Directory-Benutzer und –Computer“
Recht einfach lässt sich das Erstellungsdatum eines Benutzerobjekts über die grafische Benutzerverwaltung anzeigen.
Im Snap-In „Active Directory-Benutzer und –Computer“ ist es notwendig, unter Ansicht die Option Erweiterte Funktionen zu aktivieren um somit,
weitere Registerkarten im Benutzerobjekt anzeigen zu lassen. Danach navigiert man zum Container Users
(worin standardmäßig die Benutzerobjekte gespeichert werden) bzw. zur Organisationseinheit (Organizational Unit, OU), in dem sich die Benutzerobjekte befinden. Anschließend ruft man, mit einem Rechtsklick auf das Benutzerobjekt, die Eigenschaften des Benutzers auf.
Im Reiter Objekt befindet sich der Eintrag "Erstellt am:".
MMC Active Directory Service Interface Editor - ADSIEdit
Es ist ebenfalls möglich, mit ADSIEdit.msc (aus den Windows Support Tools) sich das Attribut anzeigen zu lassen. Dazu gilt es,
ADSIEdit.msc über Start – Ausführen – ADSIEdit.msc aufzurufen und sich mit der Domain-Partition zu verbinden (falls noch keine Verbindung besteht).
Als nächstes erweitert man die Einträge Domain [DC-Name.<Domäne>.<TLD>] sowie den Container DC=<Domäne>,DC=<TLD>.
Im Anschluss navigiert man zum Container CN=Users bzw. OU=<OU-Name> in dem sich die Benutzerobjekte befinden und wählt mit einem Rechtsklick
auf das Benutzerobjekt CN=<Benutzername>, die Eigenschaften aus. Nun kann man im Eigenschaften-Fenster des Benutzers,
dass Attribut whenCreated kontrollieren.
Befehlszeilen-Abfrage mit DSQUERY
Neben der grafischen Oberfläche, lässt sich das Attribut auch über die Befehlszeile abfragen.
Dazu bietet sich eines der DS-Tools, dass im Windows Server 2003 Betriebssystem integriert ist an. Das Tool das sich dazu eignet, lautet dsquery.
Der Befehl für die Abfrage, könnte folgendermaßen lauten (alles in einer Zeile):
dsquery * domainroot -filter "(&(objectClass=User)(objectCategory=Person))" -attr distinguishedName sAMAccountName whenCreated -Limit 0
Dsquery
How do I know what attribute names to use when performing a 'DSQUERY *'?
Hinweis: Möchte man ausschließlich Benutzerobjekte angezeigt bekommen, so ist neben dem Attribut „ObjectClass=User”,
zusätzlich das Attribut „ObjectCategory=Person“ bzw. „ObjectCategory=User“ abzufragen.
Befehlszeilen-Abfrage mit ADFind
Ein weiteres Befehlszeilenprogramm, das auf keinem administrativen PC fehlen sollte, ist das von Joe Richards entwickelte Tool – ADFind.
Die Abfrage könnte z.B. folgendermaßen lauten:
Adfind -b DC=<Domäne>,DC=<TLD> -f “&(objectclass=user)(objectcategory=person)" sAMAccountName whencreated
Download: AdFind
Wie die Abfrage mit der AD-PowerShell aussieht, wird im folgenden Artikel beschrieben
Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|