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
In der heutigen Zeit ist es üblich das Firmen fusionieren, übernommen werden, komplett oder bloß ein Firmenteil verkauft
bzw. selbstständig wird. Wenn Firmen fusionieren ist es meistens erforderlich, eine Verbindung zwischen den Strukturen herzustellen.
Das kann eine Vertrauensstellung oder aber auch eine Migration bedeuten, je nachdem welche Anforderungen erfüllt werden müssen.
Soll sich aber ein Firmenteil eigenständig machen, steht dem Administrator eine Migration bevor. Oder etwa doch nicht?
Der gestresste Administrator der ohnehin mit seinen täglichen Aufgaben mehr als genug zu tun hat, möchte sich die Arbeit
der Firmenteilung gering halten. Er stellt sich dabei vor, weitere DCs in der Root-Domäne der Muttergesellschaft zu installieren
und die AD/DNS-Replikation abzuwarten. Anschließend stellt er diese DCs in einem isolierten Netzwerk, das keine Verbindung
zur Gesamtstruktur der Muttergesellschaft hat an ihren Zielort auf. Die überflüssigen AD-Objekte (Benutzer- und Computerkonten,
OUs, AD-Standorte, DC-Objekte, Sub-Domänen etc.) werden auf den verschobenen DCs entfernt. Ebenso werden auf den DCs
der Muttergesellschaft die verschobenen Objekte entfernt.
Weitere Details werden an dieser Stelle mit Absicht nicht genannt!
Wenn die DCs an ihrem Zielort stehen hat man als Ergebnis nun zwei völlig unabhängige Gesamtstrukturen,
was sogar mit dem minimalsten Aufwand erreicht wurde, nicht wahr? Weiterhin denkt sich der scheinbar clevere Administrator,
dass dieser Domänensplitt keine Sicherheitsrisiken für beide Gesamtstrukturen mit sich bringt.
Das nach dem Splitt beide Gesamtstrukturen den gleichen internen NetBIOS- sowie DNS-Domänennamen haben stört
den Administrator nicht, da es sich schließlich um interne Domänennamen handelt. Diese können bekanntermaßen auch
mühevoll unter Windows Server 2003/2008 geändert werden. Aber ob dies am Ende vollständig von Erfolg gekrönt ist,
steht auf einem anderen Blatt.
Außerdem ist der ganz schlaue Administrator der Meinung, dass solch ein Domänensplitt auch einen Vorteil hätte.
Denn falls das unternehmerische Vorhaben der Firmenteilung scheitern und beide Firmenteile sich erneut zusammenschließen würden,
könnte er einfach die verschobenen DCs zurück zur Domäne der Muttergesellschaft stecken. Nur was würde das bringen,
wenn auf beiden Seiten die DC-Objekte der jeweils anderen Seite gelöscht wurden.
Kommen wir zu dem Punkt des Sicherheitsfaktors.
Unterliegen nach einem Domänensplitt beide Gesamtstrukturen wirklich keinem Sicherheitsrisiko?
Die Antwort lautet: In beiden Gesamtstrukturen wäre die Sicherheit so löchrig wie ein Schweizer Käse!
Wird eine Root-Domäne geteilt, sind in beiden Firmenteilen unter anderem die folgenden Punkte identisch:
-
Beide Seiten enthalten das vordefinierte Administratorkonto mit dem gleichen Kennwort.
-
Alle vordefinierten Sicherheitsgruppen, in erster Linie die Sicherheitsgruppe Organisations-Admins wären auf beiden Seiten identisch.
- Auf beiden Seiten ist die Domäne als Root-Domäne deklariert, mit derselben SID.
- Durch den globalen Katalog existieren auch auf den verschobenen DCs alle Objekte aus der Gesamtstruktur der Muttergesellschaft.
Diese Situation stellt für beide Seiten ein echtes Sicherheitsrisiko dar.
In den richtigen Händen ist keines der Domänen vor einer Kompromittierung sicher.
Weitere Risiken wären:
Auf den verschobenen DCs wären ebenfalls die Tombstones der Muttergesellschaft enthalten
die wiederbelebt werden könnten. Tombstones sind bereits gelöschte Objekte die aber noch in der AD-Datenbank existieren,
solange noch nicht die Tombstone Lifetime abgelaufen ist.
Wenn Applikationen in der Muttergesellschaft eingesetzt werden die sensible Informationen im Active Directory speichern,
wandern diese Daten ebenfalls auf den verschobenen DCs mit.
Sind Applikationen vorhanden die sich ins Active Directory verankern (wie z.B. Exchange), wandern diese Informationen ebenfalls mit.
Daher kann ich nur an jeden appellieren, auch wenn der Kunde König ist:
Finger weg von einem Domänensplitt!
Diese Art der Migration wird seitens Microsoft nicht supportet!
Wer einen Domänensplitt durchführt, der sollte sich ernsthaft überlegen ob er den richtigen Job ausübt.
Findet eine Firmenteilung statt, ist stets eine Migration durchzuführen.
Nur eine Migration wird seitens Microsoft unterstützt und ist auch reichlich sowie ausführlich auf den Microsoft-Seiten dokumentiert.
Eine Migration durchzuführen benötigt Zeit, Know-How und kann mehr oder weniger je nach Größe der Umgebung kompliziert sein.
Doch trotzdem rechtfertigt dies nicht einen Domänensplitt durchzuführen. Wer einer Migration nicht gewachsen ist,
der sollte sich statt einen Domänensplitt durchzuführen, besser einen erfahrenen Dienstleister zur Seite holen.
Ein Tool welches bei einer Migration nie fehlen darf, ist das Active Directory Migration Tool - ADMT.
Weitere Informationen:
Eine Domänenmigration durchführen
ADMT Version 3.1
Forest Recovery
Ein Domänencontroller der aus der Domäne entfernt werden soll, wird ordnungsgemäß mit Ausführen von DCPROMO
(Start - Ausführen - DCPROMO) zu einem Mitgliedsserver heruntergestuft. Ordnungsgemäß heißt, dass aus den Metadaten des
Active Directory (AD) die Informationen bzgl. des Domänencontrollers (DC) automatisch während dem DCPROMO-Vorgang entfernt werden.
Dazu muss natürlich der DC funktionstüchtig sein und Verbindung zur Gesamtstruktur haben.
Beim Herunterstufen eines DCs werden während des normalen DCPROMO-Vorgangs, folgende Änderungen durchgeführt:
-
Falls der DC der Träger der FSMO-Rollen sein sollte, werden diese auf einen anderen DC verschoben.
-
Das NTDS Settings Objekt wird samt Querverweisen entfernt.
-
Das Verzeichnis ...\NTDS in der sich die Verzeichnisdatenbank (Ntds.dit) samt Logs befinden, wird vom DC entfernt.
-
Abhängige Dienste des AD werden auf dem DC deinstalliert, wie z.B. der „Kerberos-Schlüsselverteilungscenter“
oder der „Standortübergreifender Messagingdienst“.
-
Das SYSVOL-Verzeichnis wird samt Inhalt vom DC entfernt.
-
Die lokale SAM-Datenbank wird auf dem Server erstellt.
-
Der Typ des Computerkontos wird von Domänencontroller zu Mitgliedsserver geändert. Dabei ändert sich der Wert
im Attribut userAccountControl, das sich in den Eigenschaften des Computerkontos befindet, von Hex=0x82000 (Dezimal=532480)
zu Hex=1000 (Dezimal=4096).
-
Das Computerkonto wird von der OU Domain Controllers in den Container Computers verschoben.
-
Das DNS wird weitestgehend bereinigt, in dem die SRV- sowie CNAME-Records des DCs entfernt werden.
Die Deinstallation der beiden Serverrollen Active Directory-Domänendienste und DNS-Server (falls installiert) unter Windows Server 2008,
muss der Administrator noch nachträglich im Server-Manager manuell durchführen.
Wenn man den DC einfach abschalten und neu installieren würde, wären in den Metadaten des Active Directory noch alle
Informationen des DCs enthalten. Die Daten des DCs wären weiterhin im AD gespeichert, falls dieser ausfallen (z.B. bei einem Hardwarecrash)
oder erzwungen aus dem AD entfernt werden sollte. Die unnötigen Daten des DCs die im Active Directory bestehen bleiben, sind z.B.
das DC-Objekt, das NTDS Settings Objekt, das FRS-Mitgliedsobjekt, die Verbindungsobjekte und die DNS-Informationen
(bei AD-integrierter Forward Lookup Zone).
Bevor jedoch ein anderer Server mit demselben Computernamen zum DC heraufgestuft werden kann, muss sichergestellt sein,
dass die Daten des DCs vollständig aus dem AD entfernt wurden. Abgesehen davon würden die Replikationspartner des ausgeschalteten
oder defekten DCs Warnungen im Verzeichnisdienstprotokoll und im Dateireplikationsdienstprotokoll (bei der SYSVOL-FRS Replikation) melden,
da sie mit ihm keine AD- bzw. SYSVOL-Replikation durchführen konnten. Daher sollten stets die Informationen eines nicht mehr existierenden
DCs aus dem AD entfernt werden.
Die erzwungene Herabstufung eines Domänencontrollers
Befindet sich ein DC an einem entfernten Standort der temporär keine WAN/VPN-Verbindung zur Zentrale und somit zur Gesamtstruktur hat,
ist das Herunterstufen eines DCs durch die erzwungene Herabstufung trotzdem möglich. Andere Ursachen die das herkömmliche Entfernen
eines DCs nicht zulassen könnten, wären z.B. Probleme mit der Konnektivität, Namensauflösung (DNS), Authentifizierung,
AD-Replikation (Stichwort: Tombstone Lifetime) oder ein Hardwaredefekt. Auch in solchen Situationen ist das herunterstufen eines DCs möglich,
dabei aber nicht so komfortabel wie sonst üblich. Die AD-Informationen können dann zum einen auf dem DC selbst entfernt werden und zum anderen,
müssen die Metadaten des ADs bereinigt werden. Diese Vorgehensweise besteht bereits seit Windows 2000.
Im ersten Schritt kann das erzwungene Herabstufen eines DCs mit dem Befehl DCPROMO /Forceremoval durchgeführt werden.
Dazu müssen die DCs die unter Windows 2000 und Windows Server 2003 betrieben werden, im normalen Modus gestartet sein!
Der Vorgang bei einer erzwungenen Herabstufung eines DCs ist die gleiche, als wenn der letzte DC einer Domäne deinstalliert werden würde.
Die Änderungen die lokal auf dem DC durchgeführt werden, sind die gleichen wie bei einem herkömmlichen DCPROMO-Vorgang. Das bedeutet,
nach dem Ausführen von DCPROMO /Forceremoval werden auf dem DC die Änderungen die zu Beginn dieses Artikels aufgezählt wurden durchgeführt.
Jedoch ist der DC nach der erzwungenen Herabstufung nicht mehr ein Mitgliedsserver der Domäne, sondern ist nun Mitglied einer Arbeitsgruppe.
Die Rolle AD-DS befindet sich (neben der Rolle des DNS-Servers) auch nach diesem Vorgang auf dem Server und kann nachträglich
manuell deinstalliert werden. Im Systemprotokoll des Servers wird unter Windows 2000 die EventID 29234 und unter Windows Server 2003
sowie Windows Server 2008 die EventID 29239 protokolliert.
Eine Neuheit ab Windows Server 2008 wäre, das sich die erzwungene Herabstufung sogar im Modus Verzeichnisdienste wiederherstellen
durchführen lässt. So können auch dann die AD-Informationen lokal vom DC entfernt werden, falls der DC nicht normal starten sollte.
Dies war unter den früheren Serverversionen nicht möglich! Die erzwungene Herabstufung funktioniert auch wenn der Dienst
Active Directory-Domänendienste gestoppt ist. Natürlich spielt es dabei keine Rolle, ob es sich um einen beschreibbaren
oder Windows Server 2008 RODC handelt.
Wenn der DC unter Windows 2000 und Windows Server 2003 nicht im normalen Modus startet, so gibt es noch eine weitere Möglichkeit
die AD-Informationen lokal vom DC zu entfernen. Das sei der Vollständigkeitshalbe erwähnt. Wie das funktioniert, wird in diesem Artikel erläutert:
Das Active Directory gewaltsam vom DC entfernen
Die Vorgehensweise bei einer erzwungenen Herabstufung eines DCs sieht folgendermaßen aus:
-
In einer Kommandozeile oder unter Start-Ausführen gilt es die erzwungene Herabstufung, mit dem Befehl DCPROMO /Forceremoval einzuleiten.
-
Seit Windows Server 2003 SP1 erhält dabei der Administrator nach Ausführen des Befehls für die folgenden Funktionen Warnhinweise. Jedoch können die Warnmeldungen bzgl. der FSMO-Rollen unterdrückt werden, wenn der Parameter /demotefsmo:yes angegeben wird.
- Wenn auf dem herunterzustufenden DC einer der FSMO-Rollen (oder alle) liegen sollte, erhält der Administrator für jede Rolle einen Warnhinweis.
- Ist das DNS auf dem DC installiert, wird ebenfalls ein Warnhinweis angezeigt.
- Auch wenn der globale Katalog (GC) auf dem DC aktiviert ist, erscheint ein weiterer Warnhinweis.
Alle diese Warnungen müssen mit Ja bestätigt werden. Andernfalls bricht der Vorgang ab. Mit den Warnungen wird der
Administrator darauf hingewiesen, diese Funktionen auf anderen DCs in der Gesamtstruktur sicherzustellen.
-
Es folgt die Willkommensseite des DCPROMO-Assistenten.
-
Im nächsten Schritt werden dem Administrator Informationen über die erzwungene Herabstufung und der Hinweis,
dass die Metadaten der Gesamtstruktur nicht aktualisiert werden angezeigt.
-
Ist der DNS-Server auf dem DC installiert, erscheint ein weiterer Hinweis.
-
Im nächsten Fenster muss das lokale Administratorkennwort vergeben werden.
-
Anschließend folgt die Zusammenfassung und mit einem letzten Klick auf Weiter beginnt nun das Herabstufen des DCs.
-
Ist der Vorgang abgeschlossen, verlangt der Assistent einen Neustart. Anschließend befindet sich der Server in einer Arbeitsgruppe.
-
Das primäre DNS-Suffix der Domäne hat der Server nach diesem Vorgang noch weiterhin gespeichert,
was natürlich geändert werden kann.
Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server
Mit NTDSUTIL die Gesamtstrukturmetadaten bereinigen
Im zweiten Schritt müssen die Metadaten des Active Directory bereinigt und somit die Daten des nicht mehr existierenden DCs
aus dem AD entfernt werden. Das bereinigen der Metadaten kann seit Windows 2000 mit NTDSUTIL oder ADSIEdit durchgeführt werden.
Die NTDSUTIL Version die ab Windows Server 2003 SP1 enthalten ist, führt dabei weiterreichende Aufgaben durch,
wie z.B. das seizen der FSMO-Rollen falls der zu entfernende DC der Rolleninhaber war. Im Anschluss daran bleibt noch das DNS zu bereinigen.
Die Metadaten werden mit NTDSUTIL ab dem Windows Server 2003 SP1 und somit auch unter Windows Server 2008 wie folgt bereinigt,
wozu Domänen-Administratoren Rechte notwendig sind:
Hinweis: Die Vorgehensweise mit NTDSUTIL unter Windows 2000 und Windows Server 2003 RTM sind identisch.
Jedoch weichen die Nacharbeiten unter Windows 2000 etwas ab.
-
Zuerst gilt es in einer Kommandozeile oder unter Start-Ausführen NTDSUTIL aufzurufen.
-
Als nächstes gibt man den Befehl Metadata cleanup ein.
-
Nun ist der Befehl Connections einzugeben.
-
Jetzt ist der Befehl Connect to Server <Servername> einzugeben. Einige machen an dieser Stelle den Fehler und versuchen sich
auf den nicht mehr existierenden DC zu verbinden, was natürlich fehlschlägt. Es muss ein DC ausgewählt werden,
der online und erreichbar ist.
-
Im fünften Schritt muss man mit dem Befehl Quit zum Menü Metadata cleanup zurückkehren.
-
Es folgt die Eingabe Select operation target.
-
Mit der Eingabe von List domains werden alle Domänen der Gesamtstruktur angezeigt.
-
Daraufhin ist mit dem Befehl Select domain <Domänennummer> die Domäne auszuwählen, aus der der DC entfernt werden soll.
-
Danach lässt man sich mit List sites alle AD-Standort der Gesamtstruktur anzeigen.
-
Mit dem Befehl Select site <Standortnummer> wählt man den Standort, aus dem der DC entfernt werden soll.
-
Dann lässt man sich mit dem Befehl List servers in site alle DCs des ausgewählten Standorts anzeigen.
-
Anschließend muss mit der Eingabe des Befehls Select server <DC-Nummer> der DC angegeben werden,
der aus dem AD entfernt werden soll.
-
Mit der Eingabe von Quit muss man erneut in die Ebene Metadata cleanup zurückkehren.
-
Zu guter letzt wird mit der Eingabe von Remove selected server der DC nun endlich aus den Metadaten des AD entfernt.
-
Es folgt eine Sicherheitsabfrage ob der DC tatsächlich entfernt werden soll.
-
Falls der zu entfernende DC der Rolleninhaber einer der FSMO-Rollen sein sollte, wird für jede Rolle das Popup
Bestätigung der Funktionenübernahme mit der entsprechenden Rolle angezeigt. Mit Ja oder Nein kann bestimmt werden,
ob der angezeigte DC die Rollen übertragen bekommen soll.
-
Mit einem genauen Blick auf die Anzeige sollte sichergestellt werden, dass - falls FSMO-Rollen zu übertragen sind -
auch tatsächlich alle Rollen übertragen wurde.
-
Wenn dem Administrator bei dem übertragen der FSMO-Rollen ein Fehler unterlaufen ist und dieser aus Versehen auf Nein geklickt hat,
kann jederzeit im Nachgang die FSMO-Rolle wie gewohnt entweder durch die GUI (ausgeschlossen ist hier der RID-Master,
dieser muss durch NTDSUTIL geseized werden) oder durch NTDSUTIL - seize auf einen anderen DC übertragen werden.
Die FSMO-Rollen verschieben
-
Mit Quit kann man nun NTDSUTIL beenden.
-
Weiterhin ist noch das DC-Objekt aus dem Snap-In Active Directory-Standorte und -Dienste (dssite.msc) zu entfernen.
Dieses DC-Objekt bleibt auch beim normalen herunterstufen bestehen und muss zusätzlich noch entfernt werden.
Unterhalb des DC-Objekts wurde bereits das NTDS Settings-Objekt entfernt, es existiert aber weiterhin noch das DC-Objekt.
Nach dem entfernen des DC-Objekts verschwinden auch evtl. bestehende Verbindungsobjekte bei den Replikationspartnern.
-
Nach dem bereinigen der Metadaten sind noch die Einträge aus dem DNS zu löschen. Dabei sind die SRV-Einträge sowie
der CNAME-Eintrag des DCs aus der Forward Lookup Zone der Domäne und aus der Zone “_msdcs.Root-Domäne“ zu entfernen.
Falls eine Reverse-Lookup Zone existiert, dann sind auch dort die Einträge des DCs zu entfernen. Zusätzlich sollte der DC aus
dem Reiter Namenserver, welches in den Eigenschaften der Forward Lookup Zone zu finden ist, entfernt werden.
Die Einträge im DNS können auch mit Hilfe von NLTEST entfernt werden. Das Tool befindet sich unter Windows 2000 sowie
Windows Server 2003/2003 R2 in den Windows Support Tools und ist im Windows Server 2008 "on Bord". Die DC-spezifischen
SRV-Einträge werden mit dem Befehl nltest /DSDEREGDNS:DomCon01.Domäne.TLD entfernt. Damit auch die GUID-Einträge des DCs
entfernt werden, sind die Parameter /DOMGUID sowie /DSAGUID hilfreich.
Eine weitere und kürzere Variante mit NTDSUTIL die Metadaten zu bereinigen,
die aber erst ab dem Windows Server 2003 SP1 zur Verfügung steht, wäre die folgende:
-
Es gilt zuerst das NTDSUTIL in der Befehlszeile oder unter Start-Ausführen zu starten.
-
Dann muss in die Ebene Metadata cleanup gewechselt werden.
-
Nun muss der Befehl remove selected server <DN des DCs aus der Konfigurationspartition> eingegeben werden.
Der Befehl würde so aussehen:
remove selected server CN=<DC-Name>,CN=Servers,CN=<Standortname>,CN=Sites,CN=Configuration,DC=<Root-Domäne>.
Wenn sich der DC mit dem Namen MZDCON01 im AD-Standort Mainz befindet und der FQDN der Root-Domäne „intra.dikmenoglu.de“ lautet,
würde der Befehl zum entfernen so aussehen:
remove selected server CN=MZDCON01,CN=Servers,CN=Mainz,CN=Sites,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de.
-
Die Sicherheitsabfrage Bestätigung des Entfernens des Servers erscheint, die mit Ja zu bestätigen ist.
-
Befinden sich FSMO-Rollen auf dem zu entfernenden DC, wird für jede Rolle die Sicherheitsfrage
Bestätigung der Funktionenübernahme gestellt. Es muss dann mit Ja oder Nein bestätigt werden,
ob die entsprechende Rolle übertragen werden soll.
-
Die FSMO-Rollen können auch zu einem späteren Zeitpunkt in gewohnter Weise, mit NTDSUTIL - seize oder durch die GUI
(bis auf den RID-Master) auf einen anderen DC übertragen werden.
-
Danach muss noch das DC-Objekt aus dem Snap-In Active Directory-Standorte und -Dienste entfernt werden.
-
Die SRV- sowie CNAME-Einträge aus den beiden Forward Lookup Zonen <Domäne> und <_msdcs.Root-Domäne>,
sind ebenfalls noch zu löschen. Deise können manuell oder einfacher mit NLTEST entfernt werden. Der Befehl
dazu lautet: nltest /DSDEREGDNS:DomCon01.Domäne.TLD. Zum entfernen der DC-GUID Einträge im DNS
helfen die Parameter /DOMGUID sowie /DSAGUID.
Die genaue Vorgehensweise für ältere Server-Versionen wird in diesem Artikel erläutert:
How to remove data in Active Directory after an unsuccessful domain controller demotion
War das der letzte DC einer Domäne, muss noch die Domäne aus den Metadaten entfernt werden.
How to remove orphaned domains from Active Directory
Das bereinigen der Metadaten nach einer erzwungenen Herabstufung oder eines defekten
beschreibbaren Windows Server 2008 DCs
Unter Windows Server 2008 wurde wie vieles andere, auch das bereinigen der Metadaten verbessert und für den Administrator erleichtert.
Nun kann man das bereinigen der Metadaten, neben NTDSUTIL und ADSIEdit, zusätzlich in der MMC Active Directory-Benutzer und -Computer
oder Active Directory-Standorte und -Dienste durchführen. Das bereinigen der Metadaten kann nun alleine
durch die grafische Oberfläche durchgeführt werden.
Dazu sind in der MMC Active Directory-Benutzer und -Computer (ADBuC) die folgenden Schritte durchzuführen:
-
Im ersten Schritt ruft man das Snap-In ADBuC, entweder unter Start-Programme-Verwaltung oder durch Start-Ausführen-dsa.msc auf.
-
Danach wählt man in der OU Domain Controllers, worin sich standardmäßig die DCs befinden, den entsprechenden DC aus.
-
Mit einem Rechtsklick auf das Icon des DC-Objekts wählt man nun aus dem Kontextmenü die Option Löschen aus.
Zum Löschen kann auch das rote „X“ auf der Symbolleiste gewählt werden.
-
Wie üblich unter Windows folgt eine Sicherheitsabfrage die es zu bestätigen gilt.
-
Im nächsten Schritt folgt erneut ein Warnhinweis. Der Administrator wird darauf hingewiesen, dass er versucht einen DC aus
dem AD zu löschen, obwohl das DCPROMO für das ordnungsgemäße Herunterstufen noch nicht ausgeführt wurde. Für das
ordnungsgemäße Herunterstufen solle man das DCPROMO auf dem DC ausführen.
Da z.B. bei einem Hardwarecrash des DCs das DCPROMO eben nicht ausgeführt werden kann, muss an dieser Stelle der Haken
bei der folgenden Option gesetzt werden:
Dieser Domänencontroller ist ständig offline und kann nicht mehr mit dem Installations-Assistenten für
die Active Directory-Domänendienste (DCPROMO) herabgestuft werden.
Anschließend ist auf die Schaltfläche Löschen zu klicken.
-
Wenn auf dem zu löschenden DC der globale Katalog (GC) aktiviert sein sollte, erscheint ein weiterer Hinweis.
Es sollte natürlich sichergestellt werden, dass die Funktion des GC weiterhin in der Gesamtstruktur zur Verfügung steht.
-
Falls der zu entfernende DC der Träger einer der FSMO-Rollen sein sollte, erscheint ein weiterer Hinweis mit der Frage,
ob die Rollen auf den neuen DC übertragen werden sollen. Mit einem Klick auf OK werden die Rollen dann übertragen.
-
Des Weiteren ist noch das DC-Objekt aus der MMC Active Directory-Standorte und -Dienste zu entfernen.
Spätestens danach verschwinden bestehende Verbindungsobjekte bei den Replikationspartnern.
Somit wurden endgültig die Metadaten des AD bereinigt.
Leider erscheint bei dieser Vorgehensweise zum bereinigen der Metadaten am Ende kein Hinweis, dass der Vorgang abgeschlossen wurde.
Zum Schluss sollten noch die Informationen des DCs aus dem DNS entfernt werden. Das wären die SRV-Einträge sowie der CNAME Eintrag
aus der Domänen-Forward Lookup Zone und aus der Zone „_msdcs.Root-Domäne“. Aus dem Reiter Namenserver in den Eigenschaften der
Forward Lookup Zone ist der DC ebenfalls noch zu löschen. Mit NLTEST können die Einträge einfach entfernt werden:
nltest /DSDEREGDNS:DomCon01.Domäne.TLD. Zum entfernen der DC-GUID Einträge im DNS helfen die Parameter /DOMGUID sowie /DSAGUID.
Hinweis für Windows Server 2008 DCs (und höher): Beim Bereinigen der AD-Metadaten durch den Domänen-Admin kann es unter Umständen
vorkommen, dass man die Fehlermeldung Zugriff verweigert erhält. Die Ursache in den meisten Fällen ist, dass das NTDS Settings- und/oder DC-Objekt
vor dem zufälligen Löschen geschützt ist! Entfernt man anschließend in der MMC Active Directory-Standorte und -Dienste diesen Schutz,
können anschließend die Metadaten erfolgreich bereinigt werden.
Siehe auch: Wer hat das Objekt gelöscht?
Das bereinigen der Metadaten nach einer erzwungenen Herabstufung oder eines defekten
Windows Server 2008 Read-Only Domänencontroller
Die Daten eines Read-Only Domänencontrollers (RODC) werden aus dem AD, auf ähnliche Weise wie ein beschreibbarer
Windows Server 2008 entfernt. Das Verfahren durch die MMC Active Directory-Benutzer und -Computer (dsa.msc) sieht folgendermaßen aus:
-
Nach dem öffnen der MMC dsa.msc gilt es das RODC-Objekt in der OU Domain Controllers mit einem Rechtklick auszuwählen und aus dem
Kontextmenü die Option Löschen zu wählen. In der Symbolleiste kann auch das rote „X“ zu löschen des RODC-Objekts gewählt werden.
-
Es folgt eine Sicherheitsabfrage, ob der ausgewählte RODC gelöscht werden soll.
-
Als nächstes hat man die Möglichkeit auszuwählen, ob die Kennwörter der Benutzer- und/oder Computerkonten die auf dem
RODC gespeichert wurden, zurückgesetzt werden sollen. Im Fall der Computerkonten müssen nach dem zurücksetzen
der Computerkontokennwörter die Clients erneut zur Domäne hinzugefügt werden. Zusätzlich wird die Option angeboten,
die Konten die auf dem RODC gespeichert wurden (sei es Benutzer- oder Computerkonten) sich anzeigen oder in eine Datei exportieren zu lassen.
Diese Optionen werden beim Entfernen eines RODCs durch NTDSUTIL nicht angeboten!
Dem Administrator stehen diese Optionen ausschließlich beim entfernen eines RODCs über die grafische Oberfläche (dsa.msc und dssite.msc) zur Verfügung.
-
Es folgt eine Übersicht über die im vorherigen Schritt gewählten Optionen.
-
Ist der GC auf dem RODC aktiviert, erscheint ein weiterer Hinweis mit der Frage, ob der Löschvorgang fortgesetzt werden soll.
-
Zum Schluss muss noch das RODC-Objekt aus dem Snap-In Active Directory-Standorte und -Dienste entfernt werden.
Anschließend muss im DNS nichts durchgeführt werden. Die Einträge in der Domänen-Forward Lookup Zone
sowie „_msdcs.Root-Domäne“ sind automatisch gelöscht.
Einen beschreibbaren Windows Server 2008 DC oder RODC aus
Active Directory-Standorte und -Dienste entfernen
Neben der MMC Active Directory-Benutzer und -Computer können die Daten eines beschreibbaren Windows Server 2008 DC
oder RODC auch durch die MMC Active Directory-Standorte und -Dienste entfernt werden. Die Vorgehensweise ist die gleiche
wie in der MMC ADBuC. Allerdings muss das NTDS Settings Objekt gelöscht werden und nicht etwa das DC-Objekt!
Der Versuch direkt das DC-Objekt in dssite.msc zu löschen schlägt fehl,
solange nicht zuerst das NTDS Settings Objekt unterhalb des DC-Objekts gelöscht wurde.
Weitere Informationen:
How to use the UserAccountControl flags to manipulate user account properties
Active Directory-Domänendienste (AD-DS)
Wenn ein zusätzlicher Domänencontroller (DC) z.B. durch die Install from Media-Funktion (kurz IFM) bereitgestellt wird, kann es je nach
Umgebung eine Weile dauern bis die Replikation vollständig abgeschlossen wurde. Die Dauer der Replikation hängt von der Größe der
Active Directory-Datenbank (Ntds.dit), von der zur Verfügung stehenden Badbreite und von dem Replikationszeitplan ab. Wobei die zur
Verfügung stehende Bandbreite sowie der Replikationszeitplan bei der standortübergreifenden, der sogenannten Inter-Site Replikation
eher eine Rolle spielt.
In vielen Umgebungen in denen vielleicht nur ein AD-Standort existiert reicht meistens ein Blick in die einzelnen MMCs aus. Diese wären
z.B. das Active Directory-Benutzer und –Computer Snap-In, das DNS-Snap-In (bei AD-integrierter FLZ) oder dem Verzeichnisdienstprotokoll,
um festzustellen ob bereits die Active Directory-Replikation stattgefunden hat oder evtl. ein Problem mit der AD-Replikation besteht.
Wer es aber genau wissen möchte hat die Möglichkeit, sich im laufenden Betrieb einen Überblick über die Replikation zu verschaffen,
ob auch tatsächlich die Repliken auf den verschiedenen DCs identisch sind. Ohnehin sollte ein Administrator die AD-Replikation stets überprüfen.
Mit den beiden Kommandozeilentools DSASTAT und REPADMIN lässt sich zum einen der Inhalt einer Verzeichnispartition auf zwei DCs
vergleichen und zum anderen, eine statistische Auswertung der Verzeichnispartition durchführen. So lassen sich Unstimmigkeiten innerhalb
einer Active Directory-Partition zwischen zwei DCs aufdecken. Auch lässt sich das ganze über die grafische Oberfläche mit REPLMON überprüfen.
Alle drei genannten Tools befinden sich unter Windows 2000 sowie Windows Server 2003 in den Windows Support Tools, die auf der
Windows 2000 sowie Windows Server 2003 CD im Verzeichnis Support/Tools zu finden sind. Für beide Server-Versionen können die
Support Tools auch von den Microsoft-Seiten heruntergeladen werden (siehe unter Weitere Informationen). Die beiden Tools
DSASTAT und REPLMON existieren unter Windows Server 2008 nicht. Aber auch unter Windows Server 2008 lassen sich die
Windows Server 2003 SP2 Support Tools installieren. Direkt nach dem Starten der Installation meldet der Assistent zwar bekannte
Kompatibilitätsprobleme, aber dennoch lassen sich die Support Tools ohne weiteres installieren und im Fall von DSASTAT sowie REPLMON,
auch ohne Funktionsverlust verwenden. Andererseits ist im Windows Server 2008 das REPADMIN bereits im Betriebssystem integriert.
DSASTAT
Das DSASTAT kann eine Verzeichnispartition zwischen zwei DCs der gleichen Domäne oder im Falle des globalen Katalogs,
zwischen verschiedenen Domänen überprüfen. Dabei werden im ersten Schritt die Informationen wie Megabyte pro Server,
Objekte pro Server und Megabyte pro Objektklasse ausgelesen. Im zweiten Schritt werden dann die Attribute der replizierten Objekte
miteinander verglichen. So kann überprüft werden, ob die Verzeichnispartition auf beiden DCs exakt übereinstimmt.
Die Hilfe zu DSASTAT lässt sich wie gewohnt in der Kommandozeile mit dem Befehl dsastat /? aufrufen,
in der die wenigen Parameter erläutert werden.
Die Verzeichnisinformationen aller DCs in der Domäne, werden mit diesem Befehl vergliechen:
Dsastat –loglevel:debug –output:both
Dieser Befehl vergleicht die Verzeichnisinformationen der angegebenen DCs:
Dsastat -s:<DC01>;<DC02>;<DC03>
Eine ausführlichere Überprüfung wird mit diesem Befehl durchgeführt:
dsastat –s:DomainS1;DomainS2 –b:DC=Domain,DC=com –gcattrs:all –sort:true –t:false –p:100
Um z.B. den Standard-Container Users zwischen zwei DCs zu vergleichen, muss der folgende Befehl eingegeben werden (alles in einer Zeile):
dsastat -s:DC01;DC02 -b:CN=Users,DC=intra,DC=domaene,DC=de -gcattrs:all -sort:true -t:false -p:100
-filter:"(&(objectcategory=person)(objectclass=user))"
Wenn ein DC aus der Sub-Domäne mit dem globalen Katalog der Root-Domäne verglichen werden soll, so gilt es diesen Befehl einzugeben:
dsastat -s:RootDC:3268;FQDN-SubDC -b:DC=sub,DC=domäne,DC=de -gcattrs:objectclass -p:500
Wichtig ist egal welcher Befehl verwendet wird, immer das Ende der Ausgabe.
REPADMIN
Eine andere Möglichkeit eine Verzeichnispartition zwischen zwei DCs zu vergleichen, stellt das REPADMIN dar.
Unter Windows 2000 lautet die Syntax wie folgt:
Repadmin /getchanges <DN-NamingContext> <FQDN-DC01> <GUID-DC02>
Repadmin /getchanges <DN-NamingContext> <FQDN-DC02> <GUID-DC01>
Besteht zwischen beiden DCs ein unterschiedlicher Datenbestand innerhalb einer Verzeichnispartition,
werden die Objekte um die es geht in der Ausgabe aufgeführt.
Hinweis: Der Parameter /getchanges in Windows 2000, wird auch unter Windows Server 2003 sowie Windows Server 2008 weiterhin unterstützt.
Des Weiteren können auch die folgenden Befehle, auf jeweils beiden DCs unter Windows 2000, Windows Server 2003 und 2008
ausgeführt werden, um so den up-to-dateness vector zu vergleichen:
Repadmin /showvector <DN-NamingContext> <NameDC1>
Repadmin /showvector <DN-NamingContext> <NameDC2>
Unter Windows Server 2003 sowie Windows Server 2008 ist dieser Befehl einzugeben:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <DN-NamingContext> /statistics
Die Konfigurationspartition kann zwischen einem DC der Root-Domäne und einem DC einer Sub-Domäne wie folgt überprüft werden:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <CN=Configuration,DC=Root-Domäne,DC=de> /statistics
Die Anwendungsverzeichnispartition ForestDNSZones kann folgendermaßen überprüft werden:
Repadmin /showchanges <FQDN-ZielDC> <GUID-QuellDC> <DC=ForestDNSZones,DC=Root-Domäne,DC=de> /statistics
Die Object-GUID eines DCs lässt sich z.B. unter Windows 2000 mit Repadmin /showreps und unter Windows Server 2003 sowie
Windows Server 2008 mit Repadmin /showrepl herausfinden.
REPLMON
Mit dem Replication-Monitor lassen sich ebenfalls Unterschiede einer Verzeichnispartition zwischen zwei DCs unter Windows 2000,
Windows Server 2003 und Windows Server 2008 aufdecken.
-
Nach dem Starten von REPLMON gilt es zuerst unter dem Menüpunkt View die Options aufzurufen.
-
Im Reiter General ist die Option Show Transitive Replication Partners and Extended Data zu aktivieren und anschließend
die Auswahl mit OK zu bestätigen.
-
Danach ist in der linken Spalte mit einem Rechtsklick auf Monitored Server die Option Add Monitored Server… zu wählen.
-
Im Assistent Add Monitored Server Wizard der daraufhin startet, gilt es einen gewünschten DC (z.B. einen neu hinzugefügten DC „DC01“)
anzugeben, der dann in der linken Spalte im Replmon erscheint.
-
Nun muss auf das Pluszeichen der entsprechenden Verzeichnispartition geklickt werden, damit mit einem Rechtsklick
auf dem anderen DC (DC02), mit dem die Verzeichnispartition verglichen werden soll, die Option Check Current USN
and Un-replicated Objects ausgewählt werden kann.
-
Falls notwendig, können für diesen Vorgang alternative Benutzerinformationen angegeben werden.
-
Wenn es nun Objekte gäbe die von DC02 zu DC01 noch nicht repliziert wurden, würden diese noch nicht replizierten Objekte
in einer Meldung angezeigt werden.
-
Soll hingegen die Replikation einer bestimmten Verzeichnispartition von DC01 zu DC02 kontrolliert werden, so sind die
gleichen Schritte auszuführen bis auf Punkt 4 (und 5). Dort ist dann DC02 als Monitored Server auszuwählen und an der
gewünschten Verzeichnispartition mit einem Rechtsklick auf DC01, erneut die Option Check Current USN and Un-replicated Objects auszuwählen.
Weitere Informationen:
Windows 2000 Service Pack 4 Support Tools
Windows Server 2003 Service Pack 2 32-bit Support Tools
Dsastat Examples
Determining the Server GUID of a Domain Controller
Nun da seit einigen Monaten der Windows Server 2008 gelaunched wurde, ist auch seit gestern (09.07.2008) die neue ADMT Version 3.1 verfügbar,
das jetzt auch den Windows Server 2008 unterstützt. Wer einmal eine Migration mit dem „Active Directory Migration Tool“ durchgeführt hat,
weiß dieses Tool zu schätzen. Damit ist es möglich, Benutzer-, Computer- sowie Gruppenkonten von einer Domäne in eine andere Domäne
zu migrieren. Die Profileinstellungen der Benutzer bleiben alle samt erhalten. Der Benutzer selbst merkt von dieser Migration nichts.
Allerdings wird Windows NT standardmäßig nicht mehr unterstützt!
Jedoch gibt es auf der Download-Seite von ADMT v3.1 den folgenden Hinweis:
To obtain customer support if you are performing migration operations involving NT 4.0 source domains or NT 4.0 domain controllers
(with SP4 or higher), please contact your Microsoft Services representative or visit http://www.microsoft.com/microsoftservices.
Hier der Download:
Download details: ADMT v3.1
Hier das Whitepaper zu dem Tool:
Download details: Migrating and Restructuring Active Directory Domains Using ADMT v3.1
Weitere Informationen:
Benutzermigration mit ADMT v3: How-To
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|