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:



  1. Ein Schemamaster 
  2. Ein Domänennamenmaster
  3. Zehn RID-Master (Relative ID)
  4. Zehn PDC-Emulatoren
  5. Zehn Infrastrukturmaster für die Domänen bzw. Domänenpartitionen
  6. Ein Infrastrukturmaster für die Anwendungsverzeichnispartition “ForestDNSZones”
  7. 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:



  1. Unter Windows Server 2003 gilt es zuerst die Windows Support Tools (auf der Server-CD im Verzeichnis Support\Tools) zu installieren. 
  2. Danach startet man das ADSIEdit, was ab Windows Server 2008 bereits “on Bord” ist. 
  3. Im ADSIEdit wählt man mit einem Rechtsklick auf den Eintrag “ADSI Edit” die Option “Connect to…” aus. 
  4. Im darauffolgenden Fenster “Connection Settings” ist im Bereich “Connection Point” die Option “Select or type a Distinguished Name or Naming Context” auszuwählen. 
  5. 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
     
  6. 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
     
  7. 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. 
  8. 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


 




  1. Unter Windows Server 2003 befindet sich das LDP in den Windows Support Tools und ab Windows Server 2008 ist es bereits „on Bord“.



  2. Zuerst gilt es das LDP unter Start – Ausführen – LDP zu starten.



  3. 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…



  4. 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“.



  5. 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.



  6. 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.



  7. 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?


 

Comments are closed, but trackbacks and pingbacks are open.