Die Information wann ein AD-Objekt erstellt wurde, ist im einwertigen (single-valued) Attribut whenCreated gespeichert. Um also das Erstellungsdatum z.B. eines Domänen-Benutzers in Erfahrung zu bringen, muss eine Abfrage des Attributs whenCreated auf irgendeinem DC erfolgen, denn das Attribut whenCreated wird sowohl zwischen den Domänencontrollern (DCs), als auch in den globalen Katalog (GC) repliziert.
Um die Abfrage jedoch State of the Art durchzuführen, ist die Wahl des Werkzeugs die AD-PowerShell.
Andere Möglichkeiten um an diese Information zu kommen, werden im folgenden Artikel erläutert:
Erstellungsdatum eines Benutzerobjekts
Das Attribut whenCreated mit der AD-PowerShell abfragen
-
Wann ein bestimmter Benutzer erstellt wurde, erfährt man mit diesem Befehl:
Get-ADUser -Filter {sAMAccountName -eq "Yusuf"} -Properties whenCreated | Select Name,whenCreated,distinguishedName | FT -Autosize -Wrap
Oder mit diesem Befehl:
$user = [ADSI]"LDAP://CN=<Benutzer>,OU=<OU>,DC=Domäne,DC=de"
$user.Get("whencreated")
Oder so: $User = Get-ADUser -Filter { sAMAccountName -eq "Yusuf" } -Properties whenCreated
$User.whenCreated
-
Vor wie vielen Tagen ein bestimmter Benutzer erstellt wurde, erfährt man wie folgt: $Heute = Get-Date
$Damals = Get-ADUser -Filter { Name -Like "Yusuf*" } -Properties whenCreated
($Heute - $Damals.whenCreated).Days
-
Alle Benutzer die in den letzten 90 Tagen erstellt wurden, lassen sich mit diesem AD-PowerShell Befehl anzeigen:
Get-ADUser -Filter * -Properties whenCreated | where { $_.whenCreated -gt (Get-Date).AddDays(-90) } | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Eine andere Variante ist:
$Date = (Get-Date) - (New-Timespan -Days 90)
Get-ADUser -Filter { whencreated -gt $Date } -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Oder diese Abfrage:
$VorvielenTagen = (Get-Date).AddDays(-90)
Get-ADUser -Filter { whenCreated -gt $VorvielenTagen } -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Oder wie folgt:
Get-ADUser -Filter * -Properties whenCreated | ? { ((Get-Date) - $_.whenCreated).Days -lt 90} | FT Name,whenCreated,Name,distinguishedName -Autosize -Wrap
-
Alle Benutzer die ab einem bestimmten Datum, in diesem Beispiel ab dem 01.01.2010 erstellt wurden, werden mit diesem AD-PowerShell Befehl angezeigt:
$Date = New-Object DateTime(2010,01,01,0,0,0)
Get-ADUser -Filter { whenCreated -gt $date } -Properties whenCreated | Select Name,whenCreated,distinguishedName | FT -Autosize -Wrap
Oder mit diesem Befehl:
$Date = New-Object System.Datetime -ArgumentList @(2010,01,01,0,0,0)
Get-ADUser -Filter { whenCreated -gt $date } -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Auch mit diesem Befehl werden alle Benutzer die ab dem 01.01.2010 erstellt wurden angezeigt:
Get-ADUser -LDAPFilter "(&(objectCategory=person)(whenCreated>=20100101000000.0Z))" -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
-
Alle Benutzer die bis vor 10 Tagen und früher erstellt wurden werden mit diesem Befehl angezeigt: $Date = Get-Date
Get-ADUser -Filter * -Properties whenCreated | ? { ($date - $_.whenCreated).days -gt 10 } | FT Name,whenCreated,distinguishedName -Autosize -Wrap
-
Alle Benutzer die in einem bestimmten Zeitraum, hier zwischen dem 01.09.2009 und 30.09.2009 erstellt wurden, werden wie folgt angezeigt: $Anfang = Get-Date -Day 01 -Month 09 -Year 2009 -Hour 00
$Ende = Get-Date -Day 30 -Month 09 -Year 2009 -Hour 23 -Minute 59
Get-ADUser -Filter * -Properties whenCreated | ? { ($_.whenCreated -gt $Anfang) -and ($_.whenCreated -le $Ende) } | FT Name,whenCreated,distinguishedName -Autosize -Wrap
-
In den oben genannten AD-PowerShellbefehlen handelt es sich um Benutzerabfragen. Möchte man sich jedoch statt Benutzer --> Gruppen anzeigen lassen, so muss man lediglich in den Abfragen das Cmdlet Get-ADUser durch das Cmdlet Get-ADGroup ersetzen, mit dem man gezielt Gruppen abfragen kann.
Demnach sieht die Abfrage nach einer bestimmten Gruppe so aus:
Get-ADGroup -Filter {sAMAccountName -eq "ADConsultants"} -Properties whenCreated | Select Name,whenCreated,distinguishedName | FT -Autosize -Wrap
Die Abfrage welche Gruppen in den letzten 90 Tagen erstellt wurden lautet so:
Get-ADGroup -Filter * -Properties whenCreated | where { $_.whenCreated -gt (Get-Date).AddDays(-90) } | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Und welche Gruppen ab dem 01.01.2010 erstellt wurden, werden wie folgt angezeigt:
$Date = New-Object DateTime(2010,01,01,0,0,0)
Get-ADGroup -Filter { whenCreated -gt $date } -Properties whenCreated | Select Name,whenCreated,distinguishedName | FT -Autosize -Wrap
-
Sollen hingegen Computer abgefragt werden, so muss das Cmdlet Get-ADComputer angegeben werden, anstelle vom Cmdlet Get-ADUser.
Alle Computerkonten die in den letzten 90 Tagen im AD erstellt wurden (wenn ein Client zur Domäne hinzugefügt wird), lassen sich mit diesem Befehl anzeigen:
Get-ADComputer -Filter * -Properties whenCreated | ? { ((Get-Date) - $_.whenCreated).Days -lt 90} | FT Name,whenCreated,Name,distinguishedName -Autosize -Wrap
Alle Computerkonten die ab dem 01.01.2010 im AD erstellt wurden abfragen:
Get-ADComputer -LDAPFilter "(&(objectCategory=person)(whenCreated>=20100101000000.0Z))" -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
Alle Computerkonten die in einem bestimmten Zeitraum, hier zwischen dem 01.11.2009 und 30.11.2009 im AD erstellt wurden, werden wie folgt angezeigt:
$Anfang = Get-Date -Day 01 -Month 11 -Year 2009 -Hour 00
$Ende = Get-Date -Day 30 -Month 11 -Year 2009 -Hour 23 -Minute 59
Get-ADComputer -Filter * -Properties whenCreated | ? { ($_.whenCreated -gt $Anfang) -and ($_.whenCreated -le $Ende) } | FT Name,whenCreated,distinguishedName -Autosize -Wrap
-
Oder wenn man Organisationseinheiten (OUs) anzeigen lassen möchte, muss man in den o.g. Befehlen Get-ADOrganizationalUnit angeben anstatt Get-ADUser.
Alle OUs die ab dem 01.01.2010 erstellt wurden, werden folgendermaßen angezeigt: $Date = New-Object System.Datetime -ArgumentList @(2010,01,01,0,0,0)
Get-ADOrganizationalUnit -Filter { whenCreated -gt $date } -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
-
Sollen hingegen alle und nicht nur bestimmte AD-Objekte angezeigt werden, so muss in den o.g. Befehlen das Cmdlet Get-ADObject angeben werden.
Alle AD-Objekte (Benutzer, Gruppen, Computer, OUs, Drucker etc.) die seit dem 01.01.2010 erstellt wurden, werden folgendermaßen angezeigt: Get-ADObject -LDAPFilter "(&(objectClass=*)(whenCreated>=20100101000000.0Z))" -Properties whenCreated | FT Name,whenCreated,distinguishedName -Autosize -Wrap
-
Möchte man statt den neu erstellten Objekten die geänderten Objekte abfragen, so muss statt whenCreated, das Attribut whenChanged abgefragt werden. Dazu muss in den o.g. Befehlen nur das Attribut whenCreated, durch das ebenfalls einwertige Attribut whenChanged ersetzt werden. Auch whenChanged wird zum einen zwischen den DCs und zum anderen in den GC repliziert.
Weitere Informationen:
AD-PowerShell Befehle
Die Active Directory-Attribute hinter den Feldnamen
Gespeicherte Abfragen für dsa.msc
Alle Gruppenmitgliedschaften eines Benutzers exportieren
Den OS- und SP-Stand abfragen
Wie finde ich heraus wo sich ein Objekt befindet?
Die AD-Powershell im Windows Server 2008 R2
Dem Administrator steht seit Windows Server 2003 die gespeicherte Abfrage im Snap-In Active Directory-Benutzer und -Computer (dsa.msc) zur Verfügung. Mit dieser Funktion hat man die Möglichkeit, Suchanfragen zu speichern. Die gespeicherten Abfragen stehen dann für erneute Suchanfragen zu einem späteren Zeitpunkt zur Verfügung. Komplexe Abfragen müssen somit nicht jedesmal neu erstellt werden und können bei gleichbleibenden Bedingungen jedesmal genutzt werden. Mit einer gespeicherten Abfrage können auch benutzerdefinierte Abfragen erstellt werden, die einen LDAP-Suchfilter enthalten.
Alle erstellten Abfragen werden im Ordner Gespeicherte Abfragen gespeichert. Dort können sie bearbeitet und gelöscht werden. Die gespeicherten Abfragen werden jedoch nur in der MMC gespeichert, in der sie durchgeführt wurden und dort auch nur unter dem angemeldeten Benutzer. Fügt man die dsa.msc in eine neue MMC (Start-Ausführen-MMC) hinzu, kann dieses Snap-In als MSC-Datei mit samt den gespeicherten Abfragen gespeichert und auf einer anderen Maschine verwendet bzw. den IT-Kollegen zur Verfügung gestellt werden.
Die gespeicherten Abfragen kann man aber auch als XML-Datei exportieren und auf einer anderen Maschine importieren. Mit einem Rechtsklick auf die gespeicherte Abfrage kann aus dem Kontextmenü die Abfrage mit der Option Abfragedefinition exportieren… als XML-Datei exportiert werden. Auf einer anderen Maschine lässt sich anschließend mit einem Rechtsklick auf den Ordner Gespeicherte Abfrage oder auf einem selbst erstellen Ordner die Option Abfragedefinition importieren… auswählen, um danach die XML-Datei zu importieren.
In der folgenden ZIP-Datei sind 72 gespeicherte Abfragen, sortiert nach Benutzer-, Gruppen-, Computer-, Drucker und Exchange-Abfragen als XML-Datei gespeichert.
Gespeicherte-Abfragen.zip (55,66 KB)
Weitere Informationen:
Wie finde ich heraus wo sich ein Objekt befindet?
Die Active Directory-Attribute hinter den Feldnamen
Active Directory - Abfrage
AD-PowerShell Befehle
Den Security Descriptor (SD - die erweiterten Sicherheitseinstellungen) vom Container Deleted Objects, den es in der Domänen-, Konfigurations- sowie den beiden DNS-Anwendungsverzeichnispartitionen DomainDNSZones sowie ForestDNSZones gibt, kann man nicht so ohne weiteres abfragen bzw. auslesen.
Doch ab Windows Vista und Windows Server 2008 können mit LDP, das sich in den Remote Server Administration Tools (kurz RSAT) befindet, die Access Control Entries (ACEs) vom Deleted Objects Container angezeigt werden.
Nach dem man sich in LDP mit einem Domänencontroller verbunden und mit dem AD gebinded hat, trägt man unter Ansicht – Struktur entweder den Distinguished Name (DN) der Verzeichnispartition ein oder gibt direkt den LDAP-Pfad des Deleted Objects Container aus der gewünschten Verzeichnispartition an.
Anschließend ruft man mit einem Rechtsklick den Security Descriptor von Deleted Objects auf. Wie im Screenshot dargestellt muss man dazu auf Schwer – Sicherheitsbeschreibung klicken.
Im darauffolgenden Fenster muss bestätigt werden, dass man den SD von Deleted Objects aufrufen möchte.
Als Besitzer wird <null> angezeigt, was ein gewünschtes Verhalten ist. Denn bevor man sich die ACEs anzeigen lassen kann, muss man vorher die Besitzrechte von Deleted Objects übernehmen.
Gibt man im Feld „Besitzer“ z.B. nicht explizit den „Administrator“ (also den Domänen-Admin) an, wird als Besitzer die Gruppe „Domäne\Domänen-Admins“ für den Deleted Objects Container in der Domänenpartition eingetragen.
Nach der Besitzübernahme sieht man die eingetragenen ACEs. Es gibt lediglich zwei ACEs. Die Gruppe Builtin\Administratoren die das Leserecht besitzt und NT-AUTORITÄT\System, das den Vollzugriff besitzt.
Da in der Builtin\Administratoren Gruppe standardmäßig der Administrator und die beiden Gruppen „Domänen-Admins“ sowie „Organisations-Admins“ Mitglied sind, haben automatisch diese Konten das Leserecht auf den Container Deleted Objects. Selbstverständlich sollten nicht nur die bestehenden ACEs nicht verändert werden, sondern die gesamte Zugriffssteuerungsliste sollte nicht verändert und die Standardeinträge beibehalten werden.
Weitere Informationen:
Der Container Deleted Objects
Der Active Directory-Papierkorb im Windows Server 2008 R2
Neben dem CSVDE das seit Windows 2000 „on Bord“ existiert, kann mit der AD-PowerShell und einer Comma-Separated Value (CSV)-Datei ebenfalls ein Massenimport- sowie -export von Objekten durchgeführt werden. CSVDE steht bis einschließlich Windows Server 2003 nur auf einem Serverbetriebssystem zur Verfügung. Erst ab Windows Vista steht das CSVDE in den Remote Server Administration Tools (kurz RSAT) auf dem Client zur Verfügung. Doch auch unter Windows 2000 und Windows XP ist es möglich die Csvde.exe von einem Server aus dem Verzeichnis „%windir%\system32“ auf eine Admin-Workstation zu kopieren, um das Kommandozeilentool unter diesen beiden Clientversionen zu verwenden. Denn CSVDE steht weder im Adminpak, noch in den Windows Support Tools zur Verfügung.
Die AD-PowerShell steht ab Windows Server 2008 R2 sowie Windows 7 in den RSAT (Remote Server Administration Tools) zur Verfügung und kann ab Windows Server 2003 und Windows XP nachinstalliert werden.
Siehe:
Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0)
Mit der AD-PowerShell lässt sich ebenfalls eine CSV-Datei mit den Cmdlets Import-CSV sowie New-ADUser (für den Import von Benutzern) ins AD importieren und mit dem Cmdlet Export-CSV, Daten aus dem AD exportieren.
Der Vorteil eines Massenimports mit einer CSV-Datei ist, dass man sich die Datei mit den zu importierenden Objekten und Daten in Excel übersichtlich erstellen und als CSV-Datei speichern kann. Nach anschließender Überarbeitung der CSV-Datei kann dann der Import ins AD stattfinden. Auch der Export von vielen Objekten in eine CSV-Datei hat seine Vorteile. Die exportierte CSV-Datei lässt sich zur weiteren Bearbeitung in Excel importieren.
CSVDE und die AD-PowerShell können mit der Dateiendung CSV und TXT einen Im- sowie Export durchführen.
CSVDE zum Im- und Export verwenden
Mit CSVDE, das im Übrigen für Comma Separated Value Data Exchange steht, können Daten im kommaseparierten Format importiert sowie exportiert werden. CSVDE liest beim Import die Informationen aus einer Datendatei und erstellt anschließend AD-Objekte entsprechend den Anweisungen in der Datendatei. Es können jedoch keine bestehenden Objekte geändert werden. Nur das Hinzufügen von neuen Objekten ist möglich! Mit CSVDE können auch keine Benutzerkennwörter gesetzt werden.
Ist neben dem Im- oder Export das Ändern von bestehenden Objekten gewünscht, kann das neben der AD-PowerShell mit LDIFDE durchgeführt werden, das sich auch seit Windows 2000 standardmäßig auf einem Server befindet. LDIFDE kann zwar ebenfalls beim Import von neuen Benutzerobjekten keine Kennwörter setzen, doch dafür kann es Kennwörter von bestehenden Benutzerobjekten ändern, wenn vorher eine 128Bit SSL-Verbindung zum DC hergestellt wurde.
LDIFDE - LDAP Data Interchange Format Data Exchange
CSVDE kann beliebige Objekte, wie beispielsweise Organisationseinheiten (OU), Benutzer-, Gruppen- und Computerkonten ins AD importieren. Damit CSVDE seine Arbeit korrekt verrichtet, müssen alle notwendigen Parameter angegeben werden.
Die Parameter die für den Im- sowie Export gelten:
-c Dieser Parameter ersetzt bestimmte Daten der Datendatei. Hat man z.B. eine Datendatei zur Hand in der der Distinguished Name der Objekte angepasst werden muss, so hat man zwei Möglichkeiten: Entweder man nutzt im Editor (Notepad) die „Ersetzen…“ Funktion oder man verwendet diesen Parameter, ohne die Datei bearbeiten zu müssen. Die Eingabe würde so aussehen: „-c <DC=alte,DC=Domäne> <DC=neue,DC=Domäne>“.
-f Mit diesem Parameter wird die Datei für den Im- bzw. Export angegeben.
-j Wenn ein Im- oder Export aus welchen Gründen auch immer nicht funktioniert, sollte man diesen Parameter angeben, gefolgt von einem Pfad (z.B. „-j C:\“). Im Fehlerfall werden zwei Protokolldateien erstellt „csv.log“ und „csv.err“. Bei Erfolg wird lediglich die „csv.log“ erstellt.
-s Mit diesem Parameter kann man gezielt einen DC angeben, der für den Im- oder Export verwendet werden soll.
-v Bei der Angabe dieses Parameters wird der ausführliche Modus aktiviert. Es werden in der CMD mehr Informationen angezeigt.
-t Dieser Parameter gibt den LDAP-Port an. Standardmäßig wird der LDAP-Port 389 verwendet. Möchte man aber Daten z.B. von einem globalen Katalog exportieren, so muss der Port 3268 angegeben werden.
-u Umlaute in den zu exportierenden Daten werden mit diesem Parameter korrekt dargestellt. Dieser Parameter verwendet das Unicodeformat.
csvde -? In gewohnter Windows Manier zeigt dieser Befehl die Hilfe zu CSVDE an.
Die relevanten Parameter für einen Import sind:
-f Mit diesem Parameter wird die Datei für den Import angegeben.
-i Dieser Parameter aktiviert den Importmodus. Standardmäßig wird CSVDE ohne Angabe dieses Parameters im Export-Modus ausgeführt.
-k Damit die Fehler „Beschränkungsverletzung“ und „Objekt ist bereits vorhanden“ beim Import ignoriert werden, gilt es diesen Parameter anzugeben.
Die relevanten Parameter für einen Export sind:
-d Dieser Parameter gibt den DN für den zu exportierenden LDAP-Pfad an.
-f Mit diesem Parameter wird die Datei für den Export angegeben.
-g Deaktiviert die seitenweise Suche.
-l Die zu exportierenden Attribute werden mit diesem Parameter angeben (durch Komma getrennt). Dieser Parameter sollte nicht zusammen mit dem Parameter -i verwendet werden, da beide Parameter für andere Szenarien gedacht sind.
-m Aktiviert die SAM-Logik beim Export. Mit diesem Parameter werden die Systemattribute wie z.B. ObjectGUID, objectSID und pwdLastSet nicht exportiert. Daher ist es sinnvoll stets diesen Parameter beim Export zu verwenden. Denn wenn die gleiche Datendatei zum Import verwendet werden soll, müssen ohnehin die Systemattribute aus der Datendatei entfernt werden, da ansonsten der Import fehlschlägt.
-n Exportiert keine Binärwerte.
-o Die Liste der Attribute (durch Komma getrennt), die beim Export ausgelassen werden sollen, werden mit diesem Parameter angegeben.
-p Den Suchbereich (Base/OneLevel/SubTree) gibt man mit diesem Parameter an.
-r Mit diesem Parameter gibt man den LDAP-Suchfilter an. Wird der Parameter nicht angegeben, nimmt CSVDE standardmäßig diesen Suchfilter "(objectClass=*)".
Einen Import mit CSVDE durchführen
Für den Import wird zuerst eine Dateidatei mit den zu importierenden Attributen sowie gewünschten Werten benötigt. Diese Datei lässt sich einfach und übersichtlich in Excel erstellen.
Für den erfolgreichen Import muss die Datendatei folgenden Bedingungen entsprechen:
-
-
Zwingende- und Mindestangaben für den Import von Benutzern und Gruppen sind: DN, objectClass und sAMAccountName. Für den Import von Organisationseinheiten (OUs) sind es die beiden Attribute DN und objectClass.
-
Die Reihenfolge in der die Attribute in der ersten Zeile angegeben werden, spielt keine Rolle.
-
Die Reihenfolge der Werte bzw. Feldinhalte ab der zweiten Zeile in der Datendatei, müssen allerdings mit der ersten übereinstimmen.
-
Sollen neben Benutzern auch Gruppen importiert werden, in denen die zu importierenden Benutzer Mitglied sein sollen, so müssen die Benutzereinträge vor den Gruppeneinträgen in der Datendatei enthalten sein. Oder wenn auch die OU importiert werden soll, in der die Benutzer und Gruppen erstellt werden sollen, so muss der Eintrag zum erstellen der OU ebenfalls vor den Benutzer- und Gruppenobjekten zuerst in der Datendatei enthalten sein. Beide Fälle sind in diesem Beispiel aufgeführt.
-
Wird ein Wert für ein angegebenes Attribut nicht eingetragen, muss es dennoch in der Datendatei durch ein Komma angegeben werden.
-
Systemattribute wie z.B. die ObjectSID oder ObjectGUID können nicht importiert werden. Wie es der Name „Systemattribute“ schon verrät, sind das Attribute die vom System vergeben werden.
-
Die Exceldatei könnte z.B. so aussehen:
-
Ist die Exceldatei fertiggestellt, muss diese als CSV-Datei abgespeichert werden. Dazu klickt man in Excel in der Menüleiste auf das Diskettensymbol oder verwendet das Tastaturkürzel „STRG + S“. Das Fenster „Speichern unter“ öffnet sich. Als Dateityp wählt man die Option „CSV (Trennzeichen-getrennt)(*.csv)“ aus und vergibt einen Dateinamen. Mit einem Klick auf Speichern folgt eine Warnung die darauf hinweist, dass der gewählte Dateityp keine Arbeitsmappen mit mehreren Blättern unterstützt und deshalb nur das aktuelle Blatt gespeichert wird. Mit einem Klick auf OK erscheint eine weitere Information die darauf hinweist, dass in der CSV-Datei Merkmale enthalten sein können, die mit „CSV (Trennzeichen-getrennt)“ nicht kompatibel sind. Mit einem Klick auf „Ja“ wird nun endlich die CSV-Datei gespeichert.
-
Nun muss die CSV-Datei mit dem „Editor“ (Notepad) noch bearbeitet werden. Mit einem Rechtsklick auf die CSV-Datei wählt man à Öffnen mit à Editor. Danach öffnet sich die CSV-Datei im Editor.
-
Als Trennzeichen verwendet Excel das Semikolon (;), das durch das Komma (,) ersetzt werden muss. Dies kann man am einfachsten, wenn man im Editor auf Bearbeiten – Ersetzen… klickt. Dort gibt man dann im Feld „Suchen nach“ das Semikolon an und im Feld „Ersetzen durch“ das Komma. Anschließend werden mit einem Klick auf „Alle ersetzen“ die Änderungen durchgeführt.
-
Werte die selbst ein Komma enthalten, müssen in Anführungszeichen (im Volksmund auch als „Gänsefüßchen“ bekannt) gesetzt werden. Das kann man ebenfalls durch die Ersetzen-Funktion im Editor durchführen. In diesem Beispiel müssen die Werte von DN, displayName und Member in Anführungszeichen gesetzt werden.
Vorsicht: Importiert man so wie in diesem Beispiel auch eine Gruppe in der ebenfalls die zu importierenden Benutzer Mitglied sein sollen, müssen die DNs der Benutzer zwingend durch eine Semikolon getrennt werden. Des Weiteren darf das Anführungszeichen nur am Anfang und am Ende der Einträge stehen. Also: „<DN Benutzer1>;<DN Benutzer2>;<DN Benutzer3>“.
-
Die fertige Datendatei sieht dann wie folgt aus:
-
Die gelben Markierungen in dem Beispiel kennzeichnen die Werte die Kommas enthalten und somit in Anführungszeichen gesetzt werden müssen und die roten Markierungen kennzeichnen die nicht enthaltenen Werte, die trotzdem durch ein Komma gesetzt werden müssen.
-
Zur Vollständigkeit, hier der komplette Inhalt der Datendatei:
DN,objectClass,givenname,sn,displayname,description,sAMAccountName,userPrincipalName,Member,groupType,userAccountControl
"OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",organizationalUnit,,,,,,,,,
"CN=Sabine Mueller,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Sabine,Mueller,"Mueller, Sabine",Festangestellte,sabine,sabine@ad2008r2.dikmenoglu.de,,,544
"CN=Klara Tolle,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Klara,Tolle,"Tolle, Klara",,Klara,Klara@ad2008r2.dikmenoglu.de,,,544
"CN=Simone Wagner,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Simone,Wagner,"Wagner, Simone",Aushilfe,Simone,Simone@ad2008r2.dikmenoglu.de,,,544
"CN=Maria Schmitt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Maria,Schmitt,"Schmitt, Maria",,Maria,Maria@ad2008r2.dikmenoglu.de,,,544
"CN=Bettina Bauer,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Bettina,Bauer,"Bauer, Bettina",Befristet,Bettina,Bettina@ad2008r2.dikmenoglu.de,,,544
"CN=Andrea Schmidt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Andrea,Schmitt,"Schmitt, Andrea",,Andrea,Andrea@ad2008r2.dikmenoglu.de,,,544
"CN=Sonja Neu,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Sonja,Neu,"Neu, Sonja",Praktikant,Sonja,Sonja@ad2008r2.dikmenoglu.de,,,544
"CN=Silke Vogt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",user,Silke,Vogt,"Vogt, Silke",Festangestellte,Silke,Silke@ad2008r2.dikmenoglu.de,,,544
"CN=AD-Consultants,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",group,,,,,AD-Consultants,,"CN=Sabine Mueller,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de;CN=Silke Vogt,OU=NeueOU,DC=ad2008r2,DC=dikmenoglu,DC=de",-2147483644,
-
Die Datendatei kann dann mit diesem Befehl importiert werden:
Csvde -i -f C:\Datendatei.txt Wenn beim Import ein Fehler auftritt, sollte man den Parameter -j verwenden damit die beiden Protokolldateien erstellt werden, um dann dem Fehler auf die Schliche zu kommen. Der Befehl würde dann so aussehen:
Csvde -i –v -f C:\Datendatei.txt –j C:\
Mit dem Attribut userAccountControl den Kennwortstatus der zu importierenden Benutzer steuern
Gibt man beim Import von Benutzern das Attribut userAccountControl in der Datendatei nicht oder mit dem Wert 514 an, erhält man anschließend deaktivierte Benutzer im AD. Denn wie bereits anfangs in diesem Artikel erwähnt, kann CSVDE keine Kennwörter setzen, was zwingend notwendig ist um hinterher aktive Benutzer zu erhalten. Der Wert 512 im userAccountControl würde zwar aktive Benutzer erstellen, jedoch reicht dass alleine nicht aus, da auch hierbei kein Kennwort vergeben wird. Das Deaktivieren der Kennwortrichtlinie würde zwar den gewünschten Erfolg bringen, nämlich nach dem Import aktivierte Benutzer im AD zu erhalten, jedoch ist das in einer produktiven Umgebung keineswegs empfohlen! Das ist höchstens für eine Testumgebung zulässig!
Aber das Abschalten der Kennwortrichtlinie ist auch nicht notwendig. Bekanntlich besteht das userAccountControl aus einer Bitmaske, bestehend aus mehreren Flags. Kombiniert man zwei davon, erhält man nach dem Import aktivierte Benutzer ohne ein Kennwort vergeben zu haben!
Kombiniert man die beiden Flags:
|
NORMAL_ACCOUNT |
512 |
|
PASSWD_NOTREQD |
32 |
und trägt in der Datendatei als Wert für userAccountControl 544 ein (wie im o.g. Beispiel), erhält man aktive Benutzerkonten im AD!
Die Benutzer melden sich ohne ein Kennwort an und werden direkt aufgefordert ein neues Kennwort zu vergeben. Denn das userAccountControl mit dem Wert 544 in den Benutzerobjekten aktiviert die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“.
How to use the UserAccountControl flags to manipulate user account properties
Gruppen mit CSVDE importieren
Die Werte die in der Datendatei für einen Import von Gruppen zwingend angegeben werden müssen sind: DN,objectClass und sAMAccountName. Somit werden aber lediglich „globale Sicherheitsgruppen“ erstellt. Daher ist es ratsam noch das Attribut groupType anzugeben, um den „Gruppenbereich“ und „Gruppentyp“ zu bestimmen.
Der Import der Datendatei erfolgt mit diesem Befehl:
Csvde -i -f C:\Gruppen.txt
Beispiele einer Datendatei zum Import von Gruppen
# Eine domänenlokale Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=DLSG,OU=<OU>,DC=Domäne,DC=de",group,DLSG,-2147483644
# Eine globale Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName
„CN=GG1,OU=<OU>,DC=Domäne,DC=de“,group,GG1
Oder:
DN,objectClass,sAMAccountName,groupType
„CN=GG1,OU=<OU>,DC=Domäne,DC=de“,group,GG1,-2147483646
# Eine universelle Sicherheitsgruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=USG,OU=<OU>,DC= Domäne,DC=de ",group,USG,-2147483640
# Eine domänenlokale Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=DLVG,OU=<OU>,DC= Domäne,DC=de ",group,DLVG,4
# Eine globale Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=GVG,OU=<OU>,DC= Domäne,DC=de ",group,GVG,2
# Eine universelle Verteilergruppe importieren:
DN,objectClass,sAMAccountName,groupType
"CN=UVG,OU=<OU>,DC= Domäne,DC=de ",group,UVG,8
Einen Export mit CSVDE durchführen
CSVDE wird standardmäßig ohne die Angabe eines Parameters im Export-Modus ausgeführt. Die Kunst beim Export ist es, lediglich die Informationen zu exportieren die von Interesse sind. Daher ist das entscheidende beim Export der Filter, der mit dem Parameter -r eingeleitet wird und die Attribute, die mit dem Parameter –l angegeben werden.
Beispiel Exportbefehle:
# Alle Benutzer mit den Attributen sAMAccountName und name exportieren:
Csvde -m -n -u -f C:\AlleBenutzer.txt -r "(&(objectclass=user)(objectcategory=person))" -l sAMAccountName,name
# Alle Benutzer aus einer OU mit den Attributen sAMAccountName und name exportieren:
Csvde -m -n -u -f C:\ExportBenutzer.txt -s DCON01 -d "OU=<OU>,DC=Domäne,DC=TLD" –p OneLevel –r "(&(objectClass=user)(objectcategory=person))" -l sAMAccountName,name
# Alle Kontakte mit den angegebenen Attributen exportieren:
Csvde -m -n -u -r "(objectClass=Contact)" -d "OU=<OU>,DC=Domäne,DC=de" -l displayname,telephoneNumber,othertelephone,mobile,homePhone,Pager,facsimileTelephoneNumber,ipPhone,otherHomePhone,otherPager,otherMobile,otherFacsimileTelephoneNumber,otherIpPhone -f C:\Kontakte.txt
# Mitglieder einer bestimmten Gruppe exportieren:
Csvde -m -n -u -f C:\Benutzer.txt -r "(&(objectcategory=user)(memberof=CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de))" -l samaccountname,name
# Alle Benutzer anzeigen, die NICHT Mitglied einer bestimmten Gruppe sind:
Csvde –m –n –u –f C:\Benutzer.txt -r „(&(objectCategory=person)(objectClass=user)(!memberof=CN=<Gruppe>,OU=<OU>,DC=Domäne,DC=de))“ –l name,sAMAccountName
# Alle Benutzer mit ihrem DN und dem LastLogon exportieren:
Csvde -m -n -u -f C:\Benutzer.txt -r "(&(objectClass=user)(objectCategory=person))" -l DN,LastLogon
Der Wert von LastLogon kann dann folgendermaßen in unsere Zeitangabe umgerechnet werden:
Einen Large Integer Wert umrechnen
# Alle Benutzer mit ihrem Anmeldenamen und dem eingetragenen Anmeldeskript exportieren:
Csvde -f C:\BenutzermitAnmeldeskript.txt -r "(&(objectClass=user)(scriptPath=*))" -l sAMAccountName,scriptPath
# Alle Benutzerobjekte exportieren, die NICHT deaktiviert sind (also aktive Benutzer):
Csvde -m -n -u -f C:\AktiveBenutzer.txt -r "(&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" –l sAMAccountName,name
# Alle Benutzer exportieren und überprüfen, bei wem die Option „Zugriff gestatten“ im Reiter „Einwählen“ aktiviert ist. Steht als Wert TRUE, ist die Option aktiviert:
Csvde -f C:\Ras.txt -u -r "(&(objectClass=user)(objectCategory=person))" -l name,sAMAccountName,msNPAllowDialin
# Alle deaktivierten Computerkonten exportieren:
Csvde –f C:\DeaktiviertePCs.txt –r „(&(objectclass=computer)(userAccountControl:1.2.840.113556.1.4.803:=2))“ –l DN
# Alle Public Folder exportieren:
Csvde -m -n -u -f C:\PublicFolders.txt -r "(objectClass=publicFolder)" -l name
# Alle SMTP-Adressen exportieren:
Csvde -m -n -u -f C:\SMTPList.txt -d "DC=Domäne,DC=de" -L proxyaddresses –r "(proxyaddresses=*smtp:*@*)"
Weitere Filter können aus diesem Artikel entnommen werden:
Gespeicherte Abfragen
Eine Datendatei mit Excel, zum Import mit der AD-PowerShell erstellen
Auch mit der AD-PowerShell können beliebige Objekte, wie beispielsweise Organisationseinheiten (OU), Benutzer-, Gruppen- und Computerkonten ins AD importiert werden. Für den erfolgreichen Import mit der AD-PowerShell wird zum einen eine Datendatei mit den korrekten Angaben benötigt und zum zweiten, der AD-PowerShell Befehl mit dem der Import durchgeführt wird.
Für das Erstellen einer Datendatei um Benutzerobjekte in Verbindung mit der AD-PowerShell zu importieren, gilt es folgendes zu beachten:
-
In der ersten Zeile müssen die Felder stehen, für die man einen Wert eintragen möchte. Möchte man Benutzer importieren, ist es hilfreich sich in der AD-PowerShell mit dem Befehl Get-Help New-ADUser -detailed die Syntax des Cmdlets anzuschauen. Dort werden die genauen Feldbezeichnungen genannt, wie es die AD-PowerShell in der Datendatei gerne hätte. Die Angaben unterscheiden sich teilweise von den unter CSVDE, da die AD-PowerShell nicht den LDAP-Display-Name eines Attributs verwendet (anstatt „sn“ für Nachname möchte die AD-PowerShell die Angabe „surname“)
-
Zwingend notwendige und die Mindestangaben für den Import von Benutzerobjekten sind: Path, Name und sAMAccountName. Für Gruppenobjekte sind es die Werte: Path, GroupScope, Name und sAMAccountName.
-
Im Gegensatz zu CSVDE darf es nicht DN (für Distinguished Name) heißen, sondern muss Path lauten. Dabei darf auch nicht das eigentliche Objekt (sprich der RDN) mit angegeben werden. Des Weiteren ist auch die Angabe von objectClass (oder userAccountControl) nicht notwendig, da durch das Cmdlet New-ADUser die Information bereits mitgegeben wird.
-
In welcher Reihenfolge die Felder in der ersten Zeile angegeben werden, spielt keine Rolle. Die Reihenfolge der Werte bzw. Feldinhalte ab der zweiten Zeile müssen jedoch mit der ersten übereinstimmen.
-
Wird ein Wert für ein angegebenes Feld nicht eingetragen, muss es dennoch in der Datendatei durch ein Komma angegeben werden.
-
Systemattribute wie z.B. die ObjectSID oder ObjectGUID können nicht importiert werden. Wie es der Name „Systemattribute“ schon verrät, sind das Attribute die vom System vergeben werden.
-
Beispielsweise könnte die Excel-Datei wie folgt aussehen:
-
Ist die Exceldatei fertiggestellt, gilt es diese als CSV-Datei abzuspeichern. Dazu klickt man in Excel in der Menüleiste auf das Diskettensymbol oder verwendet das Tastaturkürzel „STRG + S“. Das Fenster „Speichern unter“ öffnet sich. Als Dateityp wählt man die Option „CSV (Trennzeichen-getrennt)(*.csv)“ aus und vergibt einen Dateinamen. Es folgt eine Warnung die darauf hinweist, dass der gewählte Dateityp keine Arbeitsmappen mit mehreren Blättern unterstützt und deshalb nur das aktuelle Blatt gespeichert wird. Mit einem Klick auf OK erscheint eine weitere Information die darauf hinweist, dass in der CSV-Datei Merkmale enthalten sein können, die mit „CSV (Trennzeichen-getrennt)“ nicht kompatibel sind. Mit einem Klick auf „Ja“ wird nun endlich die CSV-Datei gespeichert.
-
Nun muss die CSV-Datei mit dem „Editor“ (Notepad) noch bearbeitet werden. Mit einem Rechtsklick auf die CSV-Datei wählt man à Öffnen mit à Editor. Danach öffnet sich die CSV-Datei im Editor.
-
Excel verwendet nämlich als Trennzeichen das Semikolon (;), das durch das Komma (,) ersetzt werden muss. Dies kann man am einfachsten, wenn man im Editor auf Bearbeiten – Ersetzen… klickt. Dort gibt man dann im Feld „Suchen nach“ das Semikolon an und im Feld „Ersetzen durch“ das Komma. Anschließend werden mit einem Klick auf „Alle ersetzen“ die Änderungen durchgeführt.
-
Werte die selbst ein Komma enthalten, müssen in Anführungszeichen (im Volksmund auch als „Gänsefüßchen“ bekannt) gesetzt werden. Das kann man ebenfalls durch die Ersetzen-Funktion im Editor durchführen. In diesem Beispiel müssen die Werte von „Path“ sowie „Name“ in Anführungszeichen gesetzt werden.
-
Die fertige Datendatei sieht dann wie folgt aus:
-
Die gelben Markierungen in dem Beispiel kennzeichnen die Werte die Kommas enthalten und somit in Anführungszeichen gesetzt werden müssen und die roten Markierungen kennzeichnen die nicht enthaltenen Werte, die trotzdem durch ein Komma gesetzt werden müssen. In diesem Fall sind es die Felder „description“ und „HomePage“.
-
Zur Vollständigkeit, hier der komplette Inhalt der Datendatei:
Path,name,givenname,surname,displayname,description,Office,emailaddress,HomePage,streetAddress,pobox,city,state,postalCode,country,userPrincipalName,sAMAccountName,profilePath,scriptPath,title,department,company
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Mueller, Sabine",Sabine,Mueller,Sabine Mueller,Festangestellte,Buero Mainz,s.mueller@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sab@ad2008r2.dikmenoglu.de,sab,\\Server\Profile\smueller,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Tolle, Klara",Klara,Tolle,Klara Tolle,,Buero Frankfurt,k.tolle@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,kla@ad2008r2.dikmenoglu.de,kla,\\Server\Profile\ktolle,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Wagner, Simone",Simone,Wagner,Simone Wagner,Aushilfe,Buero Istanbul,s.wagner@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sim@ad2008r2.dikmenoglu.de,sim,\\Server\Profile\swagner,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Schmitt, Maria",Maria,Schmitt,Maria Schmitt,,Buero Berlin,m.schmitt@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,mar@ad2008r2.dikmenoglu.de,mar,\\Server\Profile\mschmitt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Bauer, Bettina",Bettina,Bauer,Bettina Bauer,Befristet,Buero Muenchen,b.bauer@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,bet@ad2008r2.dikmenoglu.de,bet,\\Server\Profile\bbauer,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Schmidt, Andrea",Andrea,Schmidt,Andrea Schmidt,,Buero Hamburg,a.schmidt@dikmenoglu.de,,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,and@ad2008r2.dikmenoglu.de,and,\\Server\Profile\aschmidt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Neu, Sonja",Sonja,Neu,Sonja Neu,Praktikantin,Buero Stuttgart,s.neu@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,son@ad2008r2.dikmenoglu.de,son,\\Server\Profile\sneu,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
"OU=IT,DC=ad2008R2,DC=dikmenoglu,DC=de","Vogt, Silke",Silke,Vogt,Silke Vogt,Festangestellte,Buero Dresden,s.vogt@dikmenoglu.de,http://blog.dikmenoglu.de,Test Strasse 1,123456,Mainz,Rheinland-Pfalz,55116,DE,sil@ad2008r2.dikmenoglu.de,sil,\\Server\Profile\svogt,Login.bat,Systems Engineer,AD-Freaks,AD Consult GmbH
Das Importieren der Datendatei mit der AD-PowerShell
Zum importieren von Benutzerobjekten mit der AD-PowerShell hat man folgende Möglichkeiten.
Variante 1
Der AD-PowerShell Befehl mit dem die Datendatei ins AD importiert wird sieht so aus:
Import-CSV C:\Massenimport.csv | New-ADUser -AccountPassword (ConvertTo-SecureString –AsPlainText “Pa$$w0rd!” -Force) -Enabled:$true -ChangePasswordAtLogon:$true
Wie unschwer aus dem Befehl zu erkennen ist, wird mit dem Cmdlet Import-CSV der Inhalt der Datendatei Massenimport.csv durch die Pipeline-Funktion (|) der AD-PowerShell, in das Cmdlet New-ADUser gepiped. Der Vorteil der AD-PowerShell gegenüber CSVDE ist, dass mit CSVDE keine Kennwörter gesetzt werden können, mit der AD-PowerShell aber sehr wohl! Mit diesem AD-PowerShell Befehl erhält jeder Benutzer das Startkennwort Pa$$w0rd!. Durch die Angabe von -Enabled:$true erhält man nach dem Import aktivierte Benutzer (wozu zwingend ein Kennwort vergeben werden muss). Die Angabe von -ChangePasswordAtLogon:$true aktiviert bei allen importierten Benutzern die Kontooption Benutzer muss Kennwort bei der nächsten Anmeldung ändern.
Variante 2
Eine andere Variante zum importieren von Benutzerobjekten mit dem gleichen Ergebnis, ist dieser Befehl:
Import-Csv C:\Massenimport.csv | Foreach { New-ADUser -Path $_.path -Name $_.name -givenname $_.givenname -surname $_.surname -displayname $_.displayname -office $_.office -emailaddress $_.emailaddress -HomePage $_.HomePage -streetaddress $_.streetaddress -pobox $_.pobox -city $_.city -state $_.state -postalCode $_.postalCode -userPrincipalName $_.userPrincipalName -sAMAccountName $_.sAMAccountName -profilePath $_.profilePath -scriptPath $_.scriptPath -title $_.title -department $_.department -company $_.company -PasswordNotRequired:$true -Enabled:$true }
Die Parameter wie z.B. „-Path $_.path“ entsprechen den Angaben aus der ersten Zeile der Datendatei. Dabei spielt die Reihenfolge bei der Angabe der Werte keine Rolle. Z.B. könnte die erste Zeile in der Datendatei so aussehen: sAMAccountName,Path,Name,… und der Befehl wie folgt:
Import-Csv C:\Massenimport.csv | Foreach { New-ADUser -Name $_.name –sAMAccountName $_.sAMAccountName -Path $_.path …
Die Hauptsache ist, es werden alle Felder im Befehl angegeben, die auch in der Datendatei enthalten sind.
Auch mit diesem Befehl erhält man nach dem Import aktivierte Benutzerkonten im AD! Denn der Parameter -PasswordNotRequired:$true bewirkt nichts anderes, als das im Attribut userAccountControl im Benutzerobjekt als Wert 544 eingetragen wird. Das userAccountControl besteht nämlich aus einer Bitmaske, bestehend aus mehreren Flags.
Der Parameter -PasswordNotRequired mit dem Wert $true kombiniert diese beiden Flags:
|
NORMAL_ACCOUNT |
512 |
|
PASSWD_NOTREQD |
32 |
Doch der Eintrag -PasswordNotRequired:$true alleine reicht nicht aus, um aktivierte Benutzerkonten zu erhalten. Es muss zwingend noch der Parameter mit dem Wert -Enabled:$true eingegeben werden. Erst dadurch sind die Benutzerkonten aktiv.
Die Benutzer melden sich dann ohne ein Kennwort an und werden direkt aufgefordert ein neues Kennwort zu vergeben. Denn der Wert 544 im userAccountControl aktiviert bei jedem importierten Benutzerobjekt die Kontooption „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“.
How to use the UserAccountControl flags to manipulate user account properties
Gruppen mit der AD-PowerShell importieren
Die Werte die in der Datendatei für einen Import von Gruppen zwingend angegeben werden müssen sind: Path, GroupScope, Name und sAMAccountName. Somit werden lediglich Sicherheitsgruppen erstellt. Daher ist es ratsam noch GroupCategory anzugeben, um den „Gruppentyp“ zu bestimmen.
Der Import der Datendatei erfolgt mit diesem Befehl:
Import-CSV C:\Gruppen.csv | New-ADGroup
Beispiele einer Datendatei zum Import von Gruppen:
# Eine domänenlokale Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,domainlocal,DLSG1,DLSG1,Vertrieb
# Eine globale Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,global,GSG1,GSG1,Buchhaltung
# Eine universelle Sicherheitsgruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",security,universal,USG1,USG1,Einkauf
# Eine domänenlokale Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,domainlocal,DLVG1,DLVG1,Key Account
# Eine globale Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,global,GVG1,GVG1,Techniker
# Eine universelle Verteilergruppe importieren:
Path,GroupCategory,GroupScope,Name,sAMAccountName,description
"OU=Gruppen,DC=ad2008R2,DC=dikmenoglu,DC=de",distribution,universal,UVG1,UVG1,Support
Einen Export mit der AD-PowerShell durchführen
Wie mit jedem Werkzeug mit dem man einen Export durchführt, kommt es auch bei der AD-PowerShell auf die gewünschten Informationen und somit auf den Filter an. Wird ein „falscher“ Filter genutzt, bekommt man unter Umständen gar keine Informationen exportiert. Nutzt man hingegen einen „ungenauen“ Filter, erhält man diesmal ggf. zu viele Informationen die es dann mühselig zu durchforsten gilt. Die wichtigste Aufgabe beim Export ist es zu definieren, welche Informationen benötigt werden und dann den Filter (sofern möglich) zu bauen.
Die folgenden Beispiele zeigen jeweils eine LDAP-Abfrage, die dann durch die Pipeline-Funktion der AD-PowerShell an das Cmdlet Export-Csv übergeben und somit die Ausgabe exportiert wird.
Export Beispiele
# Alle Benutzer aus einer OU mit allen Eigenschaften exportieren:
Get-ADUser -Filter * -Searchbase "OU=<OU>,DC=Domäne,DC=de" -Properties * | Export-Csv C:\Export.txt -NoTypeInformation
Hinweis: Nutzt man das Cmdlet Get-ADUser um Benutzerinformationen zu exportieren, werden in jedem Fall diese Attribute ausgegeben: DistinguishedName, Enabled, givenName, Name, ObjectClass, ObjectGUID, SamAccountName, ObjectSID, Surname, userPrincipalName. Gibt man beim Parameter -Properties eigene Attribute an, werden diese zusätzlich zu den bereits genannten Attributen mit ausgegeben.
# Alle Benutzerkonten exportieren, die als Vorgesetzten „Yusuf“ eingetragen haben:
Get-ADUser -Filter { Manager -eq "Yusuf" } | Export-Csv C:\Export.txt -NoTypeInformation
# Alle Organisationseinheiten (OU) der Domäne exportieren:
Get-ADOrganizationalUnit -Filter {Name -Like „*“} | Export-Csv C:\OUs.txt -NoTypeInformation
# Alle Objekte einer OU exportieren:
Get-ADObject -Filter { Name -Like "*" } -Searchbase "OU=<OU>,DC=Domäne,DC=de” | Export-Csv -NoTypeInformation C:\AlleObjekte.txt
# Alle Attribute und Klassen eines Active Directory exportieren:
Get-ADObject -Filter { Name -Like “*” } -SearchBase “CN=Schema,CN=Configuration,DC=Domäne,DC=de” | Export-Csv -NoTypeInformation C:\Schema.txt
AD-PowerShell Befehle
Eine Datendatei in Excel importieren
In Excel lässt sich eine Datendatei wie folgt importieren:
Weitere Informationen:
How to use CSVDE.EXE to back up and restore connection agreements
Wenn ein Administrator ein Objekt im AD löscht, sollte er das bewusst tun und ein versehentliches löschen sollte nie vorkommen. Jedoch passieren die meisten Missgeschicke gerade im Alltag versehentlich, obwohl die Microsoft Werkzeuge (z.B. die MMCs Active Directory-Benutzer und -Computer sowie Active Directory-Standorte und -Dienste, dsrm, AD-PowerShell etc.) eine Sicherheitsabfrage stellen, ob man das Objekt auch wirklich löschen möchte. Handelt es sich bei dem zu löschenden Objekt um eine OU in dem weitere Objekte enthalten sind (Benutzer, Gruppen, OUs etc.), wird sogar noch eine weitere Sicherheitsabfrage gestellt.
Ein Objekt vor dem versehentlichen Löschen schützen
Damit ein Objekt nicht ausversehen gelöscht werden kann, sollte man ab Windows Server 2008 von der Option Objekt vor zufälligem Löschen schützen (auf Englisch: Protect object from accidental deletion) regen Gebrauch machen. Es ist empfehlenswert diesen Schutz mindestens auf OU-Ebene anzuwenden, sie vererbt sich aber nicht auf die untergeordneten Objekte wie z.B. auf untergeordnete OUs oder auf Benutzer-, Gruppen oder Computerobjekte die sich innerhalb der OU befinden. Einzelne Objekte wie Benutzerobjekte, Sicherheits- sowie Verteilergruppen- und Computerobjekte lassen sich ebenfalls vor dem versehentlichen Löschen schützen. Auch die Objekte in der MMC Active Directory-Standorte und -Dienste (AD-Standorte, Subnetze) lassen sich vor dem versehentlichen Löschen schützen.
Die Option Objekt vor zufälligem Löschen schützen lässt sich in den Eigenschaften eines Objekts im Reiter „Objekt“ aktivieren. Dieser Reiter kommt aber in der MMC „Active Directory-Benutzer und -Computer“ erst dann zum Vorschein, wenn unter „Ansicht“ die Option „Erweiterte Features“ aktiviert wurde.
Unter Windows 2000 und Windows Server 2003 existiert zwar die Möglichkeit zum aktivieren der Option „Objekt vor zufälligem Löschen schützen“ nicht, doch man kann natürlich auch unter Windows 2000 und Windows Server 2003 ein Objekt vor dem versehentlichen löschen schützen. Denn das aktivieren der Option „Objekt vor zufälligem Löschen schützen“ bewirkt nichts anderes, als das im Security-Descriptor des Objekts das "Verweigerungsrecht" zum "Löschen" für "Jeder" gesetzt wird. Genau das kann man auch unter Windows 2000 und Windows Server 2003 z.B. auf einer OU oder einem Benutzerobjekt konfigurieren.
Mit DSACLS, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich eine OU folgendermaßen vor dem versehentlichen Löschen schützen:
Dsacls „<DN der OU>“ /D Jeder:SDDT
In der Kommandozeile (CMD) lässt sich mit einer FOR-Schleife und den ds*-Tools die ab Windows Server 2003 "on Bord" sind, eine OU samt den untergeordneten OUs vor dem versehentlichen Löschen wie folgt schützen. Die Objekte wie z.B. Benutzer-, Gruppen- oder Computerobjekte die sich innerhalb dieser OUs befinden, werden dabei aber nicht vor dem versehentlichen Löschen geschützt:
FOR /F "tokens=*" %i in ('Dsquery OU "<DN der OU>" -Limit 0') do Dsacls %i /D "Jeder:SDDCDT"
Alle OUs innerhalb einer Domäne lassen sich in einer CMD mit dieser FOR-Schleife vor dem versehentlichen Löschen schützen:
FOR /F "tokens=*" %i in ('Dsquery OU -Limit 0') do Dsacls %i /D "Jeder:SDDCDT"
Über die AD-Powershell lässt sich diese Option auf einer OU wie folgt aktivieren:
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentialDeletion 1
bzw.
Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentialDeletion $true
Auf allen bestehenden OUs lässt sich die Option wie folgt aktivieren:
Get-ADOrganizationalUnit -Filter * | Set-ADOrganizationalUnit –ProtectedFromAccidentialDeletion 1
Deaktivieren lässt sich die Option „Objekt vor zufälligem Löschen schützen“ in der AD-PowerShell wie folgt:
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentialDeletion 0
oder
Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentialDeletion $false
Wird eine bestehende Domäne auf mindestens „Windows Server 2008“ aktualisiert, wird bei bestehenden Objekten diese Option nicht automatisch aktiviert. Auch nach dem installieren einer neuen Windows Server 2008 Domäne ist auf den bestehenden Objekten die Option „Objekt vor zufälligem Löschen schützen“ nicht aktiv. Der Schutz ist standardmäßig nur beim erstellen von neuen OUs ab Windows Server 2008 aktiviert, nicht jedoch beim erstellen von Benutzer-, Gruppen- oder Computerkonten bzw. AD-Standorten und Subnetzen.
Ist hingegen dieser Schutz auf einer OU aktiviert und man möchte diese OU verschieben, erhält man folgende Fehlermeldung. Denn zum Verschieben einer OU benötigt man das Löschrecht am Quell- und Schreibrecht am Zielort. Das Verschieben der OU ist erst dann möglich, wenn die Option deaktiviert wurde.
Das gilt natürlich auch beim löschen einer OU. Erst wenn die Option deaktiviert ist, kann die OU nach bestätigen der Sicherheitsabfrage gelöscht werden. Spätestens mit dieser Option gehört das versehentliche Löschen eines Objekts endlich der Vergangenheit an.
Wer hat den Benutzer gelöscht?
Wenn nun doch mal ausversehen z.B. das Benutzerobjekt des GFs gelöscht wurde, möchte man evtl. aufklären wer das Benutzerobjekt auf welchem DC gelöscht hat. Im Sicherheitsprotokoll des DCs auf dem das Objekt gelöscht wurde, wird unter Windows Server 2003 die EventID 630 und unter Windows Server 2008 sowie Windows Server 2008 R2 die EventID 4726 protokolliert. Denn standardmäßig wird unter Windows Server 2003 und Windows Server 2008 R2 beim Löschen eines Benutzerkontos ein Eventlogeintrag generiert, nicht jedoch unter Windows Server 2008.
Unter Windows Server 2008 muss zuerst die Unterkategorie Verzeichnisdienständerungen mit der Option Erfolgreich durch den folgenden Befehl aktiviert werden:
Auditpol /set /subcategory:Verzeichnisdienständerungen /success:enable
Erst danach wird das Löschen eines Objekts auch unter Windows Server 2008 protokolliert.
Active Directory Domain Services (AD DS) - Protokollierung
Achtung: Eine Protokollierung ist vom Betriebsrat bzw. Datenschutzbeauftragten zu genehmigen!
Die Information auf welchem DC das Objekt gelöscht wurde, wird aber nicht zwischen den DCs repliziert. Die Aufgabe besteht also darin, herauszufinden wann das Benutzerkonto auf welchem DC gelöscht wurde, um anschließend den Eventlogeintrag ausfindig zu machen. Sofern der Eventlogeintrag natürlich noch auf dem betroffenen DC existiert und nicht überschrieben wurde.
Auch das Löschen von Gruppen wird standardmäßig mit folgenden EventIDs protokolliert:
Unter Windows Server 2003
- Domänenlokale Sicherheitsgruppe = EventID 638
- Globale Sicherheitsgruppe = EventID 634
- Universelle Sicherheitsgruppe = EventID 662
- Domänenlokale Verteilergruppe = EventID 652
- Globale Verteilergruppe = EventID 657
- Universelle Verteilergruppe = EventID 667
Unter Windows Server 2008 und Windows Server 2008 R2
- Domänenlokale Sicherheitsgruppe = EventID 4734
- Globale Sicherheitsgruppe = EventID 4730
- Universelle Sicherheitsgruppe = EventID 4758
In kleineren AD-Umgebungen lassen sich die Eventlogs auf den DCs vielleicht noch schnell und vor allem manuell durchforsten, doch in großen bzw. weltweiten AD-Umgebungen ist das schier eine unmögliche Aufgabe. Zumindest nicht ohne Zusatzwerkzeuge wie z.B. SCOM, Log Parser oder EventComb.
Doch es gibt auch eine einfache Methode, um den Übeltäter ausfindig zu machen. Mit Hilfe von LDP und REPADMIN kann man in Erfahrung bringen, auf welchem DC das Objekt wann zu welcher Uhrzeit gelöscht wurde. Anschließend öffnet man das Sicherheitsprotokoll des betroffenen DCs und kann anschließend in der Beschreibung des Eventlogeintrags erkennen, wer das Objekt gelöscht hat. Es spielt auch keine Rolle ob unter Windows Server 2008 R2 der AD-Papierkorb aktiviert ist oder nicht.
Dazu sind die folgenden Schritte notwendig.
In LDP
Mit LDP gilt es zuerst herauszufinden, wie der Distinguished Name (DN) des gelöschten Objekts im Deleted Objects Container das sich in der Domänenpartition befindet lautet.
- Im ersten Schritt verbindet man sich mit einem DC aus der Domäne, in der das Objekt gelöscht wurde. Unter Windows 2000 und Windows Server 2003 wählt man im Menü „Connection – Connect…“ und unter Windows Server 2008 sowie Windows Sever 2008 R2 „Remotedesktopverbindung – Verbinden…“ und gibt den DC an, mit dem man sich verbinden möchte.
- Im zweiten Schritt binded man sich mit dem AD. Unter Windows 2000 und Windows Server 2003 wählt man dazu im Menü „Connection – Bind“ und unter Windows Server 2008 und Windows Server 2008 R2 „Remotedesktopverbindung – Gebunden…“.
- Danach wählt man im Menü unter Windows 2000 und Windows Server 2003 „Options – Controls“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Optionen – Steuerelemente“. Im darauf erscheinenden Fenster „Controls“ bzw. „Steuerelemente” fügt man das LDAP-Control „Return deleted objects“ mit der OID (Object Identifier) 1.2.840.113556.1.4.417 hinzu.
-
Als nächstes ruft man unter Windows 2000 und Windows Server 2003 im Menü „Browse - Search“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Durchsuchen - Suchen“ das Suchfenster auf. Dort gibt man als Basis-DN den „Deleted Objects“ Container in der Domänenpartition an. Dieser lautet: CN=Deleted Objects,DC=<Domäne>,DC=<de>
Im Feld Filter gibt man die Kriterien an, nach denen man die Suche im Container “Deleted Objects” durchführen möchte. Ist der Benutzeranmeldename (Prä-Windows 2000), also das Attribut sAMAccountName bekannt, trägt man in dem Feld sAMAccountName=<Benutzeranmeldename> ein. Es kann natürlich auch ein anderes Attribut angegeben werden, dass das gewünschte Benutzerobjekt identifiziert.
Als Scope/Bereich wählt man OneLevel/Eine Ebene aus. Wählt man als Suchbereich Subtree/Unterstruktur aus, funktioniert das ebenfalls. Unter Windows Server 2008 und Windows Server 2008 R2 gibt man im Feld „Attribute“ die Attribute an, die in der rechten Hälfte von LDP, im Suchergebnis zusätzlich zum DN angezeigt werden sollen. Gibt man keine Attribute an, werden alle Attribute des gelöschten Objekts angezeigt.
- Anschließend ruft man mit einem Klick auf Optionen die Suchoptionen auf und konfiguriert die Einstellungen wie folgt. Mit einem Klick auf OK übernimmt man die vorgenommenen Einstellungen.
- Unter Windows 2000 und Windows Server 2003 muss man vorher auf Options klicken, um die gewünschten Attribute und die weiteren Einstellungen vornehmen zu können.
-
Führt man die Suche nun mit einem Klick auf Run/Ausführen aus, erscheint in der rechten Hälfte von LDP unter anderem der gesuchte DN des gelöschten Benutzerobjekts. Dieser sieht z.B. so aus: Dn: CN=Yusuf Dikmenoglu\0ADEL:3e9e243e-8ba9-473a-a1ee-f1b001337923,CN=Deleted Objects,DC=ad2008R2,DC=dikmenoglu,DC=de
In REPADMIN
Da nun bekannt ist wie der DN des gelöschten Benutzerobjekts lautet, gilt es auf einem DC in der Domäne in der das Benutzerobjekt gelöscht wurde, den folgenden REPADMIN-Befehl in der Kommandozeile auszuführen. Die Ausgabe von REPADMIN wird zur besseren Übersicht in eine Textdatei exportiert.
Repadmin /showobjmeta <DC> "CN=Yusuf Dikmenoglu\0ADEL:2ffa7423-7b00-4962-96f6-69d052e08c51,CN=Deleted Objects,DC=ad2008r2,DC=dikmenoglu,DC=de" > C:\Repadmin.txt
Entscheidend in der Ausgabe ist das Attribut isDeleted.
Daraus kann man erkennen, dass das Benutzerobjekt am 14.11.2009 um 23:05:08 Uhr auf dem DC R2DCON01 gelöscht wurde. Nun kann man hoffen, dass auf dem DC der erwähnte Zeitpunkt im Sicherheitsprotokoll noch nicht überschrieben wurde. Wenn der Eintrag noch existiert, findet man in der Beschreibung des Eventlogeintrags den Übeltäter.
Weitere Informationen:
Der Container Deleted Objects
Repadmin /showobjmeta
|