Freigeben über

Dcpromo mit Fehler "1908. (Could not find the domain controller for this domain)" und Angabe eines falschen Domänen Controller Namens

  • Artikel

Hallo, hier ist mal wieder der Thomas.

Letzte Woche bin ich auf eine ganz merkwürdige Sache gestoßen:

Ein Kunde wollte eine neue Domäne namens DC in seinem Forest WAN.LAN einrichten und erhielt immer wieder einen Error 1908.
Der für die Domäne "DC" vorgesehene 1. DC in spe befand sich noch in einer Arbeitsgruppe mit dem schönen Namen Workgroup, war also kein Mitglied irgendeiner Domäne im Forest.

Also erst einmal das Standardbesteck ausgepackt und DCPROMO.LOG, DCPROMUI.LOG und einen Netzwertrace der ganzen Aktion angeschaut.
Das DCPROMO.LOG zeigte, dass der neue DC gerade damit beginnen wollte, die Schema Directory Partition zu replizieren und dann meldete, dass auf den Domänen Controller rtdc001.wan.lan nicht zugegriffen werden konnte.

Diese wurde so laut DCPROMOUI.LOG auch als Dialogbox dem Administrator mitgeteilt:

Active Directory Domain Services could not replicate the directory partition CN=Schema,CN=Configuration,DC=wan,DC=lan from the remote Active Directory Domain Controller rtdc001.wan.lan.

Was tut man in einem solchen Fall relativ automatisch? Na klar, man versucht, seit den Kindertagen von Windows NT den PDC-Emulator der Forest Root, dem NetBIOS Namenscache hinzuzufügen.

Das geht dann so:
Man lege eine  LMHOSTS-Datei an und füge folgende Einträge hinzu:

10.10.0.55 rtdc001 #PRE #DOM:WAN

10.10.0.55 "WAN \0x1b" #PRE

NBTSTAT -c gibt danach folgendes aus, aber nur, wenn man vorher mit NBTSTAT -R ein erneutes Laden veranlasst hat:

Node IpAddress: [55.30.10.10] Scope Id: []

NetBIOS Remote Cache Name Table

Name Type Host Address Life [sec]
------------------------------------------------------------
RTDC001 <03> UNIQUE 10.10.0.55 -1
RTDC001 <00> UNIQUE 10.10.0.55 -1
RTDC001 <20> UNIQUE 10.10.0.55 -1
WAN <1C> GROUP 10.10.0.55 -1
WAN <1B> UNIQUE 10.10.0.55 -1   

Das ist häufig bereits die Lösung, war es in diesem Fall aber nicht.

Im Trace konnte man danach sehen, dass der rtdc001 ohne weiteres erreicht werden konnte.

Der RPC-Verkehr ging auch noch so weit, dass der Jung-DC sich die Port-Redirection Auswahl ( 49555, 49558 und 49194) abholte, sich auf TCP Ebene mit Port 49555 verband,  danach aber nur noch TCP Keep Alives sendete. Es sah fast so aus, als würde er auf etwas warten.

Der nächste Schritt besteht darin, eine solche Problemstellung von der Netzwerkseite her zu untersuchen.
Dies bedeutet:

  1. Anzahl der NW-Karten feststellen. Mehr als eine ist in solchen Fällen immer schlecht. 
  2. Teaming von Netzwerkkarten deaktivieren. 
  3. NW-Treiber auf Aktualität überprüfen und ggf. die neuesten Treiber installieren. 
  4.  TCP-Performanceoptimierungen wie Checksum Offloading, Chimney etc. deaktivieren und alle automatischen Einstellungen wie Geschwindigkeit und Richtung auf feste Werte setzen.

Nächste Vermutung war, dass es eventuell am Namen der neuen Domäne "DC.WAN.LAN" liegen könnte, denn DC=DC,DC=WAN,DC=LAN sieht in LDAP Syntax zugegebenermaßen etwas schräg aus. Also das Ganze mit DC-AD.WAN.LAN probiert, war aber nichts mit einem potentiellen Parsing Bug.

Schließlich habe ich mir die Traces  und das DCPROMO.LOG nochmals vorgenommen und folgendes festgestellt:

DCPROMO.LOG: Der verwendete User war euro\xy4711.
Trace: Unser Möchtegern-DC fahndete die ganze Zeit nach einem Domänen Controller der EURO Domäne.

Ein Nachfrage ergab, dass EURO.WAN.LAN eine weitere Child-Domäne ist,  aus welcher eine administrative Gruppe der Gruppe der Enterprise  Administratoren der Forest Root WAN.LAN hinzugefügt worden war.
Diese Domäne war aber aufgrund von Firewall Regeln aus dem Subnetz des DC-in-spe nicht erreichbar.
Nachdem wir einen Enterprise Administrator Account der Forest Root in UPN Notation verwendet haben (EA@wan.lan) funktionierte alles.

Warum war der Fehler schwer zu finden?

  1. Im Event 1908 wurde der falsche Rechnername, nämlich der Root-DC, von dem das Schema repliziert werden sollte,  zurückgegeben.
  2. Wohl kaum jemand rechnet damit, dass Enterprise Administratoren in Child Domänen definiert werden.
  3. Das Anlegen anderer Child Domänen mit dem EUR\xy4711 Konto war vorher erfolgreich gewesen, da Domänen Controller der  EUR Domäne über das Netzwerk erreicht wurden.
  4. Das Ganze hätte wohl auch funktioniert, wenn man zusätzlich einen erreichbaren DC der EURO in den LMHOSTS cache eingetragen hätte.

Fazit:
Definiert Enterprise Administratoren nur in der Forest Root, dann gibt es weniger Ärger und Verwirrung.

Viele Grüße
Thomas

Comments

  • Anonymous
    April 15, 2010
    Ein sehr interresanter Fall. ;-)

  • Anonymous
    April 15, 2010
    The comment has been removed