Die Active Directory (AD) Schemaversionen sind (in Dezimal) unter:
- Windows 2000 mit allen Service Packs = 13
- Windows Server 2003 mit allen Service Packs = 30
- Windows Server 2003 R2 mit allen Service Packs = 31
- Windows Server 2008 mit allen Service Packs = 44
- Windows Server 2008 R2 mit allen Service Packs = 47
- Windows Server 2012 mit allen Service Packs = 56
Das Installieren eines Service Packs ändert niemals die AD Schemaversion! Die AD Schemaversion ändert sich auch dann nicht, wenn andere Technologien (beispielsweise Exchange) installiert werden und eine Schemaaktualisierung durchführen. Oder wenn eine eigene Schemaänderung durchgeführt wird, ändert sich ebenfalls die AD Schemaversion nicht. Die AD Schemaversion ändert sich nur dann, wenn das ADPREP einer neueren Windows Server Version ausgeführt wird.
Die Information in der die AD Schemaversion enthalten ist, verbirgt sich im Attribut objectVersion, das sich in den Eigenschaften der Schemapartition befindet. Dadurch, dass die Schemapartition auf alle DCs in der Gesamtstruktur repliziert wird, kann man zur Abfrage einen lokalen DC verwenden. Deshalb besteht keine Notwendig in einer Gesamtstruktur mit mehreren Domänen, einen DC aus der Root-Domäne oder gar den globalen Katalog zu verwenden. Diese Information hat jeder DC, egal in welcher Domäne er sich befindet.
Die AD Schemaversion mit der AD-PowerShell abfragen
Mit der AD PowerShell lässt sich die AD Schemaversion folgendermaßen herausfinden:
([ADSI]"LDAP://<Domäne.TLD>/CN=Schema,CN=Configuration,DC=Root-Domäne").objectVersion
Oder mit diesem AD PowerShellbefehl:
Get-ADObject "CN=Schema,CN=Configuration,DC=Root-Domäne" -Properties objectVersion | Select objectVersion | FT -A
Die AD Schemaversion mit ADSIEdit anzeigen
Nach dem man sich in ADSIEdit (oder mit anderen LDAP-Browsern) mit der Schemapartition verbunden hat, gilt es den Eintrag zu erweitern und mit einem Rechtsklick auf den Container CN=Schema,CN=Configuration,DC=Root-Domäne im Kontextmenü die Eigenschaften des Containers aufzurufen. Dort findet man das Attribut objectVersion mit der aktuellen AD Schemaversion.
Die AD Schemaversion mit LDP anzeigen
Ist das LDP gestartet, muss man sich als erstes unter Remotedesktopverbindung – Verbinden… mit einem DC verbinden. Danach muss man sich mit dem AD unter Remotedesktopverbindung – Gebunden… binden. Ist das erfolgt, ruft man unter Durchsuchen – Suchen das Suchfenster auf und gibt folgende Daten in die Felder ein:
Basis-DN: CN=Schema,CN=Configuration,DC=Root-Domäne
Filter: (objectClass=top)
Bereich: Basis
Attribute: objectVersion
Klickt man anschließend auf Ausführen, erscheint in der rechten Hälfte von LDP das Attribut objectVersion mit der aktuellen Schemaversion.
Die AD Schemaversion mit dsquery abfragen
Auch mit dsquery lässt sich die AD Schemaversion in einer Kommandozeile abfragen. Der Befehl lautet wie folgt:
dsquery * "CN=Schema,CN=Configuration,DC=Root-Domäne" -Scope Base -attr objectVersion
Die AD Schemaversion in der Registry überprüfen
Die AD Schemaversion kann man sich auf jedem DC in der Gesamtstruktur, sogar in der Registry in dem folgenden Registrykey ansehen:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version>
Im selben Registrykey existiert auch der Schlüssel System Schema Version. Dieser Schlüssel wird lediglich von der Install from Media (IFM) Funktion verwendet. Damit wird sichergestellt, dass beim heraufstufen eines DCs mit der IFM Funktion, keine ältere oder neuere Schemaversion auf dem DC wiederhergestellt wird. Dieser Wert dient zur Kontrolle.
Domänencontroller-Installation von einer Sicherung
Die Exchange Schemaversion abfragen
Exchange hat seine eigene Schemaversion. Die Schemaversion von Exchange steckt im Attribut rangeUpper, das sich in der Schemapartition im Objekt ms-Exch-Schema-Version-Pt befindet. So wie bei der AD Schemaversion, kann man für die Abfrage der Exchange Schemaversion jeden DC in der Gesamtstruktur verwenden, da sich die gewünschte Information ebenfalls in der Schemapartition befindet, die wie bereits erwähnt auf jeden DC in der Gesamtstruktur repliziert wird.
Anders als bei der AD Schemaversion, kann sich unter Exchange die Schemaversion schon beim Installieren eines Service Packs für Exchange ändern.
Die Exchange Schemaversionen sind unter:
- Exchange 2000 = 4397
- Exchange 2000 SP3 = 4406
- Exchange Server 2003 RTM = 6870
- Exchange Server 2003 SP2 = 6936
- Exchange Server 2007 RTM = 10637
- Exchange Server 2007 SP1 = 11116
- Exchange Server 2007 SP2 = 14622
- Exchange Server 2007 SP3 = 14625
- Exchange Server 2010 RTM = 14622
- Exchange Server 2010 SP1 = 14726
Die Exchange Schemaversion mit der AD-PowerShell abfragen
In der AD PowerShell findet man die Exchange Schemaversion wie folgt heraus:
([ADSI]"LDAP://Domäne.de/CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne").rangeUpper
Auch dieser AD PowerShellbefehl liefert die Schemaversion von Exchange:
Get-ADObject "CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC= Root-Domäne " -Properties rangeUpper | Select rangeUpper | FT –A
Die Exchange Schemaversion mit ADSIEdit anzeigen
Ist ADSIEdit gestartet, muss man sich zuerst mit der Schemapartition verbinden, sofern noch keine Verbindung existiert. Danach ruft man mit einem Rechtsklick auf den Container CN=Schema,CN=Configuration,DC=Root-Domäne die Eigenschaften auf und navigiert zum Attribut rangeUpper. Der Wert in diesem Attribut, ist die Exchange Schemaversion.
Die Exchange Schemaversion mit LDP anzeigen
Möchte man sich die Exchange Schemaversion in LDP anzeigen lassen, gilt es sich zuerst unter Remotedesktopverbindung – Verbinden… mit einem DC zu verbinden. Im zweiten Schritt bindet man sich unter Remotedesktopverbindung – Gebunden… mit dem AD. Als nächstes ruft man unter Durchsuchen – Suchen das Suchfenster auf und gibt folgende Daten in die Felder ein:
Basis-DN: CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne
Filter: (objectClass=*)
Bereich: Basis
Attribute: rangeUpper
Klickt man anschließend auf Ausführen, erscheint das Attribut rangeUpper mit der aktuellen Exchange Schemaversion.
Die Exchange Schemaversion mit dsquery abfragen
In der Kommandozeile lässt sich die Schemaversion von Exchange mit dsquery wie folgt abfragen:
dsquery * CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr rangeUpper
Wenn Unternehmen fusionieren, folgt des Öfteren eine Migration. Vor einer Migration ist es gut zu wissen, welche Active Directory (AD) Schemaerweiterungen in der zu migrierenden Gesamtstruktur existieren, damit diese falls notwendig, in der Ziel-Gesamtstruktur ebenfalls zur Verfügung gestellt werden können. Mit Schemaerweiterungen sind Erweiterungen im AD Schema gemeint, die von einer Standardinstallation des AD in der entsprechenden Version (Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2) abweichen. Aber auch aus Dokumentationsgründen ist es empfehlenswert, die AD Schemaerweiterungen einer Gesamtstruktur stets zu kennen.
Die Schemaerweiterungen lassen sich recht einfach mit dem Tool ADSchemaAnalyzer aufspüren, dass Bestandteil des früheren ADAM (Active Directory Application Mode) und heutigen AD LDS (Active Directory Lightweight Directory Services) ist und ab Windows XP und Windows Server 2003 zur Verfügung steht. Hat man ADAM bzw. AD LDS installiert, findet man den ADSchemaAnalyzer unter allen unterstützten Betriebssystemen im Verzeichnis %windir%\ADAM.
Während man unter Windows Server 2003 ADAM noch extra herunterladen musste, befindet es sich ab Windows Server 2003 R2 unter den Windows-Komponenten bereits on Bord. Ab Windows Server 2008 findet man die AD LDS unter den Rollen. Aber auch auf den Clients Windows XP, Windows Vista und Windows 7 lässt sich ADAM bzw. AD LDS installieren und das AD Schema vergleichen. Doch vorher muss für das eingesetzte Betriebssystem, die entsprechende Version heruntergeladen werden.
Active Directory Application Mode (ADAM)
AD LDS für Windows Vista
AD LDS für Windows 7
Es ist irrelevant, auf welchem System das AD Schema verglichen wird. Ob auf einem Client, der sich in einer Arbeitsgruppe oder Domäne befindet, Standaloneserver, Mitgliedserver oder DC. Das AD Schema lässt sich stets vergleichen.
Die Vorgehensweise
- Nach der Installation des ADAM bzw. der AD LDS, startet man zuerst aus dem Verzeichnis %windir%\ADAM den ADSchemaAnalyzer. Ist das Tool gestartet, klickt man auf Datei – Zielschema laden… um das Ziel AD Schema zu laden. Möchte man das AD Schema eine aktuelle AD Umgebung dahingehend überprüfen ob es von einer Standardinstallation abweicht, so sollte als Ziel, das AD Schema der bestehenden AD Umgebung als Erstes geladen werden.
Soll jedoch das AD Schema von zwei aktuellen AD-Umgebungen verglichen werden (beispielsweise vor einer Inter-Forest Migration), ist es empfehlenswert, im ersten Durchlauf das AD Schema der einen Gesamtstruktur und in einem empfohlenen zweiten Durchlauf, das AD Schema der anderen Gesamtstruktur als Ziel AD Schema zu laden!
-
Im darauffolgenden Fenster Zielschema laden kann entweder das AD Schema von einer aktuellen AD Umgebung oder von einer LDF-Datei, eines zuvor exportierten AD Schemas geladen werden. Somit hat man die folgenden drei Möglichkeiten, um das AD Schema zu vergleichen:
- Man kann das AD Schema einer aktuellen AD Umgebung mit einer LDF-Datei vergleichen.
- Es können zwei aktuelle AD Umgebungen verglichen werden.
- Es können zwei LDF-Dateien verglichen werden. Soll das AD Schema von zwei aktuellen AD Umgebungen verglichen werden, muss vorher natürlich sichergestellt werden, dass das System auf dem der ADSchemaAnalyzer gestartet wurde, Verbindung zu beiden Gesamtstrukturen hat und die entsprechenden Rechte bestehen.
-
Das AD Schema einer AD Umgebung kann man in einer Kommandozeile mit LDIFDE wie folgt exportieren: Ldifde -F C:\ADSchema.ldf -d "CN=Schema,CN=Configuration,DC=Root-Domäne"
- Wurde das Zielschema von einer aktuellen AD Umgebung oder von einer LDF-Datei geladen, muss als nächstes unter Datei – Basisschema laden… diesmal das Basisschema geladen werden. Wenn das AD Schema einer aktuellen AD Umgebung mit einer Standardinstallation verglichen werden soll, muss als Basisschema das AD Schema der Standardinstallation, beispielsweise in Form einer LDF-Datei geladen werden.
Ein LDF-Export einer Standardinstallation eines Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 und Windows Server 2008 R2 AD Schemas, wird hier zur Verfügung gestellt.
ADSchema.zip (673,58 KB)
- Ist das Basisschema geladen, muss zum Schluss noch im Menü Schema die Option Vorhandene Elemente ausblenden ausgewählt werden. Denn schließlich sollen lediglich die Unterschiede zwischen zwei AD Schemas angezeigt werden.
- Nun sieht man in der Ausgabe unter dem Container Klassen und Attribute die evtl. bestehenden Unterschiede zwischen beiden AD Schemas. Danach können die Einträge einzeln, durch das Markieren der gewünschten Klassen bzw. Attribute oder alle Unterschiede durch Auswahl von Schema – Alle nicht vorhandenen Elemente als eingeschlossen markieren exportiert werden. Zum Exportieren wählt man Datei – LDIF-Datei erstellen… .
Weitere Informationen:
ADSchemaAnalyzer
LDIFDE - LDAP Data Interchange Format Data Exchange
Das Active Directory (AD), das auf dem Extensible Storage Engine (ESE) Datenbankmodul basiert organisiert Objekte in einer hierarchischen Baumstruktur und stellt die Hierarchie der Objekte für eine Gesamtstruktur. Das AD speichert die transaktionale Datenbank intern in drei Tabellen: Datentabelle (Data-Table), Verknüpfungstabelle (Link-Table) und in der erweiterten Sicherheitseinstellungen Tabelle (Security Descriptor-Table, kurz SD-Table). Die beiden wichtigsten Tabellen in der sich die Daten des AD befinden ist die Datentabelle, die alle Objekte sowie Attribute enthält und die Verknüpfungstabelle, in der die Beziehungen zwischen den Objekten gespeichert werden.
Siehe auch: Verknüpfte Attribute
In der Datentabelle wird jedes Attribut und jedes Objekt in einer einzelnen Zeile, mit einer Spalte pro Attribut gespeichert. Das bedeutet, jede Zeile in der Datentabelle entspricht einem Attribut bzw. Objekt. Die Einträge die sich auf einem Domänencontroller (DC) in der Datentabelle befinden, sind aus der Schema-, Konfigurations-, Anwendungs- und Domänenpartition. Die Datentabelle eines globalen Katalogs (GC) enthält neben den Einträgen aus den bereits erwähnten Verzeichnispartitionen, zusätzlich noch die Einträge aus allen anderen Domänenpartitionen innerhalb der Gesamtstruktur. Denn bekanntermaßen werden alle Objekte aus allen Domänen innerhalb einer Gesamtstruktur, lediglich mit den Attributen die für eine Suche relevant sind in den GC repliziert.
Um jede Zeile in der Datentabelle eindeutig identifizieren zu können, verwendet das AD als eindeutige Kennung das Distinguished Name Tag (DNT). Bei dem DNT handelt es sich um einen vier Byte (32Bit) Integer Wert und dieser wird zum internen Verweis auf Attribute und Objekte verwendet. Der Distinguished Name Tag ist eine lokale Kennung der nicht zwischen den DCs repliziert wird und lautet bei jedem DC anders.
Der DNT gibt die Zeile in der AD-Datenbank an, in der das Attribut bzw. Objekt gespeichert ist. Jedes Objekt das erstellt wird erhält im DNT eine fortlaufende Nummer. Oder wenn z.B. ein Benutzer einer Gruppe hinzugefügt wird, speichert das AD den DNT des Benutzerobjekts im member Attribut der Gruppe und nicht den Distinguished Name (DN). Dadurch das sich der DNT selbst beim Umbenennen eines Objekts nicht ändert kann ein Benutzerobjekt umbenannt werden, ohne dass das AD alle Gruppen durchsuchen muss um den DN des Benutzers in jedem member Attribut der Gruppe aktualisieren zu müssen.
Im AD hat jedes Objekt genau ein übergeordnetes Objekt und ein Verweis auf das übergeordnete Objekt ist mit dem Objekt selbst gespeichert. Für die Beziehung zwischen den über- und untergeordneten Objekten speichert das AD in einer zusätzlichen Spalte innerhalb der Datentabelle den Parent Distinguished Name Tag (PDNT). In dieser Spalte wird der DNT vom übergeordneten Objekt gespeichert. Die Auflösung der Beziehung zwischen den über- und untergeordneten Objekten ist optimiert, da der DNT und PDNT indizierte Felder in der AD-Datenbank sind.
Um sich das genauer vor Augen zu führen empfiehlt es sich einen Export der AD-Datenbank mit LDP zu generieren. Diese Möglichkeit, einen Export der AD-Datenbank und das sogar im laufenden Betrieb durchzuführen, existiert seit Windows 2000 und ist dank des speziellen Attributs dumpdatabase möglich, das nur für diesen Zweck existiert. Nach dem man LDP gestartet hat, muss man sich zunächst mit einem DC verbinden. Dazu wählt man in LDP unter dem Menüpunkt Remotedesktopverbindung die Option Verbinden… und gibt den gewünschten DC an, von dem aus ein Export der lokalen AD-Datenbankkopie durchgeführt werden soll. Danach muss man ebenfalls unter dem Menüpunkt Remotedesktopverbindung die Option Gebunden… wählen, um sich mit dem AD zu binden. Anschließend gilt es unter dem Menüpunkt Durchsuchen die Option Ändern aufzurufen. Nun muss im Feld Attribut das Attribut dumpdatabase eingetragen werden. Im Feld Werte können die gewünschten Attribute angegeben werden die mit exportiert werden sollen. Das Feld darf dabei nicht leer bleiben und es muss mindestens ein Attribut angegeben werden. Standardmäßig werden unter Windows Server 2008 R2 bereits diese Werte exportiert: DNT - PDNT - CNT - NCDNT - OBJ – DelTime - RecTime - INST - RDNTyp – RDN. Hat man die entsprechenden Attribute eingegeben, muss im Bereich Vorgang die Option Hinzufügen gewählt und mit einem Klick auf Eingabe die getätigten Einträge in die Eingabeliste übernommen werden. Mit einem Klick auf Ausführen wird der Export dann durchgeführt.
Je nach Anzahl der Attribute, Objekte und Größe der AD-Datenbank kann der Export einige Zeit in Anspruch nehmen. Daher ist es empfehlenswert, den Export auf einem DC zu einem Zeitpunkt zu generieren, wenn gerade keine größere Last auf dem DC besteht!
Die exportierte Datei mit dem Dateinamen NTDS.dmp kann mit einem Texteditor geöffnet werden (z.B. Notepad) und wird im gleichen Verzeichnis erstellt, in der sich auch die AD-Datenbank NTDS.dit befindet (standardmäßig %windir%\NTDS).
Was passiert denn nun in der AD-Datenbank wenn ein Objekt, z.B. ein Benutzer gelöscht wird?
Es heißt wenn ein Objekt, z.B. ein Benutzer gelöscht wird, wandert es in den versteckten Container Deleted Objects das sich in der Domänenpartition befindet.
Näheres zum Container Deleted Objects liefert der folgende Artikel:
Der Container Deleted Objects
Doch bevor das Objekt überhaupt gelöscht wird, findet anhand bestimmter Kriterien eine Überprüfung statt, ob das Objekt auch tatsächlich gelöscht werden darf.
Welche Kriterien das hauptsächlich sind, steht im diesem Artikel:
Active Directory Wiederherstellung
Wenn die Kriterien erfüllt und das Objekt gelöscht werden darf, werden folgende Änderungen am dem gelöschten Objekt vorgenommen:
Lingering Objects (veraltete Objekte)
In Wirklichkeit wird in der AD-Datenbank das Objekt das gelöscht wurde, also z.B. ein Benutzer nicht verschoben. Stattdessen bleibt das Objekt nach dem Löschen weiterhin in der AD-Datenbank an seinem Platz bestehen! Lediglich die Beziehung zu dem übergeordneten Objekt, also der PDNT im gelöschten Objekt ändert sich. Das gelöschte Objekt erhält in der Spalte PDNT den DNT vom Container Deleted Objects.
Im Übrigen trifft das nicht nur auf das Löschen von Objekten zu. Auch wenn ein Objekt in eine andere OU verschoben wird, bleibt das Objekt weiterhin an seinem Ursprungsort in der AD-Datenbank bestehen. Das Einzige was sich auch hier ändert, ist die Beziehung zum übergeordneten Objekt, also der Wert in der Spalte PDNT.
Schauen wir uns das im folgenden Beispiel an:
Das Benutzerobjekt Yusuf Dikmenoglu enthält in der Spalte DNT den Wert 3702. Das Objekt befindet sich also in der Zeile 3702. In der Spalte PDNT ist als Wert 3697 eingetragen. Im PDNT ist der DNT vom übergeordneten Objekt gespeichert. Schaut man sich nun in der Spalte DNT die Zeile 3697 an wird schnell klar, das sich der Benutzer Yusuf Dikmenoglu in der OU „IT“ befindet.
Löscht man jetzt das Benutzerobjekt Yusuf Dikmenoglu, bleibt das Objekt weiterhin in der Zeile 3702 bestehen. Der Wert in der Spalte PDNT, sprich die Beziehung zum übergeordneten Objekt ändert sich jedoch! Das übergeordnete Objekt des gelöschten Benutzerobjekts Yusuf Dikmenoglu ist jetzt nicht mehr die OU „IT“, sondern der Container Deleted Objects in der Domänenpartition.
Wie zu erkennen ist wurde der Wert in der Spalte PDNT im gelöschten Benutzerobjekt Yusuf Dikmenoglu, von 3697 auf 1802 geändert.
Was an dieser Stelle auch zu erkennen ist, der Relative Distinguished Name (RDN) des gelöschten Benutzerobjekts hat einen eindeutigen Namen erhalten. Das gelöschte Objekt erhält intern den Namen <alterRDN>DEL:<objectGUID>. Durch das Hinzufügen der objectGUID ist sichergestellt, dass das Objekt auch im gelöschten Status einen einmaligen Namen innerhalb der AD-Datenbank besitzt und somit eindeutig zu identifizieren ist. Das ist auch notwendig, denn wenn es ein zweites Benutzerobjekt Yusuf Dikmenoglu geben würde das ebenfalls gelöscht wird, müssen beide Objekte im Container Deleted Objects identifiziert werden können. Diese Vorgehensweise ist insbesondere für das wiederherstellen des Tombstones oder aus dem AD-Papierkorb zwingend notwendig!
Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Domänencontroller vergleichen
Phantome im Active Directory
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 © 2013 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|