Dem Administrator steht seit Windows Server 2003 in der Microsoft Management Console (MMC) Active Directory-Benutzer und –Computer (dsa.msc)
die Funktion Gespeicherte Abfragen zur Verfügung. In diesem Ordner hat man die Möglichkeit Abfragen zu erstellen, bearbeiten und zu speichern.
Dabei ist es auch möglich, eigene benutzerdefinierte Abfragen zu erstellen. Abfragen wurden früher aufwändig mit ADSI-Skripten erstellt.
Heute lässt es sich „recht einfach“ in dem Snap-In „Active Directory-Benutzer und –Computer“ definieren.
Somit hat der Administrator die Möglichkeit, wiederkehrende Abfragen nicht jedes Mal neu zu erstellen,
sondern die bereits getätigten Abfragen erneut zu nutzen.
Die durchgeführten Abfragen werden unter dem angemeldeten Benutzerkonto automatisch nur in der MMC gespeichert, in der sie durchgeführt wurden.
Auch wenn man sich mehrere MMCs mit dem Snap-In „Active Directory-Benutzer und –Computer“ erstellt, wird die Abfrage nur in der einen MMC gespeichert,
in der sie durchgeführt wurde. Man könnte aber eine MMC erstellen (Start-Ausführen-MMC), in dieser das Snap-In „Active Directory-Benutzer und –Computer“
hinzufügen, die gewünschten Abfragen tätigen und die MMC (als MSC-Datei) auf einem Netzlaufwerk speichern, damit andere Kollegen diese nutzen können.
Des Weiteren besteht die Möglichkeit, die Abfragen im XML-Format zu exportieren und in einer anderen MMC bzw. auf einem anderen Client, zu importieren.
Eine Abfrage erstellt man folgendermaßen:
- Zuerst gilt es das Snap-In Active Directory-Benutzer und –Computer zu starten.
- Mit einem Rechtsklick auf Gespeicherte Abfragen gilt es das Kontextmenü aufzurufen.
- Anschließend wählt man den Punkt Neu und bekommt die Auswahl zwischen Abfrage und Ordner.
Durch erstellen von Ordnern kann man sich eine eigene Abfrage-Struktur aufbauen und lässt sich dadurch, besser verwalten.
- Wurde der Punkt Abfrage ausgewählt, öffnet sich als nächstes ein Fenster das Neue Abfrage lautet.
Dort ist es möglich, der zu erstellenden Abfrage einen Namen und eine Beschreibung, die die eigentliche Abfrage evtl. etwas erläutert, einzugeben.
- Im Feld Abfragestamm gilt es den Container auszuwählen (mit Durchsuchen), im dem die Suche starten soll.
Möchte man alle untergeordneten Container des ausgewählten Containers in die Suche mit einbeziehen, so ist es notwendig das Kontrollkästchen
Untergeordnete Container miteinbeziehen zu aktivieren.
- Als nächstes gilt es mit einem Klick auf Festlegen… die gewünschte Abfrage zu definieren.
Der Vorteil an dieser Aufgabe ist, dass keinerlei administrative Rechte notwendig sind. Daher bietet es sich an, das Adminpak (von einem
Windows Server 2003 DC oder Mitgliedsserver aus dem Verzeichnis %windir%\system32\adminpak.msi) auf einer Admin-Workstation
zu installieren und die Abfrage mit Benutzerrechten auszuführen. Möchte man z.B. nur die Active Directory Snap-Ins installieren,
so lässt sich das auf folgende Art realisieren:
msiexec /i adminpak.msi ADDLOCAL=FeADTools /qb
How to use Adminpak.msi to install a specific server administration tool in Windows
Beispiel LDAP-Abfragen
Möchte man z.B. eine eigene Abfrage definieren, so vergibt man der Abfrage einen Namen und wenn gewünscht eine Beschreibung,
wählt anschließend den Abfragestamm und klickt auf Festlegen… Im darauf erscheinenden Fenster gilt es im Feld Suchen:
die Benutzerdefinierte Suche auszuwählen. Anschließend muss im Reiter Erweitert der LDAP-Filter eingegeben werden.
Im folgenden sind einige LDAP-Filter aufgeführt.
Benutzer Filter
Alle Benutzer die eine E-Mail Adresse in den Benutzereigenschaften eingetragen haben, können mit diesem LDAP-Filter angezeigt werden:
(objectCategory=person)(mail=*)
Möchte man nur die Benutzer angezeigt bekommen, die keine E-Mail Adresse eingetragen haben, so wäre dieser Filter zu verwenden:
(objectCategory=person)(!mail=*)
Alle gesperrten Benutzer anzeigen (zu oft falsch eingegebenes Kennwort):
(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))
Benutzerkonten die ab dem 01.01.2010 erstellt wurden, kann man sich mit folgendem Filter anzeigen lassen:
(objectCategory=person)(whenCreated>=20100101000000.0Z)
Alle aktiven Benutzerkonten (also keine deaktivierten Benutzer) anzeigen, die ab dem 01.01.2010 erstellt wurden
(&(sAMAccountType=805306368)(whenCreated>=20100101000000.0Z)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
Alle Benutzerkonten anzeigen, die nach dem 01.01.2010 geändert wurden:
(&(sAMAccountType=805306368)(whenChanged>=20100101000000.0Z))
Alle Benutzer anzeigen, die sich seit dem 10.01.2010 nicht mehr angemeldet haben:
(&(&(objectCategory=person)(objectClass=user)(LastLogonTimeStamp<=129076122047040000)))
Alle "aktivierten" (und keine deaktivierten) Benutzer anzeigen, die bei der nächsten Anmeldung ihr Kennwort ändern müssen:
(objectCategory=person)(objectClass=user)(pwdLastSet=0)(!useraccountcontrol:1.2.840.113556.1.4.803:=2)
Alle Benutzer die bei ihrer nächsten Anmeldung ihr Kennwort ändern müssen, lassen sich auf diese Art anzeigen:
(&(objectCategory=person)(pwdLastSet=0))
Der LDAP-Filter der alle deaktivierten Benutzerkonten anzeigt, wäre dieser:
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))
Der Filter zum anzeigen von nicht deaktivierten Benutzerkonten (also lediglich aktive Benutzerkonten), sieht wie folgt aus:
(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
Die Abfrage würde mit Dsquery zusammen mit Dsget wie folgt aussehen:
Dsquery User <DN des Containers> | Dsget User -samid -disabled
Um sich alle Benutzer anzuzeigen, die Mitglied einer bestimmten Gruppe sind, wäre dieser LDAP-Filter anzuwenden:
(objectCategory=user)(memberOf=CN=Techniker,CN=Users,DC=intra,DC=dikmenoglu,DC=de)
In diesem Beispiel befindet sich die Gruppe Techniker im Standard-Container Users und die Domäne lautet intra.dikmenoglu.de.
Damit alle Benutzer angezeigt werden, die nicht in einer bestimmten Gruppe Mitglied sind, gilt es diesen Filter zu verwenden:
(&(objectCategory=person)(objectClass=user)(!memberof=CN=GRUPPE,CN=Users,DC=DOMÄNE,DC=TLD))
Mit Dsquery würde die Abfrage folgendermaßen aussehen:
dsquery * domainroot -filter "(&(objectCategory=person)(objectClass=user)(!memberof=CN=GRUPPE,CN=Users,DC=DOMÄNE,DC=TLD))" -limit 1000
Die Benutzerkonten bei denen in den Benutzereigenschaften das Kontrollkästchen Kennwort läuft nie ab (z.B. bei Dienstkonten) aktiviert sind, lassen sich auf diese Weise anzeigen:
(&(objectcategory=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))
Alle Benutzer anzeigen, die nichts im Profilpfad eingetragen haben:
(&(objectCategory=person)(!profilepath=*))
Alle Benutzer anzeigen, die KEIN LoginSkript eingetragen haben:
(&(objectcategory=person)(!scriptPath=*))
Alle Benutzer anzeigen, die ein bestimmtes LoginSkript eingetragen haben:
(&(objectCategory=person)(scriptPath=Login.bat))
Alle Benutzer anzeigen, die sich noch NIE angemeldet haben:
(&(objectCategory=person)(objectClass=user))(|(lastLogon=0)(!(lastLogon=*)))
Alle Benutzer anzeigen, die KEINEN Vorgesetzten eingetragen haben:
(&(objectCategory=person)(!directreports=*))
Alle Objekte anzeigen, in im Feld Abteilung, Beschreibung oder Firma "AD" eingetragen haben:
(|(department=AD)(company=AD)(description=AD))
Alle Benutzerkonten anzeigen, die keine Beschreibung haben:
(&(objectCategory=person)(!description=*))
Alle Benutzerkonten anzeigen, die am 01.01.2010 abgelaufen sind:
(&(objectCategory=person)(accountExpires=129068604000000000))
Alle Benutzer die eine Handynummer beginnend mit 0151 oder 0171 anzeigen:
(&(objectCategory=person)(|(mobile=0151*)(mobile=0171*)))
Alle Benutzer mit dem Vornamen "Yusuf" anzeigen:
(&(objectCategory=person)(CN=Yusuf*))
Alle Benutzer mit dem Vornamen Yusuf oder Kaan anzeigen:
(objectCategory=person)(|(CN=Yusuf*)(CN=Kaan*))
Alle Benutzer anzeigen, die sich einwählen dürfen:
(&(objectCategory=person)(msNPAllowDialin=TRUE))
Alle Benutzer anzeigen die 2 Mal (oder mehr) ihr Kennwort falsch eingegeben haben:
(&(objectCategory=person)(badPwdCount>=2))
Alle Benutzer anzeigen, ausser Fritz:
(&(objectCategory=person)(!cn=Fritz*))
Gruppen Filter
Alle domänenlokale-, globale- und universelle Sicherheitsgruppen werden hiermit angezeigt:
(groupType:1.2.840.113556.1.4.803:=2147483648)
Alle domänenlokale Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483644))
Alle globale Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483646))
Alle universellen Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483640))
Alle domänenlokale Verteilergruppen anzeigen:
(&(objectCategory=group)(groupType=4))
Alle Verteilergruppen anzeigen:
(&(objectCategory=group)(!groupType:1.2.840.113556.1.4.803:=2147483648))
Alle globale Verteilergruppen anzeigen:
(&(objectCategory=group)(groupType=2))
Alle universelle Verteilergruppen anzeigen:
(&(objectCategory=group)(groupType=8))
Alle Gruppen anzeigen, die keine Mitglieder enthalten (also leere Gruppen):
(&(objectClass=group)(!member=*))
Möchte man sich alle Gruppen anzeigen, in denen ein bestimmter Benutzer (direkt, nicht verschachtelt) Mitglied ist, so würde der Filter wie folgt aussehen:
(&(objectCategory=group)(member=CN=Yusuf,CN=Users,DC=intra,DC=dikmenoglu,DC=de))
In diesem Beispiel befindet sich der Benutzer Yusuf im Standard-Container Users und die Domäne lautet intra.dikmenoglu.de.
Alle Gruppenkonten anzeigen, die keine Beschreibung eingetragen haben:
(&(objectCategory=group)(!description=*))
Alle Gruppen anzeigen die mit "AD" oder "LDAP" anfangen:
(objectCategory=group)(|(CN=AD*)(CN=LDAP*))
Computer Filter
Alle NT4 Computer anzeigen:
(&(objectCategory=computer)(operatingSystemVersion=4*))
Alle Windows 2000 Computer in der Domäne anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 2000*))
Alle Windows Server 2003 mit Service Pack 1 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))
Alle Windows Server 2008 (aber kein 2008 R2) anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))
Alle Windows Server 2008 R2 (alle Editionen) anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))
Alle deaktivierten Computer-Konten in der Domäne, lassen sich mit diesem Filter anzeigen:
(&(objectclass=computer)(userAccountControl:1.2.840.113556.1.4.803:=2))
Die Benutzer- sowie Computerkonten die eine Beschreibung enthalten, können mit diesem Filter aufgelistet werden:
(&(description=*)(|(objectCategory=computer)(objectCategory=user)))
Alle Domänencontroller anzeigen:
(&(objectCategory=Computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))
Nur Windows Server 2003 DCs anzeigen:
(&(primaryGroupId=516)(objectCategory=computer)(operatingSystem=Windows Server 2003*))
Nur Windows Server 2003 Mitgliedsserver anzeigen, aber KEINE DCs:
(&(samAccountType=805306369)(!(primaryGroupId=516))(objectCategory=computer)(operatingSystem=Windows Server 2003*))
Nur Windows Server 2008 DCs anzeigen:
(&(primaryGroupId=516)(objectCategory=computer)(operatingSystem=Windows Server* 2008*))
Nur Windows Server 2008 Mitgliedsserver anzeigen, aber KEINE DCs:
(&(samAccountType=805306369)(!(primaryGroupId=516))(objectCategory=computer)(operatingSystem=Windows Server* 2008*))
Alle Windows XP Clients mit Service Pack 2 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))
Alle Windows Vista Clients mit Service Pack 1 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))
Alle Windows 7 Clients anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 7*))
Alle Windows 7 "Ultimate" Clients anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 7 Ultimate))
Alle globalen Kataloge (GCs) in der Gesamtstruktur anzeigen:
(&(objectCategory=nTDSDSA)(options:1.2.840.113556.1.4.803:=1))
Exchange Abfragen
Alle Kontakte einer Domäne die keiner Gruppe zugeordnet sind, werden mit dem folgenden Filter angezeigt:
(objectclass=contact)(!(memberof=*))
Alle Benutzer anzeigen, die nicht den Standardwert für ihre Exchange-Postfachgröße verwenden:
(&(objectCategory=user)(mDBUseDefaults=FALSE))
Alle Konten anzeigen die eine bestimmte Exchange Mailadresse eingetragen haben:
(&(objectClass=user)(proxyAddresses=SMTP:mail@blog.dikmenoglu.de))
Benutzer, Kontakte und Verteilergruppen die nicht in der GAL auftauchen (ausgenommen Public Folder):
(&(msExchHideFromAddressLists=TRUE)(!objectClass=publicFolder))
Alle Benutzer anzeigen, die keine Exchange Mailadresse (proxyAddresses) haben:
(&(objectCategory=person)(objectClass=user)(!proxyAddresses=*))
Weitere Informationen:
Gespeicherte Abfragen für dsa.msc
Search Filter Syntax
How to use the PrimaryGroupID attribute to find the primary group for a user
How to query Active Directory by using a bitwise filter
Das Active Directory speichert alle Informationen der bestehenden Objekte in der Datenbank NTDS.DIT. Im Laufe der Zeit kann es nötig sein,
dass Änderungen an diesen (sei es bei einzelnen oder mehreren) Objekten vorgenommen werden müssen.
Das Standard Datei-Format das in den LDAP Implementationen verwendet wird, nennt sich LDAP Data Interchange Format (LDIF) und wird in RFC 2849 beschrieben.
Das Tool mit dem sich Active Directory Objekte exportieren sowie importieren lassen, nennt sich LDAP Data Interchange Format Data Exchange,
kurz LDIFDE. Des Weiteren kann man einen Im- sowie Export mit CSVDE durchführen.
Mit LDIFDE, das neben CSVDE seit Windows 2000 im Serverbetriebssystem enthalten ist, kann man (mehrere) Objekte wie es Benutzer, Gruppen, Drucker, Server,
Organisationseinheiten, Domänen etc. darstellen, aus dem Active Directory exportieren, bearbeiten, löschen, importieren, Daten hinzufügen und sogar
das Schema erweitern. Ebenfalls ist es möglich, Benutzer und Gruppen aus dem Active Directory in andere Applikationen bzw. Dienste zu exportieren
oder diese LDAP-konform für einen Import in einen anderen Verzeichnisdienst bereitzustellen. Natürlich können LDIF-Daten auch aus anderen Verzeichnisdiensten,
ebenso in das Active Directory importiert werden.
LDIFDE ist ein Kommandozeilentool und befindet sich neben CSVDE (Comma Separated Value Data Exchange) im %windir%\system32 Verzeichnis.
Der Vorteil von LDIFDE gegenüber CSVDE ist, dass mit LIDIFDE die Bearbeitung bestehender Objekte möglich ist.
Wenn bei einem Export von Benutzer- bzw. Gruppen-Informationen ohne Filter gearbeitet wurde, kann die exportierte Datei so nicht erneut importiert werden.
Eine ungefilterte LDIF Export Datei exportiert alle Daten ohne zu prüfen, ob die Felder vom Active Directory geschützt sind und somit nur vom System gesetzt
werden können (system only).
Fehlermeldungen wie es die folgenden darstellen:
"Die Änderung war aus Sicherheitsgründen nicht erlaubt."
oder
"Der Zugriff auf das Attribut ist unzulässig, da das Attribut Eigentum der Sicherheitskontenverwaltung (SAM) ist.“
zeigen das ganz deutlich.
Wenn diese Fehlermeldungen bei einem Import der LDF Datei erscheinen, ist es ein klarer Indiz dafür, dass in der Import-Datei Einträge vorhanden sind,
die nicht vom Administrator gesetzt werden können.
Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM)
Mit dem Schalter -o kann man die Attribute angeben, die beim Export unterdrückt werden sollen. Mit folgendem Befehl werden die Benutzerdaten in der
angegebenen Domäne exportiert bis auf die Informationen, die nicht importiert werden können (alles in einer Zeile):
LDIFDE -f Export.ldf -s <DC-Name> -d "dc=<Domäne>,dc=<TLD>" -p subtree -r "(&(objectCategory=person)(objectClass=User))" -o
"badPasswordTime,badPwdCount,lastLogoff,lastLogon,logonCount,memberOf,objectGUID,objectSid,primaryGroupID,pwdLastSet,sAMAccountType"
Da es aufwändig ist mit dem Schalter -o alle einzelnen Attribute anzugeben die nicht mit exportiert werden sollen, ist es ratsam,
gleich beim Export die Systemattribute mit einem einzigen Schalter wegzulassen. Dieses ist mit dem Schalter -m möglich.
Der Befehl würde wie folgt aussehen:
LDIFDE -m -f Export.ldf -s <DC-Name> -d "dc=<Domäne>,dc=<TLD>" -p subtree -r "(&(objectCategory=person)(objectClass=User))"
Anschließend kann beim Import die Fehlertoleranz mit dem Schalter -k aktiviert werden.
LDIFDE wird standardmäßig unter dem Benutzernamen ausgeführt, unter dem man es aufruft.
Möchte man stattdessen andere Benutzerinformationen beim ausführen von LDIFDE eingeben, so ist dies mit dem Schalter -a möglich.
Die Angabe wäre folgendermaßen: -a <DN des Benutzers> Kennwort
Wenn der Benutzer YD sich in dem Container Users befindet und die Domäne intra.dikmenoglu.de lauten würde, so wäre die Eingabe wie folgt:
-a CN=YD,CN=Users,DC=intra,DC=dikmenoglu,DC=de Kennwort
Das gleiche kann mit dem Schalter -b erreicht werden.
Allerdings ist dort die Angabe wie folgt: -b <Benutzername Domäne> Kennwort
Wenn der Benutzername YD wäre und die Domäne intra.dikmenoglu.de lauten würde, so wäre die Eingabe in diesem Format:
-b yd intra.dikmenoglu.de Kennwort
Möchte man z.B. einen Export von Objekten, aus einer bestimmten Organisationseinheit (Organizational Unit, OU) tätigen,
so ist dafür der Schalter -d vorgesehen.
Beispiel: -d „OU=Technet,dc=intra,dc=dikmenoglu,dc=de“
Den Dateinamen der zur exportierenden bzw. importierenden LDF-Datei, gibt man mit dem Schalter -f an.
LDIFDE wird standardmäßig im Export Modus ausgeführt. Damit ein Import stattfinden kann, muss der Schalter -i angegeben werden.
Der Befehl, damit Benutzer von einer LDF-Datei importiert werden können, wäre folgendermaßen:
LDIFDE -i -f ExportBenutzer.ldf -s <DC-Name>
Sollen bei einem Export bloß bestimmte Attribute exportiert werden, so ist dafür der Schalter –L gedacht.
Wenn dieser Schalter nicht mit angegeben wird, werden alle Attribute exportiert.
Damit keine Binärwerte exportiert werden sollen, wird dies mit dem Schalter -n unterbunden.
Den Suchbereich gibt man mit dem Schalter -p an. Zur Verfügung stehen die drei Optionen: Base, OneLevel und Subtree.
Der Schalter -r definiert einen LDAP-Suchfilter bei einem Export.
Mit dem folgenden Befehl, exportiert man alle Computerobjekte (samt allen Attributen) von dem angegebenen Domänencontroller:
LDIFDE -f ExportComputer.ldf -s <DC-Name> -r "(objectclass=computer)"
Mit dem Schalter „-s DC-Name“ gibt man den Domänencontroller an, von dem der Export- bzw. Importvorgang getätigt werden soll.
Standardmäßig wird LDIFDE auf dem Domänencontroller ausgeführt, auf dem man es aufruft. Der Schalter -s sollte bei einem Export stets verwendet werden,
da ansonsten LDIFDE.exe sich mit dem am nähesten befindlichen Domänencontroller, auf dem der globale Katalog (Global Catalog, GC) aktiviert ist
verbindet und es dann, zu diesem Problem kommen kann:
Ldifde.exe may not export objects from Active Directory in Windows Server 2003 or Windows 2000
Weitere Schalter können auf dieser Seite eingesehen werden:
LDIFDE
Beim Import einer LDIF-Datei muss der Eintrag changeType gesetzt werden, damit beim Import klar ist, welchen Zweck dieser Import erfüllt.
Dieser kann die Werte „add, modify, moddn, modrdn oder delete“ enthalten.
Bei einem Export ist der changetype standardmäßig add.
Beispiele
Wenn alle Organisationseinheiten (OU) einer bestimmten Domäne exportiert werden sollen, so könnte der Befehl folgendermaßen aussehen:
LDIFDE -f Export-Ou.ldf -s <DC-Name> -d "dc=<Domäne>,dc=<TLD>" -p subtree -r "(objectCategory=organizationalUnit)" -l "cn,objectclass,ou"
Möchte man mit LDIFDE einen Benutzer einrichten, so ginge das auf folgende Art:
Zuerst gilt es mit einem Text-Editor (Notepad/Wordpad) eine Datei zu erstellen.
Dabei ist es wichtig, dass die Datei die Endung LDF besitzt.
Als nächstes sollten folgende Daten eingetragen werden:
DN: CN=Yusuf,CN=Users,DC=intra,DC=dikmenoglu,DC=de
Changetype: Add
CN: Yusuf Dikmenoglu
ObjectClass: User
SamAccountName: YD
GivenName: Yusuf
SN: Dikmenoglu
Nach dem speichern dieser Datei (ImportUser.ldf) ruft man folgenden Befehl für den Import auf: LDIFDE -i -f ImportUser.ldf -s <DC-Name>
Ein Benutzer kann mit LDIFDE auf folgende Weise entfernt werden (dazu wird der Distinguished Name (DN) vom Benutzerobjekt benötigt).
Der Benutzer „Yusuf“ befindet sich in der OU Technet und die Domäne lautet intra.dikmenoglu.de, so würde die Syntax wie folgt lauten:
DN: CN=Yusuf,OU=Technet,DC=intra,dc=dikmenoglu,dc=de
Changetype: Delete
Falls sich das Benutzerobjekt im Standard-Container Users befinden würde, so wäre der Befehl folgendermaßen:
DN: CN=Yusuf,CN=Users,DC=intra,dc=dikmenoglu,dc=de
Changetype: Delete
Weitere Informationen:
Using LDIFDE to import and export directory objects to Active Directory
LDIFDE - Export / Import data from Active Directory
LDIFDE - Export / Import data from Active Directory - LDIFDE commands
LDIFDE - Export / Import data from Active Directory - LDIFDE commands 2 (AN: 555636)
Leitfaden zum Importieren und Exportieren großer Datenmengen in Active Directory
How to set a user's password with Ldifde
Das Erstellungsdatum eines Benutzerobjekts, kann aus dem Active Directory abgefragt werden.
Das Attribut in dem das Datum gespeichert wird, nennt sich When-Created und wird auf andere Domänencontroller,
sowie in den globalen Katalog (Global Catalog, GC) repliziert.
When-Created
Eine Abfrage per Skript könnte folgendermaßen aussehen:
How Can I Get a List of All the Objects that have been Added to Active Directory Since a Specified Date?
Ein ähnliches Attribut ist Create-Time-Stamp (RFC 2251). Es ist zwar im Schema definiert, aber es enthält selbst keinen Wert.
Die Attributwerte werden allerdings im Moment der Abfrage errechnet. Diese Art von Attribut wird „Operational Attribute“ oder
auch „Constructed Attribute“ genannt. Da das Attribut Create-Time-Stamp „constructed“ ist, kann es nicht repliziert werden.
Sein Wert wird auch nicht in den GC übertragen.
Um die Kompatibilität mit X.500/LDAP herzustellen, erhält man bei einer Abfrage des Attributs Create-Time-Stamp,
den Wert von When-Created zurück. Möchte man dieses Attribut per Skript abfragen, so muss dies explizit über die GetInfoEx Methode erfolgen.
Create-Time-Stamp
Operational Attributes
MMC Snap-In „Active Directory-Benutzer und –Computer“
Recht einfach lässt sich das Erstellungsdatum eines Benutzerobjekts über die grafische Benutzerverwaltung anzeigen.
Im Snap-In „Active Directory-Benutzer und –Computer“ ist es notwendig, unter Ansicht die Option Erweiterte Funktionen zu aktivieren um somit,
weitere Registerkarten im Benutzerobjekt anzeigen zu lassen. Danach navigiert man zum Container Users
(worin standardmäßig die Benutzerobjekte gespeichert werden) bzw. zur Organisationseinheit (Organizational Unit, OU), in dem sich die Benutzerobjekte befinden. Anschließend ruft man, mit einem Rechtsklick auf das Benutzerobjekt, die Eigenschaften des Benutzers auf.
Im Reiter Objekt befindet sich der Eintrag "Erstellt am:".
MMC Active Directory Service Interface Editor - ADSIEdit
Es ist ebenfalls möglich, mit ADSIEdit.msc (aus den Windows Support Tools) sich das Attribut anzeigen zu lassen. Dazu gilt es,
ADSIEdit.msc über Start – Ausführen – ADSIEdit.msc aufzurufen und sich mit der Domain-Partition zu verbinden (falls noch keine Verbindung besteht).
Als nächstes erweitert man die Einträge Domain [DC-Name.<Domäne>.<TLD>] sowie den Container DC=<Domäne>,DC=<TLD>.
Im Anschluss navigiert man zum Container CN=Users bzw. OU=<OU-Name> in dem sich die Benutzerobjekte befinden und wählt mit einem Rechtsklick
auf das Benutzerobjekt CN=<Benutzername>, die Eigenschaften aus. Nun kann man im Eigenschaften-Fenster des Benutzers,
dass Attribut whenCreated kontrollieren.
Befehlszeilen-Abfrage mit DSQUERY
Neben der grafischen Oberfläche, lässt sich das Attribut auch über die Befehlszeile abfragen.
Dazu bietet sich eines der DS-Tools, dass im Windows Server 2003 Betriebssystem integriert ist an. Das Tool das sich dazu eignet, lautet dsquery.
Der Befehl für die Abfrage, könnte folgendermaßen lauten (alles in einer Zeile):
dsquery * domainroot -filter "(&(objectClass=User)(objectCategory=Person))" -attr distinguishedName sAMAccountName whenCreated -Limit 0
Dsquery
How do I know what attribute names to use when performing a 'DSQUERY *'?
Hinweis: Möchte man ausschließlich Benutzerobjekte angezeigt bekommen, so ist neben dem Attribut „ObjectClass=User”,
zusätzlich das Attribut „ObjectCategory=Person“ bzw. „ObjectCategory=User“ abzufragen.
Befehlszeilen-Abfrage mit ADFind
Ein weiteres Befehlszeilenprogramm, das auf keinem administrativen PC fehlen sollte, ist das von Joe Richards entwickelte Tool – ADFind.
Die Abfrage könnte z.B. folgendermaßen lauten:
Adfind -b DC=<Domäne>,DC=<TLD> -f “&(objectclass=user)(objectcategory=person)" sAMAccountName whencreated
Download: AdFind
Wie die Abfrage mit der AD-PowerShell aussieht, wird im folgenden Artikel beschrieben
Das Erstellungsdatum eines AD-Objekts mit der AD-PowerShell abfragen
Mit dem Server Performance Advisor (SPA) kann man Performanceprobleme, die unter anderem ein DNS-Server oder IIS hat, aufspüren.
Auch Probleme im Active Directory, z.B. bei einer Active Directory-Abfrage, können damit aufgedeckt werden.
Allerdings erwartet einem während der Installation des SPAs eine kleine Überraschung, die ich im folgenden Artikel beschreibe:
Server Performance Advisor (SPA) auf einem deutschen System
Standorte sind eine (neben Domänencontrollern) physikalische Komponente des Active Directorys. Durch das erstellen von Standorten kann:
- die Replikation (Inter-Site) zwischen Domänencontrollern (DC) optimiert (standortübergreifend werden die Daten komprimiert) und
- den Clients, der Zugriff auf Netzwerkressourcen die sich an deren physischen Standort befinden gewährleistet werden, ohne die WAN-Verbindung zu belasten.
Grundsätzlich gilt, durch das Festlegen von Standorten im Active Directory, beeinflusst man den Replikationsverkehr sowie welche Dienste von
den Clients im wesentlichen genutzt werden.
Z.B. wird ein lokaler Domänencontroller eher verwendet (Domänencontroller am Standort), als ein Domänencontroller an einem anderen Standort oder
eine lokale Replik eines DFS-Ordners wird anstelle einer Replik eines anderen Standortes bevorzugt. Weiterhin ist es möglich,
standortabhängig nach Druckern zu suchen.
Der Knowledge Consistency Checker (KCC) erstellt anhand der Standort-Informationen die optimale Replikationstopologie.
Nähere Informationen unter: Active Directory-Replikation
Was ist alles zu beachten und durchzuführen, wenn ein Domänencontroller an einen anderen bzw. neuen Standort verschoben werden soll?
- Zuerst muss die WAN-Verbindung physikalisch eingerichtet werden. Dazu müssen die jeweiligen Router in ihren Standorten aufgestellt,
eingestellt sowie das Routing konfiguriert werden.
- Wie so oft, ist das DNS ein elementarer Dienst bei diesem Vorgang. Existieren alle Unterordner (_sites, _msdcs, _tcp, _udp) in der Forward Lookup Zone (FLZ)?
Die interne DNS-Namensauflösung sollte ordnungsgemäß funktionieren und in den TCP/IP-Einstellungen sollte ein autoritativer DNS-Server
eingetragen sein (Punkt 8 beachten). Die beiden Tools DCDIAG und NetDIAG, sind hilfreiche Werkzeuge um die Ausgangsbasis zu kontrollieren.
REPADMIN und REPLMON helfen beim Aufdecken von Replikationsproblemen die sich in den Windows Support Tools befinden.
- Im MMC Snap-In „Active Directory-Standorte und –Dienste“ muss zuerst ein Standortobjekt erstellt (mit einem Rechtsklick auf Sites) und eine
Standortverknüpfung für diesen Standort ausgewählt werden. Beim Einrichten des ersten Domänencontrollers in der Gesamtstruktur wird ein
Standortobjekt mit dem Namen Standardname-des-ersten-Standorts erstellt, sowie die Standortverknüpfung DEFAULTIPSITELINK,
allerdings ohne ein Subnetzobjekt. Beide Objekte können jederzeit umbenannt werden.
- Als nächstes sollte zu einem korrekten Design, das entsprechende Subnetzobjekt erstellt (mit einem Rechtklick auf Subnets) und dem
Standort zugewiesen werden. Zum erstellen eines Subnetzobjekts werden die Informationen, Netzwerkadresse oder IP-Adressbereich sowie
die Subnetzmaske benötigt. Ein Standort kann dabei mehrere Subnetze umfassen.
- Im nächsten Schritt, gilt es eine Standortverknüpfung für die Inter-Site (standortübergreifende) Replikation zu erstellen.
Dazu erweitert man Sites, danach Inter-Site-Transports, klickt mit rechts auf den Container IP und wählt Neue Standortverknüpfung.
Danach vergibt man dieser Standortverknüpfung einen Namen und fügt zwei (oder mehr) Standorte in die Spalte Standorte in dieser Standortverknüpfung hinzu.
Wobei jede Standortverknüpfung mindestens zwei Standorte enthalten muss. Idealerweise vergibt man Namen, die zeigen welche Standorte verknüpft sind.
Als Beispiel für eine Verknüpfung zwischen Frankfurt und Berlin: FRA-BER.
- In den Eigenschaften der Standortverknüpfung können der Zeitplan (standardmäßig jederzeit), das Intervall (standardmäßig alle 180 Minuten),
die Kosten (standardmäßig 100) und das Replikationszeitfenster konfiguriert werden. Umso niedriger die Kosten sind, umso höher ist die Priorität.
- Bevor der Domänencontroller an seinen neuen Standort verschoben wird, gilt es die IP-Informationen entsprechend dem Ziel-Ort anzupassen.
Diese wären:
- IP-Adresse inklusive der Subnetzmaske
- Standardgateway
- DNS-Server Adresse
- WINS-Server Adresse
Für Details siehe: Die IP - Adresse eines Domänencontrollers ändern
- Ist auf dem Domänencontroller der DNS Dienst installiert und dieser zeigt in seinen TCP/IP-Einstellungen als Bevorzugter DNS-Server auf sich selbst,
so sollte (übergangsweise) ein zentraler/anderer DNS-Server dort eingetragen werden (bzw. ein DC/DNS des „alten“ Standorts).
Diesen Vorgang beschreibt Microsoft als Inseleffekt vermeiden
Unter Windows Server 2003 kann als Alternativer DNS-Server der DC selbst mit seiner echten IP-Adresse dort eingetragen werden.
Stattdessen wird unter Windows Server 2000 als „Bevorzugter DNS-Server“ ein zentraler DNS-Server und als „Alternativer DNS-Server“
ein anderer DNS-Server empfohlen einzutragen DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain
- Wenn von einer übergeordneten DNS-Zone eine Zonen Delegierung auf diesen DC/DNS-Server existiert,
so gilt es die IP-Adresse für diese Delegierung zu aktualisieren.
- Es sollte kontrolliert werden, ob dieser Domänencontroller ein bevorzugter Bridgeheadserver an seinem alten Standort ist.
Im Kontextmenü (Rechtsklick) des Servers (im Snap-In "Active Directory-Standorte und -Dienste", unter Sites-seinem Standort-Servers) wählt man
die Eigenschaften aus. Danach kann in der Spalte Server ist ein bevorzugter Bridgeheadserver für folgende Transporte: überprüft werden,
ob dort der Eintrag IP existiert. Mit markieren von IP und anschließend durch klicken auf Entfernen, kann der Server so konfiguriert werden,
dass er kein bevorzugter Bridgeheadserver ist. Welche Server in der Gesamtstruktur als Bridgeheadserver fungieren, kann mit ADSIEdit.msc aus den
Windows Support Tools, auf einen Blick im Configuration Container eingesehen werden.
Dort im Pfad CN=Configuration,DC=NamederRootDomäne,CN=Sites,CN=Inter-Site-Transports,
gilt es mit einem Rechtsklick auf CN=IP die Eigenschaften auszuwählen. Danach mit einem Doppelklick auf bridgeheadServerListBL sieht man
unter Values die Distinguished Names (DN) der jeweiligen Serverobjekte.
- Zum Verschieben eines Serverobjekts in einen anderen Standort, navigiert man im Snap-In „Active Directory-Standorte und –Dienste“ unter Sites auf
den Standort in dem sich das Serverobjekt befindet, erweitert Servers und klickt mit rechts auf den zu verschiebenden Server und wählt Verschieben…
Im anschließend erscheinenden Dialogfeld wählt man den Zielstandort aus und bestätigt mit OK. Danach sollte der neue Standort ausgewählt und der
Container Servers erweitert werden um zu kontrollieren, ob das Serverobjekt (sowie unterhalb dessen, dass NTDS Settings Objekt) vorhanden ist.
Verschieben eines Domänencontrollers zwischen Standorten
- Nach dem Verschieben, aktualisiert der Domänencontroller die SRV-Records im DNS entsprechend seiner neuen IP- sowie Standort-Informationen.
Genauer gesagt, aktualisiert der Netlogon-Dienst die Einträge. Dieser Vorgang kann auch manuell vollzogen werden (net stop netlogon && net start netlogon).
Falls sich der DC nicht mit seinen neuen Standort-Informationen im DNS einträgt, könnte es hilfreich sein, die Datei NETLOGON.DNS im Verzeichnis
%windir%\system32\config zu überprüfen. Zur Kontrolle hilft ein Blick in die Ereignisanzeige auf dem verschobenen Domänencontroller.
Dort sollte im Verzeichnisprotokoll nach kurzer Zeit, nicht der Netlogon-Fehler mit der Ereignis-ID 5774 erscheinen.
SRV Records Cannot Be Registered on a DNS Server
- Das DNS sollte zwingend bereinigt werden. Denn nach dem verschieben des DCs, bleiben die Einträge vom alten Standort weiterhin im DNS bestehen.
Dazu sind die SRV-Records aus dem Pfad _tcp.<Name des Standorts>._sites.dc._msdcs.Domäne.TLD vom alten Standort zu entfernen.
Ansonsten könnten sich die Clients weiterhin versuchen, an dem DC der an einen anderen Standort verschoben wurde, zu authentifizieren.
Das Resultat wären langsame Anmeldevorgänge.
Nach einem Domänencontroller-Neustart läuft die Konsistenzprüfung (KCC) zum ersten Mal nach fünf, anschließend alle 15 Minuten.
Dieser erstellt und löscht nach Bedarf die Replikationsverbindungsobjekte um die Intra- (standortintern) sowie Inter-Site (standortübergreifend)
Replikationstopologie den neuen Anforderungen anzupassen. Daher ist es wichtig, im Snap-In „Active Directory-Standorte und –Dienste“
die Standortstruktur (sowie die Subnetze) vollständig zu konfigurieren (Zeitplan+Intervall+Kosten), damit der KCC mit den eingetragenen Informationen,
die ideale Replikationstopologie berechnen kann.
Das Intervall kann mit einem Eintrag in der Registry verändert werden. Standardmäßig existieren die folgenden beiden Schlüssel nicht.
Durch erstellen dieser Schlüssel, kann Einfluss auf das Verhalten des KCC genommen werden:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Repl topology update delay (secs)
Default: 300 Sekunden (5 Minuten)
Data type: REG_DWORD
Repl topology update delay (secs)
sowie im gleichen Pfad:
Repl topology update period (secs)
Default: 900 Sekunden (15 Minuten)
Data type: REG_DWORD
Repl topology update period (secs)
Zum Schluss sollten die Dienste DNS sowie WINS kontrolliert werden.
Sind die Einträge im DNS aktualisiert worden, vor allem in dem _sites Ordner unterhalb der FLZ bzw. in der _msdcs.<FLZ> Zone?
Stimmen die Einträge im WINS, falls nicht, sind diese Registrierungen per nbtstat –RR zu forcieren oder im Ausnahmefall manuell zu korrigieren.
Zeigen die anderen Domänencontroller in den anderen Standorten den verschobenen Domänencontroller in ihren eigenen MMC Snap-Ins
"Active Directory-Standorte und –Dienste" im neuen Standort an?
Mit REPLMON sowie REPADMIN kann die Replikation überprüft werden.
Die Replikationstopologie des verschobenen Domänencontrollers sollte ebenfalls überprüft werden. Dieses kann im Snap-In „Active Directory-Standorte und –Dienste“
mit einem Rechtsklick auf die NTDS-Settings des verschobenen DCs, dann nach Auswahl von Alle Aufgaben mit einem Klick
auf Replikationstopologie überprüfen geprüft werden.
Mit REPADMIN /SHOWREPL kann ebenfalls überprüft werden, ob sich der DC an seinem neuen Standort mit den anderen Domänencontrollern repliziert.
Weiterhin kann nach dem verschieben erneut mit DCDIAG sowie NetDIAG der Domänencontroller überprüft werden. Mit beiden Tools kann sichergestellt werden,
dass der Domänencontroller seine Dienste im Active Directory nun unter der aktuellen IP-Adresse anbietet sowie erreichbar ist.
Ein Blick in das Verzeichnisdienstprotokoll das in der Ereignisanzeige enthalten ist, wäre ebenfalls sinnvoll um sicherzugehen, dass keine etwaigen Probleme bestehen.
Falls auf dem verschobenen Domänencontroller der DHCP-Dienst installiert ist, so sollte die konfigurierte IP-Bereichsoption den aktuellen IP-Informationen des neuen
Standorts angepasst werden. Die korrekte DHCP Autorisierung im Active Directory sollte jetzt ebenfalls überprüft werden.
Weitere Informationen:
Einen Standort umbenennen
Gründe für das Einrichten eines Einzelstandortes oder separater Standorte
Replikation: Standorte & Standortverknüpfungsbrücken
Konfigurieren einer Replikation zwischen Standorten
Entwerfen der Standorttopologie
KCC and Topology Generation
Using Repadmin.exe to troubleshoot Active Directory replication
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|