Es gibt seit Windows 2000 ein mitgeliefertes Tool zur Bearbeitung von AD-Daten von der Kommandozeile aus: ldifde.exe. Es arbeitet mit Datensätzen, die zeilenweise eingelesen werden. Datensätze sind durch Leerzeilen voneinander getrennt. Diese werden via LDAP in das Active Directory geparsed.
Beide Tools können auch Userdaten exportieren – User ändern kann nur ldifde.exe. Da ich zu ldifde deutlich weniger Dokumentation gefunden habe, als zu csvde (zu dem es auf dieser Webseite bereits mehrere Artikel gibt), gehe ich hier auf die Möglichkeiten von ldifde näher ein.
Ich schätze persönlich die Zeilenorientiertheit von ldifde, da man nicht Gefahr läuft, die maximale Zeilenlänge zu erreichen. Um trotzdem die Vorteile von Excel bei der Verwaltung der Userinformationen nutzen zu können (weshalb viele auf die Nutzung von csvde fokussiert sind), habe ich einen weiteren Artikel zur Nutzung von ldifde-Templates in Verbindung mit GNU Awk verfaßt.
Wenn für die Migration das ADMTv2 zu unflexibel ist, hat man damit sämtliche Usermigrationsschritte in der eigenen Hand. Das Setzen der SIDHistory kann dabei ebenfalls kommandozeilengesteuert erfolgen.
Import einer ldf-Datei:
ldifde -i -f <dateiname>
Export in eine .ldf-Datei:
ldifde -f <dateiname> -d "<rootDN>" -r "(<filter>)" -l "<list>"
-d bezeichnet den Root-Pfad zu der OU, in der sich das/die Objekt(e) befinde(n). Dabei wird quasi rückwärts gelesen: Beispiel für die OU mit dem Namen ROOT in der Domäne firma.local, wobei die OU in der obersten Hierarchiebene liegt: "ou=ROOT,dc=firma,dc=local"
-r bezeichnet den Typ des Objekts, das man exportieren will: "(objectCategory=organizationalUnit)", "(objectCategory=person)", "(objectCategory=group)", "(objectCategory=contact)"
-l bezeichnet ein oder mehrere AD-Attribut(e), die man exportieren will. Für -l kann man alle Attribute, die ein AD-Objekt haben kann, durch Kommata getrennt, angeben: "objectClass,ou,name"
-k ignoriert beim Import die Fehlermeldungen 'Constraint Violation' und 'Object Already Exists'
-y benutzt beim Import 'lazy commit' benutzt, was die Performance in großen Umgebungen verbessert
Eine UND-Verknüpfung mit AD-Attributen zum Filtern ist mit "(&(..))" möglich. Die Nutzung von Wildcards ist dabei erlaubt. Alle Benutzer deren Vorname 'Max' lautet, kann man also folgendermaßen filtern: "(&(objectCategory=person)(givenname=Max))". Alle Benutzer, deren Vorname 'Max' lautet und deren Nachname mit 'A' beginnt: "(&(objectCategory=person)(givenname=Max)(sn=A*))"
Änderbare Attribute (modify): sn, c, countryCode, displayName, logonHours, countryCode, sAMAccountName, userPrincipalName, company, department, streetAddress, postalCode, l, st, co, mail, givenName, physicalDeliveryOfficeName, facsimileTelephoneNumber, mobile
Nicht mit modify änderbare Attribute (moddn): dn, cn, name, distinguishedName
Um diese Attribute abändern zu können, muss der RDN geändert werden. Ein ldifde-Template dazu könnte folgendermaßen aussehen:
dn: CN=MaxM,OU=Migration,DC=firma,DC=local
changetype: moddn
newrdn: cn=Mustermann, Max
deleteoldrdn: 1
Man kann mittels ldifde auch Kennworte setzen. Voraussetzung dafür ist eine SSL-Verbindung mit 128 Bit Verschlüsselung mittels LDAP: How to Set a User's Password with Ldifde
dn: CN=TestUser,DC=testdomain,DC=com
changetype: modify
replace: unicodePwd
unicodePwd::IgBuAGUAdwBQAGEAcwBzAHcAbwByAGQAIgA=
{mospagebreak}
Um jetzt einzelne Attribute abzuändern, benötigt man eine ldifde-Datei mit entsprechenen Steuerbefehlen. Dabei können auch mehrere Operationen pro User und mehrere User hintereinander bearbeitet werden. Anbei ein Beispiel für die Änderung einiger Attribute für den User 'MMustermann' in der Domöäne firma.local. Hinterher wird der User unter 'Mustermann, Max' zu finden sein. Die Namensangabe in der Emailadresse wird jedoch 'Max Mustermann' lauten:
dn: CN=MMustermann,OU=Migration,DC=firma,DC=local
changetype: modify
replace: sn
sn: Mustermann
–
replace: c
c: DE
–
replace: countryCode
countryCode: 276
–
replace: displayName
displayName: Max Mustermann
–
replace: logonHours
logonHours:: ////////////////////////////
–
replace: sAMAccountName
sAMAccountName: MMustermann
–
replace: userPrincipalName
userPrincipalName: MMustermann@firma.local
–
replace: company
company: Firma GmbH
–
replace: department
department: Marketing
–
replace: streetAddress
streetAddress: Musterstrasse 1
–
replace: postalCode
postalCode: 12345
–
replace: l
l: Musterort
–
replace: st
st: Hamburg
–
replace: co
co: GERMANY
–
replace: mail
mail: MMustermann@firma.de
–
replace: givenName
givenName: Max
–
replace: physicalDeliveryOfficeName
physicalDeliveryOfficeName: Raumnummer 1029
–
replace: facsimileTelephoneNumber
facsimileTelephoneNumber: 32156
–
replace: mobile
mobile: 0172-12345
–
delete: description
–
replace: info
–
changetype: modrdn
newrdn: cn=Mustermann, Max
deleteoldrdn: 1
Gruppenzugehörigkeiten lassen sich auf diesem Weg auch ändern. Dabei ist zu beachten, dass die Änderung an der Gruppe ansetzen muss, nicht am Benutzer. Man fügt oder entfernt also Benutzer in/aus einer Gruppe:
dn: CN=Test,OU=Migration,DC=firma,DC=local
changetype: modify
replace: member
member: CN=Mustermann, Max,OU=Migration,DC=firma,DC=local
member: CN=Musterfrau, Anna,OU=Migration,DC=firma,DC=local
–
Bei der Erzeugung von Gruppen kann man den Gruppentyp nicht namentlich mitgeben. Der Typ ist in bestimmten Zahlenwerten codiert. Mit folgendem Template legt man je eine Gruppe eines jeden Typs im AD firma.local in der OU Migration an:
# Universal Security Group
dn: CN=G_Universal,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_Universal
groupType: -2147483640
objectClass: group
sAMAccountName: G_Universal
# Global Security Group
dn: CN=G_Global,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_Global
groupType: -2147483646
objectClass: group
sAMAccountName: G_Global
# Domain local Security Group
dn: CN=G_Local,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_Local
groupType: -2147483644
objectClass: group
sAMAccountName: G_Local
# Universal Distribution Group
dn: CN=G_DL_universal,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_DL_universal
groupType: 8
objectClass: group
sAMAccountName: G_DL_universal
# Global Distribution Group
dn: CN=G_DL_global,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_DL_global
groupType: 2
objectClass: group
sAMAccountName: G_DL_global
# Domain local Distribution Group
dn: CN=G_DL_local,OU=Migration,DC=firma,DC=local
changetype: add
cn: G_DL_local
groupType: 4
objectClass: group
sAMAccountName: G_DL_local
Eine OU läßt sich ebenso einfach erzeugen:
dn: OU=Migration,DC=firma,DC=local
changetype: add
objectClass: organizationalUnit
ou: Migration
name: Migration
Eine Userumbennennung läßt sich auch prima mit einem Verschieben in die Ziel-OU kombinieren:
dn: CN=MMustermann,OU=Migration,DC=firma,DC=local
changetype: moddn
newrdn: Mustermann, Max
deleteoldrdn: 1
newsuperior: ou=Mitarbeiter,dc=firma,dc=local
Die Übernahme der SIDHistory kann man mittels des VB-Skriptes SIDHist.vbs aus dem Support Tools selbst vornehmen:
sidhist.vbs /srcdc:<dcname> /srcdom:<domain> /srcsam:<name> /dstdc:<dcname> /dstdom:<domain> /dstsam:<name>
- /srcdc – source domain controller NetBIOS computer name (without leading )
- /srcdom – source domain NetBIOS name
- /srcsam – source principal SAM name
- /dstdc – destination domain controller NetBIOS computer name (without leading )
- /dstdom – destination domain DNS name
/dstsam – destination principal SAM name
http://faq-o-matic.net/?p=577