Wenn im Active Directory (AD) Objekte gelöscht werden, verschwinden diese nicht sofort aus der AD-Datenbank (NTDS.dit). Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE (Wahr) gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer entfernt. Anschließend wandert das Objekt in den Container „Deleted Objects“ (der in fast allen Verzeichnispartitionen existiert) und wird ab diesem Zeitpunkt als Tombstone (zu deutsch: Grabstein) bezeichnet. Im Container Deleted Objects erhält das Tombstone einen speziellen Distinguished Name (DN), der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“. Der DN des gelöschten Benutzerobjekts „Yusuf Dikmenoglu“ sieht z.B. so aus: CN=Yusuf Dikmenoglu\0ADEL:4b506a93-d721-4cbf-87dc-565939cf07af,CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de
Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit jeder Domänencontroller (DC) z.B. in einer weltweit verteilten Umgebung von der Löschung des Objekts in Kenntnis gesetzt wird, ehe das Objekt endgültig aus dem AD gelöscht wird. Gerade in größeren AD-Umgebungen mit einem komplexen Replikationszeitplan, ist diese Vorgehensweise für das Löschen von Objekten zwingend. Denn würde das Objekt nach dem löschen direkt aus der AD-Datenbank entfernt werden, würden die anderen DCs von dieser Löschung nichts mitbekommen und es entständen Lingering Objects (zu Deutsch: herumlungernde Objekte).
Lingering Objects (veraltete Objekte)
Das gelöschte Objekt verbleibt im Container Deleted Objects so lange, bis die Tombstone Lifetime (TSL) abgelaufen ist. Die TSL beträgt standardmäßig bei einer ursprünglich erstellten Windows 2000 sowie Windows Server 2003 Gesamtstruktur 60 Tage. Beim erstellen einer Gesamtstruktur ab Windows Server 2003 SP1 oder ab Windows Server 2003 R2 SP2 beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit, wird das Objekt nun endgültig vom Garbage Collection Prozess der standardmäßig alle 12 Stunden auf jedem DC läuft, aus dem AD entfernt.
Die Tombstone Lifetime
Dabei können Objekte aus der Konfigurations-, Domänen- und Anwendungsverzeichnispartition (wie z.B. ForestDNSZones und DomainDNSZones) gelöscht werden, aber nicht aus der Schemapartition! Schemaobjekte (Attribute und Klassen) können nicht entfernt werden, höchstens deaktiviert.
Ab Windows Server 2003 kann ein gelöschtes Objekt, sprich das Tombstone mit wenigen Attributen reanimiert werden. Wurde ein Objekt gelöscht, wird der DN vom Ursprungsort des Objekts im Attribut lastKnownParent eingetragen. Ein Objekt das autoritativ wiederhergestellt wurde, enthält ebenfalls im Attribut lastKnownParent den Ursprungsort. Oder wenn ein Objekt in den Container LostAndFound verschoben wird (bei einem Konflikt), der in den Verzeichnispartitionen Konfigurationspartition, Domänenpartition und Anwendungsverzeichnispartitionen wie die beiden DNS-Partitionen ForestDNSZones und DomainDNSZones existiert, wird im Attribut lastKnownParent ebenso der Ursprungsort des Konfliktobjekts eingetragen. Beim verschieben oder kopieren eines Objekts wird kein Wert im Attribut lastKnownParent eingetragen.
Wenn nun in der Domäne blog.dikmenoglu.de der Benutzer „Yusuf“ der sich in der OU „IT“ befindet gelöscht wird, enthält das Attribut lastKnownParent des gelöschten Benutzerobjekts im Container Deleted Objects der Domänenpartition den folgenden Wert:
OU=IT,DC=blog,DC=dikmenoglu,DC=de
Dadurch lassen sich wiederhergestellte Tombstones, autoritativ wiederhergestellte Objekte oder Konfliktobjekte die sich im Container LostAndFound befinden ausfindig machen, in dem man eine Abfrage nach dem Attribut lastKnownParent durchführt und dabei diesen LDAP-Filter verwendet:
(&(objectclass=*)(lastKnownParent=*))
Möchte man sich lediglich Benutzerkonten anzeigen lassen, so kann man z.B. bei einer benutzerdefinierten gespeicherten Abfrage diesen Filter verwenden:
(objectcategory=person)(lastKnownParent=*)
Den Container Deleted Object mit LDP anzeigen
Der versteckte Container Deleted Objects wird weder in der MMC Active Directory-Benutzer und -Computer, noch in ADSIEdit.msc angezeigt. Stattdessen kann man sich mit LDP.exe oder z.B. dem AD Explorer den Container Deleted Objects anzeigen lassen. Wobei der Container in den Anwendungsverzeichnispartitionen lediglich mit LDP angezeigt werden kann und nicht mit dem AD Explorer. Natürlich können aber auch andere LDAP-Browser verwendet werden.
- Das LDP.exe befindet sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools und ist bereits ab Windows Server 2008 on Bord.
- Unter Start - Ausführen startet man als Erstes das LDP
- Danach muss man sich mit einem DC verbinden. Dazu gilt es unter Windows Server 2003 im Menüpunkt Connection die Option Connect… aufzurufen und im darauffolgenden Fenster einen DC einzutragen. Unter Windows Server 2008 heißt der Menüpunkt Remotedesktopverbindung und die Option Verbinden…
- Nun gilt es unter Connection/Remotedesktopverbindung - Bind…/Gebunden… ein entsprechendes Benutzerkonto (z.B. den Domänen-Admin) anzugeben, um sich mit diesem Benutzer an das AD zu „binden“.
- Anschließend muss der Distinguished Name (DN) des entsprechenden Deleted Objects Container unter View/Ansicht - Tree/Struktur angegeben werden.
Der DN des Container Deleted Objects in der Konfigurationspartition lautet:
CN=Deleted Objects,CN=Configuration,DC=Root-Domäne
In der Domänenpartition lautet der DN von Deleted Objects wie folgt:
CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de
Der DN von Deleted Objects in den beiden DNS-Anwendungsverzeichnispartitionen lautet folgendermaßen:
CN=Deleted Objects,DC=ForestDNSZones,DC=Root-Domäne
CN=Deleted Objects,DC=DomainDNSZones,DC=Domäne,DC=de
- Nach dem man sich mit dem Container Deleted Objects verbunden hat, sieht man den Eintrag zwar auf der linken Seite im LDP-Fenster, jedoch erscheinen unter dem Eintrag keine weiteren Einträge, sprich die gelöschten Objekte bzw. Tombstones kommen nicht zum Vorschein. Diese erscheinen erst, wenn unter dem Menüpunkt Options/Optionen der Menüeintrag Controls/Steuerelemente ausgewählt und das LDAP-Control Return deleted objects (1.2.840.113556.1.4.417) als aktives Steuerelement eingecheckt wurde.
- Um nun ein Tombstone mit LDP zu reanimieren, müssen zwei Attribute im Tombstone verändert werden. Dazu klickt man mit rechts auf das zu wiederherstellende Objekt und wählt die Option Modify/Ändern. Danach muss zum einen der Wert im Attribut isDeleted gelöscht werden (den Wert aus FALSE zu setzen reicht nicht aus) und zum anderen, muss der DN des Objekts geändert werden. Dabei muss das Tombstone auch nicht zwingend an seinem Ursprungsort, der im Attribut lastKnownParent eingetragen ist, wiederhergestellt werden. Mit einem Klick auf Run/Ausführen wird das Tombstone dann wiederhergestellt.
-
In größeren AD-Umgebungen kann es im Container Deleted Objects das sich in der Domänenpartition befindet, durch die vielen gelöschten Objekte sehr unübersichtlich werden. Um sich lediglich die gelöschten Objekte eines bestimmten Zeitraums auf der rechten Seite im LDP anzeigen zu lassen, muss nach einem bestimmten Attribut in den gelöschten Objekten (den Tombstones) gesucht werden. Das Attribut in dem das Löschdatum enthalten ist lautet whenChanged.
Möchte man sich z.B. die Objekte die in den letzten 10 Tagen gelöscht wurden anzeigen, so klickt man auf der linken Seite im LDP mit rechts auf den Eintrag CN=Deleted Objects,DC=Domäne,DC=de und wählt die Option Search/Suchen. Als Filter könnte dieser eingesetzt werden: (&(objectclass=user)(whenchanged>=20090724023000.0Z)). Im Feld Attribute können die gewünschten Attribute des Tombstones angegeben werden, die ebenfalls angezeigt werden sollen. Oder es wird ein Wildcard (das Sternchen *) angegeben, um alle Attribute die im Tombstone enthalten sind anzuzeigen. Dabei muss der Wert, sprich das Datum und die Uhrzeit im Attribut whenChanged in folgender Notation angegeben werden:
2009(Jahr) 07(Monat) 24(Tag) 02(Stunden) 30(Minuten) 00(Sekunden).0Z
Man beachte bei der Zeitangabe, dass das Attribut whenChanged nicht zwischen den DCs repliziert wird.
Das bedeutet, dass der Wert im Attribut whenChanged sich von DC zu DC unterscheidet.
- Schaut man sich die LDAP-Controls im LDP unter Windows Server 2008 R2 genauer an, entdeckt man zwei neue Einträge. Die beiden neuen Einträge sind:
Mit dem LDAP-Control Return deactivated links (1.2.840.113556.1.4.2065) werden die verknüpften Attribute bei aktiviertem AD-Papierkorb eines Objekts angezeigt (z.B. das memberOf Attribut eines Benutzerobjekts). Denn wenn der AD-Papierkorb im Windows Server 2008 R2 aktiviert wurde, werden die verknüpften Attribute (Forward- und Backlink) beim Löschen eines Objekts nicht entfernt. Somit ist auch das Geheimnis des AD-Papierkorbs entlüftet, wie es mit den verknüpften Attributen umgeht.
Weitere Informationen:
Last-Known-Parent Attribute (Windows)
When-Changed Attribute (Windows)
Der Active Directory-Papierkorb im Windows Server 2008 R2
Verknüpfte Attribute
Viewing deleted objects in Active Directory
How to let non-administrators view the Active Directory deleted objects container in Windows Server 2003 and in Windows 2000 Server
Searching for Deleted Objects
Soll der erste Read-Only Domänencontroller (kurz RODC) zu einer Windows Server 2003 Gesamtstruktur hinzugefügt werden, müssen bestimmte Voraussetzungen erfüllt sein. Eine davon ist, dass das ADPREP mit dem Parameter /RODCPREP mit „Organisations-Admin“ Rechten auf irgendeinem DC auszuführen gilt. In einer Gesamtstruktur mit mehreren Domänen kontaktiert das ADPREP jeden Infrastrukturmaster um die Berechtigungen der Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren. Mit Ausführen von ADPREP /RODCPREP werden die Security Descriptor der Anwendungsverzeichnispartitionen "DomainDNSZones" sowie "ForestDNSZones" angepasst. Nach Ausführen des Befehls wird der Gruppe NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION auf den beiden DNS-Anwendungsverzeichnispartitionen die entsprechenden Zugriffsberechtigungen auf die Replikation erteilt. Ist die Gesamtstruktur mit Windows Server 2008 erstellt worden, ist das Ausführen von ADPREP nicht notwendig.
Beim aktualisieren des security descriptor der einzelnen DNS-Anwendungsverzeichnispartitionen mit ADPREP /RODCPREP kann es jedoch zu dem Problem kommen, dass der Infrastrukturmaster einer DNS-Anwendungsverzeichnispartition nicht erreichbar ist.
Die Fehlermeldungen in der Kommandozeile lauten:
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).
Der Grund dafür ist, dass ab Windows Server 2003 eine Besonderheit was die Rolle des Infrastrukturmasters anbetrifft existiert. Denn mit Windows Server 2003 wurden erstmals die Anwendungsverzeichnispartitionen eingeführt, wie z.B. im DNS die ForestDNSZones- und DomainDNSZones-Partitionen. Ab Windows Server 2003 existiert nämlich zusätzlich je ein Infrastrukturmaster pro Anwendungsverzeichnispartition. Als Infrastrukturmaster einer Anwendungsverzeichnispartition kann irgendein DC aus der jeweiligen Domäne ausgewählt werden und dieser muss nicht der Träger der Infrastrukturmasterrolle für die Domänenpartition sein.
Es existiert also ein Infrastrukturmaster für die Gesamtstrukturweite Anwendungsverzeichnispartition „ForestDNSZones“ und je ein Infrastrukturmaster pro „DomainDNSZones“. Das bedeutet für eine Gesamtstruktur mit zehn Domänen in der lediglich die Standard-Anwendungsverzeichnispartition im DNS genutzt werden und die DNS-Informationen pro Domäne in der DomainDNSZones gespeichert wird, folgende Aufteilung der FSMO-Rollen:
- Ein Schemamaster
- Ein Domänennamenmaster
- Zehn RID-Master (Relative ID)
- Zehn PDC-Emulatoren
- Zehn Infrastrukturmaster für die Domänen bzw. Domänenpartitionen
- Ein Infrastrukturmaster für die Anwendungsverzeichnispartition "ForestDNSZones"
- Zehn Infrastrukturmaster für die Anwendungsverzeichnispartition "DomainDNSZones"
Es existieren also insgesamt 21 Infrastrukturmaster in der Gesamtstruktur.
In allen Unternehmen die seit mehreren Jahren eine AD-Umgebung betreiben, müssen mit der Zeit auch die Hardware der Betriebsmasterrollen ausgetauscht werden. Wird die Hardware des FSMO-Rolleninhabers ausgetauscht, müssen alle Rollen die der DC innehat auf einen anderen DC verschoben werden. Dies kann händisch oder automatisch während dem DCPROMO-Vorgang erfolgen. Natürlich müssen auch bei einem Hardware-Crash des Rolleninhabers die gecrashten Rollen auf einem anderen DC erneut bereitgestellt werden.
Die FSMO-Rollen verschieben
Die FSMO-Rollen mit DCPROMO verschieben
Und genau bei dem Übertragen oder Übernehmen der FSMO-Rollen gehen die Infrastrukturmaster der Anwendungsverzeichnispartitionen in Vergessenheit. In den meisten Umgebungen handelt es sich dabei um den Infrastrukturmaster der beiden DNS-Anwendungsverzeichnispartitionen „ForestDNSZones“ sowie „DomainDNSZones“. Andere Anwendungsverzeichnispartitionen sind in vielen Umgebungen nicht im Einsatz.
Leider werden die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen unter Windows Server 2003 sowie Windows Server 2008 beim Übertragen (Rolleninhaber ist online) auf einen anderen DC weder über die GUI, noch in der Kommandozeile mit NTDSUTIL (NTDSUTIL - Transfer) "verschoben". Diese müssen zusätzlich noch händisch auf einen anderen DC übertragen werden. Auch beim Übernehmen (Rolleninhaber ist offline, z.B. bei einem DC-Crash) der FSMO-Rollen auf einen anderen DC, müssen zusätzlich die Infrastrukturmaster der Anwendungsverzeichnispartitionen händisch verschoben werden.
Bedauerlich das Microsoft an die Infrastrukturmaster der Anwendungsverzeichnispartitionen keine Beachtung geschenkt hat. Es erscheint weder ein Hinweis beim verschieben der FSMO-Rollen, noch wird ein Eintrag in der Ereignisanzeige protokolliert, der auf das Fehlen der Infrastrukturmaster für die Anwendungsverzeichnispartitionen hinweist. Auch überprüft das DCDIAG bei dem Test KnowsOfRoleHolders nicht die Anwendungsverzeichnispartitionen nach dem Infrastrukturmaster, sondern nur den Infrastrukturmaster der Domänenpartition. Das Fehlen eines Infrastrukturmasters für eine Anwendungsverzeichnispartition bleibt somit unbemerkt.
Den Infrastrukturmaster der DNS-Anwendungsverzeichnispartitionen mit ADSIEdit ändern
Die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen "ForestDNSZones und "DomainDNSZones" sollten bevorzugt auf dem aktuellen Infrastrukturmaster wie folgt mit ADSIEdit auf einen anderen DC verschoben werden:
- Unter Windows Server 2003 gilt es zuerst die Windows Support Tools (auf der Server-CD im Verzeichnis Support\Tools) zu installieren.
- Danach startet man das ADSIEdit, was ab Windows Server 2008 bereits "on Bord" ist.
- Im ADSIEdit wählt man mit einem Rechtsklick auf den Eintrag "ADSI Edit" die Option "Connect to..." aus.
- Im darauffolgenden Fenster "Connection Settings" ist im Bereich "Connection Point" die Option "Select or type a Distinguished Name or Naming Context" auszuwählen.
- In dem Feld trägt man dann den Distinguished Name (DN) der entsprechenden Anwendungsverzeichnispartition ein, um sich mit dieser Verzeichnispartition zu verbinden. Im Fall der "ForestDNSZones" würde der DN so lauten:
DC=ForestDNSZones,DC=Root-Domäne,DC=TLD
- Anschließend verbindet man sich noch mit den einzelnen (je nach Anzahl der Domänen) "DomainDNSZones" Partitionen. Der DN lautet wie folgt:
DC=DomainDNSZones,DC=Domäne,DC=TLD
- Wenn man nun im ADSIEdit auf der linken Seite die einzelnen Verzeichnispartitionen mit denen man sich verbunden hat erweitert, findet man auf der rechten Seite das Objekt CN=Infrastructure. Mit einem Rechtsklick auf dieses Objekt ruft man die Eigenschaften des Objekts auf und ändert dort den Wert im Attribut fSMORoleOwner. An dieser Stelle muss nicht zwingend(!) der Infrastrukturmaster für die Domänenpartition angegeben werden. Es muss bloß ein verfügbarer DC der Domäne eingetragen werden.
- Der Wert im Attribut sieht z.B. so aus:
CN=NTDS Settings,CN=DCON01,CN=Servers,CN=<Standort>,CN=Sites,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de
Den Infrastrukturmaster der DNS-Anwendungsverzeichnispartitionen mit LDP ändern
-
Unter Windows Server 2003 befindet sich das LDP in den Windows Support Tools und ab Windows Server 2008 ist es bereits „on Bord“.
-
Zuerst gilt es das LDP unter Start - Ausführen - LDP zu starten.
-
Als nächstes sollte man sich mit dem aktuellen Infrastrukturmaster verbinden. Dazu ruft man unter Windows Server 2003 im Menüpunkt Connection die Option „Connect…“ auf und trägt im darauf erscheinenden Fenster den DC ein und klickt auf OK. Unter Windows Server 2008 heißt der Menüpunkt Remotedesktopverbindung und die Option Verbinden…
-
Jetzt gilt es unter Connection/Remotedesktopverbindung - Bind…/Gebunden… ein entsprechendes Benutzerkonto (z.B. den Domänen-Admin) anzugeben, um sich mit diesem Benutzer an das AD zu „binden“.
-
Nun muss der Distinguished Name (DN) der entsprechenden Anwendungsverzeichnispartition unter View/Ansicht - Tree/Struktur angegeben werden. Der DN für ForestDNSZones lautet DC=ForestDNSZones,DC=Root-Domäne,DC=TLD und für DomainDNSZones DC=DomainDNSZones,DC=Domäne,DC=TLD.
-
Mit einem Rechtsklick auf den Eintrag CN=Infrastructure,DC=ForestDnsZones,DC=Root-Domäne,DC=de bzw. CN=Infrastructure,DC=DomainDnsZones,DC=Domäne,DC=de gilt es die Option Modify auszuwählen.
-
Anschließend muss als Wert im Attribut fSMORoleOwner der DN des NTDS Settings Objekts des zukünftigen Infrastrukturmaster eingetragen werden, z.B.:
CN=NTDS Settings,CN=MZDCON02,CN=Servers,CN=Mainz,CN=Sites,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de
Existieren evtl. noch selbst erstellte Anwendungsverzeichnispartitionen, so müssen die Infrastrukturmasterrollen dieser Verzeichnispartitionen ebenfalls auf einen anderen DC verschoben werden, wenn der Ursprungsrollenträger aus der Domäne entfernt werden soll oder nicht mehr zur Verfügung steht.
Zum ändern des Infrastrukturmasters für die Anwendungsverzeichnispartition „DomainDNSZones“ kann man auch das Skript in dem folgenden Artikel verwenden:
Error message when you run the "Adprep /rodcprep" command in Windows Server 2008: "Adprep could not contact a replica for partition DC=DomainDnsZones,DC=Contoso,DC=com"
Die Verzeichnispartitionen und die Infrastrukturmasterrolle der DNS-Partitionen anzeigen
Der folgende Befehl kann dazu verwendet werden, alle Verzeichnispartitionen die in der Gesamtstruktur existieren anzeigen zu lassen:
Dsquery * CN=Partitions,CN=Configuration,DC=Domäne,DC=de -attr nCName
Möchte man sich lediglich die Anwendungsverzeichnispartitionen die in der Gesamtstruktur existieren anzeigen lassen, so ist das mit diesem Befehl möglich:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=de -Filter "(&(objectcategory=crossRef)(systemFlags:1.2.840.113556.1.4.803:=5))" -Scope OneLevel -attr dnsRoot
Bei dieser Abfrage werden alle crossRef-Objekte im Container Partitions abgefragt, die im systemFlags Attribut als Wert 0101 (Dezimal 5) eingetragen haben. Der Befehl sieht in einer kürzeren Fassung mit dem gleichen Ergebnis so aus:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=de -Filter (systemFlags=5) -Scope OneLevel -attr dnsRoot
Die Abfrage nach dem Attribut dnsRoot liefert als Ergebnis immer den DNS-Namen der Anwendungsverzeichnispartitionen, wie z.B.: DomainDNSZones.blog.dikmenoglu.de. Bei der Abfrage nach dem Attribut nCName wird als Ergebnis der „Distinguished Name“ der Partitionen geliefert. Die Abfrage sieht wie folgt aus:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne,DC=de -Filter (systemFlags=5) -Scope OneLevel -attr nCName
Die Infrastrukturmasterrolle der ForestDNSZones-Partition lässt sich mit diesem Befehl anzeigen:
Dsquery * CN=Infrastructure,DC=ForestDNSZones,DC=Root-Domäne -attr fSMORoleOwner
Die Infrastrukturmasterrollen der jeweiligen DomainDNSZones-Partition lassen sich wie folgt herausfinden:
Dsquery * CN=Infrastructure,DC=DomainDNSZones,DC=<die entsprechende Domäne>,DC=TLD -attr fSMORoleOwner
Warum beeinträchtigt ein fehlender Infrastrukturmaster einer DNS-Anwendungsverzeichnispartition nicht die Domäne?
Die Arbeit des Infrastrukturmaster besteht darin, domänenübergreifende Objektreferenzen (z.B. bei domänenübergreifenden Gruppenmitgliedschaften) innerhalb seiner Domäne stets aktuell zu halten. In den beiden DNS-Anwendungsverzeichnispartitionen werden jedoch ausschließlich die DNS-Zonen (Forward Lookup- und Reverse Lookup Zonen) gespeichert, die keine Verweise zu anderen Objekten in anderen Verzeichnispartitionen verwenden. Daher hat ein Infrastrukturmaster für die beiden DNS-Anwendungsverzeichnispartitionen nichts zu tun und wird deshalb nicht benötigt. Aus diesem Grund fällt an dieser Stelle ein fehlender Infrastrukturmaster für die DNS-Anwendungsverzeichnispartitionen im laufenden Betrieb nicht auf.
Siehe auch:
Phantome im Active Directory
Erst beim ausführen von ADPREP /RODCPREP wird man auf diesen Fehler aufmerksam gemacht, der sich schnell und einfach beheben lässt.
Weitere Informationen:
DCDIAG: NCSecDesc Fehler
Read-Only Domain Controller (RODC)
Die Installation eines RODC
How many Infrastructure Masters do you have?
Phantome im Active Directory (AD) sind nichts anderes als Referenzen auf Objekte aus anderen Domänen innerhalb der Gesamtstruktur. Wird z.B. ein Domänen-Benutzer zu einer Gruppe in einer anderen Domäne hinzugefügt, erstellt der lokale Domänencontroller (DC) der den Domänen-Benutzer zur Gruppe hinzufügt automatisch ein spezielles Objekt in der Datentabelle. Das spezielle Objekt ist das Phantomobjekt für den Domänen-Benutzer. Mit einem Phantomobjekt können DCs Verweise auf Objekte die sich in anderen Domänen innerhalb der Gesamtstruktur befinden verwalten. Im Phantomobjekt wird der ObjektGUID, ObjektSID und der Distinguished Name (DN) des neuen Gruppenmitglieds gespeichert. Durch dieses Phantomobjekt wird ein Distinguished Name Tag (DNT) bereitgestellt, das im member Attribut einer Gruppe gespeichert werden kann. Ist jedoch auf dem DC der globale Katalog (GC) aktiviert, so wird kein Phantomobjekt erstellt. Denn im GC befindet sich bereits ein Eintrag in der Datentabelle für jedes Objekt in der Gesamtstruktur. Phantomobjekte sind eine spezielle Art von internen Datenbankobjekten die einzig und alleine zum nachverfolgen dienen und lassen sich deshalb weder über die LDAP- noch ADSI-Schnittstelle anzeigen.
Die Anzahl der Phantomobjekte kann man sich mit NTDSUTIL anzeigen lassen. Führt man mit NTDSUTIL eine Analyse der AD-Datenbank mit Semantic Database Analysis durch, wird eine Datei erzeugt deren Inhalt so aussieht:
Summary:
Active Objects 9647
Phantoms 67
Deleted 2469
Der DC der die Rolle des Infrastrukturmasters innehat vergleicht regelmäßig die Einträge in seiner Datentabelle mit dem GC. Stellt dieser fest das ein Objekt umbenannt, verschoben oder gelöscht wurde, aktualisiert der Infrastrukturmaster automatisch das Phantomobjekt in der Datentabelle und repliziert die Änderung auf seine Replikationspartner innerhalb der Domäne. Wird das Quell-Objekt in eine andere Domäne verschoben, ändert sich der DN des Objekts und der Infrastrukturmaster aktualisiert automatisch den DN vom Phantomobjekt. Der Infrastrukturmaster überprüft standardmäßig alle zwei Tage die Verknüpfungsbeziehungen und kann auch Phantomobjekte entfernen, auf die sich keine Forward-Link Attribute in der Domäne mehr beziehen. Bei Bedarf kann das Intervall auf dem DC der die Rolle des Infrastrukturmasters innehat, mit Erstellen des folgenden Registryschlüssels angepasst werden:
Registrierungseintrag: Days per database Phantom scan
Type: DWORD
Standardwert: 2 Tage (der Mindestwert wäre ein Tag)
Ein Phantomobjekt wird letztendlich vom Garbage Collection Prozess der alle 12 Stunden auf jedem DC ausgeführt wird erst dann entfernt, wenn alle Verweise zum Quell-Objekt entfernt wurden.
Es könnte aber auch durchaus sein, dass ein Forward-Link Attribut auf Objekte außerhalb der eigenen Gesamtstruktur verweist (z.B. auf Objekte einer vertrauenswürdigen Domäne). In solch einem Fall wird vom AD in der Domänenverzeichnispartition ein Objekt im Container ForeignSecurityPrincipals erstellt. Dieses Objekt wird dann als Foreign Security Principal (kurz FSP) bezeichnet. In diesem FSP werden neben dem SID zusätzliche Attribute gespeichert, damit das Objekt in der vertrauenswürdigen Domäne eindeutig identifiziert werden kann. Ein Nachteil des FSP ist, das es keinen Prozess gibt damit der FSP stets aktuell bleibt (z.B. wenn das Quell-Objekt umbenannt wird). Muss ein FSP von einer System State-Sicherung wiederhergestellt werden, so wird das FSP wie jedes andere AD-Objekt behandelt.
Weitere Informationen:
Verknüpfte Attribute
Die Active Directory-Datenbank reparieren
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Phantoms, tombstones and the infrastructure master
How the Data Store Works
Alle Active Directory (AD) Daten wie z.B. Benutzer-, Gruppen- oder Computerobjekte werden in der transaktionalen Datenbankdatei NTDS.DIT gespeichert, die sich standardmäßig im Verzeichnis %windir%\NTDS auf jedem Domänencontroller (DC) befindet. Die zugrundeliegende Datenbank-Engine ist die Extensible Storage Engine (ESE), die ebenfalls im Exchange und WINS-Umfeld zum Einsatz kommt. Die AD-Datenbank NTDS.DIT besteht intern aus drei Tabellen: Datentabelle (Data-Table), Verknüpfungstabelle (Link-Table) und (security descriptor) SD-Table. Die beiden elementarsten 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.
Jedes AD-Objekt (z.B. Benutzer, Gruppen, Computer und Anwendungsspezifische Daten) wird zusammen mit seinem „Distinguished Name“ (DN) und einer eindeutigen Kennung in einer einzelnen Zeile, mit einer Spalte pro Attribut in der Datentabelle gespeichert. Oder anders ausgedrückt entspricht jede Zeile in der Datentabelle einem Objekt. Bei einem DC enthält die Datentabelle die Einträge aus der Schema-, Konfigurations-, Anwendungs- und Domänenpartition. Auf einem globalen Katalog (GC) enthält die Datentabelle Einträge für jedes Objekt in der Gesamtstruktur, denn alle Objekte aus allen Domänenpartitionen innerhalb der Gesamtstruktur werden mit den Attributen die für eine Suche relevant sind, in den GC repliziert.
Das AD verwendet als eindeutige Kennung das Distinguished Name Tag (DNT), um jede Zeile in der Datentabelle eindeutig zu identifizieren. Bei dem DNT handelt es sich um einen 32Bit Integer Wert und dieser wird zum internen Verweis auf Objekte verwendet. Der Distinguished Name Tag ist eine lokale Kennung der nicht zwischen den DCs repliziert wird und lautet bei jedem DC anders.
Das Verknüpfen von Objekten
Im AD existieren zwei Arten von Beziehungen die zwischen den Objekten verwaltet werden. Zum einen ist es die Beziehung zwischen den über- und untergeordneten Objekten und zum anderen ist es die Verknüpfungsbeziehung. 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 Verknüpfungsbeziehung zwischen einem Verknüpfungspaar wird in der Verknüpfungstabelle gespeichert. Die Verknüpfungstabelle verwendet nur den DNT der gespeicherten Objekte, um den DN und somit das Objekt selbst ausfindig zu machen. Diese Vorgehensweise innerhalb der AD-Datenbank stellt sicher, dass die Integrität der Objekte und den jeweiligen Links gewährleistet ist.
Im AD werden alle Attribute durch ein attributeSchema-Objekt in der Schemapartition definiert, wobei diverse Attribute im AD als Verknüpfungsattribute definiert sind. Als Verknüpfungsattribute werden Attribute bestimmt, die einen geraden Wert im LinkID Attribut des attributeSchema-Objekts enthalten.
Verknüpfte Attribute (auf Englisch: Linked Attributes) stellen eine besondere Beziehung im Active Directory zueinander dar und sind Verknüpfungspaare, die aus einem Forward-Link Attribut und einem Back-Link Attribut bestehen um eine Verknüpfung zwischen zwei AD-Objekten zu erstellen.
Der Wert des Back-Link Attributs wird basierend auf dem Wert das im Forward-Link Attribut eingetragen ist berechnet. Der Wert eines Back-Link Attributs im Zielobjekt besteht aus den Distinguished Name Einträgen aller Objekte, in denen der DN des Quellobjekts im entsprechenden Forward-Link Attribut eingetragen ist.
Z.B. stellen in den Eigenschaften eines Benutzerkontos, in der Registerkarte „Organisation“ die Attribute „manager“ (Feldname: Vorgesetzter) und das Attribut „directReports“ (Feldname: Mitarbeiter) ein Verknüpfungspaar dar. Dabei handelt es sich bei dem einwertigen (single-value) Attribut „manager“ um das Forward-Link und bei dem mehrwertigen (multivalue) Attribut „directReports“ um das Back-Link Attribut.
Ein weiteres Beispiel ist die Gruppenmitgliedschaft eines Domänen-Benutzers. Das MemberOf-Attribut im Benutzerobjekt ist das Back-Link und das Member-Attribut im Gruppenobjekt das Forward-Link Attribut. Beide Attribute sind mehrwertig und stellen eine Verknüpfung zwischen dem Gruppenobjekt und seinen Benutzerobjekten dar. Denn schließlich kann ein Domänen-Benutzer Mitglied in mehreren Gruppen sein und eine Gruppe kann mehrere Domänen-Benutzer als Gruppenmitglieder enthalten. Das member Atribut im Gruppenobjekt scheint in der MMC Active Directory-Benutzer und -Computer die DNs der Mitglieder zu enthalten, aber tatsächlich werden die DNs vom AD anders gespeichert. Wird der DN eines Benutzerobjekts dem member Attribut einer Gruppe hinzugefügt, speichert das AD den DNT des Objekts und nicht den DN. Da 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 in jedem member Attribut zu aktualisieren.
Wird in einem Verknüpfungspaar der Wert eines Forward-Link Attributs vom Administrator verändert, aktualisiert das Active Directory automatisch das Back-Link Attribut. Das beinhaltet selbstverständlich auch das Löschen von Werten. Dabei kann lediglich der Forward-Link vom Administrator bearbeitet werden (wie z.B. das Member-Attribut eines Gruppenobjekts), der zwischen den DCs repliziert wird.
Back-Links dagegen werden von jedem DC selbst verwaltet und können auch nicht vom Administrator bearbeitet werden. Es ist ein sogenanntes system-only Attribut und wird auch nicht auf andere DCs repliziert. Ein Back-Link und sein Wert werden zum Zeitpunkt der Abfrage generiert. Solche Attribute tragen den Namen constructed.
Das LinkID Attribut im Forward-Link enthält immer einen geraden und das LinkID Attribut im verknüpften Back-Link enthält einen ungeraden Wert, nämlich den Wert „Forward-LinkID plus 1“. Beispielsweise enthält das LinkID Attribut im attributeSchema-Objekt Manager den Wert 42 und das LinkID Attribut im attributeSchema-Objekt directReports den Wert 43. Im attributeSchema-Objekt Member enthält das LinkID Attribut den Wert 2 und im attributeSchema-Objekt MemberOf enthält das LinkID Attribut den Wert 3.
Es gibt aber auch Gruppentypen die Mitglieder enthalten können, die sich in einer anderen Domäne befinden. Das AD speichert dazu ein spezielles Objekt in der Datentabelle, damit ein DNT bereitgestellt und im member Attribut der Gruppe gespeichert werden kann. Was genau das auf sich hat, wird in diesem Artikel beschrieben:
Phantome im Active Directory
Weitere Informationen:
Die unterschiedliche Größe der AD-Datenbank
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Link-ID Attribute (Windows)
Linked Attributes (Windows)
How the Data Store Works: Active Directory
Wenn das DCDIAG auf einem Windows Server 2008 oder Windows Server 2008 R2 ausgeführt wird, kann es unter Umständen zu folgendem Fehler bei dem NCSecDesc Test kommen:
Starting test: NCSecDesc
Fehler: NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION besitzt
keine Replicating Directory Changes In Filtered Set
Zugriffsrechte für den Namenskontext:
DC=DomainDnsZones,DC=Domäne,DC=TLD
Fehler: NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION besitzt
keine Replicating Directory Changes In Filtered Set
Zugriffsrechte für den Namenskontext:
DC=ForestDnsZones,DC=Domäne,DC=TLD
.................. DCON01 hat den Test NCSecDesc nicht bestanden.
Wird ein Windows Server 2008 oder Windows Server 2008 R2 als zusätzlicher Domänencontroller (DC) zu einer Windows 2000 oder Windows Server 2003 Domäne hinzugefügt, kann es zu diesem Fehler kommen. Das DCDIAG ab Windows Server 2008 bringt bei dem NCSecDesc Test einen Fehler, wenn der Befehl ADPREP /RODCPREP nicht ausgeführt wurde.
Denn bei diesem Test wird überprüft, ob der Security Descriptor der genannten Verzeichnispartitionen, in dem Fall die beiden Anwendungsverzeichnispartitionen "DomainDNSZones" sowie "ForestDNSZones", über die entsprechenden Berechtigungen für die Replikation verfügt. Der Fehler zeigt an, dass die Gruppe NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION keine Zugriffsberechtigung auf die Replikation der Verzeichnisänderungen für die beiden DNS-Anwendungsverzeichnispartitionen besitzt.
Falls es nicht geplant ist einen Read-Only Domänencontroller (RODC) in der Gesamtstruktur zu installieren, kann dieser Fehler getrost ignoriert werden. Aber wenn es doch geplant ist einen RODC in der Gesamtstruktur zu installieren, verschwindet dieser Fehler nach dem Ausführen von ADPREP /RODCPREP. Dabei kann das ADPREP sowohl von der Windows Server 2008 DVD als auch von der Windows Server 2008 R2 DVD auf irgendeinem DC mit „Organisations-Admin“ Rechten ausgeführt werden. Denn beide ADPREP-Versionen setzen beim Ausführen des Parameters /RODCPREP die gleichen Berechtigungen in den DNS-Anwendungsverzeichnispartitionen.
Das ADPREP kontaktiert während der Ausführung alle Infrastrukturmasterrollen der einzelnen DNS-Anwendungsverzeichnispartitionen in der Gesamtstruktur und aktualisiert die Berechtigungen. Während der Durchführung von ADPREP /RODCPREP könnte es sein, dass ein Infrastrukturmaster nicht erreichbar ist. Was genau das auf sich hat, beschreibt der folgende Artikel:
Die Infrastrukturmaster der Anwendungsverzeichnispartitionen
Weitere Informationen:
Die Installation eines RODC
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|