Bevor der erste Server, der mit einem neueren Serverbetriebssystem installiert ist als die bereits bestehenden Domänencontroller (DCs) einer Gesamtstruktur, als DC zur Gesamtstruktur hinzugefügt werden kann, muss vorher zwingend mit dem Active Directory Preparation Tool (ADPREP) das Active Directory-Schema aktualisiert werden. Erst nachdem ADPREP ausgeführt wurde, kann der neue Server als DC zur Gesamtstruktur hinzugefügt werden. Dabei muss ADPREP stets von der CD/DVD ausgeführt werden, mit dem der neue Server installiert wurde. Möchte man also einen Windows Server 2008 oder Windows Server 2008 R2 in eine Windows 2000 bzw. Windows Server 2003 Gesamtstruktur hinzufügen, so muss das ADPREP von der Windows Server 2008 bzw. Windows Server 2008 R2 DVD ausgeführt werden.
ADPREP muss aber nur dann ausgeführt werden, wenn der Server mit dem neueren Serverbetriebssystem zum DC gestuft werden soll! Wird der neue Server lediglich als Mitgliedsserver zur Domäne hinzugefügt, so muss das ADPREP nicht ausgeführt werden.
Soll der Server, der mit einem neuerem OS (Operating System = Betriebssystem) installiert ist als die existierenden DCs, zu einer bestehenden Domäne als zusätzlicher DC hinzugefügt werden, muss zuerst ADPREP /FORESTPREP auf dem Schemamaster und anschließend ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster in der Domäne ausgeführt werden, zu der der neue Server als DC hinzugefügt werden soll.
Wird jedoch mit dem neuen Server eine neue Subdomäne in einer bestehenden Gesamtstruktur erstellt, muss lediglich das ADPREP /FORESTPREP ausgeführt werden. Das ADPREP /DOMAINPREP /GPPREP muss und kann in diesem Szenario nicht ausgeführt werden, da es keine zu aktualisierende Domäne gibt. Schließlich wird mit dem neuen DC erst eine (weitere) Subdomäne erstellt.
Weitere Details beschreibt der folgende Artikel:
Das Active Directory Preparation Tool - ADPREP
Fehler die beim Ausführen von ADPREP auftreten können
- Wenn das Ausführen von ADPREP aus welchen Gründen auch immer fehl schlagen sollte, ist es empfehlenswert als erstes immer ins ADPREP-Protokoll zu schauen. Das ADPREP-Log wird im Verzeichnis %windir%\System32\Debug\Adprep\Logs erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
-
Bevor der erste Server mit neuerem OS als die bereits existierenden DCs, als DC zur Gesamtstruktur hinzugefügt werden kann, muss zuerst das ADPREP /FORESTPREP in der Kommandozeile auf dem Schemamaster ausgeführt werden. Das Benutzerkonto mit dem dieser Befehl ausgeführt wird, muss Mitglied in den Gruppen Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet. Wenn ADPREP /FORESTPREP auf dem Schemamaster mit den notwendigen Rechten ausgeführt wurde und es trotzdem zu einem Fehler führt, weil ADPREP keinen Kontakt zum Schemamaster herstellen konnte (in seltenen Fällen), sollte der Schemamaster zuerst auf einen anderen DC und erneut zurück verschoben werden. Anschließend ist der Befehl ADPREP /FORESTPREP nochmals auszuführen.
-
Befindet sich das Benutzerkonto beim ausführen von ADPREP hingegen nicht in den entsprechenden Gruppen, kommt es zu diesem Fehler: Adprep encountered a Win32 error.
Error code: 0x5 Error message: Access is denied
Das Benutzerkonto muss zum ausführen von ADPREP /FORESTPREP Mitglied in den folgenden Gruppen sein:
- Schema-Admins
- Organisations-Admins
- Domänen-Admin in der Domäne, in der sich der Schemamaster befindet. Zum ausführen von ADPREP /DOMAINPREP /GPPREP muss das Benutzerkonto Mitglied in der Gruppe Domänen-Admins in der Domäne sein, in der dieser Befehl auf dem Infrastrukturmaster ausgeführt wird.
-
Kommt es beim ausführen von ADPREP /FORESTPREP zu diesem Fehler:
Es war Adprep nicht möglich, das Schema zu erweitern.
[Status/Folgen]
Der Schemamaster schloss einen Replikationszyklus nach dem letzten Neu-Start nicht ab. Der Schemamaster muss mindestens einen Replikationszyklus, bevor das Schema erweitert werden kann, abschließen.
[Benutzeraktion]
Überprüfen Sie, dass der Schemamaster mit dem Netzwerk verbunden ist, und mit anderen Domäne-Controllern kommunizieren kann…
liegt ein AD-Replikationsproblem vor. Es ist zwingend, dass zuerst das Replikationsproblem behoben wird, bevor das Ausführen von ADPREP erfolgreich durchgeführt werden kann. Einen ersten Ansatz zur Fehlersuche bei der AD-Replikation sollte neben dem Eventlog, auch das Schweizer Messer der AD-Replikation REPADMIN zum Vorschein bringen. Mit ausführen von Repadmin /Showreps bzw. Repadmin /Showrepl auf dem Schemamaster sieht man recht schnell, mit welchen DCs der Schemamaster nicht replizieren kann.
Wenn die DCs identifiziert wurden mit denen der Schemamaster nicht replizieren kann, sollte man versuchen sich per UNC auf die DCs zu verbinden. Bekommt man auf dem Schemamaster mit \\DC-Computername und \\FQDNdesDCs keine Verbindung zu den betroffenen DCs hin, liegt entweder ein Netzwerkproblem, ein DNS Problem, ein gebrochener sicherer Kanal (secure channel) oder ein Zeitunterschied von mindestens fünf Minuten zwischen den DCs vor. Gerade das DNS ist für eine AD-Umgebung von großer Bedeutung! Ein Ping sowohl auf die IP-Adresse als auch auf den Computernamen sollte von und zu den betroffenen DCs erfolgreich sein. Funktioniert ein Ping auf die IP-Adresse nicht, liegt höchstwahrscheinlich ein Netzwerkproblem vor. Es sollte der Weg vom Schemamaster zum betroffenen DC untersucht werden.
Funktioniert hingegen ein Ping auf den Computernamen oder FQDN des DCs nicht, liegt höchstwahrscheinlich ein DNS-Problem vor. In den TCP/IP-Einstellungen des DCs sollte ein zentraler DNS-Server als primärer DNS-Server eingetragen werden. Des Weiteren sollte in der Forward Lookup Zone überprüft werden, ob die SRV-Einträge existieren. Mit Repadmin /KCC <DC> sollte anschließend die eingehende Replikationstopologie auf den DCs neu berechnet werden.
-
Auch durch Schemakonflikte kann ADPREP Fehler verursachen. Wurden benutzerdefinierte Schemaänderungen vorgenommen oder Schemaänderungen durch Drittanbieterlösungen durchgeführt die mit einer Schemaaktualisierung durch ADPREP in Konflikt stehen, kann es ebenfalls zu Fehlern kommen. Die Fehler die angezeigt werden können darauf hindeuten, dass der Object Identifier (OID) nicht geändert wurde und somit keine neuen Klassen dem AD-Schema hinzugefügt werden können. Das Konfliktobjekt wird im ADPREP-Protokoll protokolliert. Wenn das Objekt das den Konflikt verursacht hat durch eine Drittanbieterlösung ins AD-Schema hinzugefügt wurde, sollte man sich für eine Lösung des Problems an den Hersteller wenden. Andernfalls sollte man sich an den (kostenpflichtigen) Microsoft Produkt Support Service (MS PSS) wenden. Ein weiterer Schemakonflikt könnte entstehen, wenn eine Verknüpfungskennung (Link Identifier) für ein Attribut durch eine Drittanbieterlösung bereits vergeben ist und ADPREP beim aktualisieren von bestehenden Attributen oder beim hinzufügen von neuen, dieselbe Verknüpfungskennung ebenfalls vergeben möchte. In diesem Fall sollte der MS PSS kontaktiert werden.
- Wenn beim ausführen von ADPREP /FORESTPREP der Fehler Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden erscheint, ist der Schuldige der Virenscanner. Der Echtzeitscanner (On-Access) agiert im Hintergrund als Systemdienst und scannt unsichtbar alle Dateien, Programme und den Arbeitsspeicher. Hat der Echtzeitscanner eine Datei oder ein Verzeichnis im Zugriff worauf ebenfalls beim ausführen von ADPREP /FORESTPREP der Zugriff auf dieselben Dateien oder Verzeichnisse benötigt wird, erscheint diese Fehlermeldung. Wenn dieser Fehler erscheint, muss der Virenscanner deaktiviert und anschließend erneut ADPREP /FORESTPREP ausgeführt werden. Danach kann der Virenscanner aktiviert werden.
-
Die Fehlermeldung Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden kann auch erscheinen, wenn ADPREP /DOMAINPREP /GPPREP ausgeführt wurde. Dann muss der Virenscanner zuerst deaktiviert und anschließend ADPREP /DOMAINPREP /GPPREP erneut ausgeführt werden. Oder wenn im ADPREP-Protokoll der Fehler Error 0x80070020 (Error_sharing_Violation) protokolliert wird, liegt das ebenso am Virenscanner. Das Deaktivieren des Virenscanners sollte auch in diesem Fall zum Erfolg führen.
Führt das deaktivieren des Virenscanners nicht zum Ziel, könnte es noch an den folgenden Ursachen liegen:
1. Der Registry-Eintrag HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SYSVOL ist nicht vorhanden oder zeigt nicht auf das echte SYSVOL Verzeichnis %windir%\SYSVOL\sysvol. Wenn der Eintrag fehlt, muss ein REG_SZ Eintrag mit dem Pfad zum SYSVOL-Verzeichnis erstellt werden.
2. Die Default Domain Policy (die GUID ist {31B2F340-016D-11D2-945F-00C04FB984F9} ) und Default Domain Controllers Policy (die GUID ist {6AC1786C-016F-11D2-945F-00C04fB984F9} ) fehlen im SYSVOL Verzeichnis.
3. Im SYSVOL Verzeichnis fehlt das SCRIPTS Verzeichnis. 4. Der NTFS-Bereitstellungspunkt und/oder die Bereitstellungspunkte zwischen %windir%\SYSVOL\sysvol\domain und %windir%\SYSVOL existieren nicht (mehr). Sollten die Bereitstellungspunkte fehlen, so können diese mit dem Tool LINKD erneut gesetzt werden.
Die Befehle lauten:
LINKD %windir%\SYSVOL\SYSVOL\<DNS-Domänenname> %windir%\sysvol\domain
LINKD %windir%\SYSVOL\staging areas\<DNS-Domänenname> %windir%\SYSVOL\staging\domain
LINKD %windir%\SYSVOL\sysvol\<FQDN>
- Wenn ADPREP /FORESTPREP ausgeführt wurde, müssen die Änderungen zuerst auf den Infrastrukturmaster in der Domäne repliziert werden, in der der neue Server als zusätzlicher DC hinzugefügt werden soll. Erst dann kann mit Domänen-Admin Rechten der Befehl ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster ausgeführt werden. Wurden die Änderungen noch nicht auf den Infrastrukturmaster repliziert oder wenn ADPREP /FORESTPREP nicht ausgeführt wurde, meldet das ADPREP /DOMAINPREP /GPPREP einen Fehler der darauf hinweist, dass die Gesamtstrukturweiten Informationen zuerst aktualisiert werden müssen.
- Der Domänenfunktionsmodus muss sich im einheitlichen Modus (Windows 2000 pur, Windows Server 2003 oder Windows Server 2008) befinden. Ansonsten schlägt das Ausführen von ADPREP /DOMAINPREP /GPPREP fehl!
Domänen- und Gesamtstrukturfunktionsmodus
-
Wenn ADPREP /RODCPREP mit Organisations- und Domänen-Admin Rechten auf einem Infrastrukturmaster ausgeführt wird, kann es zu folgendem Fehler kommen:
Adprep konnte kein Replikat für Partition DC=ForestDnsZones,DC=Root-Domäne erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).
und
Adprep konnte kein Replikat für Partition DC=DomainDnsZones,DC=Domäne,DC=de erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null). Dann muss der Infrastrukturmaster den entsprechenden DNS-Anwendungsverzeichnispartition idealerweise auf den aktuellen Infrastrukturmaster der Domäne verschoben werden. Wie das vonstattengeht, beschreibt der folgende Artikel:
Die Infrastrukturmaster der Anwendungsverzeichnispartitionen
Weitere Informationen:
Die FSMO-Rollen verschieben
Im Active Directory-Schema sind verschiedene Arten von Attribute definiert. Die meisten davon sind in der Active Directory-Datenbank (NTDS.dit) gespeichert und können einen festen Wert enthalten.
Aber längst nicht alle Attribute für ein Objekt sind in der AD-Datenbank gespeichert. Diese Art von Attribut bezeichnet man als Constructed Attribute, auch bekannt als Computed Attribute.
Die Merkmale eines solchen Attributs sind:
-
Constructed Attribute, zu Deutsch „konstruierte Attribute“ sind zwar im Schema definiert, sie enthalten jedoch selbst keinen Wert. Die Attributwerte werden erst von einem Domänencontroller im Moment der LDAP-Anfrage gebildet.
-
Da diese Attribute "constructed" sind, können sie auch nicht repliziert werden. Die Werte können auch nicht in den globalen Katalog (GC) übertragen werden.
-
Wird eine Abfrage nach solch einem Attribut durchgeführt, bildet jeder DC eigenständig den Wert.
-
Ein Wert eines konstruierten Attributs kann nicht vergeben bzw. geschrieben werden. Diese Art von Attribut wird lediglich für eine gezielte Abfrage vom DC zusammengesetzt.
-
Konstruierte Attribute können in der Regel nicht für Abfragen verwendet werden (die Ausnahme stellt das Attribut aNR oder memberOf dar).
-
In einigen Fällen muss bei der Abfrage im Parameter -Scope die Option BASE angegeben werden, wie z.B. für das Attribut tokenGroups. Mit dieser Option wird auf ein einziges Objekt zugegriffen.
-
Eine Abfrage nach allen Objekten in einem Container, die ein konstruiertes Attribut der Objekte die sich in dem Container befinden anzeigt, bringt kein Ergebnis.
Ein konstruiertes Attribut wird durch das dritte Bit im System-Flags Attribut definiert. Verbindet man sich in LDP z.B. mit dem konstruierten Attribut CN=Token-Groups,CN=Schema,CN=Configuration,DC=Root-Domäne lässt sich das System-Flag folgendermaßen kontrollieren:
Die konstruierten Attribute einer Gesamtstruktur anzeigen
In der AD-Powershell
Get-ADObject -LDAPFilter “(&(objectClass=attributeSchema)(systemflags:1.2.840.113556.1.4.803:=4))” -Searchbase “CN=Schema,CN=Configuration,DC=Root-Domäne” | Select Name
Oder:
Get-ADObject -LDAPFilter "(objectClass=attributeSchema)" -Searchbase "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties Systemflags | Where {$_.Systemflags -band 4} | Select Name
Mit LDP
-
Nach dem Starten von LDP gilt es zuerst eine Verbindung zu einem DC herzustellen.
-
Im zweiten Schritt muss man sich mit dem AD binden.
-
Anschließend gibt man im Suchfenster (unter Browse/Durchsuchen-Search/Suchen) als Basis-DN CN=Schema,CN=Configuration,DC=Root-Domäne ein und verwendet als Filter (&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4)).
-
Als Scope/Bereich gilt es One Level/Eine Ebene zu wählen.
-
Im Feld Attribute können dann die gewünschten Attribute angegeben werden.
In der Kommandozeile mit Dsquery, ab Windows Server 2003
dsquery * “CN=Schema,CN=Configuration,DC=Root-Domäne” -Scope Onelevel -attr Name -Filter "(&(objectcategory=attributeSchema)(systemFlags:1.2.840.113556.1.4.803:=4))"
Weitere Informationen:
AD-PowerShell Befehle
Microsoft Windows 2000 Scripting Guide - Operational Attributes
How to query Active Directory by using a bitwise filter
System-Flags Attribute
Standardmäßig werden in der MMC Active Directory-Benutzer und -Computer (ADBuC) die drei Spalten Name, Typ und Beschreibung angezeigt.
In der MMC lassen sich unter Ansicht - Spalten hinzufügen/entfernen… in Windows 2000 sowie Windows Server 2003 weitere 22 und unter
Windows Server 2008 weitere 27 Spalten einblenden.
Nun ist es seit Windows Server 2003 möglich eigene Spalten in der MMC dsa.msc zu integrieren. Dafür ist ein Windows Server 2003
oder Windows Server 2008 Schema notwendig. Somit hat man dann die Möglichkeit die in keinem Feld angezeigten, jedoch im Schema
existierenden Attribute (wie z.B. employeeID) doch in einer Spalte zum Vorschein zu bringen. Natürlich können dabei auch eigene Attribute
die durch eine Schemaerweiterung hinzugefügt wurden, in der MMC angezeigt werden. Die Werte in den Attributen sind allerdings auf einem
anderen Weg einzutragen. Entweder skriptbasiert oder manuell (z.B. mit ADSIEdit). Im Fall der Personalnummer lässt sich das durch die in dem
folgenden Artikel gezeigte Vorgehensweise erledigen.
Personalnummer im AD eintragen
Weitere Reiter oder Datenfelder können in die Verwaltungstools nur mühselig und mit viel Aufwand (z.B. durch die COM-Programmierung
mit C++, VB oder durch Dritt-Anbieter) eingefügt werden. Leichter ist es hingegen, sich die Informationen skriptbasiert über das Kontextmenü
anzeigen zu lassen (siehe o.g. Artikel). Diese Variante der Anzeige hat den Vorteil, dass es sich recht einfach und schnell implementieren lässt.
Denn im Active Directory-Schema existieren weitaus mehr Attribute, als in den MMCs angezeigt werden. Daher sollte stets vor einer
Schemaerweiterung das Schema kontrolliert werden, ob nicht doch ein passendes Attribut bereits existiert, jedoch nirgendwo angezeigt wird.
Das modifizieren der Spalten ist dank der Display-Specifier Klasse möglich. In Windows Server 2003 sowie Windows Server 2008
existieren standardmäßig 55 Display-Specifier Objekte. Die Klasse Display-Specifier beschreibt das Kontextmenü und die Eigenschaften
von Active Directory-Objekten. Durch das Bearbeiten der Display-Specifier lassen sich recht simpel die grafischen Active Directory-
Verwaltungswerkzeuge anpassen. Jede Objektklasse die in der grafischen Oberfläche erscheint, besitzt ein Display-Specifier Objekt
in der die Elemente die angezeigt werden definiert sind. Denn die AD-Verwaltungswerkzeuge (wie dsa.msc oder dssite.msc) rufen ihre
Konfigurationen aus den Display-Specifiern ab.
Zu finden sind die Display-Specifier in der Konfigurationspartition, im Container:
CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>.
Dort befinden sich weitere durchnummerierte Container, wobei jeder Container jeweils einer bestimmten Sprachversion entspricht.
Der für das deutsche Gebietsschema zuständige Container lautet CN=407. Demnach müssen auf einem deutschen Server die Änderungen
mit Organisations-Admin Rechten im Container CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
durchgeführt werden. Auf einer englischen Serverversion müssen die Display-Specifier im Container CN=409 bearbeitet werden.
Entsprechendes gilt natürlich für die anderen Sprachen.
Locale Identifier Constants and Strings
Wo kann man eigene Spalten definieren?
Eigene Spalten können im mehrwertigen Attribut Extra-Columns, des jeweiligen Display-Specifier Objekts definiert werden. Dies kann
getrennt entweder für Container wie z.B. dem Standard-Container Users bzw. Computers oder für Organisationseinheiten (OUs)
festgelegt werden. Die zusätzlichen Spalten die standardmäßig im dsa.msc zur Verfügung stehen, sind im Attribut extraColumns
das sich im Objekt CN=default-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne> befindet, definiert.
Die technische Umsetzung
Wenn man nun z.B. die Personalnummer statt aus dem Kontextmenü heraus, direkt in einer Spalte angezeigt haben möchte,
so ist das folgendermaßen möglich:
-
Zuerst gilt es mit ADSIEdit oder LDP, welche sich unter Windows Server 2003 in den Support Tools befinden und unter
Windows Server 2008 bereits im Betriebssystem integriert ist, zu dem für Container zuständigen Display-Specifier Objekt
zu navigieren. Der Pfad lautet:
container-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne> Anschließend ruft man durch einen Doppelklick auf das Objekt container-Display die Eigenschaften auf. Mit dem Objekt
container-Display hat man Einfluss auf die Spalten in Containern, wie es die beiden Standard-Container Computers oder Users darstellen.
-
Möchte man stattdessen eigene Spalten in Organisationseinheiten (OU) integrieren, so navigiert man zu diesem Pfad:
organizationalUnit-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
-
Eine weitere Möglichkeit wäre die "eigenen" Spalten lediglich in den gespeicherten Abfragen anzuzeigen.
Das hat den Vorteil, dass dadurch die selbst hinzugefügten Spalten mit den bereits bestehenden Spalten
zusammengefügt werden. Somit bleibt die Anzeige der Spalten in den Standardcontainern Users und Computers
sowie in den OUs unverändert.
Damit neben den bereits existierenden Spalten die eigenen Spalten bei einer gespeicherten Abfrage
angezeigt werden, gilt es zuerst die Eigenschaften des folgenden Containers aufzurufen:
default-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Root-Domäne>
Als nächstes ist in den Eigenschaften des entsprechenden Objekts, dass mehrwertige Attribut extraColumns zu bearbeiten.
Die Syntax wäre wie folgt:
<Ldap-Display-Name>,<Spaltenbezeichnung>,<Default Visibility>,<Spaltenbreite>,<Reserviert/unbenutzt> Die Werte bedeuten:
<Ldap-Display-Name>= Zuerst muss der LDAP-Display Name des gewünschten Attributs angegeben werden.
<Spaltenbezeichnung>= Der angezeigte Name der im Spaltenkopf der MMC erscheint.
<Default Visibility>= Wenn die eigene Spalte standardmäßig angezeigt werden soll, ist als Wert 1 einzutragen.
Soll hingegen die Spalte unter Ansicht - Spalten hinzufügen/entfernen… manuell hinzugefügt werden, so ist als Wert 0 einzutragen.
<Spaltenbreite>= Mit diesem Wert wird die Breite der Spalte in Pixels angegeben. Der Wert -1 gibt an,
das sich die Breite der Spalte nach der Spaltenbezeichnung richtet.
<Reserviert/Unbenutzt>= Hier ist als Wert 0 einzutragen.
Die einzelnen Werte sollten fortlaufend ohne Leerzeichen und jeweils durch ein Komma getrennt angegeben werden.
Im Falle der Personalnummer sähe die Syntax so aus:
employeeID,Personalnummer,1,150,0 oder employeeID,Personalnummer,1,-1,0
Was ist der Nachteil an dieser Vorgehensweise?
-
Werden im Objekt container-Display und/oder organizationalUnit-Display eigene Spalten integriert, erscheinen neben den
drei standardmäßig angezeigten Spalten (Name, Typ, Beschreibung) nur noch die selbst hinzugefügten Spalten.
Danach werden die zusätzlichen 22 bzw. 27 Spalten unter Windows Server 2003/2008 vollständig durch die eigenen Spalten
ersetzt und nicht zusammengefügt.
Stattdessen werden die eigenen Spalten die im Objekt default-Display definiert wurden, neben den Standard-Spalten bei
einer gespeicherten Abfrage angezeigt.
-
Wird lediglich das Objekt container-Display bearbeitet, stehen jedoch die zusätzlichen Spalten für OUs weiterhin zur Verfügung.
Das gleiche gilt auch vice-versa. Werden eigene Spalten nur für OUs hinzugefügt, stehen für die Standard-Container
Computers/Users weiterhin die zusätzlichen Spalten aus dem Objekt default-Display zur Verfügung.
Das Hinzufügen der eigenen Spalten im Attribut extraColumns das sich im Objekt default-Display befindet,
bringt in diesem Fall auch nicht den gewünschten Erfolg.
Möchte man aber neben den eigenen auch die vom System vorgegebenen Spalten weiter nutzen, können die Einträge aus
dem Objekt default-Display kopiert und in das gewünschte Container-Objekt (container-Display oder organizationaUnit-Display)
hinzugefügt werden.
-
Ein weiterer Haken an dieser Vorgehensweise wäre, dass die Änderungen in der Konfigurationspartition durchgeführt werden.
Diese Verzeichnispartition wird auf jeden DC in der Gesamtstruktur repliziert. Folglich wären alle Domänen in der Gesamtstruktur
von dieser Änderung betroffen.
Weitere Informationen:
Extending the User Interface for Directory Objects
Display Specifiers
About MMC 2.0
Microsoft Management Console 3.0
Eines der sich immer wiederholenden Aufgaben eines Administrators ist es, Benutzer im Active Directory einzurichten.
Um sich die tägliche Arbeit etwas zu erleichtern, ist es möglich, ein Benutzer- oder inetOrgPerson-Objekt zu kopieren.
Somit ist es mit wenigen Mausklicks möglich, Benutzer, die z.B. in den gleichen Gruppen Mitglied sein sollen oder die
gleichen Firmendaten haben, zu erstellen und somit Zeit zu sparen.
Wird nun ein Benutzer im Snap-In Active Directory-Benutzer und -Computer kopiert (Rechtsklick auf den Benutzer – Kopieren…),
müssen lediglich der Vorname, Nachname, der Benutzeranmeldename sowie ein Kennwort vergeben werden.
Für das einrichten eines Benutzerkontos muss das Konto mit dem die Benutzer eingerichtet werden, entweder Mitglied
der Gruppe Konten-Operatoren, Domänen-Admins oder Organisations-Admins sein. Die entsprechenden Berechtigungen
können natürlich auch über die Objektverwaltung delegiert werden.
Wird nun ein Benutzer-Objekt kopiert, werden nicht alle Informationen kopiert.
Im Active Directory-Schema ist definiert, welche Attribute im einzelnen kopiert werden.
Lediglich die am meisten verwendeten Attribute, wie z. B. die Gruppenmitgliedschaften, Anmeldezeiten,
Konto-Optionen und Adress-Daten werden beim kopieren eines Benutzers übernommen.
Es macht wenig Sinn, Persönliche Daten wie es z.B. der Reiter Rufnummern in den Benutzereigenschaften darstellt, zu kopieren.
Es werden folgende Attribute standardmäßig kopiert.
Im Reiter Adresse wären es: Post-Office-Box, L (Locality-Name), ST (State-Or-Province-Name),
Postal-Code, C (Country-Name), CO (Text-Country), Country-Code.
Das interessante an diesem Reiter ist, dass das Attribut Street-Address nicht mit kopiert wird.
Im Reiter Konto wären es: Account-Expires, Logon-Hours, Logon-Workstation, User-Account-Control (Konto-Optionen).
Im Reiter Mitglied von sind es: Is-Member-Of-DL, Primary-Group-ID.
Im Reiter Organisation: Department, Company, Manager.
Im Reiter Profil: Profile-Path, Script-Path, Home-Directory, Home-Drive.
Es werden noch weitere Attribute kopiert, die nicht in der MMC angezeigt werden.
Diese wären: Assistant, Code-Page, Local-ID, Max-Storage, Postal-Address, Preferred-OU, Other-Login-Workstations und einige mehr.
Andere Attribute wiederum, wie z.B. die Object-GUID oder Object-SID können nicht kopiert werden, da diese einmalig vergeben werden.
Des Weiteren werden auch die Informationen auf diversen Reitern by Design nicht mit kopiert.
Diese wären die Reiter: Einwählen, Remoteüberwachung, Sitzungen, Terminaldiensteprofil sowie Umgebung.
In diesen Reitern werden benutzerspezifische Daten, die im Attribut User-Parameters hinterlegt werden, gespeichert.
Im folgenden Artikel wird gezeigt wie man beeinflussen kann, ob ein Attribut kopiert wird oder nicht.
Dabei ist im Schema-Snap-In, in den Eigenschaften des entsprechenden Attributs, die Option
Attribut wird kopiert, wenn ein Benutzer dupliziert wird zu aktivieren bzw. deaktivieren.
Wie kann ich beeinflussen, welche Attribute beim Kopieren eines Benutzers kopiert werden?
Durch aktivieren oder deaktivieren der Kopieroption, lässt sich das Kopierverhalten von Attributen beeinflussen.
Die Option Attribut wird kopiert, wenn ein Benutzer dupliziert wird steht ohnehin (wenn überhaupt) nur bei
den Attributen zur Verfügung, die zur Benutzerklasse User Class gehören.
Was aber, wenn die Option zum kopieren ausgegraut und somit nicht zur Verfügung steht
(wie z.B. bei den Attributen Description oder Facsimile-Telephone-Number etc.)?
Dann lässt sich das Attribut nicht so ohne weiteres kopieren.
Hinweis: Das dieses Feld ausgegraut ist, ist ein bekannter Fehler des Schema-Snap-Ins und liegt
nicht am Schema selbst. Das liegt einzig und allein an dem Tool das eingesetzt wird.
Ob ein Attribut kopiert wird oder nicht, entscheidet das fünfte Bit im Attribut Search-Flags.
Wenn nun also ein Attribut kopiert werden soll, das standardmäßig nicht mit kopiert wird und das Kopier-Flag ausgegraut ist
(wie es z.B. bei dem Attribut Description der Fall ist), gilt es mit ADSIEdit (aus den Windows Support Tools) in die Schema-Partition
zu navigieren und in den Eigenschaften des gewünschten Attributs, als Wert 16 (Dezimal) bei Search-Flags einzutragen.
Oder man verwendet diese Skripts zum aktivieren bzw. deaktivieren der Kopiermöglichkeit eines Attributs:
http://www.it-administrator.de/magazin/download/ita0703-SearchFlags.zip
Danach ist zwar das Kontrollkästchen bei der Option Attribut wird kopiert, wenn ein Benutzer dupliziert wird weiterhin ausgegraut,
doch nun ist es aktiviert und somit wird das Attribut kopiert. Möchte man dieses rückgängig machen, gilt es als Wert „0“ einzutragen
Weitere Informationen:
Copying Users Does Not Copy All Attributes
The "Attribute is copied when duplicating a user" check box is unavailable in the Active Directory Schema console
When I copy a user account, not all the attributes in the source account are copied to the destination account?
User Object User Interface Mapping
Active Directory: LDAP-Feldnamen
Copying User Accounts
Steht eine Migration bevor, z.B. von Windows 2000 auf Windows Server 2003, sollte stets die Ausgangsbasis kontrolliert werden.
Bevor ein solcher Schritt durchgeführt wird, wäre es empfehlenswert, den Zustand der Domänencontroller zu überprüfen um während der
Migration keine bösen Überraschungen zu erleben.
Auf der anderen Seite ist es eines der Routineaufgaben des Administrators, den Status der Domänencontroller regelmäßig zu überprüfen.
In beiden Fällen, sind die beiden Windows Support Tools DCDIAG sowie NetDIAG hilfreich. Mit diesen Tools lassen sich Fehler schnell aufdecken.
Kommt es dabei, beim ausführen von DCDIAG zu folgender Warn-Meldung:
Starting test: MachineAccount
Warning: Attribute userAccountControl of <DC-NAME> is: 0x82020 = ( UF_PASSWD_NOTREQD | UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION )
Typical setting for a DC is 0x82000 = ( UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION )
This may be affecting replication?
......................... <DC-NAME> passed test MachineAccount
ist der Grund für diese Meldung, dass der Wert des Attributs User-Account-Control vom Domänencontroller-Computerobjekt nicht korrekt ist.
Als Wert des Attributs ist 0x82020 (Hex) eingetragen. Allerdings müsste entweder 0x82000 (Hex) bzw. 532480 (Dezimal) darin enthalten sein.
Das Flag PASSWD_NOTREQD ist im Computerobjekt des Domänencontrollers gesetzt, was nicht der Fall sein sollte.
Das gesetzte Flag PASSWD_NOTREQD bedeutet, dass kein Kennwort erforderlich ist.
Der Wert des Attributs lässt sich recht einfach mit LDP.exe oder ADSIEdit.msc korrigieren.
Die Vorgehensweise mit ADSIEdit.msc wäre folgende:
-
Zuerst gilt es über Start-Ausführen-Adsiedit.msc aufzurufen.
-
Danach ist eine Verbindung mit der Domänen-Partition herzustellen, falls keine bestehen sollte.
-
Im nächsten Schritt navigiert man zu der OU bzw. zu dem Container, in dem sich das Domänencontroller-Objekt befindet.
Standardmäßig befinden sich die Domänencontroller-Objekte in der "OU=Domain Controllers".
-
Dort wählt man mit einem Rechtsklick auf dem entsprechenden Domänencontroller-Objekt, die Eigenschaften aus.
-
Im Anschluss gilt es das Attribut User-Account-Control auszurufen und den Wert auf "532480" zu korrigieren.
Das Attribut User-Account-Control lässt sich mit DSQUERY abfragen.
Der Befehl dazu lautet folgendermaßen:
Dsquery * domainroot -filter "(&(objectCategory=Computer)(objectClass=Computer)(Name=DC-NAME))" -attr userAccountControl
Weitere Informationen:
How to use the UserAccountControl flags to manipulate user account properties
Möchte man die Personalnummern der Mitarbeiter in die Benutzerverwaltung mit eingeben, so kommt man unter Umständen auf den Gedanken,
dass Schema erweitern zu müssen da kein entsprechendes Feld für die Eingabe existiert.
Dabei existieren im Schema des Active Directory`s bereits zwei Attribute, nämlich Employee-ID sowie Employee-Number.
Deshalb ist es nicht nötig das Schema zu erweitern. Diese tauchen lediglich nicht in Form eines Feldes in einer MMC auf und genau das ist das Problem.
Was sich recht kompliziert bei dem erstellen eines Eingabe-Feldes in den bestehenden MMCs (z.B. im Snap-In Active Directory-Benutzer und
-Computer) darstellt, lässt sich verhältnismäßig einfach über das Kontextmenü eines Benutzerobjekts durchführen.
In diesem Beispeil, wird das Skript von Sakari Kouti verwendet:
-
Zuerst gilt es mit ADSIEdit das user-Display Objekt das sich in der Konfigurationspartition befindet (CN=user-
Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Domäne>,DC=<TLD>) aufzurufen.
-
Dort muss im Attribut adminContextMenu ein neuer Eintrag hinzugefügt werden:
<2, Personalnummer, C:\Skripte\employeeid.vbs> allerdings ohne die Klammern.
Der Eintrag bedeutet:
2 = Standardmäßig existiert bereits ein Eintrag der mit „1“ anfängt. Falls mehrere Einträge existieren sollten,
gilt es die nächste freie Zahl zu wählen.
Personalnummer = Dieser Eintrag wird im Kontextmenü des Benutzerobjekts angezeigt.
C:\Skripte\employeeid.vbs = In diesem angegebenen Pfad muss sich das Skript befinden.
-
Anschließend gilt es das Skript im angegebenen Verzeichnis zu speichern (mit der Endung VBS).
' -------------------------------------------------------------------------
' Script by Sakari Kouti (see http://www.kouti.com)
' You have a royalty-free right to use, modify, reproduce and distribute
' this script (and/or any modified version) in any way you find useful,
' provided that you agree that Addison-Wesley or Sakari Kouti has no
' warranty, obligations or liability for the script. If you modify
' the script, you must retain this copyright notice.
' -------------------------------------------------------------------------
Option Explicit
Dim wshArguments, objUser, objSchemaEmployeeID, strCurrentID, strEmployeeID, intMaxLen
On Error Resume Next
Set wshArguments = WScript.Arguments
Set objUser = GetObject(wshArguments(0))
Set objSchemaEmployeeID = GetObject("LDAP://schema/employeeID")
intMaxLen = objSchemaEmployeeID.MaxRange
If objUser.employeeID <> "" Then
strCurrentID = objUser.employeeID
Else
strCurrentID = "empty"
End If
strEmployeeID = InputBox( _
"Die aktuelle Personalnummer lautet " & strCurrentID & vbCrLf & _
vbCrLf & _
"Tragen Sie bitte die neue Personalnummer ein (1 bis " & intMaxLen & " Zeichen)", _
Right(objUser.Name, Len(objUser.Name) - 3) & " Personalnummer", _
objUser.employeeID)
If strEmployeeID = "" Then WScript.Quit 'User clicked Cancel
If Len(strEmployeeID) > intMaxLen Then
MsgBox "Die neue Personalnummer ist zu lang und wird somit nicht gespeichert.", _
vbCritical, "Fehler"
Else
Err.Clear
objUser.employeeID = strEmployeeID
objUser.SetInfo
If Err Then MsgBox "Die neue Personalnummer wird nicht gespeichert.", _
vbCritical, "Fehler"
End If
-
Wenn man nun mit einem Rechtsklick auf einem Benutzerobjekt das Kontextmenü aufruft,
erscheint ein weiterer Eintrag der lautet: Personalnummer.
Als Alternative kann die Personalnummer auch als Spalte in der MMC Active Directory-Benutzer und -Computer angezeigt werden.
Wie das funktioniert, zeigt der folgende Artikel:
Eigene Spalten in ADBuC integrieren
An dieser Stelle sei erwähnt, man sollte das Active Directory nicht mit einer Human-Ressourcen Datenbank verwechseln.
Das Active Directory ist in erster Linie dafür da, IT-Informationen für die Netzwerkverwaltung bereitzustellen.
Weitere Informationen:
Extending the User Interface for Directory Objects
|
Copyright © 2010 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|