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
Die Active Directory (AD) Schemaversionen sind (in Dezimal) unter:
- Windows 2000 mit allen Service Packs = 13
- Windows Server 2003 mit allen Service Packs = 30
- Windows Server 2003 R2 mit allen Service Packs = 31
- Windows Server 2008 mit allen Service Packs = 44
- Windows Server 2008 R2 mit allen Service Packs = 47
- Windows Server 2012 mit allen Service Packs = 56
Das Installieren eines Service Packs ändert niemals die AD Schemaversion! Die AD Schemaversion ändert sich auch dann nicht, wenn andere Technologien (beispielsweise Exchange) installiert werden und eine Schemaaktualisierung durchführen. Oder wenn eine eigene Schemaänderung durchgeführt wird, ändert sich ebenfalls die AD Schemaversion nicht. Die AD Schemaversion ändert sich nur dann, wenn das ADPREP einer neueren Windows Server Version ausgeführt wird.
Die Information in der die AD Schemaversion enthalten ist, verbirgt sich im Attribut objectVersion, das sich in den Eigenschaften der Schemapartition befindet. Dadurch, dass die Schemapartition auf alle DCs in der Gesamtstruktur repliziert wird, kann man zur Abfrage einen lokalen DC verwenden. Deshalb besteht keine Notwendig in einer Gesamtstruktur mit mehreren Domänen, einen DC aus der Root-Domäne oder gar den globalen Katalog zu verwenden. Diese Information hat jeder DC, egal in welcher Domäne er sich befindet.
Die AD Schemaversion mit der AD-PowerShell abfragen
Mit der AD PowerShell lässt sich die AD Schemaversion folgendermaßen herausfinden:
([ADSI]"LDAP://<Domäne.TLD>/CN=Schema,CN=Configuration,DC=Root-Domäne").objectVersion
Oder mit diesem AD PowerShellbefehl:
Get-ADObject "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties objectVersion | Select objectVersion | FT -A
Die AD Schemaversion mit ADSIEdit anzeigen
Nach dem man sich in ADSIEdit (oder mit anderen LDAP-Browsern) mit der Schemapartition verbunden hat, gilt es den Eintrag zu erweitern und mit einem Rechtsklick auf den Container CN=Schema,CN=Configuration,DC=Root-Domäne im Kontextmenü die Eigenschaften des Containers aufzurufen. Dort findet man das Attribut objectVersion mit der aktuellen AD Schemaversion.
Die AD Schemaversion mit LDP anzeigen
Ist das LDP gestartet, muss man sich als erstes unter Remotedesktopverbindung – Verbinden… mit einem DC verbinden. Danach muss man sich mit dem AD unter Remotedesktopverbindung – Gebunden… binden. Ist das erfolgt, ruft man unter Durchsuchen – Suchen das Suchfenster auf und gibt folgende Daten in die Felder ein:
Basis-DN: CN=Schema,CN=Configuration,DC=Root-Domäne
Filter: (objectClass=top)
Bereich: Basis
Attribute: objectVersion
Klickt man anschließend auf Ausführen, erscheint in der rechten Hälfte von LDP das Attribut objectVersion mit der aktuellen Schemaversion.
Die AD Schemaversion mit dsquery abfragen
Auch mit dsquery lässt sich die AD Schemaversion in einer Kommandozeile abfragen. Der Befehl lautet wie folgt:
dsquery * "CN=Schema,CN=Configuration,DC=Root-Domäne" -Scope Base -attr objectVersion
Die AD Schemaversion in der Registry überprüfen
Die AD Schemaversion kann man sich auf jedem DC in der Gesamtstruktur, sogar in der Registry in dem folgenden Registrykey ansehen:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version>
Im selben Registrykey existiert auch der Schlüssel System Schema Version. Dieser Schlüssel wird lediglich von der Install from Media (IFM) Funktion verwendet. Damit wird sichergestellt, dass beim heraufstufen eines DCs mit der IFM Funktion, keine ältere oder neuere Schemaversion auf dem DC wiederhergestellt wird. Dieser Wert dient zur Kontrolle.
Domänencontroller-Installation von einer Sicherung
Die Exchange Schemaversion abfragen
Exchange hat seine eigene Schemaversion. Die Schemaversion von Exchange steckt im Attribut rangeUpper, das sich in der Schemapartition im Objekt ms-Exch-Schema-Version-Pt befindet. So wie bei der AD Schemaversion, kann man für die Abfrage der Exchange Schemaversion jeden DC in der Gesamtstruktur verwenden, da sich die gewünschte Information ebenfalls in der Schemapartition befindet, die wie bereits erwähnt auf jeden DC in der Gesamtstruktur repliziert wird.
Anders als bei der AD Schemaversion, kann sich unter Exchange die Schemaversion schon beim Installieren eines Service Packs für Exchange ändern.
Die Exchange Schemaversionen sind unter:
- Exchange 2000 = 4397
- Exchange 2000 SP3 = 4406
- Exchange Server 2003 RTM = 6870
- Exchange Server 2003 SP2 = 6936
- Exchange Server 2007 RTM = 10637
- Exchange Server 2007 SP1 = 11116
- Exchange Server 2007 SP2 = 14622
- Exchange Server 2007 SP3 = 14625
- Exchange Server 2010 RTM = 14622
- Exchange Server 2010 SP1 = 14726
Die Exchange Schemaversion mit der AD-PowerShell abfragen
In der AD PowerShell findet man die Exchange Schemaversion wie folgt heraus:
([ADSI]"LDAP://Domäne.de/CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne").rangeUpper
Auch dieser AD PowerShellbefehl liefert die Schemaversion von Exchange:
Get-ADObject "CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC= Root-Domäne " -Properties rangeUpper | Select rangeUpper | FT –A
Die Exchange Schemaversion mit ADSIEdit anzeigen
Ist ADSIEdit gestartet, muss man sich zuerst mit der Schemapartition verbinden, sofern noch keine Verbindung existiert. Danach ruft man mit einem Rechtsklick auf den Container CN=Schema,CN=Configuration,DC=Root-Domäne die Eigenschaften auf und navigiert zum Attribut rangeUpper. Der Wert in diesem Attribut, ist die Exchange Schemaversion.
Die Exchange Schemaversion mit LDP anzeigen
Möchte man sich die Exchange Schemaversion in LDP anzeigen lassen, gilt es sich zuerst unter Remotedesktopverbindung – Verbinden… mit einem DC zu verbinden. Im zweiten Schritt bindet man sich unter Remotedesktopverbindung – Gebunden… mit dem AD. Als nächstes ruft man unter Durchsuchen – Suchen das Suchfenster auf und gibt folgende Daten in die Felder ein:
Basis-DN: CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne
Filter: (objectClass=*)
Bereich: Basis
Attribute: rangeUpper
Klickt man anschließend auf Ausführen, erscheint das Attribut rangeUpper mit der aktuellen Exchange Schemaversion.
Die Exchange Schemaversion mit dsquery abfragen
In der Kommandozeile lässt sich die Schemaversion von Exchange mit dsquery wie folgt abfragen:
dsquery * CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr rangeUpper
Möchte man im Active Directory Informationen über einen Dienst der innerhalb einer Domäne zur Verfügung stehen soll veröffentlichen, so benötigt man ein Service Connection Point (SCP) Objekt. Ein SCP wird bei der Installation von vielen Applikation automatisch, ohne das Zutun des Administrators erstellt. Die SCPs gehören zur Klasse serviceConnectionPoint, die wiederum von der Klasse connectionPoint abgeleitet ist.
Beispielsweise wird bei der Installation von Remotedesktoplizenzierung, Remote-Installation-Services, Hyper-V, Microsoft basierte virtuelle Maschinen, MS Virtual Machine Manager, der Autodiscover-Funktion ab Exchange 2007 etc. ein SCP im AD erstellt. Diese und viele anderen Dienste veröffentlichen ihr Dasein in der Domäne, durch das Erstellen von SCPs. ADAM / AD LDS stellt dabei keine Ausnahme dar. Client-Anwendungen wiederum verwenden SCPs, um den entsprechenden Dienst in der Domäne zu finden und um sich mit diesem zu verbinden.
Aktiviert man in der MMC Active Directory-Benutzer und -Computer (dsa.msc) unter Ansicht die Option Benutzer, Kontakte, Gruppen und Computer als Container, so kommen einige der SCPs unterhalb der Serverobjekte zum Vorschein.
Möchte man sich den Autodiscover SCP von Exchange in der grafischen Oberfläche anzeigen lassen, so kann man den SCP in der MMC Active Directory-Standorte und -Dienste (dssite.msc) zum Vorschein bringen. Dazu markiert man zuerst in der MMC dssite.msc mit einem Linksklick den Eintrag Active Directory-Standorte und -Dienste [FQDN des DCs], ruft mit einem Rechtklick das Kontextmenü auf und aktiviert unter Ansicht die Option Dienstknoten anzeigen. Danach navigiert man zum folgenden Container:
Services\Microsoft Exchange\<Exchange Organisation>\Administrative Groups\Exchange Administrative Group (FYDIBOHF23SPDLT)\Servers\<Exchange Server>\Protocols\Autodiscover\
Im Container Autodiscover findet man dann den SCP <Exchange Server>.
In ADSIEdit oder jedem anderen LDAP-Browser findet man den Autodiscover SCP von Exchange in der Konfigurationspartition im folgenden LDAP-Pfad:
CN=<Exchange Server>,CN=Autodiscover,CN=Protocols,CN=<Exchange Server>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Exchange Organisation>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Root-Domäne
Die SCPs mit der AD-PowerShell abfragen
Welche SCPs innerhalb einer Domäne von welchen Objekten im AD veröffentlicht wurden, erfährt man mit diesem AD-Powershellbefehl:
Get-ADObject -LDAPFilter "(objectClass=serviceConnectionPoint)" | Select distinguishedName | FT -A –Wrap
In der Ausgabe erhält man den Distinguished Name (DN) aller SCPs die in der Domäne existieren. Aus dem DN lässt sich auch ableiten, welches Objekt den SCP erstellt hat.
Welche SCPs in der Konfigurationspartition existieren (bspw. Autodiscover von Exchange), kann man sich folgendermaßen anzeigen lassen:
Get-ADObject -LDAPFilter "(objectClass=serviceConnectionPoint)" -Searchbase "CN=Configuration,DC=Root-Domäne" | Select distinguishedName | FT -A -Wrap
Bestimmte SCPs mit der AD-PowerShell abfragen
Man kann natürlich auch nur bestimmte SCPs abfragen. Möchte man sich beispielsweise alle Hyper-V Hosts in der Domäne anzeigen lassen, so kann man dies mit diesem AD-PowerShellbefehl folgendermaßen durchführen:
Get-ADObject -LDAPFilter "(&(objectClass=serviceConnectionPoint)(CN=Microsoft Hyper-V))" | Select distinguishedName | FT -A -Wrap
Alle Microsoft basierte virtuelle Maschinen innerhalb einer Domäne, lassen sich mit diesem AD-PowerShellbefehl wie folgt Anzeigen:
Get-ADObject -LDAPFilter "(&(objectClass=serviceConnectionPoint)(CN=Windows Virtual Machine))" | Select distinguishedName | FT -A -Wrap
Den Autodiscover SCP von Exchange kann man sich wie folgt anzeigen lassen:
Get-ADObject -LDAPFilter "(objectClass=serviceConnectionPoint)" -Searchbase "CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Root-Domäne" | Select distinguishedName | FT -A -Wrap
Den Server auf dem die Remotedesktoplizenzierung installiert ist, kann man sich mit diesem AD-PowerShellbefehl anzeigen lassen:
Get-ADObject -LDAPFilter "(&(objectClass=serviceConnectionPoint)(CN=TermServLicensing))" | Select distinguishedName | FT -A -Wrap
Die SCPs mit dem Kommandozeilentool dsquery abfragen
Alle SCPs innerhalb der Gesamtstruktur (unter anderem Autodiscover von Exchange) lassen sich mit dsquery wie folgt Anzeigen:
dsquery * Forestroot -Filter (objectClass=serviceConnectionPoint)
Alle SCPs innerhalb der Domäne lassen sich mit dsquery wie folgt Anzeigen:
dsquery * Domainroot -Filter (objectClass=serviceConnectionPoint)
Bestimmte SCPs mit dsquery abfragen
Alle Hyper-V Hosts innerhalb einer Domäne lassen sich mit dem folgenden dsquery Befehl Anzeigen:
dsquery * Domainroot –Filter "(&(objectClass=serviceConnectionPoint)(CN=Microsoft Hyper-V))"
Alle Microsoft basierte virtuelle Maschinen innerhalb einer Domäne werden mit dsquery wie folgt angezeigt:
dsquery * Domainroot –Filter "(&(objectClass=serviceConnectionPoint)(CN=Windows Virtual Machine))"
Mit dsquery lässt sich der Server auf dem die Remotedesktoplizenzierung installiert ist, folgendermaßen Anzeigen:
dsquery * Domainroot –Filter "(&(objectClass=serviceConnectionPoint)(CN=TermServLicensing))"
Ersetzt man in den dsquery Befehlen das Domainroot durch Forestroot, wird die Abfrage in der Gesamtstruktur durchgeführt.
Weitere Informationen:
Creating a Service Connection Point
Where to Create a Service Connection Point
Publishing with Service Connection Points
Verknüpfte Attribute (linked attributes) sind Verknüpfungspaare, die aus einem Forward-Link und einem Back-Link Attribut bestehen. Ob es sich bei einem Attribut im AD-Schema um ein verknüpftes Attribut handelt, wird von dem linkID Attribut bestimmt, das sich im attributeSchema-Objekt befindet. Das linkID Attribut im Forward-Link enthält immer einen geraden und das linkID Attribut im verknüpften Back-Link enthält stets einen ungeraden Wert, nämlich den Wert „Forward-linkID plus 1“. Der Administrator kann dabei ausschließlich das Forward-Link Attribut bearbeiten, nicht jedoch das Back-Link Attribut! Repliziert werden nur die Forward-Link Attribute, nicht jedoch die Back-Links.
Weitere Details liefert der folgende Artikel:
Verknüpfte Attribute
Alle verknüpften Attribute mit der AD-PowerShell abfragen
Alle Forward- und Back-Link Attribute die im AD-Schema existieren, kann man sich mit der AD-PowerShell wie folgt anzeigen lassen:
Get-ADObject -LDAPFilter "(&(objectClass=attributeSchema)(linkID=*))" -Properties lDAPDisplayName,linkID -SearchBase "CN=Schema,CN=Configuration,DC=AD2008R2,DC=Dikmenoglu,DC=DE" -searchScope oneLevel | Select lDAPDisplayName,linkID | Sort-Object linkID | FT -A
Alle verknüpften Attribute mit dem Kommandozeilentool dsquery abfragen
Mit dsquery lassen sich alle Forward- und Back-Link Attribute folgendermaßen anzeigen:
dsquery * "CN=Schema,CN=Configuration,DC=AD2008R2,DC=Dikmenoglu,DC=DE" -Scope oneLevel -Filter "(&(objectClass=attributeSchema)(linkID=*))" -attr lDAPDisplayName linkID -Limit 0
Alle verknüpften Attribute mit LDP abfragen
Nachdem man sich in LDP mit einem DC verbunden und mit dem AD “gebunden” hat, muss man unter Durchsuchen – Suchen zuerst diesen Filter angeben: (&(objectClass=attributeSchema)(linkID=*)). Es genügt als Suchbereich die Option Eine Ebene zu wählen und im Feld Attribute, die beiden Attribute lDAPDisplayName;linkID anzugeben. Anschließend werden alle verknüpften Attribute angezeigt.
Die verknüpften Attribute mit einem AD-PowerShell Skript abfragen
Mit dem folgenden AD-PowerShell Skript kann man sich gezielt nur die Forward-Link, Back-Link oder Forward- und Back-Link Attribute anzeigen lassen. Für das Skript ist es zwingend notwendig, dass die AD-PowerShell Cmdlets zur Verfügung stehen. Die AD-PowerShell, die out-of-the-box unter Windows Server 2008 R2 zur Verfügung steht, lässt sich auch in einer Windows Server 2003 und Windows Server 2008 Umgebung einsetzen. In diesen Umgebungen ist es jedoch erforderlich, das Active Directory Management Gateway Service bereitzustellen.
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
######################################################
#
# AD-PowerShell Skript zum Anzeigen von Forward-Link,
# Back-Link oder Forward- und Back-Link Attribute
#
# Von: Yusuf Dikmenoglu 11/2010
#
# http://blog.dikmenoglu.de
#
######################################################
clear
$auswahl = Read-Host "Welche Attribut Art soll angezeigt werden (1...Forward-Link 2...Back-Link 3...Forward- und Back-Link):"
switch ($auswahl){
1 {
Get-ADObject -LDAPFilter "(&(objectClass=attributeSchema)(linkID=*))" -Properties lDAPDisplayName,linkID -SearchBase "CN=Schema,CN=Configuration,DC=Root-Domäne" -searchScope oneLevel | Sort-Object linkID | ForEach-Object {
if (!($_.linkID % 2)){
Write-Host "Forward-Link: " $_.lDAPDisplayName $_.linkID
}
}
}
2 {
Get-ADObject -LDAPFilter "(&(objectClass=attributeSchema)(linkID=*))" -Properties lDAPDisplayName,linkID -SearchBase "CN=Schema,CN=Configuration,DC=Root-Domäne" -searchScope oneLevel | Sort-Object linkID | ForEach-Object {
if ($_.linkID % 2){
Write-Host "Back-Link: " $_.lDAPDisplayName $_.linkID
}
}
}
3 {
Get-ADObject -LDAPFilter "(&(objectClass=attributeSchema)(linkID=*))" -Properties lDAPDisplayName,linkID -SearchBase "CN=Schema,CN=Configuration,DC=Root-Domäne" -searchScope oneLevel | Sort-Object linkID | ForEach-Object {
if ($_.linkID % 2){
Write-Host "Back-Link: " $_.lDAPDisplayName $_.linkID
}
else {
Write-Host "Forward-Link: " $_.lDAPDisplayName $_.linkID
}
}
}
default{
Write-Host "Ungültige Eingabe"
}
}
In einer Windows Server 2008 R2 AD Umgebung ohne jegliche AD-Erweiterung (wie beispielsweise eigene Schemaerweiterungen, Exchange etc.), existieren folgende 97 verknüpfte Attribute:
member 2
memberOf 3
manager 42
directReports 43
owner 44
ownerBL 45
siteObject 46
siteObjectBL 47
nonSecurityMember 50
nonSecurityMemberBL 51
queryPolicyObject 68
queryPolicyBL 69
privilegeHolder 70
isPrivilegeHolder 71
managedBy 72
managedObjects 73
hasPartialReplicaNCs 74
msDS-IsPartialReplicaFor 75
hasMasterNCs 76
masteredBy 77
syncMembership 78
serverReference 94
serverReferenceBL 95
bridgeheadTransportList 98
bridgeheadServerListBL 99
netbootServer 100
netbootSCPBL 101
frsComputerReference 102
frsComputerReferenceBL 103
fRSMemberReference 104
fRSMemberReferenceBL 105
fRSPrimaryMember 106
siteLinkList 142
siteList 144
msCOM-PartitionLink 1040
msCOM-PartitionSetLink 1041
msDS-NC-Replica-Locations 1044
msFRS-Hub-Member 1046
msCOM-UserPartitionSetLink 1048
msCOM-UserLink 1049
msDS-SDReferenceDomain 2000
msDS-HasInstantiatedNCs 2002
msDS-NonMembers 2014
msDS-NonMembersBL 2015
msDS-MembersForAzRole 2016
msDS-MembersForAzRoleBL 2017
msDS-OperationsForAzTask 2018
msDS-OperationsForAzTaskBL 2019
msDS-TasksForAzTask 2020
msDS-TasksForAzTaskBL 2021
msDS-OperationsForAzRole 2022
msDS-OperationsForAzRoleBL 2023
msDS-TasksForAzRole 2024
msDS-TasksForAzRoleBL 2025
msDS-HasDomainNCs 2026
msDS-IsDomainFor 2027
msSFU30PosixMember 2030
msSFU30PosixMemberOf 2031
msDS-hasMasterNCs 2036
msDs-masteredBy 2037
msDS-ObjectReference 2038
msDS-ObjectReferenceBL 2039
msPKIDPAPIMasterKeys 2046
msPKIAccountCredentials 2048
msDFSR-ComputerReference 2050
msDFSR-ComputerReferenceBL 2051
msDFSR-MemberReference 2052
msDFSR-MemberReferenceBL 2053
msDS-KrbTgtLink 2100
msDS-KrbTgtLinkBl 2101
msDS-RevealedUsers 2102
msDS-RevealedDSAs 2103
msDS-hasFullReplicaNCs 2104
msDS-IsFullReplicaFor 2105
msDS-NeverRevealGroup 2106
msDS-RevealOnDemandGroup 2110
msDS-AuthenticatedAtDC 2112
msDS-AuthenticatedToAccountlist 2113
msDS-NC-RO-Replica-Locations 2114
msDS-NC-RO-Replica-Locations-BL 2115
msDS-PSOAppliesTo 2118
msDS-PSOApplied 2119
addressBookRoots2 2122
globalAddressList2 2124
templateRoots2 2126
msDS-BridgeHeadServersUsed 2160
msPKI-CredentialRoamingTokens 2162
msDS-OIDToGroupLink 2164
msDS-OIDToGroupLinkBl 2165
msDS-HostServiceAccount 2166
msDS-HostServiceAccountBL 2167
msDS-EnabledFeature 2168
msDS-EnabledFeatureBL 2169
msTSPrimaryDesktop 2170
msTSPrimaryDesktopBL 2171
msTSSecondaryDesktops 2172
msTSSecondaryDesktopBL 2173
In einer Windows Server 2008 R2 und Exchange 2010 SP1 Umgebung, existieren folgende 314 verknüpfte Attribute:
member 2
memberOf 3
altRecipient 12
altRecipientBL 13
publicDelegates 14
publicDelegatesBL 15
homeMDB 32
homeMDBBL 33
manager 42
directReports 43
owner 44
ownerBL 45
siteObject 46
siteObjectBL 47
nonSecurityMember 50
nonSecurityMemberBL 51
queryPolicyObject 68
queryPolicyBL 69
privilegeHolder 70
isPrivilegeHolder 71
managedBy 72
managedObjects 73
hasPartialReplicaNCs 74
msDS-IsPartialReplicaFor 75
hasMasterNCs 76
masteredBy 77
syncMembership 78
serverReference 94
serverReferenceBL 95
bridgeheadTransportList 98
bridgeheadServerListBL 99
netbootServer 100
netbootSCPBL 101
frsComputerReference 102
frsComputerReferenceBL 103
fRSMemberReference 104
fRSMemberReferenceBL 105
fRSPrimaryMember 106
authOrig 110
authOrigBL 111
dLMemSubmitPerms 112
dLMemSubmitPermsBL 113
unauthOrig 114
unauthOrigBL 115
dLMemRejectPerms 116
dLMemRejectPermsBL 117
responsibleLocalDXA 122
assocRemoteDXA 123
supportingStack 132
supportingStackBL 133
siteLinkList 142
siteList 144
msExchHomeSyncService 146
msExchChildSyncAgreements 147
msExchRoutingGroupMembersDN 1000
msExchHomeRoutingGroupDNBL 1001
msExchSourceBridgeheadServersDN 1002
msExchBridgeheadedLocalConnectorsDNBL 1003
msExchTargetBridgeheadServersDN 1004
msExchBridgeheadedRemoteConnectorsDNBL 1005
msExchCASchemaPolicy 1006
msExchSchemaPolicyConsumers 1007
msExchOwningPFTree 1008
msExchOwningPFTreeBL 1009
msExchPolicyList 1012
msExchPolicyListBL 1013
msExchUseOAB 1014
msExchUseOABBL 1015
msExchAddressListServiceLink 1016
msExchAddressListServiceBL 1017
msExchComputerLink 1018
msExchExchangeServerLink 1019
msExchConferenceZone 1020
msExchConferenceZoneBL 1021
msExchMasterService 1022
msExchMasterServiceBL 1023
msExchExportContainersLinked 1028
msExchExportContainersBL 1029
msExchResponsibleMTAServer 1030
msExchResponsibleMTAServerBL 1031
msExchImportContainerLinked 1032
msExchAppliesToSmtpVS 1034
msExchAppliesToSmtpVSBL 1035
msExchConferenceMailbox 1036
msExchConferenceMailboxBL 1037
msExchMCUHostsSites 1038
msExchMCUHostsSitesBL 1039
msCOM-PartitionLink 1040
msCOM-PartitionSetLink 1041
msDS-NC-Replica-Locations 1044
msFRS-Hub-Member 1046
msCOM-UserPartitionSetLink 1048
msCOM-UserLink 1049
msExchHomeRoutingGroup 1050
msExchRoutingGroupMembersBL 1051
msExchMobileMailboxPolicyLink 1058
msExchMobileMailboxPolicyBL 1059
msExchAvailabilityPerUserAccount 1060
msExchAvailabilityPerUserAccountBL 1061
msExchAvailabilityOrgWideAccount 1062
msExchAvailabilityOrgWideAccountBL 1063
msExchUMDTMFFallbackAutoAttendantLink 1064
msExchUMDTMFFallbackAutoAttendantBL 1065
msExchOWATranscodingFileTypes 1066
msExchOWATranscodingFileTypesBL 1067
msExchOWAAllowedFileTypes 1068
msExchOWAAllowedFileTypesBL 1069
msExchOWAAllowedMimeTypes 1070
msExchOWAAllowedMimeTypesBL 1071
msExchOWAForceSaveFileTypes 1072
msExchOWAForceSaveFileTypesBL 1073
msExchOWAForceSaveMIMETypes 1074
msExchOWAForceSaveMIMETypesBL 1075
msExchOWABlockedFileTypes 1076
msExchOWABlockedFileTypesBL 1077
msExchOWABlockedMIMETypes 1078
msExchOWABlockedMIMETypesBL 1079
msExchOWARemoteDocumentsAllowedServers 1080
msExchOWARemoteDocumentsAllowedServersBL 1081
msExchOWARemoteDocumentsBlockedServers 1082
msExchOWARemoteDocumentsBlockedServersBL 1083
msExchOWARemoteDocumentsInternalDomainSuffixList 1084
msExchOWARemoteDocumentsInternalDomainSuffixListBL 1085
msExchOWATranscodingMimeTypes 1086
msExchOWATranscodingMimeTypesBL 1087
msExchSMTPReceiveDefaultAcceptedDomainLink 1088
msExchSMTPReceiveDefaultAcceptedDomainBL 1089
msExchHABShowInDepartments 1090
msExchHABShowInDepartmentsBL 1091
msExchHABRootDepartmentLink 1092
msExchHABRootDepartmentBL 1093
msExchHABChildDepartmentsLink 1094
msExchHABChildDepartmentsBL 1095
msExchMobileRemoteDocumentsAllowedServers 1096
msExchMobileRemoteDocumentsAllowedServersBL 1097
msExchMobileRemoteDocumentsBlockedServers 1098
msExchMobileRemoteDocumentsBlockedServersBL 1099
msExchMobileRemoteDocumentsInternalDomainSuffixList 1100
msExchMobileRemoteDocumentsInternalDomainSuffixListBL1101
msExchServerSite 1102
msExchServerSiteBL 1103
msExchHostServerLink 1104
msExchHostServerBL 1105
msExchMDBAvailabilityGroupLink 1110
msExchMDBAvailabilityGroupBL 1111
msExchConfigurationUnitLink 1112
msExchConfigurationUnitBL 1113
msExchPolicyTagLink 1114
msExchPolicyTagLinkBL 1115
msExchRoleLink 1116
msExchRoleBL 1117
msExchUserLink 1118
msExchUserBL 1119
msExchDomainRestrictionLink 1120
msExchDomainRestrictionBL 1121
msExchConfigRestrictionLink 1122
msExchConfigRestrictionBL 1123
msExchApprovalApplicationLink 1124
msExchArbitrationMailboxesBL 1125
msExchCoManagedByLink 1126
msExchCoManagedObjectsBL 1127
msExchModeratedByLink 1128
msExchModeratedObjectsBL 1129
msExchOrganizationsGlobalAddressListsLink 1130
msExchOrganizationsGlobalAddressListsBL 1131
msExchOrganizationsAddressBookRootsLink 1132
msExchOrganizationsAddressBookRootsBL 1133
msExchOrganizationsTemplateRootsLink 1134
msExchOrganizationsTemplateRootsBL 1135
msExchExchangeRPCServiceArrayLink 1136
msExchExchangeRPCServiceArrayBL 1137
msExchParentPlanLink 1178
msExchParentPlanBL 1179
msExchBypassModerationLink 1180
msExchBypassModerationBL 1181
msExchBypassModerationFromDLMembersLink 1182
msExchBypassModerationFromDLMembersBL 1183
msExchFedAcceptedDomainLink 1184
msExchFedAcceptedDomainBL 1185
msExchServerAssociationLink 1186
msExchServerAssociationBL 1187
msExchSupervisionUserLink 1188
msExchSupervisionUserBL 1189
msExchSupervisionDLLink 1190
msExchSupervisionDLBL 1191
msExchSupervisionOneOffLink 1192
msExchSupervisionOneOffBL 1193
msExchMailboxMoveTargetMDBLink 1194
msExchMailboxMoveTargetMDBBL 1195
msExchRBACPolicyLink 1196
msExchRBACPolicyBL 1197
msExchMailboxMoveSourceMDBLink 1198
msExchMailboxMoveSourceMDBBL 1199
msExchArchiveDatabaseLink 1200
msExchArchiveDatabaseBL 1201
msExchRMSComputerAccountsLink 1202
msExchRMSComputerAccountsBL 1203
msExchDelegateListLink 1204
msExchDelegateListBL 1205
msExchDeviceAccessControlRuleLink 1206
msExchDeviceAccessControlRuleBL 1207
msOrg-Leaders 1208
msOrg-LeadersBL 1209
msExchIntendedMailboxPlanLink 1210
msExchIntendedMailboxPlanBL 1211
msExchDefaultPublicMDB 1212
msExchDefaultPublicMDBBL 1213
msExchMailboxMoveSourceUserLink 1214
msExchMailboxMoveSourceUserBL 1215
msExchMailboxMoveStorageMDBLink 1216
msExchMailboxMoveStorageMDBBL 1217
msExchMailboxMoveTargetUserLink 1218
msExchMailboxMoveTargetUserBL 1219
msExchSharedConfigLink 1220
msExchSharedConfigBL 1221
msExchMailboxMoveSourceArchiveMDBLink 1222
msExchMailboxMoveSourceArchiveMDBBL 1223
msExchMailboxMoveTargetArchiveMDBLink 1224
msExchMailboxMoveTargetArchiveMDBBL 1225
msExchShadowManagerLink 1226
msExchSupportedSharedConfigLink 1228
msExchSupportedSharedConfigBL 1229
msExchDisabledArchiveDatabaseLink 1230
msDS-SDReferenceDomain 2000
msDS-HasInstantiatedNCs 2002
msDS-NonMembers 2014
msDS-NonMembersBL 2015
msDS-MembersForAzRole 2016
msDS-MembersForAzRoleBL 2017
msDS-OperationsForAzTask 2018
msDS-OperationsForAzTaskBL 2019
msDS-TasksForAzTask 2020
msDS-TasksForAzTaskBL 2021
msDS-OperationsForAzRole 2022
msDS-OperationsForAzRoleBL 2023
msDS-TasksForAzRole 2024
msDS-TasksForAzRoleBL 2025
msDS-HasDomainNCs 2026
msDS-IsDomainFor 2027
msSFU30PosixMember 2030
msSFU30PosixMemberOf 2031
msDS-hasMasterNCs 2036
msDs-masteredBy 2037
msDS-ObjectReference 2038
msDS-ObjectReferenceBL 2039
msPKIDPAPIMasterKeys 2046
msPKIAccountCredentials 2048
msDFSR-ComputerReference 2050
msDFSR-ComputerReferenceBL 2051
msDFSR-MemberReference 2052
msDFSR-MemberReferenceBL 2053
msExchELCFolderLink 2054
msExchELCFolderBL 2055
msExchMailboxTemplateLink 2056
msExchMailboxTemplateBL 2057
msExchUMTemplateLink 2058
msExchUMTemplateBL 2059
msExchUMRecipientDialPlanLink 2060
msExchUMRecipientDialPlanBL 2061
msExchUMServerDialPlanLink 2062
msExchUMServerDialPlanBL 2063
msExchUMIPGatewayDialPlanLink 2064
msExchUMIPGatewayDialPlanBL 2065
msExchUMIPGatewayServerLink 2066
msExchUMIPGatewayServerBL 2067
msExchUMAutoAttendantDialPlanLink 2068
msExchUMAutoAttendantDialPlanBL 2069
msExchUMDialPlanDefaultAutoAttendantLink 2070
msExchUMDialPlanDefaultAutoAttendantBL 2071
msExchUMHuntGroupDialPlanLink 2072
msExchUMHuntGroupDialPlanBL 2073
msExchELCExpiryDestinationLink 2080
msExchAttachmentFilteringExceptionConnectorsLink 2082
msExchJournalingRulesLink 2084
msExchMailboxOABVirtualDirectoriesLink 2086
msExchMailboxOABVirtualDirectoriesBL 2087
msExchOABVirtualDirectoriesLink 2088
msExchOABVirtualDirectoriesBL 2089
msExchELCAutoCopyAddressLink 2090
msExchUMMailboxPolicyDialPlanLink 2092
msExchUMMailboxPolicyDialPlanBL 2093
msExchSmtpSendReceiveConnectorLink 2094
msExchTransportSubmissionServerOverrideList 2096
msExchServerAdminDelegationLink 2098
msExchServerAdminDelegationBL 2099
msDS-KrbTgtLink 2100
msDS-KrbTgtLinkBl 2101
msDS-RevealedUsers 2102
msDS-RevealedDSAs 2103
msDS-hasFullReplicaNCs 2104
msDS-IsFullReplicaFor 2105
msDS-NeverRevealGroup 2106
msDS-RevealOnDemandGroup 2110
msDS-AuthenticatedAtDC 2112
msDS-AuthenticatedToAccountlist 2113
msDS-NC-RO-Replica-Locations 2114
msDS-NC-RO-Replica-Locations-BL 2115
msDS-PSOAppliesTo 2118
msDS-PSOApplied 2119
addressBookRoots2 2122
globalAddressList2 2124
templateRoots2 2126
msDS-BridgeHeadServersUsed 2160
msPKI-CredentialRoamingTokens 2162
msDS-OIDToGroupLink 2164
msDS-OIDToGroupLinkBl 2165
msDS-HostServiceAccount 2166
msDS-HostServiceAccountBL 2167
msDS-EnabledFeature 2168
msDS-EnabledFeatureBL 2169
msTSPrimaryDesktop 2170
msTSPrimaryDesktopBL 2171
msTSSecondaryDesktops 2172
msTSSecondaryDesktopBL 2173
Gibt ein Benutzer sein Kennwort öfter falsch ein, als es in der Kontosperrungsrichtlinie oder in einem PSO (Password Setting Objects, ab Windows Server 2008) konfiguriert ist, wird sein Benutzerkonto gesperrt. Einige Administratoren verwechseln das mit einem deaktivierten Benutzerkonto. Das Deaktivieren eines Benutzerkontos ist jedoch ein administrativer Vorgang, der manuell mit entsprechenden administrativen Rechten durchgeführt werden muss.
Das Attribut, in dem der Zeitpunkt der Kontosperrung gespeichert ist, lautet lockoutTime.
Das Attribut lockoutTime kann dabei folgende Werte enthalten:
- Bei einem Benutzerkonto, das noch nie gesperrt wurde, der Benutzer sich also bisher immer erfolgreich an der Domäne authentisieren konnte, enthält das Attribut lockoutTime als Wert <Nicht festgelegt>. Wie oft der Benutzer ein falsches Kennwort eingeben darf bis sein Benutzerkonto gesperrt wird, kann von der Kontosperrungsrichtlinie, bzw. ab Windows Server 2008 durch ein PSO, vorgegeben werden.
- Hat ein Benutzer sein Kennwort häufiger falsch eingegeben, als es in der Kontosperrungsrichtlinie oder in einem PSO definiert ist, wird sein Benutzerkonto gesperrt. Dabei wird in lockoutTime ein Large Integer Wert eingetragen, der den Zeitpunkt der Kontosperrung darstellt.
- Wenn ein Benutzerkonto nach den Vorgaben der Kontosperrungsrichtlinie oder durch ein PSO automatisch wieder entsperrt wurde, bleibt in lockoutTime vorerst weiterhin der Zeitpunkt der Kontosperrung als ein Large Integer Wert gespeichert. Das Attribut lockoutTime enthält dann zwar weiterhin einen Zeitwert, aber der Haken Konto ist gesperrt in den Eigenschaften des Benutzerkontos ist nicht mehr gesetzt.
- Wenn sich jedoch der Benutzer nach der Kontosperrdauer an der Domäne erfolgreich authentisiert, wird lockoutTime genullt. Als Wert wird in lockoutTime „0“ gespeichert. Auch wenn ein gesperrtes Benutzerkonto vom Administrator entsperrt wurde, erhält das Attribut lockoutTime in den Eigenschaften des entsprechenden Benutzerkontos den Wert 0.
Der LDAP-Filter, mit dem man die gesperrten Benutzerkonten beispielsweise mit einer benutzerdefinierten gespeicherten Abfrage in der MMC Active Directory-Benutzer und -Computer ermitteln kann, lautet:
(&(sAMAccountType=805306368)(lockoutTime>=1))
Wenn jedoch in der Kontosperrungsrichtlinie oder in dem zugewiesenen PSO definiert ist, dass ein Benutzer nach einer bestimmten Zeit automatisch entsperrt wird, greift diese Abfrage nach den tatsächlich gesperrten Benutzerkonten nicht! Denn nach der automatischen Entsperrung des Benutzerkontos bleibt der Zeitpunkt der Kontosperrung in lockoutTime, noch bevor sich der Benutzer erfolgreich an der Domäne authentisiert, gespeichert. Dadurch werden mit dem genannten LDAP-Filter auch die mittlerweile automatisch entsperrten Benutzerkonten angezeigt.
Insbesondere, wenn man Besuch vom Conficker Wurm hat, der alle Benutzer im AD sperrt, möchte man zügig die echten gesperrten Benutzer finden und idealerweise alle gleichzeitig entsperren.
Mit dem oben genannten LDAP-Filter funktioniert die Suche nach den tatsächlich gesperrten Benutzerkonten nur, wenn ein möglichst aktueller Zeitwert verwendet wird. Wenn beispielsweise der Conficker Wurm am 10.10.2010 um 08:05 Uhr alle Benutzerkonten im AD sperrt, könnte man als Zeitangabe den 10.10.2010 – 08:00 Uhr verwenden. Der umgerechnete Large Integer Wert lautet 129311640045030000 und demnach würde der LDAP-Filter wie folgt aussehen:
(&(sAMAccountType=805306368)(lockoutTime>=129311640045030000))
Aber die Suche nach den tatsächlich gesperrten und vor allem das Entsperren dieser Benutzerkonten, lässt sich ganz einfach realisieren. Die Lösung ist wieder einmal die AD-PowerShell! Mit diesem State of the Art Werkzeug lässt sich das schnell und einfach mit einem Einzeiler erledigen.
Mit diesem Befehl werden alle tatsächlich gesperrten Benutzer angezeigt:
Search-ADAccount –LockedOut | FT Name
Mit dem folgenden Befehl werden alle tatsächlich gesperrten Benutzer entsperrt:
Search-ADAccount -LockedOut | Unlock-ADAccount
Danach bleibt, bis zur erfolgreichen Authentisierung des entsprechenden Benutzers an der Domäne, der Zeitpunkt der Kontosperrung weiterhin in lockoutTime gespeichert, aber die Benutzerkonten sind entsperrt!
Wer noch eine Windows Server 2003 bzw. Windows Server 2008 Umgebung betreibt und unter anderem von der AD-PowerShell noch nicht sofort profitieren kann, der kann die „AD Management Gateway Services“ installieren und kommt somit ebenfalls in den Genuß der AD-PowerShell.
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Weitere Informationen:
Password Setting Objects erstellen und verwalten
Einen Large Integer Wert umrechnen
AD-PowerShell Befehle
Gespeicherte Abfragen
Gespeicherte Abfragen für dsa.msc
Objektdelegierungen einrichten
Der Objektdelegierungsassistent
Das Active Directory (AD) stets zu pflegen, ist eines der Aufgaben eines AD-Administrators. Mit der Zeit entstehen Leichen was die Computerkonten im AD betrifft. Clients die verschrottet wurden, sind vorher nicht aus der Domäne entfernt worden. Aber auch wenn Clients oder Mitgliedsserver aus der Domäne entfernt und zu einer Arbeitsgruppe (AG) hinzugefügt werden, wird nicht automatisch das Computerkonto im AD gelöscht. Es wird lediglich deaktiviert und bleibt im AD bestehen. Im Nachgang muss dann das Computerkonto manuell entfernt werden.
State oft the Art löscht man die Computerkonten mit der AD-PowerShell. Weitere Möglichkeiten findet man im folgenden Artikel:
Computerkonto löschen
# Alle deaktivierten Computerkonten, also alle Computer (Clients und Mitgliedsserver) die aus der Domäne entfernt und in eine AG hinzugefügt oder manuell deaktiviert wurden, werden mit diesem Befehl angezeigt:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object | FT Name -A
Sollen die deaktivierten Computerkonten aus einer bestimmten Organisationseinheit (OU) angezeigt werden, so gilt es diesen Befehl zu verwenden:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object | FT Name -A
# Alle deaktivierten Computerkonten werden auf Nachfrage, nacheinander mit diesem Befehl gelöscht:
Search-ADAccount -AccountDisabled -ComputersOnly | Sort-Object| Remove-ADComputer
Deaktivierte Computerkonten aus einer bestimmten OU werden auf Nachfrage mit diesem Befehl entfernt:
Search-ADAccount -AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Sort-Object| Remove-ADComputer
Sollen alle deaktivierten Computerkonten auf einmal ohne Nachfrage gelöscht werden, so muss der Parameter „-Confirm:“ mit dem Wert „$False“ mit angegeben werden. Sprich:
Search-ADAccount –AccountDisabled -ComputersOnly | Remove-ADComputer -Confirm:$False
Ohne Nachfrage werden die deaktivierten Computerkonten aus einer OU wie folgt gelöscht:
Search-ADAccount –AccountDisabled -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False
# Alle Computer die sich seit 180 Tagen nicht am AD angemeldet haben werden mit dem folgenden Befehl angezeigt. Damit der Parameter AccountInactive verwendet werden kann, muss sich jedoch der Domänenfunktionsmodus mindestens auf der Ebene “Windows Server 2003” befinden:
Search-ADAccount -AccountInactive –Timespan 180 –ComputersOnly | Sort-Object | FT Name -A
Möchte man sich alle Computer aus einer bestimmten OU anzeigen, die sich seit 180 Tagen nicht mehr am AD angemeldet haben, so sieht der Befehl folgendermaßen aus:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A
Gelöscht werden die Computerkonten dann wie folgt:
Search-ADAccount -AccountInactive –Timespan 180 -ComputersOnly | Remove-ADComputer -Confirm:$False
Aus einer bestimmten OU werden die Computerkonten so entfernt:
Search-ADAccount -AccountInactive –Timespan 180 -Searchbase “OU=<OU>,DC=Domäne,DC=de” -ComputersOnly | Remove-ADComputer -Confirm:$False
# Alle Computer die seit dem 01.01.2010 inaktiv sind und sich nicht mehr am AD angemeldet haben, werden wie folgt angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Sort-Object | FT Name -A
Alle Computer aus einer bestimmten OU, die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, werden so angezeigt:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Sort-Object | FT Name -A
Alle Computerkonten die sich seit dem 01.01.2010 nicht mehr am AD angemeldet haben, lassen sich dann mit diesem Befehl löschen:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" –ComputersOnly | Remove-ADComputer -Confirm:$False
Die Computer einer bestimmten OU, die seit dem 01.01.2010 inaktiv sind, werden wie folgt gelöscht:
Search-ADAccount -AccountInactive -DateTime "01.01.2010" -Searchbase “OU=<OU>,DC=Domäne,DC=de” –ComputersOnly | Remove-ADComputer -Confirm:$False
Weitere Informationen:
Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
AD-PowerShell Befehle
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" –SearchScope OneLevel | ? {$_.systemFlags -band 5} | 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
Mit Windows Server 2008 führte Redmond den Read Only Domänencontroller (kurz RODC) ein. Der RODC der für Außenstellen die eine geringe bis keine physikalische Sicherheit den Servern bieten können konzipiert wurde, ist ein Domänencontroller (DC) der ausschließlich einen lesenden Zugriff auf die Active Directory-Domänendienste (AD DS) hat. Der RODC kann keine Änderungen in den AD DS und im AD-integrierten DNS vornehmen (RODNS). Clients oder Applikationen die einen Lesezugriff auf die AD DS benötigen erhalten Zugriff auf den RODC, während Clients oder Applikationen die einen Schreibvorgang in die AD DS durchführen wollen, diesen nicht auf dem RODC durchführen können sondern vom RODC an einen beschreibbaren DC verwiesen werden.
Der RODC besitzt ein vollständiges Replikat der AD-Datenbank, mit allen Attributen und Objekten die sich auch auf einem beschreibbaren DC befinden. Neben dem Unterschied das der RODC lediglich das Leserecht auf die AD-Datenbank hat, werden im Gegensatz zu einem beschreibbaren DC standardmäßig auch keine Benutzer- oder Computeranmeldeinformationen auf dem RODC gespeichert, außer das eigene Computerkonto sowie ein besonderes krbtgt-Konto für diesen RODC. Damit die Anmeldeinformationen der entsprechenden Benutzer-, Computer- und Dienstkonten auf dem RODC gespeichert werden können, muss das explizit in der Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) auf einem beschreibbaren DC gestattet werden, damit der RODC Authentifizierungs- und Dienstticketanforderungen eigenständig verarbeiten kann. Mit der Kennwortreplikationsrichtlinie wird bestimmt, ob die Anmeldeinformationen eines Benutzer- oder Computerkontos von einem beschreibbaren DC auf den RODC repliziert werden können.
Weitere Informationen zum RODC bekommt man in den folgenden beiden Artikeln:
Read-Only Domain Controller (RODC)
Die Installation eines RODC
Der gefilterte Attributsatz vom RODC
Diverse Applikationen könnten die AD-Domänendienste als Datenspeicher verwenden und sensible Daten darin speichern. Oder evtl. möchte man einfach nicht, dass bestimmte Daten von Benutzern (z.B. die Adressdaten oder die Personalnummer) auf einen RODC repliziert werden. Natürlich sollen diese kritischen Daten ebenfalls geschützt sein und nicht auf einem RODC gespeichert werden, falls der RODC kompromittiert, gestohlen oder die Sicherheit gefährdet wird. Und für genau diesen Anwendungstyp gibt es den gefilterten Attributsatz. Der gefilterte Attributsatz (auf Englisch: Filtered Attribute Set, kurz FAS) ist ein dynamischer Attributsatz, die nie auf einen RODC in der Gesamtstruktur repliziert werden da sie sensible oder vertrauliche Daten enthalten. Der gefilterte Attributsatz kann aber erst ab Windows Server 2008 konfiguriert werden.
Damit ein Attribut das wichtige Daten enthält nicht auf einen RODC repliziert wird, sollten die folgenden Schritte durchgeführt werden:
-
Das entsprechende Attribut sollte zu dem gefilterten Attributsatz (FAS) hinzugefügt werden. Damit wird verhindert, dass das Attribut an die RODCs in der Gesamtstruktur repliziert wird. Die Konfiguration des gefilterten Attributsatzes betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden!
-
Des Weiteren sollte das Attribut als vertraulich gekennzeichnet werden. Dies ist eine weitere Sicherheitseinstellung das konfiguriert werden sollte, wenn man nicht möchte das ein sensibles Attribut zu einem RODC repliziert werden soll! Ein Attribut wird als vertraulich gekennzeichnet, in dem die Leseberechtigung für das entsprechende Attribut für die Gruppe Authentifizierte Benutzer entfernt wird. Somit können diese Attribute von den Mitgliedern der Gruppe Authentifizierte Benutzer (das betrifft alle Benutzer- sowie Computerkonten, inklusive RODCs) nicht mehr gelesen werden. Auch die Konfiguration eines vertraulichen Attributs betrifft die Gesamtstruktur und kann nicht pro Domäne konfiguriert werden! Doch bevor ein Attribut als vertraulich gekennzeichnet wird, sollte der Vorgang in einer Testumgebung ausgiebig getestet werden!
-
Der Gesamtstrukturfunktionsmodus sollte sich aus Sicherheitsgründen mindestens auf Windows Server 2008 befinden. Denn die Attribute die sich im gefilterten Attributsatz befinden, werden nur von DCs die mindestens unter Windows Server 2008 laufen berücksichtigt! Windows Server 2003 DCs ignorieren die Konfiguration das ein Attribut geschützt ist und replizieren die Attribute die sich in dem gefilterten Attributsatz befinden trotzdem auf einen RODC. Die Domänenpartition in der sich der RODC befindet wird zwar erst ab einem beschreibbaren Windows Server 2008 DC auf den RODC repliziert, doch wenn auf dem RODC der globale Katalog (ROGC) aktiviert wird, baut sich eine eigene Replikationstopologie für die Replikation des GCs auf. Existieren in der Gesamtstruktur noch weitere Domänen mit Windows Server 2003 GCs in denen ebenfalls ein gefilterter Attributsatz konfiguriert wurde, ist es durchaus möglich das ein Windows Server 2003 GC den gefilterten Attributsatz aus seiner Domäne zu einem RODC repliziert.
-
Das Hinzufügen eines systemkritischen Attributs zum gefilterten Attributsatz ist nicht möglich! Ein systemkritisches Attribut ist ein Attribut, das z.B. für die ordnungsgemäße Funktion der AD DS oder für das Kerberos-Authentifizierungsprotokoll benötigt wird. Erst wenn in den Eigenschaften des entsprechenden Attributs im Attribut schemaFlagsEx, das aus einer Bitmaske besteht, das Flag FLAG_ATTR_IS_CRITICAL aktiviert ist, handelt es sich um ein systemkritisches Attribut. Dieses Flag existiert aber erst seit Windows Server 2008 und Windows Server 2003 DCs würden diese Einstellung ignorieren. Daher ist es umso mehr wichtig, dass sich nicht nur der Schemamaster auf mindestens einem Windows Server 2008 DC, sondern der Gesamtstrukturfunktionsmodus sich zwingend im Modus Windows Server 2008 oder höher befindet. Denn wäre der Schemamaster ein Windows Server 2003 DC, würde sich ein systemkritisches Attribut dem gefilterten Attributsatz scheinbar erfolgreich hinzufügen lassen. Aber da ein Windows Server 2003 DC die Konfiguration eines gefilterten Attributsatzes sowieso nicht kennt, sollte in einer Gesamtstruktur in der ein gefilterter Attributsatz genutzt wird ein Windows Server 2003 DC ohnehin nicht mehr existieren!
Die technische Umsetzung wie ein Attribut zum gefilterten Attributsatz hinzugefügt wird, findet wie folgt statt
-
Um ein Attribut zum gefilterten Attributsatz hinzuzufügen und somit die Replikation des entsprechenden Attributs zu einem RODC zu verwehren, muss im zu schützenden Attribut das zehnte Bit (also Bit 9) im searchFlags Attribut gesetzt werden. Im searchFlags Attribut kann unter anderem bestimmt werden, dass ein Attribut zum gefilterten Attributsatz hinzugefügt wird und das es vertraulich ist. Im searchFlags Attribut das aus einer Bitmaske besteht, muss im zehnten Bit als Wert in Hexadezimal 0x200 und in Dezimal 512 eingetragen werden. Anschließend wird das entsprechende Attribut zu keinem RODC in der Gesamtstruktur repliziert.
-
Im Attribut searchFlags liegt auch das Geheimnis, warum ein Windows Server 2003 DC die Attribute im gefilterten Attributsatz nicht berücksichtigt. Denn das zehnte Bit, also Bit 9 in searchFlags ist erst mit Windows Server 2008 und der Einführung des RODCs hinzugekommen.
-
Soll ein Attribut zum gefilterten Attributsatz hinzugefügt werden, sollte es auch als vertraulich deklariert werden. Als vertraulich deklariert und somit die Leseberechtigung den Authentifizierten Benutzern entzogen, wird ein Attribut durch das Setzen des achten Bits (Bit 7) ebenfalls im searchFlags Attribut. Dieses Flag kam mit Windows Server 2003 SP1 hinzu. Daher sollte darauf geachtet werden, dass wenn mit diesem Flag Attribute als vertraulich definiert werden, alle DCs in der Gesamtstruktur mindestens unter Windows Server 2003 SP1 installiert sind. Alle älteren Serverversionen ignorieren die Kennzeichnung als vertraulich! Im achten Bit des searchFlags Attributs muss als Wert in Hexadezimal 0x080 und in Dezimal 128 eingetragen werden.
-
Demnach erhält also searchFlags als Wert 640 in Dezimal (in Hexadezimal 0x280), damit zum einen das gewünschte Attribut zum gefilterten Attributsatz hinzugefügt und zum anderen, als vertraulich definiert wird. Trägt man als Wert 641 ein, wird zugleich das Attribut indiziert. Sollten bereits andere Flags im searchFlags Attribut konfiguriert sein, müssen die Werte addiert werden!
Den gefilterten Attributsatz abfragen
Standardmäßig befinden sich die folgenden Attribute ab Windows Server 2008 im gefilterten Attributsatz:
ms-FVE-KeyPackage
ms-FVE-RecoveryPassword
ms-PKI-AccountCredentials
ms-PKI-DPAPIMasterKeys
ms-PKI-RoamingTimeStamp
ms-TPM-OwnerInformation
Um die Attribute die sich im gefilterten Attributsatz befinden abzufragen, muss eine Abfrage nach dem Attribut searchFlags mit dem Wert 512 (das zehnte Bit in searchFlags) durchgeführt werden.
Die Abfrage mit der AD-PowerShell könnte wie folgt lauten
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties searchFlags | Where {$_.searchFlags -band 512} | Select Name,searchFlags | Sort Name | FT -Autosize -Wrap
Auch mit diesem AD-PowerShell Befehl lassen sich die gefilterten Attribute anzeigen:
Get-ADObject -LDAPFilter "(&(ObjectClass=attributeSchema)(searchFlags:1.2.840.113556.1.4.803:=512))" -SearchBase “CN=Schema,CN=Configuration,DC=Root-Domäne” -SearchScope Subtree | Select Name | Sort Name | FT -Autosize -Wrap
Mit LDP lässt sich der gefilterte Attributsatz folgendermaßen anzeigen
Nach dem man sich in LDP mit einem DC verbunden und an das AD gebindet hat, muss man unter Durchsuchen - Suchen als Basis-DN die Schemapartition und als Filter (searchFlags:1.2.840.113556.1.4.803:=512) angeben.
Weitere Informationen:
How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
Anhang D: Schritte zum Hinzufügen eines Attributs zu einem Attributsatz mit RODC-Filter
Search-Flags Attribute
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
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
Mit dem Kommandozeilentool Whoami das sich unter Windows 2000 im Ressource Kit befindet und ab Windows Server 2003 on Bord ist, lässt sich der komplette Inhalt des Access-Tokens des aktuell angemeldeten Benutzers anzeigen und exportieren. Im Accesss-Token ist die SID des Benutzers, die SIDs der SID-History (ab Windows Server 2003) und die SID's aller Gruppen in denen der angemeldete Benutzer innerhalb der Domäne direkt oder verschachtelt Mitglied ist enthalten. Whoami zeigt auch direkte oder verschachtelte domänenübergreifende universelle Gruppenmitgliedschaften an.
Führt man in einer CMD den Befehl Whoami /all > C:\Temp\Whoami.txt aus, wird solch eine Datei im angegebenen Pfad erstellt:
Die Hilfe zu Whoami lässt sich in gewohnter Windows-Manier mit Whoami /? anzeigen.
In welcher Situation ist es sinnvoll Whoami auszuführen?
Wenn ein Benutzer zu einer Gruppe hinzugefügt und dieser Gruppe die entsprechenden Rechte auf eine Ressource (Dateien, Drucker etc.) erteilt wurde, der Benutzer aber immer noch keinen Zugriff auf die Ressource hat, sollten zwei Punkte sichergestellt werden:
-
Hat sich der Benutzer nach dem hinzufügen zur Gruppen erneut an seinem Client angemeldet? Denn Gruppenmitgliedschaften werden nicht während einer Benutzersitzung ausgewertet, sondern nur bei der Anmeldung.
-
Hat sich der Benutzer bereits neu angemeldet, kann mit Whoami /all das Access-Token ausgewertet werden. Damit kann man überprüfen, ob sich der Benutzer auch tatsächlich in der entsprechenden Gruppe befindet.
Die Gruppenmitgliedschaften eines Benutzers mit der AD-PowerShell exportieren
Das Pendant zu Whoami stellt mit „Windows Server 2008 R2“ und Windows 7 die „Active Directory-PowerShell“ dar. Wird auf einem „Windows Server 2008 R2“ DC oder auf einem Windows 7 Client mit installiertem RSAT (Remote Server Administration Tools) das Cmdlet Get-ADAccountAuthorizationGroup ausgeführt, werden ebenfalls die direkten und verschachtelten Gruppenmitgliedschaften des angegebenen Benutzerkontos angezeigt. Domänenübergreifende „domänenlokale“ Gruppenmitgliedschaften werden nicht angezeigt, aber domänenübergreifende „universelle“ Gruppenmitgliedschaften schon. Domänenübergreifende globale Gruppen sind aus technischen Gründen ohnehin nicht möglich, da eine globale Gruppe nur Mitglieder aus der eigenen Domäne enthalten kann.
Ein DC kann „domänenlokale“, „globale“ und „universelle“ Gruppenmitgliedschaften eines Benutzers, nur innerhalb seiner Domäne ermitteln. Domänenlokale- und globale Gruppen werden zwar (neben den universellen Gruppen) auch in den globalen Katalog (GC) repliziert, allerdings nicht die Mitglieder dieser Gruppen! Deshalb findet auch bei Gruppenveränderungen in domänenlokalen und globalen Gruppen keine GC-Replikation statt. Da aber ein Benutzer Mitglied einer universellen Gruppe in unterschiedlichen Domänen sein kann, ist für die Abfrage von domänenübergreifenden universellen Gruppenmitgliedschaften ein GC notwendig. Denn nur der GC kennt die domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers, da das member Attribut von universellen Gruppen auf den GC repliziert wird. Wenn sich ein Benutzer in einer Gesamtstruktur mit mehreren Domänen an einer Domäne anmeldet, muss der DC einen GC kontaktieren um die universellen Gruppenmitgliedschaften abzurufen, in denen der Benutzer evtl. in anderen Domänen Mitglied ist. Oder es ist ab Windows Server 2003 das „zwischenspeichern der universellen Gruppenmitgliedschaften“ auf einem AD-Standort aktiviert.
In einer Multidomänen-Gesamtstruktur ist es zwingend erforderlich, dass zum Zeitpunkt der Abfrage mit dem Cmdlet Get-ADAccountAuthorizationGroup ein GC erreichbar ist. Denn schließlich wird für die Auswertung der domänenübergreifenden universellen Gruppenmitgliedschaften ein GC benötigt. Wenn zum Zeitpunkt der Abfrage kein GC erreicht werden kann schlägt die Abfrage fehl. Allerdings schlägt die Abfrage nur dann fehl, wenn es sich um eine Multidomänen-Gesamtstruktur handelt!
Die Option „Das zwischenspeichern von universellen Gruppenmitgliedschaften“ bringt nicht den gewünschten Erfolg. Die Abfrage mit dem Cmdlet in einer Gesamtstruktur mit mehreren Domänen schlägt auch in diesem Fall fehl.
Ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften ist für die Benutzeranmeldung nur in einer Gesamtstruktur mit mehreren Domänen notwendig. Handelt es sich um eine Einzeldomänen-Gesamtstruktur (Single-Domänen Forest), wird weder ein GC, noch das zwischenspeichern von universellen Gruppenmitgliedschaften benötigt. Es existieren ohnehin keine domänenübergreifenden Gruppenmitgliedschaften, wozu ein GC oder das zwischenspeichern von universellen Gruppenmitgliedschaften notwendig wäre.
In einer Einzeldomänen-Gesamtstruktur benötigt das Cmdlet deshalb auch keinen GC. Schließlich kennt in einer Einzeldomänen-Gesamtstruktur der DC alle Gruppenmitgliedschaften eines Benutzers. Auch der Benutzer kann sich in einer Einzeldomänen-Gesamtstruktur ohne einen GC erfolgreich an der Domäne anmelden.
In einer Windows Server 2003 oder Windows Server 2008 Umgebung lässt sich die AD-PowerShell ebenfalls z.B. von einem Windows 7 Client nutzen. Dazu muss jedoch das „AD MGS“ auf mindestens einem DC installiert werden:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Das Cmdlet Get-ADAccountAuthorizationGroup liest das Attribut tokenGroups des angegebenen Sicherheitsprinzipals aus. Dabei kann ein Benutzer oder Computer angegeben werden, aber keine Gruppe! Es werden zum einen alle direkten und verschachtelten Sicherheits-Gruppenmitgliedschaften (domänenlokale, globale und universelle Gruppen) innerhalb der Domäne und zum anderen die direkten und verschachtelten domänenübergreifenden universellen Gruppenmitgliedschaften eines Benutzers angezeigt. Es werden jedoch keine Verteilergruppen angezeigt!
Das mehrwertige Attribut tokenGroups ist zwar im Schema definiert, es enthält jedoch selbst keinen Wert. Die Attributwerte werden erst im Moment der Abfrage errechnet. Diese Art von Attribut bezeichnet man als Constructed Attribute oder auch Computed Attribute. Da das Attribut tokenGroups "constructed" ist, kann es nicht repliziert werden. Sein Wert wird auch nicht in den GC übertragen.
Siehe auch:
Die konstruierten Attribute abfragen
Die Gruppenmitgliedschaften eines Benutzers werden wie folgt in eine CSV-Datei exportiert:
Get-ADAccountAuthorizationGroup Yusuf | Export-CSV C:\Yusuf.csv -NoTypeInformation
Soll die Ausgabe bis auf wenige Attribute gekürzt werden, lautet der Befehl wie folgt:
Get-ADAccountAuthorizationGroup Yusuf | Select distinguishedName,sAMAccountName,GroupCategory,GroupScope,objectClass | Export-CSV C:\Yusuf.csv -NoTypeInformation
Die Ausgabe sieht wie folgt aus:
Die Hilfe zu dem Cmdlet lässt sich mit diesem Befehl anzeigen:
Get-Help Get-ADAccountAuthorizationGroup -Full
Die Gruppenmitgliedschaften eines Benutzers mit den ds*-Tools exportieren
Mit den beiden Kommandozeilentools dsquery und dsget die sich seit Windows Server 2003 "on Bord" befinden, lassen sich ebenfalls die Gruppenmitgliedschaften eines Benutzers exportieren.
Möchte man die direkten Gruppenmitgliedschaften eines Benutzers exportieren, so kann dazu der folgende Befehl verwendet werden:
dsquery user -samid <Benutzername> | dsget user -memberof > C:\Temp\Gruppenmitgliedschaften.txt
oder:
dsget user "DN des Benutzerobjekts" -memberof > C:\Temp\Gruppenmitgliedschaften.txt
Sollen hingegen auch die verschachtelten Gruppenmitgliedschaften angezeigt werden, dann gilt es diesen Befehl auszuführen:
dsget user "DN des Benutzerobjekts" -memberof -expand > C:\Temp\Gruppenmitgliedschaften.txt
bzw.
dsquery user -samid <Benutzername> | dsget user -memberof -expand > C:\Temp\Gruppenmitgliedschaften.txt
Hinweis: Unter Windows Server 2008 R2 und Windows 7 liefert dsget nicht die korrekten Daten.
Das lässt sich jedoch durch einen Hotfix beheben:
The "dsget user -memberof -expand" command returns incorrect results in Windows Server 2008 R2 and in Windows 7
Die Gruppenmitgliedschaften eines Benutzers mit "Net User" exportieren
Auch mit dem Kommandozeilentool NET kann man die Gruppenmitgliedschaften eines Benutzer wie folgt exportieren:
Net User <sAMAccountName> /Domain > C:\Temp\Gruppenmitgliedschaften.txt
Weitere Informationen:
Delegierte Berechtigungen im AD verstehen
Active Directory – Abfrage
AD-PowerShell Befehle
Token-Groups Attribute (Windows)
How to enumerate a user's security group membership using Visual Basic or Visual Basic Script
Im Active Directory-Schema sind verschiedene Arten von Attribute definiert. Die meisten davon sind in der Active Directory-Datenbank (NTDS.dit) gespeichert und können einen festen Wert enthalten.
Aber längst nicht alle Attribute für ein Objekt sind in der AD-Datenbank gespeichert. Diese Art von Attribut bezeichnet man als Constructed Attribute, auch bekannt als Computed Attribute.
Die Merkmale eines solchen Attributs sind:
-
Constructed Attribute, zu Deutsch „konstruierte Attribute“ sind zwar im Schema definiert, sie enthalten jedoch selbst keinen Wert. Die Attributwerte werden erst von einem Domänencontroller im Moment der LDAP-Anfrage gebildet.
-
Da diese Attribute "constructed" sind, können sie auch nicht repliziert werden. Die Werte können auch nicht in den globalen Katalog (GC) übertragen werden.
-
Wird eine Abfrage nach solch einem Attribut durchgeführt, bildet jeder DC eigenständig den Wert.
-
Ein Wert eines konstruierten Attributs kann nicht vergeben bzw. geschrieben werden. Diese Art von Attribut wird lediglich für eine gezielte Abfrage vom DC zusammengesetzt.
-
Konstruierte Attribute können in der Regel nicht für Abfragen verwendet werden (die Ausnahme stellt das Attribut aNR oder memberOf dar).
-
In einigen Fällen muss bei der Abfrage im Parameter -Scope die Option BASE angegeben werden, wie z.B. für das Attribut tokenGroups. Mit dieser Option wird auf ein einziges Objekt zugegriffen.
-
Eine Abfrage nach allen Objekten in einem Container, die ein konstruiertes Attribut der Objekte die sich in dem Container befinden anzeigt, bringt kein Ergebnis.
Ein konstruiertes Attribut wird durch das dritte Bit im System-Flags Attribut definiert. Verbindet man sich in LDP z.B. mit dem konstruierten Attribut CN=Token-Groups,CN=Schema,CN=Configuration,DC=Root-Domäne lässt sich das System-Flag folgendermaßen kontrollieren:
Die konstruierten Attribute einer Gesamtstruktur anzeigen
In der AD-Powershell
Get-ADObject -LDAPFilter “(&(objectClass=attributeSchema)(systemflags:1.2.840.113556.1.4.803:=4))” -Searchbase “CN=Schema,CN=Configuration,DC=Root-Domäne” | Select Name
Oder:
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties Systemflags | Where {$_.Systemflags -band 4} | Select Name
Mit LDP
-
Nach dem Starten von LDP gilt es zuerst eine Verbindung zu einem DC herzustellen.
-
Im zweiten Schritt muss man sich mit dem AD binden.
-
Anschließend gibt man im Suchfenster (unter Browse/Durchsuchen-Search/Suchen) als Basis-DN CN=Schema,CN=Configuration,DC=Root-Domäne ein und verwendet als Filter (&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4)).
-
Als Scope/Bereich gilt es One Level/Eine Ebene zu wählen.
-
Im Feld Attribute können dann die gewünschten Attribute angegeben werden.
In der Kommandozeile mit Dsquery, ab Windows Server 2003
dsquery * “CN=Schema,CN=Configuration,DC=Root-Domäne” -Scope Onelevel -attr Name -Filter "(&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4))"
Weitere Informationen:
AD-PowerShell Befehle
Microsoft Windows 2000 Scripting Guide - Operational Attributes
How to query Active Directory by using a bitwise filter
System-Flags Attribute
Es gibt verschiedene Möglichkeiten nach Computern die ein bestimmtes Betriebssystem sowie Service Pack installiert haben zu suchen. Die Attribute in denen diese Informationen enthalten sind wären: OperatingSystem, OperatingSystemVersion und OperatingSystemServicePack.
Es ist empfehlenswert das Attribut OperatingSystem bei der Abfrage zu verwenden und nicht nur(!) das Attribut OperatingSystemVersion. Denn die Versionsnummer lautet je nach Betriebssystem sowie Service Pack zwischen Servern und Clients gleich.
Z.B. lautet die Versionsnummer zwischen „Windows Vista SP1“ und „Windows Server 2008 SP1“ bei beiden Betriebssystemen „6.0 (6001)“. Auf einem „Windows Vista SP2“ und einem „Windows Server 2008 SP2“ lautet die Versionsnummer bei beiden Betriebssystemen „6.0 (6002)“. Oder zwischen einem „Windows Server 2008 R2“ und „Windows 7“ jeweils ohne Service Pack, lautet die Versionsnummer bei beiden Betriebssystemen gleich „6.1 (7600)“.
Hinweis: Die genaue Schreibweise welches Betriebssystem sowie Service Pack installiert ist, erfährt man neben der Versionsnummer in der MMC Active Directory-Benutzer und -Computer (dsa.msc). Dort werden die Informationen in den Eigenschaften eines Computerkontos im Reiter „Betriebssystem“ angezeigt.
In der AD-PowerShell unter Windows Server 2008 R2 und Windows 7
# Alle Computerobjekte zusätzlich mit den Werten Betriebssystem, Version und Service Pack anzeigen:
Get-ADComputer –Filter {Name –Like „*“} –Properties OperatingSystem, OperatingSystemVersion, OperatingSystemServicePack
# Es ist auch möglich die Ausgabe in eine CSV-Datei zu exportieren, um diese z.B. in Excel weiterzuverarbeiten. Exportieren lässt sich das Ergebnis dank der Pipeline-Fähigkeit der AD-PowerShell und dem Cmdlet Export-CSV wie folgt:
Get-ADComputer –Filter {Name –Like „*“} –Properties OperatingSystem, OperatingSystemVersion, OperatingSystemServicePack | Export-CSV Computer.csv
Nach Windows Server 2008 R2 suchen
# Alle Computerobjekte in der Domäne mit dem Betriebssystem „Windows Server 2008 R2“ (alle Versionen) anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server 2008 R2*“}
# Alle Computerobjekte in der Domäne nur mit dem Betriebssystem „Windows Server 2008 R2 Standard“ anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server 2008 R2 Standard“}
# Alle Computerobjekte mit dem Betriebssystem „Windows Server 2008 R2“ (alle Versionen) aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server 2008 R2*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle „Windows Server 2008 R2“ (alle Versionen) Computerobjekte mit einem bestimmten Service Pack aus einer OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server 2008 R2*“ –and OperatingSystemServicePack –eq „Service Pack x“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
Nach Windows Server 2008 suchen
# Um lediglich „Windows Server® 2008 Standard“ Computerobjekte mit Service Pack 1 einer Domäne anzuzeigen, kann dieser Befehl verwendet werden:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server® 2008 Standard“ –and OperatingSystemServicePack –eq „Service Pack 1“}
Hinweis: Das ® Symbol kann per Copy&Paste in die AD-PowerShell kopiert werden.
# Alle “Windows Server 2008” (alle Versionen) Computerobjekte, egal welches Service Pack installiert ist einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –Like „6.0*“}
# Alle “Windows Server 2008” (alle Versionen) Computerobjekte mit Service Pack 1 einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –eq „6.0 (6001)“}
# Alle „Windows Server 2008“ (alle Versionen) Computerobjekte mit „Service Pack 2“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server*“ –and OperatingSystemVersion –eq „6.0 (6002)“}
# Alle Computerobjekte mit dem Betriebssystem „Windows Server 2008“ (alle Versionen), egal welches Service Pack installiert ist aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –Like „6.0*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle „Windows Server® 2008 Standard“ Computerobjekte mit „Service Pack 2“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server® 2008 Standard“ –and OperatingSystemServicePack –eq „Service Pack 2“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle „Windows Server 2008“ (alle Versionen) Computerobjekte mit „Service Pack 1“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –eq „6.0 (6001)“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle „Windows Server 2008“ (alle Versionen) Computerobjekte mit „Service Pack 2“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server*“ –and OperatingSystemVersion –eq „6.0 (6002)“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
Nach Windows Server 2003 suchen
# Um lediglich „Windows Server 2003“ Computerobjekte einer Domäne anzuzeigen, kann dieser Befehl verwendet werden:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server 2003“}
Hinweis: Unter „Windows Server 2003“ unterscheidet Microsoft im Attribut OperatingSystem nicht zwischen „Standard“ oder „Enterprise“.
# Alle Computerobjekte mit „Windows Server 2003“ und dem „Service Pack 2“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server 2003“ –and OperatingSystemServicePack –eq „Service Pack 2“}
# Alle Computerobjekte mit dem Betriebssystem „Windows Server 2003“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Server 2003“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle Computerobjekte mit „Windows Server 2003“ und dem „Service Pack 2“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows Server 2003“ –and OperatingSystemServicePack –eq „Service Pack 2“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
Nach Windows 2000 Server oder Clients suchen
# Alle „Windows 2000“ Computerobjekte (Clients und Server) einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 2000*“}
# Alle „Windows 2000 Server“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Server“}
# Alle „Windows 2000 Server“ mit „Service Pack 4“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Server“ –and OperatingSystemServicePack –eq „Service Pack 4“}
# Alle „Windows 2000 Server“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Server“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle “Windows 2000 Server“ mit „Service Pack 4“ aus einer OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Server“ –and OperatingSystemServicePack –eq „Service Pack 4“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle „Windows 2000 Professional“ Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Professional“}
# Alle „Windows 2000 Professional“ mit „Service Pack 4“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Professional“ –and OperatingSystemServicePack –eq „Service Pack 4“}
# Alle „Windows 2000 Professional“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Professional“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle „Windows 2000 Professional“ mit „Service Pack 4“ aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 2000 Professional“ –and OperatingSystemServicePack –eq „Service Pack 4“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
Nach Windows XP suchen
# Alle Windows XP Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows XP*“}
# Alle Windows XP Clients mit „Service Pack 2“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows XP*“ –and OperatingSystemServicePack –eq „Service Pack 2“}
# Alle Windows XP Clients aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows XP*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle Windows XP Clients mit “Service Pack 3” aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows XP*“ –and OperatingSystemServicePack –eq „Service Pack 3“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
Nach Windows Vista suchen
# Alle Windows Vista Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista*“}
# Alle Windows Vista Clients mit „Service Pack 1“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista*“ –and OperatingSystemServicePack –eq „Service Pack 1“}
# Alle Windows Vista Ultimate Clients mit „Service Pack 1“ einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista* Ultimate“ –and OperatingSystemServicePack –eq „Service Pack 1“}
# Alle Windows Vista Clients aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle Windows Vista Clients mit “Service Pack 2” aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows Vista*“ –and OperatingSystemServicePack –eq „Service Pack 2“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
Nach Windows 7 suchen
# Alle Windows 7 Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 7*“}
# Alle Windows 7 Ultimate Clients einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –eq „Windows 7 Ultimate“}
# Alle Windows 7 Clients mit einem bestimmten Service Pack einer Domäne anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 7*“ –and OperatingSystemServicePack –eq „Service Pack x“}
# Alle Windows 7 Clients aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 7*“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
# Alle Windows 7 Clients mit “Service Pack 2” aus einer bestimmten OU anzeigen:
Get-ADComputer –Filter {OperatingSystem –Like „Windows 7*“ –and OperatingSystemServicePack –eq „Service Pack x“} –SearchBase „OU=<OU>,DC=Domäne,DC=de“ –SearchScope OneLevel
CSVDE
In der Kommandozeile lassen sich die gewünschten Informationen mit CSVDE exportieren. Der Vorteil des Exports mit CSVDE ist, das man die exportierte CSV-Datei mit Excel öffnen und weiterverarbeiten kann.
Windows Server 2008 R2 exportieren
# Alle Windows Server 2008 R2 aus der Domäne exportieren:
Csvde –f Win2008R2.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Server 2008 R2 mit einem bestimmten Service Pack aus der Domäne exportieren:
Csvde –f Win2008R2.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" -l name,dNSHostName
# Alle Windows Server 2008 R2 aus einer OU exportieren:
Csvde -f Win2008R2.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Server 2008 R2 mit einem bestimmten Service Pack aus einer OU exportieren:
Csvde –f Win2008R2.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" -l name,dNSHostName
Windows Server 2008 exportieren
# Alle Windows Server 2008 (und nicht “Windows Server 2008 R2”) aus der Domäne exportieren:
Csvde –f Win2008.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Server 2008 mit Service Pack 1 aus der Domäne exportieren:
Csvde –f Win2008.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)(!OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName
# Alle Windows Server 2008 aus einer OU exportieren:
Csvde -f Win2008.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Server 2008 mit Service Pack 1 aus einer OU exportieren:
Csvde –f Win2008.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)(!OperatingSystem=Windows Server 2008 R2*))" -l name,dNSHostName
Windows Server 2003 exportieren
# Alle Windows Server 2003 aus der Domäne exportieren:
Csvde –f Win2003.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Server 2003 mit Service Pack 1 aus der Domäne exportieren:
Csvde –f Win2003.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" -l name,dNSHostName
# Alle Windows Server 2003 aus einer OU exportieren:
Csvde -f Win2003.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Server 2003 mit Service Pack 1 aus einer OU exportieren:
Csvde –f Win2003.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" -l name,dNSHostName
Windows 2000 Clients und Server exportieren
# Alle Windows 2000 Clients und Server aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000*))" -l name,dNSHostName,OperatingSystemServicePack
# Nur Windows 2000 Clients und Server mit Service Pack 3 aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000*)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName
# Alle Windows 2000 Clients und Server aus einer OU exportieren:
Csvde –f Win2000.csv –s <DC> –d "OU=<OU>,DC=Domäne,DC=TLD" –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000*))" -l name,dNSHostName,OperatingSystemServicePack
# Nur Windows 2000 Clients und Server mit Service Pack 3 aus einer OU exportieren:
Csvde –f Win2000.csv –s <DC> –d "OU=<OU>,DC=Domäne,DC=TLD" –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000*)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName
# Nur Windows 2000 Server aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows 2000 Server mit Service Pack 3 aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName
# Alle Windows 2000 Server aus einer OU exportieren:
Csvde -f Win2000.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows 2000 Server mit Service Pack 3 aus einer OU exportieren:
Csvde –f Win2000.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName
# Nur Windows 2000 Clients aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional))" -l name,dNSHostName,OperatingSystemServicePack
# Nur Windows 2000 Clients mit Service Pack 3 aus der Domäne exportieren:
Csvde –f Win2000.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName
# Alle Windows 2000 Clients aus einer OU exportieren:
Csvde -f Win2000.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows 2000 Clients mit Service Pack 3 aus einer OU exportieren:
Csvde –f Win2000.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 3))" -l name,dNSHostName
Windows XP Clients exportieren
# Alle Windows XP Clients aus der Domäne exportieren:
Csvde –f WinXP.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows XP*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows XP Clients mit einem bestimmten Service Pack aus der Domäne exportieren:
Csvde -f WinXP.csv -s <DC> -r "(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" -l name,dNSHostName
# Alle Windows XP Clients aus einer OU exportieren:
Csvde -f WinXP.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows XP*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows XP Clients mit Service Pack 2 aus einer OU exportieren:
Csvde –f WinXP.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" -l name,dNSHostName
Windows Vista Clients exportieren
# Alle Windows Vista Clients aus der Domäne exportieren:
Csvde –f Vista.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Vista*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Vista Ultimate Clients aus der Domäne exportieren:
Csvde –f Vista.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Vista* Ultimate))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Vista Clients mit Service Pack 1 aus der Domäne exportieren:
Csvde –f Vista.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" -l name,dNSHostName
# Alle Windows Vista Clients aus einer OU exportieren:
Csvde -f Vista.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows Vista*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows Vista Clients mit Service Pack 1 aus einer OU exportieren:
Csvde –f Vista.csv –s <DC> -d "OU=<OU>,DC=Domäne,DC=de" –r "(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" -l name,dNSHostName
Windows 7 Clients exportieren
# Alle Windows 7 Clients aus der Domäne exportieren:
Csvde –f Win7.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 7*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows 7 Ultimate Clients aus der Domäne exportieren:
Csvde –f Win7.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 7 Ultimate))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows 7 Clients mit einem bestimmten Service Pack aus der Domäne exportieren:
Csvde –f Win7.csv –s <DC> –r "(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" -l name,dNSHostName
# Alle Windows 7 Clients aus einer OU exportieren:
Csvde -f Win7.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows 7*))" -l name,dNSHostName,OperatingSystemServicePack
# Alle Windows 7 Clients mit einem bestimmten Service Pack aus einer OU exportieren:
Csvde -f Win7.csv -s <DC> -d "OU=<OU>,DC=Domäne,DC=de" -r "(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" -l name,dNSHostName
REPADMIN
Die Suche nach Computerobjekten lässt sich auch mit REPADMIN durchführen. Unter Windows 2000 und Windows Server 2003 müssen vorher die Windows Support Tools installiert werden. Ab Windows Server 2008 ist das REPADMIN bereits „on Bord“.
# Das Betriebsystem sowie das Service Pack aller DCs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(primaryGroupID=516))" /subtree /atts:name,OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack
# Das Betriebssystem sowie das Service Pack aller Clients und Mitgliedsserver einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(primaryGroupID=515))" /subtree /atts:name,OperatingSystem,OperatingSystemVersion,OperatingSystemServicePack
Windows Server 2008 R2
# Alle Windows Server 2008 R2 mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows Server 2008 R2 mit einem bestimmten SP einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" /subtree /atts:name
# Sollen die Computerobjekte aus einer bestimmten OU angezeigt werden, so muss anstelle von „ncobj:domain:“ der Distinguished Name der entsprechenden OU angegeben werden. Mit dem folgenden Befehl werden alle Windows Server 2008 R2 mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows Server 2008 R2 mit einem bestimmten SP aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" /subtree /atts:name
Windows Server 2008
# Alle Windows Server 2008 mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
Oder:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0*))" /subtree /atts:name,OperatingSystemServicePack
# Alle Windows Server 2008 mit Service Pack 1 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)(!OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name
# Alle Windows Server 2008 mit ihren installierten SPs aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows Server 2008 mit Service Pack 1 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)(!OperatingSystem=Windows Server 2008 R2*))" /subtree /atts:name
Windows Server 2003
# Alle Windows Server 2003 mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows Server 2003 mit Service Pack 1 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" /subtree /atts:name
# Mit dem folgenden Befehl werden alle Windows Server 2003 mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows Server 2003 mit Service Pack 1 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" /subtree /atts:name
Windows 2000 Server
# Alle Windows 2000 Server mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows 2000 Server mit Service Pack 3 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3))" /subtree /atts:name
# Mit dem folgenden Befehl werden alle Windows 2000 Server mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows 2000 Server mit Service Pack 4 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 4))" /subtree /atts:name
Windows 7
# Alle Windows 7 Clients mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows 7 Enterprise Clients mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7 Enterprise))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows 7 Clients mit einem bestimmten Service Pack einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" /subtree /atts:name
# Mit dem folgenden Befehl werden alle Windows 7 Clients mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7*))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows 7 Clients mit einem bestimmten Service Pack aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" /subtree /atts:name
Windows Vista
# Alle Windows Vista Clients mit ihren installierten SPs einer Domäne anzeigen
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Vista*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows Vista Clients mit Service Pack 1 einer Domäne anzeigen
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" /subtree /atts:name
# Mit dem folgenden Befehl werden alle Vista Clients aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows Vista*))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows Vista Clients mit Service Pack 1 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" /subtree /atts:name
Windows XP
# Alle Windows XP Clients mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows XP*))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows XP Clients mit Service Pack 2 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" /subtree /atts:name
# Mit dem folgenden Befehl werden alle Windows XP Clients mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows XP*))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows XP Clients mit Service Pack 2 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" /subtree /atts:name
Windows 2000 Professional
# Alle Windows 2000 Clients mit ihren installierten SPs einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional))" /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows 2000 Clients mit Service Pack 4 einer Domäne anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> ncobj:domain: "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 4))" /subtree /atts:name
# Mit dem folgenden Befehl werden alle Windows 2000 Clients mit ihren installierten SPs aus einer OU angezeigt:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ „/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional))“ /subtree /atts:name,OperatingSystemVersion,OperatingSystemServicePack
# Alle Windows 2000 Clients mit Service Pack 4 aus einer OU anzeigen:
Repadmin /showattr <DNS-Domänenname oder DC> „OU=<OU>,DC=Domäne,DC=de“ "/filter:(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 4))" /subtree /atts:name
DSQUERY
Mit dsquery das erst ab Windows Server 2003 “on Bord” ist, lassen sich ebenfalls die gesuchten Computerobjekte ausfindig machen und zeitgleich auch exportieren.
Windows Server 2008 R2
# Alle Windows Server 2008 R2 einer Domäne exportieren:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0 > C:\dsquery.txt
# Alle Windows Server 2008 R2 mit einem bestimmten Service Pack einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" -attr name distinguishedname –Limit 0
# Alle Windows Server 2008 R2 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server 2008 R2*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0
# Alle Windows Server 2008 R2 mit einem bestimmten Serice Pack aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x))" -attr name distinguishedName -Limit 0
Windows Server 2008
# Alle Windows Server 2008 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0
# Alle Windows Server 2008 mit Service Pack 1 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0 (6001)))" -attr name distinguishedname –Limit 0
# Alle Windows Server 2008 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0
# Alle Windows Server 2008 mit Serice Pack 1 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0 (6001)))" -attr name distinguishedName -Limit 0
Windows Server 2003
# Alle Windows Server 2003 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003))" -attr name OperatingSystemServicePack distinguishedname –Limit 0
# Alle Windows Server 2003 mit Service Pack 1 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))" -attr name distinguishedname –Limit 0
# Alle Windows Server 2003 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server 2003))" -attr name OperatingSystemServicePack distinguishedName -Limit 0
# Alle Windows Server 2003 mit Serice Pack 1 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Server 2003) (OperatingSystemServicePack=Service Pack 1))" -attr name distinguishedName -Limit 0
Windows 2000
# Alle Windows 2000 Server und Clients einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 2000*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0
# Alle Windows 2000 Server und Clients mit dem Service Pack 3 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 2000*)(OperatingSystemServicePack=Service Pack 3))" -attr name distinguishedname –Limit 0
# Alle Windows 2000 Server und Clients aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows 2000*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0
# Nur Windows 2000 Server mit dem Service Pack 3 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3))" -attr name distinguishedname –Limit 0
# Nur Windows 2000 Clients mit dem Service Pack 3 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 3))" -attr name distinguishedname –Limit 0
Windows XP
# Alle Windows XP Clients einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows XP*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0
# Alle Windows XP Clients mit Service Pack 2 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" -attr name distinguishedname –Limit 0
# Alle Windows XP Clients aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows XP*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0
# Alle Windows XP Clients mit Serice Pack 2 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))" -attr name distinguishedName -Limit 0
Windows Vista
# Alle Windows Vista Clients einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Vista*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0
# Alle Windows Vista Clients mit Service Pack 1 einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" -attr name distinguishedname –Limit 0
# Alle Windows Vista Clients aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Vista*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0
# Alle Windows Vista Clients mit Serice Pack 1 aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))" -attr name distinguishedName -Limit 0
Windows 7
# Alle Windows 7 Clients einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 7*))" -attr name OperatingSystemServicePack distinguishedname –Limit 0
# Alle Windows 7 Clients mit einem bestimmten Service Pack einer Domäne anzeigen:
dsquery * domainroot -Filter "(&(objectcategory=computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" -attr name distinguishedname –Limit 0
# Alle Windows 7 Clients aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows 7*))" -attr name OperatingSystemServicePack distinguishedName -Limit 0
# Alle Windows 7 Clients mit einem bestimmten Serice Pack aus einer OU anzeigen:
dsquery * “OU=<OU>,DC=Domäne,DC=de” -Filter “(&(objectCategory=Computer)(OperatingSystem=Windows 7*)(OperatingSystemServicePack=Service Pack x))" -attr name distinguishedName -Limit 0
Die Active Directory-Suche
Auch in der grafischen Oberfläche kann man nach den gewünschten Computerobjekten suchen. In der MMC Active Directory-Benutzer und -Computer klickt man mit rechts entweder auf den Domänennamen um über alle Container hinweg zu suchen oder auf eine OU, um lediglich in dieser OU zu suchen. Danach ruft man mit einem Klick auf Suchen… das Suchfenster auf.
Im Übrigen ist es auch möglich die AD-Suche direkt aufzurufen, ohne die MMC Active Directory-Benutzer und -Computer zu öffnen. Dazu gilt es mit einem Rechtsklick auf einer freien Fläche auf dem Desktop die Option Neu und anschließend Verknüpfung auszuwählen. Als "Speicherort des Elements" gilt es diesen Eintrag hinzuzufügen: %windir%\System32\rundll32.exe dsquery.dll,OpenQueryWindow (<-- ACHTUNG: Die Schreibweise von "OpenQueryWindow" ist - warum auch immer - "case sensitive"). Im nächsten Schritt gilt es lediglich noch einen Namen für die Verknüpfung zu vergeben und fertig ist die direkte Verknüpfung zur AD-Suche.
Im Suchfenster wählt man als erstes im Feld „Suchen:“ den Eintrag Computer aus. Danach wählt man im Reiter Erweitert mit einem Klick auf Feld z.B. die Option Betriebssystem aus. Anschließend behält man im Feld Bedingung: die Option „Beginnt mit“ bei und gibt im Feld Wert: das gesuchte Betriebssystem ein.
Als Werte könnte man z.B. folgendes eintragen:
- Windows Server 2008 R2*
- Windows Server* 2008*
- Windows Server 2003
- Windows 2000 Server
- Windows 7*
- Windows Vista*
- Windows XP*
- Windows 2000 Professional
Ist die AD-Suche abgeschlossen, sollte man unter Ansicht – Spalten auswählen… die Spalte „Veröffentlicht auf“ hinzufügen. Denn dadurch lässt sich der Container in dem sich das jeweilige Computerobjekt befindet ableiten.
Der Nachteil bei der AD-Suche ist, dass die Ergebnisse nicht exportiert werden können. Wer darauf Wert legt, sollte seine Suche über die „gespeicherte Abfrage“ durchführen.
Die gespeicherte Abfrage
Ab Windows Server 2003 besteht die Möglichkeit die Suche nach bestimmten Computerobjekten, in der MMC Active Directory-Benutzer und -Computer durch eine „gespeichert Abfrage“ durchzuführen.
Weitere Details über die gespeicherten Abfragen erhält man im folgenden Artikel:
Gespeicherte Abfragen
Neben der gleichen Suchmöglichkeit wie bei der AD-Suche, kann man hier eine benutzerdefinierte Suche in der Domäne durchführen. Bei der benutzerdefinierten Suche könnte man z.B. solche LDAP-Filter verwenden:
- (objectCategory=computer)(OperatingSystem=Windows Server 2008 R2*)
- (objectCategory=computer)(OperatingSystem=Windows Server 2008 R2*)(OperatingSystemServicePack=Service Pack x)
- (objectCategory=computer)(OperatingSystem=Windows Server* 2008*)(OperatingSystemServicePack=Service Pack 1)
- (objectCategory=computer)(OperatingSystem=Windows Server*)(OperatingSystemVersion=6.0*)
- (objectCategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1)
- (objectCategory=computer)(OperatingSystem=Windows 2000 Server)(OperatingSystemServicePack=Service Pack 3)
- (objectCategory=computer)(OperatingSystem=Windows 7*)
- (objectCategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1)
- (objectCategory=computer)(OperatingSystem=Windows XP*)
- (objectCategory=computer)(OperatingSystem=Windows 2000 Professional)(OperatingSystemServicePack=Service Pack 3)
Ist die Suche abgeschlossen, lässt sich das Ergebnis im Menü über Aktion -> Liste exportieren in eine TXT- oder CSV-Datei speichern.
Weitere Informationen:
AD-PowerShell Befehle
Wie finde ich heraus wo sich ein Objekt befindet?
In kleineren AD-Umgebungen wie sie in „kleineren und mittleren Unternehmen (kurz KMU)“ existieren, weiß der Administrator in welchen Containern im AD sich die entsprechenden AD-Objekte befinden. Doch in größeren und verteilten AD-Umgebungen mit mehreren AD-Administratoren lässt sich das nicht jederzeit sagen.
Um ein AD-Objekt ausfindig zu machen gibt es je nach Betriebssystem verschiedene Möglichkeiten den Distinguished Name (DN) und somit den LDAP-Pfad des gesuchten Objekts mit Bordmitteln anzuzeigen. Der DN gibt dabei den Speicherort des Objekts im AD an.
Die Active Directory Suche in der MMC Active Directory-Benutzer und -Computer (dsa.msc)
Bei der AD-Suche hat man zwei Möglichkeiten den Speicherort des Objekts herauszufinden.
Erste Möglichkeit
In der MMC dsa.msc ruft man mit einem Rechtsklick auf den Domänennamen das Suchfenster auf und gibt z.B. den Common Name (CN) oder sAMAccountName (falls bekannt) des Objekts ein. Es reichen bereits die Anfangsbuchstaben aus wie z.B. „Yus“, um Objekte aufzufinden die mit "Yus" anfangen, da bei der Suche die Ambiguous Name Resolution (ANR) angewendet wird. Die ANR durchforstet bei der Suche unter anderem die folgenden Felder: Vorname, Nachname, Anzeigename sowie den Benutzeranmeldename (Prä-Windows 2000).
Ist die Suche beendet, gilt es im Suchfenster unter Ansicht - Spalten auswählen… eine weitere Spalte hinzuzufügen. Der Name dieser Spalte unterscheidet sich jedoch zwischen den Betriebssystemen.
Unter Windows 2000 und Windows Server 2003 heißt die Spalte X500-definierter Name, unter Windows Server 2008 Definierter Name und unter Windows Server 2008 R2 Distinguished Name. Nach dem hinzufügen der Spalte erscheint im Suchergebnis der DN des Objekts.
Es ist auch möglich die AD-Suche direkt aufzurufen, ohne die MMC Active Directory-Benutzer und -Computer zu öffnen. Dazu gilt es mit einem Rechtsklick auf einer freien Fläche auf dem Desktop die Option Neu und anschließend Verknüpfung auszuwählen. Als "Speicherort des Elements" gilt es diesen Eintrag hinzuzufügen: %windir%\System32\rundll32.exe dsquery.dll,OpenQueryWindow (<-- ACHTUNG: Die Schreibweise von "OpenQueryWindow" ist "case sensitive"). Im nächsten Schritt gilt es lediglich noch einen Namen für die Verknüpfung zu vergeben und fertig ist die direkte Verknüpfung zur AD-Suche.
Zweite Möglichkeit
Im ersten Schritt ist in der MMC dsa.msc unter Ansicht die Option Erweiterte Funktionen zu aktivieren. Danach gilt es wie in der ersten Möglichkeit im Suchfenster nach dem gewünschten Objekt zu suchen. Ist die Suche beendet, ruft man im zweiten Schritt mit einem Doppelklick auf das Objekt die Eigenschaften auf und wechselt zum Reiter Objekt. Dort wird der kanonische Name des Objekts angezeigt. Liest man diesen in umgekehrter Reihenfolge (von rechts nach links), so lässt sich der DN des Objekts ableiten.
Das Kommandozeilentool: DSQUERY
Mit dsquery das erst ab Windows Server 2003 „on Bord“ zur Verfügung steht, lässt sich der DN eines Objekts wie folgt anzeigen:
dsquery computer -name <CN des Computers>
dsquery user -name <CN des Benutzers>
dsquery group -name <CN der Gruppe>
dsquery contact -name <CN des Kontaktobjekts>
Auch bei dsquery können Wildcards verwendet werden.
Lautet der Common Name (CN) eines Benutzerobjekts “Yusuf Dikmenoglu”, so kann der Befehl folgendermaßen aussehen:
dsquery user -name *us*f*
Standardmäßig durchsucht das dsquery die Domäne in der man den Befehl ausführt. Gibt man den folgenden Befehl an, so durchsucht das dsquery mit Hilfe eines globalen Katalogs (GC) nach dem gewünschten Objekt innerhalb der Gesamtstruktur, also über alle Domänen hinweg:
dsquery user Forestroot -name Yusuf*
Wenn der sAMAccountName des gesuchten Benutzerobjekts bekannt ist (Benutzeranmeldename Prä-Windows 2000), lautet die Abfrage wie folgt:
dsquery user -samid Yusuf
Ist der userPrincipalName (UPN) eines Benutzerkontos bekannt, so gilt es diese Abfrage durchzuführen um den DN anzuzeigen:
dsquery user -upn Yusuf@blog.dikmenoglu.de
Die AD-PowerShell unter Windows Server 2008 R2
In der AD-PowerShell die ab Windows Server 2008 R2 on Bord ist, lässt sich der DN des gesuchten Objekts mit diesem Befehl anzeigen:
Get-ADComputer <Computername>
Get-ADUser <sAMAccountName>
Get-ADGroup <Gruppe>
Die AD-PowerShell steht auch auf einem Windows 7 zur Verfügung, aber erst nach der Installation der Remote Server Administration Tools (RSAT).
Das Active Directory-Verwaltungscenter unter Windows Server 2008 R2
Führt man im AD-Verwaltungscenter (ADAC) eine globale Suche nach einem Objekt durch, wird im Suchergebnis ebenfalls direkt der DN mit angezeigt. Auch im ADAC kann man eine Suche mit Hilfe eines GC durchführen und so nach einem Objekt innerhalb der Gesamtstruktur suchen.
Weitere Informationen:
Gespeicherte Abfragen
Active Directory - Abfrage
AD-PowerShell Befehle
Das Active Directory-Verwaltungscenter
Die Active Directory-Attribute hinter den Feldnamen
Ambiguous Name Resolution for LDAP in Windows 2000
Remoteserver-Verwaltungstools für Windows 7
Neben den grafischen Werkzeugen wie z.B. Active Directory-Benutzer und -Computer (dsa.msc), Active Directory-Standorte und -Dienste (dssite.msc) etc. oder den ds*-Kommandozeilentools (dsadd, dsget, dsquery…) steht im Windows Server 2008 R2 erstmals die AD-PowerShell zur Verfügung. In der AD-PowerShell werden dem Administrator 76 AD-Cmdlets mit geliefert.
Die AD-PowerShell ist nicht von der RPC- oder LDAP-Schnittstelle abhängig, sondern von dem Dienst Active Directory-Webdienste (ADWS) (wie auch das AD-Verwaltungscenter), das erst ab Windows Server 2008 R2 zur Verfügung steht.
Mit der AD-PowerShell lässt sich eine Active Directory-Umgebung unter Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 administrieren. Des Weiteren kann man AD LDS-Instanzen oder „configuration sets“ und AD-Snapshots mit der AD-PowerShell verwalten.
Doch bevor eine Windows Server 2003 oder Windows Server 2008 Domäne mit der AD-PowerShell von einem Windows 7 Client oder Windows Server 2008 R2 worauf jeweils das RSAT installiert ist, administriert werden kann, muss vorher das Active Directory Management Gateway Service (AD MGS) auf einem Windows Server 2003 DC oder Windows Server 2008 DC installiert werden. Das AD MGS ist das ADWS für Windows Server 2003 und Windows Server 2008.
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Zu finden ist die AD-PowerShell unter Start – Verwaltung – Active Directory Module for Windows PowerShell. Für die Freunde der grafischen Oberfläche hat Redmond ebenfalls vorgesorgt. Im Server Manager existiert das Feature Windows PowerShell Integrated Scripting Environment (ISE), mit dem dem Administrator eine PowerShell-Entwicklungsumgebung zur Verfügung steht. Nach der Installation steht die Powershell-Entwicklungsumgebung unter Start - Alle Programme - Zubehör - Windows Powershell zur Verfügung. Doch bevor mit dem ISE auf das AD zugegriffen werden kann, müssen vorher mit dem Befehl import-module activedirectory die AD-Cmdlets geladen werden. Anschließend kann der Administrator im ISE seine AD-PowerShell-Skripte erstellen, die mit der Endung „.ps1“ zu speichern sind.
Dadurch das die AD-PowerShell pipeline-fähig ist und sich so verschiedene Cmdlets miteinander verbinden lassen, stellt die AD-PowerShell ein mächtiges Werkzeug dar. Sei es zur täglichen Administration oder bei immer wiederkehrenden Automatisierungsaufgaben, die AD-PowerShell eignet sich in jedem Fall. Mit der AD-PowerShell können in einer einzigen Konsole viele Aufgaben durchgeführt werden, wozu in früheren Betriebssystemversionen mehrere Werkzeuge bzw. MMCs notwendig waren. Mit der AD-PowerShell ist es auch möglich, wie in einer Kommandozeile (CMD) in der man durch die Verzeichnisse navigiert, durch das AD zu navigieren. In der AD-PowerShell wechselt man mit cd AD: in die AD-Ebene. Dort kann man dann mit dem Befehl cd „DC=blog,DC=dikmenoglu,DC=de“ auf die Domänenpartitionsebene wechseln und mit dir sich die Container die sich darunter befinden anzeigen lassen. Natürlich kann man auch auf jede andere Verzeichnispartition wie z.B. die Konfigurations- oder Schemapartition durch die Angabe des Distinguished Names (DN) der entsprechenden Verzeichnispartition wechseln.
Auch kann man auf diesem Weg z.B. eine neue OU erstellen. Mit dem Befehl md „OU=Neue OU“ kann man auf der Ebene auf der man sich befindet eine neue OU erstellen.
Wenn man in der AD-PowerShell Skripte einsetzen möchte, wird das unter Umständen fehlschlagen. Denn das Ausführen von Skripten wird von der Ausführungsrichtlinie, der sogenannten Execution Policy bestimmt. Damit Skripte ausgeführt werden dürfen, muss mit dem PowerShell-Befehl Set-ExecutionPolicy Remotesigned die Ausführungsrichtlinie angepasst werden. Mit dem Parameter Remotesigned wird definiert, dass Skripte die aus dem Internet oder von anderen öffentlichen Orten stammen, signiert sein müssen. Jedoch dürfen lokal gespeicherte Skripte ohne Signatur ausgeführt werden.
Weitere Informationen zum digitalen signieren von Skripten werden im folgenden Artikel beschrieben:
http://technet.microsoft.com/en-us/magazine/2008.04.powershell.aspx?pr=blog
Weitere Informationen zur AD-PowerShell:
Die AD-Powershell im Windows Server 2008 R2
Die AD-Commandlets (kurz Cmdlets) die zur Verfügung stehen
Die Cmdlets sind durch ihre Namen weitestgehend selbsterklärend. Die unten aufgeführten Cmdlets kann man sich mit dem Befehl get-command anzeigen lassen, wie z.B. get-command get-ad*, get-command new-ad* oder get-command remove-ad* usw. Alle AD-Cmdlets werden mit diesem Befehl angezeigt: Get-Command *-ad*
Eine ausführliche und detaillierte Hilfe zu den folgenden Cmdlets lässt sich wie folgt anzeigen:
- Get-Help <Cmdlet Name> -Detailed (z.B. Get-Help Search-ADAccount -Detailed)
- Get-Help <Cmdlet Name> -Examples
- Get-Help <Cmdlet Name> -Full
Die Hilfe zu den Filtermöglichkeiten lässt sich mit diesem Befehl aufrufen:
get-help about_ActiveDirectory_Filter
AD-Objekte abrufen (22 Cmdlets)
- Get-ADAccountAuthorizationGroup
- Get-ADAccountResultantPasswordReplicationPolicy
- Get-ADComputer
- Get-ADComputerServiceAccount
- Get-ADDefaultDomainPasswordPolicy
- Get-ADDomain
- Get-ADDomainController
- Get-ADDomainControllerPasswordReplicationPolicy
- Get-ADDomainControllerPasswordReplicationPolicyUsage
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADForest
- Get-ADGroup
- Get-ADGroupMember
- Get-ADObject
- Get-ADOptionalFeature
- Get-ADOrganizationalUnit
- Get-ADPrincipalGroupMembership
- Get-ADRootDSE
- Get-ADServiceAccount
- Get-ADUser
- Get-ADUserResultantPasswordPolicy
AD-Objekte erstellen (7 Cmdlets)
- New-ADComputer
- New-ADFineGrainedPasswordPolicy
- New-ADGroup
- New-ADObject
- New-ADOrganizationalUnit
- New-ADServiceAccount
- New-ADUser
AD-Objekte entfernen (12 Cmdlets)
- Remove-ADComputer
- Remove-ADComputerServiceAccount
- Remove-ADDomainControllerPasswordReplicationPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Remove-ADGroup
- Remove-ADGroupMember
- Remove-ADObject
- Remove-ADOrganizationalUnit
- Remove-ADPrincipalGroupMembership
- Remove-ADServiceAccount
- Remove-ADUser
AD-Schreibvorgänge durchführen (15 Cmdlets)
- Set-ADAccountControl
- Set-ADAccountExpiration
- Set-ADAccountPassword
- Set-ADComputer
- Set-ADDefaultDomainPasswordPolicy
- Set-ADDomain
- Set-ADDomainMode
- Set-ADFineGrainedPasswordPolicy
- Set-ADForest
- Set-ADForestMode
- Set-ADGroup
- Set-ADObject
- Set-ADOrganizationalUnit
- Set-ADServiceAccount
- Set-ADUser
AD-Objekte hinzufügen (5 Cmdlets)
- Add-ADComputerServiceAccount
- Add-ADDomainControllerPasswordReplicationPolicy
- Add-ADFineGrainedPasswordPolicySubject
- Add-ADGroupMember
- Add-ADPrincipalGroupMembership
AD-Objekte und optionale AD-Funktionen deaktivieren (2 Cmdlets)
- Disable-ADAccount
- Disable-ADOptionalFeature
AD-Objekte und optionale AD-Funktionen aktivieren (2 Cmdlets)
- Enable-ADAccount
- Enable-ADOptionalFeature
AD-Objekte verschieben (3 Cmdlets)
- Move-ADDirectoryServer
- Move-ADDirectoryServerOperationMasterRole
- Move-ADObject
AD-Objekte umbenennen (1 Cmdlet)
- Rename-ADObject
AD-Dienstkontenkennwörter zurücksetzen (1 Cmdlet)
- Reset-ADServiceAccountPassword
AD-Objekte wiederherstellen (1 Cmdlet)
- Restore-ADObject
AD-Objekte suchen (1 Cmdlet)
- Search-ADAccount
AD-Dienstkonto deinstallieren (1 Cmdlet)
- Uninstall-ADServiceAccount
AD-Objekt entsperren (1 Cmdlet)
- Unlock-ADAccount
AD-Kontoablaufdatum zurücksetzen (1 Cmdlet)
- Clear-ADAccountExpiration
AD-Dienstkonto installieren (1 Cmdlet)
- Install-ADServiceAccount
AD-PowerShell „Benutzerobjekt“ Befehle
Mit dem Cmdlet Get-ADUser lassen sich Benutzerinformationen abfragen. Je nach Angabe der Suchkriterien werden bei der Abfrage ein oder mehrere Benutzerobjekte mit den gewünschten Attributen angezeigt. Mit dem Befehl Get-ADUser Yusuf werden standardmäßig die folgenden Werte angezeigt: DistinguishedName, Enabled, givenName, Name, ObjectClass, ObjectGUID, SamAccountName, ObjectSID, Surname, userPrincipalName
Bei allen PowerShell-Befehlen kann bei der Angabe von <Benutzer> zwischen den folgenden Angaben gewählt werden:
- sAMAccountName
- Distinguished Name (DN)
- ObjectSID
- ObjectGUID
Die Abfrage Get-ADUser „CN=Yusuf,OU=IT,DC=blog,DC=dikmenoglu,DC=de“, Get-ADUser S-1-5-21-2225156702-1871195563-4034089934-1101 oder Get-ADUser 6e90b6c6-0fc6-4aab-af7f-73b74f937980 liefern alle das gleiche Ergebnis.
Hinweis: Um die Funktion der Befehle sicherzustellen, ist es empfehlenswert die Befehle händisch einzutippen anstatt sie zu kopieren!
# Soll sich die Abfrage auf eine bestimmte OU (samt Unter-OUs) beschränken, so kann das mit dem Parameter –Searchbase und der Angabe des DN der OU durchgeführt werden.
Get-ADUser –LDAPFilter „(givenName=Yusuf)“ –SearchBase „OU=IT,DC=Domäne,DC=de“
# Zum Erhöhen der Suchleistung sollte man den Suchbereich auf ein einziges Objekt oder auf eine Objektteilmenge beschränken. Für diese Aufgabe stellt die DirectorySearcher-Klasse die SearchScope-Eigenschaft bereit. Der Suchbereich lässt sich auf eine der folgenden drei Einstellungen festlegen:
- Base: Hier wird das Objekt durchsucht, mit dem man verbunden ist. Wenn man sich z.B. mit einer OU verbunden hat, wird nur diese eine OU durchsucht und nicht noch zusätzlich die evtl. bestehenden Unter-OUs.
- OneLevel: Mit dieser Option werden alle Objekte die sich direkt, also eine Ebene tiefer, unter der Suchbasis befinden durchsucht.
- Subtree: Durchsucht alle Objekte, die in der Teilstruktur des verbundenen Objekts enthalten sind. Dabei werden alle Container im aktuellen Pfad und unterhalb der Suchbasis durchsucht.
Mit der Angabe des Parameters –SearchScope, lässt sich die Abfrage im vorherigen Beispiel ausschließlich auf die angegebene OU beschränken:
Get-ADUser –LDAPFilter „(givenName=Yusuf)“ –SearchBase „OU=IT,DC=Domäne,DC=de“ –SearchScope OneLevel
# Welche Benutzerkontoeigenschaften angezeigt werden, lässt sich mit dem Parameter –Properties beeinflussen. Wird beim Parameter –Properties als Wert ein Wildcard „*“ verwendet, so lassen sich alle Benutzerkontoeigenschaften anzeigen die im Benutzerobjekt enthalten sind:
Get-ADuser <Benutzer> -Properties *
# Möchte man sich bei einem bestimmten Benutzer neben den standardmäßig angezeigten Werten lediglich als weitere Benutzereigenschaft die Personalnummer, die Attribute employeeID und employeeNumber anzeigen lassen, so lautet der Befehl
Get-ADUser <Benutzer> –Properties employeeID,employeeNumber
# Alle Benutzerkonten in der Domäne anzeigen
Get-ADUser –Filter *
# Alle AD-Objekte anzeigen
Get-ADObject –Filter { ObjectClass –Like „*“ }
# Alle Benutzerkonten einer bestimmten OU im Spaltenformat anzeigen
Get-ADUser –Filter * -Searchbase „OU=<OU>,DC=Domäne,DC=de“ | FT
# Alle Benutzer in der Domäne mit dem Vornamen „Yusuf“ anzeigen
Get-ADUser –LDAPFilter „(givenName=Yusuf)“
# Alle Benutzerkonten in der Domäne mit der Personalnummer im Spaltenformat anzeigen
Get-ADUser -Filter * -Properties employeeID,employeeNumber | FT
# Mit einer Ambiguous Name Resolution (kurz ANR) die Benutzer anzeigen, die im Vornamen, Nachnamen oder sAMAccountName den Eintrag „Yus“ enthalten
Get-ADUser –Filter { ANR –eq „Yus“ }
# Alle Benutzerkonten aus „Mainz“ anzeigen
Get-ADUser –Filter {City –Like „Mainz“}
# Alle Benutzerkonten mit dem Vornamen „Yusuf“ anzeigen
Get-ADUser –Filter {givenName –Like „Yusuf“} | FT
# Alle Benutzerkonten mit dem Nachnamen „Dikmenoglu“ anzeigen
Get-ADUser –Filter {Surname –Like „Dikmenoglu“}
# Alle Benutzerkonten aus der Abteilung „EDV“ anzeigen
Get-ADUser –Filter {Department –Like „EDV“}
# Alle Benutzerkonten anzeigen die in ihrem „Common Name“ irgendwo den Eintrag „Yus“ haben
Get-ADUser –Filter { CN –Like „*Yus*“ }
# Alle Benutzer die einen Wert im Attribut mail eingetragen haben anzeigen
Get-ADUser –Filter { mail –Like „*“ }
oder
Get-ADObject –Filter { mail –Like „*“ –and ObjectClass –eq “user” }
# Alle Benutzer die einen Wert im Attribut mail eingetragen haben und mit Nachname „Dikmenoglu“ lauten anzeigen
Get-ADUser –Filter { mail –Like „*“ –and Surname –eq „dikmenoglu“ }
oder
Get-ADUser –Filter { mail –Like „*“ –and sn –eq „dikmenoglu“ }
# Alle Benutzerkonten die keinen Wert im Attribut mail eingetragen haben anzeigen
Get-ADUser –Filter { mail –notlike „*“ }
Oder
Get-ADUser –LDAPFilter „(!(email=*))“
# Alle Benutzerkonten die im Common Name mit „Yusuf“ oder „Kaan“ beginnen anzeigen
Get-ADUser -Filter { CN -like "Yusuf*" -or CN -eq "Kaan"
oder
Get-ADObject -Filter { objectClass -eq "user" -and (CN -like "Yusuf*" -or CN -eq "Kaan") }
# Die Gruppenmitgliedschaften eines Benutzers anzeigen
Get-ADPrincipalGroupMembership Yusuf
# Alle Benutzerkonten anzeigen, die als Vorgesetzten „Yusuf“ eingetragen haben
Get-ADUser -Filter { Manager -eq "Yusuf" }
# Die direkten Gruppenmitgliedschaften samt der „primären Gruppe“ eines Benutzers anzeigen
Get-ADUser Yusuf –Properties primarygroupID,memberof
# Den Benutzer aus einer Gruppe entfernen
Remove-ADPrincipalGroupMembership Yusuf –MemberOf „Gruppe“
# Den Benutzer bis auf die primäre Gruppe, aus allen Gruppen entfernen
Get-ADPrincipalGroupMembership Yusuf | % {Remove-ADPrincipalGroupMembership Yusuf -MemberOf $_}
# Den Benutzer Kaan zu den gleichen Gruppen hinzufügen, in denen Yusuf Mitglied ist
Get-ADPrincipalGroupMembership Yusuf | % {Add-ADPrincipalGroupMembership Kaan -MemberOf $_}
# Alle Benutzerkonten anzeigen, die sich in den letzten 10 Tagen angemeldet haben
$date = (get-date) – (new-timespan –days 10)
Get-ADUser –Filter { lastlogon –gt $date }
Ein anderer Befehl mit dem die Benutzer angezeigt werden, die sich in den letzten 5 Tagen an der Domäne angemeldet haben ist dieser:
Get-ADUser –LDAPFilter „(&(LastLogon>=128812906535515110)(objectCategory=user))“
# Alle Benutzer anzeigen die sich in den letzten 50 Tagen nicht angemeldet haben
$Vorvielentagen = (Get-Date).AddDays(-50)
Get-ADUser -Filter { lastLogonTimeStamp -notlike "*" -or lastLogonTimeStamp -le $Vorvielentagen }
# Alle Benutzerkonten die mehr als vier Mal ihr Kennwort falsch eingegeben haben anzeigen
Get-ADUser –LDAPFilter „(badPwdCount>=4)“
Oder
Get-ADUser –Filter {badPwdCount –ge 4}
# Einen Benutzer deaktivieren
Disable-ADAccount Yusuf
# Einen Benutzer aktivieren
Enable-ADAccount Yusuf
# Einen deaktivierten Benutzer im Container USERS erstellen
New-ADUser Yusuf
# Einen aktivierten Benutzer in der angegebenen OU mit mehreren Werten erstellen
New-ADUser –sAMAccountName „Yusuf“ –UserPrincipalName Yusuf@ad.dikmenoglu.de –givenname “Yusuf” –Surname “Dikmenoglu” –displayName “Yusuf Dikmenoglu” –Name “Yusuf Dikmenoglu” –scriptpath “login.bat” –Enabled $true –Path “OU=<OU>,DC=Domäne,DC=DE” –AccountPassword (ConvertTo-Securestring “Pa$$w0rd!” –asplaintext –Force)
# Ein Benutzerkonto mit allen Eigenschaften kopieren und im Container USERS erstellen
PS C:\> $Groups = Get-ADPrincipalGroupMembership "Yusuf"
PS C:\> Get-ADUser "Yusuf" -Properties * | New-ADUser -Name "Benutzer2" -Displayname "Benutzer2" -samaccountname "Benutzer2" -accountpassword (ConvertTo-SecureString "Pa$$w0rd!" -AsPlainText –Force)
PS C:\>Add-ADPrincipalGroupMembership "Benutzer2" -memberOf $Groups
# Ein Benutzerkonto nur mit bestimmten Attributen kopieren und im Container USERS erstellen
PS C:\> $Groups = Get-ADPrincipalGroupMembership "Yusuf"
PS C:\> Get-ADUser "Yusuf" -Properties profilPath, scriptPath, accountExpires | New-ADUser -Name "Benutzer2" -Displayname "Benutzer2" -samaccountname "Benutzer2" -accountpassword (ConvertTo-SecureString "Pa$$w0rd!" -AsPlainText –Force)
PS C:\>Add-ADPrincipalGroupMembership "Benutzer2" -memberOf $Groups
# 50 aktivierte Benutzerkonten in einer bestimmten OU erstellen
(1..50) | Foreach-Object {New-ADUser –sAMAccountname "Benutzer$_" -Name "Benutzer$_" -AccountPassword (ConvertTo-SecureString -AsPlainText "Pa$$w0rd!" -Force) –Enabled $true –Path „OU=<OU>,DC=Domäne,DC=de“}
# Allen Benutzern einer bestimmten OU einen Wert im Feld „Beschreibung“ setzen
Get-ADUser –Filter * -Searchbase „OU=<OU>,DC=Domäne,DC=DE“ | Set-ADUser –description „Wert“
# Die Option „Konto läuft ab am:“ auf den 31. Oktober 2009 setzen
Set-ADUser Yusuf –AccountExpirationDate 01/11/2009
# Die Option „Konto läuft ab“ auf „Nie“ setzen
Clear-ADAccountExpiration Yusuf
# Den Profilpfad, das Anmeldeskript und ein Homelaufwerk für einen bestimmten Benutzer eintragen
Set-ADUser „Yusuf“ –ProfilePath \\Server01\Profiles\%username% -Scriptpath „Login.bat“ –Homedrive „X“ –HomeDirectory „\\Server01\home\Yusuf“
# Einen Benutzer in eine andere OU verschieben
Get-ADUser Yusuf | Move-ADObject –TargetPath „OU=NeueOU,DC=Domäne,DC=de“
# Den relative distinguished name (RDN) eines Benutzers ändern
Rename-ADObject „CN=Yusuf Dikmenoglu,OU=IT,DC=Domäne,DC=de“ –NewName „Yusuf Cool“
# Einen Benutzer löschen
Remove-ADUser Yusuf
# Einen Benutzer ohne Sicherheitsabfrage löschen
Remove-ADUser Yusuf -Confirm:$False
# Mehrere Benutzer anhand eines gemeinsamen Kriteriums löschen
Get-ADUser –Filter {Name –Like „*Dikmenoglu*“} | Remove-ADUser
# Mit dem folgenden Befehl wird die Voreinstellung für neue Benutzer auf einem deutschen DC (auf einem englischen System lautet der LDAP-Pfad ...,CN=409,...) auf „Nachname, Vorname“ geändert (die Ansicht im Attribut name). Bestehende Objekte sind davon nicht betroffen.
| |