Ich habe also zwei Wälder, nennen wir siealpha.beispiel.comUndbravo.example.com. Die NETBIOS-Namen der Domänen sind ALPHA bzw. BRAVO. Das würde bedeuten, dass es kein Problem mit der Domänenbenennung gibt, sie haben zwei verschiedene Namen, sowohl DNS- als auch NETBIOS-mäßig.
Ich habe die folgenden Server als Domänencontroller:
- dc01.alpha.beispiel.com
- dc02.alpha.beispiel.com
- dc01.bravo.example.com
Wenn ich versuche, auf diese Weise eine Gesamtstrukturvertrauensstellung zwischen ALPHA und BRAVO herzustellen, erhalte ich die Meldung „Keine Anmeldeserver verfügbar, um die Anmeldeanforderung zu bearbeiten“, wenn es darum geht, die Vertrauensstellung tatsächlich zu überprüfen. Ich habe festgestellteinige Forenbeiträgeonline und habe auch einige anekdotische Beweise gehört, dass es Probleme gibt, wenn zwei Domänen miteinander verbunden werden, wenn die Domänencontroller in beiden Domänen dieselben Namen haben. Das scheint mir keinen Sinn zu ergeben und klingt, als wäre es ein Fehler in den Microsoft-Tools.
Ich dachte nicht, dass dies ein Problem sein sollte, da dc01.alpha.example.com und dc01.bravo.example.com offensichtlich zwei verschiedene Maschinen sind, aber Windows scheint da nicht mit mir übereinzustimmen.
Fehlen mir Informationen, die mir helfen würden, dieses Setup zum Laufen zu bringen? Das Umbenennen der Domänencontroller ist für uns leider keine gute Lösung, da das Endergebnis darin besteht, viele Gesamtstrukturen miteinander zu verbinden, die alle Domänencontroller mit demselben Namen haben. Das würde bedeuten, eine Reihe von DCs umzubenennen.
Der Vollständigkeit halber sei erwähnt, dass ich durch die Umbenennung eines der Domänencontroller zwar eine Vertrauensstellung herstellen kann, dies in der realen Welt jedoch nach Möglichkeit nicht tun möchte.
Auf allen Maschinen im Labor läuft Windows Server 2012 R2 mit den neuesten Patches, es sind jedoch keine speziellen Hotfixes installiert.
DNS wird folgendermaßen eingerichtet: In der ALPHA-Domäne wird eine Stub-Zone für bravo.example.com hinzugefügt, die auf die IP-Adresse von dc01.bravo.example.com verweist. Im Gegenzug verwendet dc01.bravo.example.com dc01.alpha.example.com und dc01.bravo.example.com als Upstream-DNS. Das ist ein bisschen ein Hack-Setup (weil es ein Labor ist ...), aber das Ergebnis ist eine in beide Richtungen korrekt funktionierende DNS-Auflösung. dc01.bravo.example.com kann Namen in bravo.example.com auflösen (weil es maßgebend ist) und Namen von alpha.exaple.com werden korrekt aufgelöst, weil Upstream-DNS dafür maßgebend ist. Resolver in Alpha können die Namen von bravo aufgrund der Stub-Zone korrekt auflösen (die zu AD hinzugefügt wird, damit beide DNS-Server sie erhalten).
Ich habe zusätzlich versucht:
- Wechseln von einer Stubzone zu einem bedingten Forwarder
- Ausführen einer Gesamtstrukturvertrauensstellung anstelle einer externen Vertrauensstellung
Keine Veränderung der Symptome.
Antwort1
Ihr Problem ist auf das sogenannte Namenssuffixrouting zurückzuführen. Der folgende Artikel beschreibt das Problem: https://technet.microsoft.com/en-us/library/cc784334%28v=ws.10%29.aspx Darin heißt es, dass Netdom zur Lösung des Problems verwendet werden kann.
Artikel besagt teilweise
Weiterleiten von Namenssuffixen über Gesamtstrukturen hinweg
Das Namenssuffixrouting ist ein Mechanismus, der verwendet wird, um zu verwalten, wie Authentifizierungsanforderungen über Windows Server 2003-Gesamtstrukturen geroutet werden, die durch Gesamtstrukturvertrauensstellungen miteinander verbunden sind. Um die Verwaltung von Authentifizierungsanforderungen zu vereinfachen, werden beim erstmaligen Erstellen einer Gesamtstrukturvertrauensstellung alle eindeutigen Namenssuffixe standardmäßig geroutet. Ein eindeutiges Namenssuffix ist ein Namenssuffix innerhalb einer Gesamtstruktur, z. B. ein Benutzerprinzipalname-Suffix (UPN), ein Dienstprinzipalname-Suffix (SPN) oder ein DNS-Gesamtstruktur- oder Domänenstrukturname, das keinem anderen Namenssuffix untergeordnet ist. Beispielsweise ist der DNS-Gesamtstrukturname „microsoft.com“ ein eindeutiges Namenssuffix innerhalb der Gesamtstruktur „microsoft.com“.
Gesamtstrukturen können mehrere eindeutige Namenssuffixe enthalten, und alle untergeordneten Elemente eindeutiger Namenssuffixe werden implizit weitergeleitet. In Active Directory-Domänen und -Vertrauensstellungen werden Namenssuffixe deshalb am Anfang mit einem Sternchen (*) angezeigt. Wenn Ihre Gesamtstruktur beispielsweise.microsoft.com als eindeutiges Namenssuffix, dann werden Authentifizierungsanforderungen für alle untergeordneten Elemente von microsoft.com (.child.microsoft.com) wird weitergeleitet, da die untergeordneten Domänen Teil des Namenssuffixes microsoft.com sind.
Wenn zwischen zwei Gesamtstrukturen eine Gesamtstrukturvertrauensstellung besteht, können Namenssuffixe, die in einer Gesamtstruktur nicht vorhanden sind, verwendet werden, um Authentifizierungsanforderungen an eine zweite Gesamtstruktur weiterzuleiten. Wenn ein neues untergeordnetes Namenssuffix (.child.widgets.com) wird zu einem eindeutigen Namenssuffix hinzugefügt (.widgets.com), erbt das untergeordnete Namenssuffix die Routingkonfiguration des eindeutigen Namenssuffixes, zu dem es gehört. Alle neuen eindeutigen Namenssuffixe, die nach der Einrichtung einer Gesamtstrukturvertrauensstellung erstellt werden, werden im Dialogfeld „Eigenschaften der Gesamtstrukturvertrauensstellung“ angezeigt, nachdem Sie die Vertrauensstellung überprüft haben. Das Routing für diese neuen eindeutigen Namenssuffixe ist jedoch standardmäßig deaktiviert. Weitere Informationen zum Überprüfen einer Vertrauensstellung finden Sie unter Überprüfen einer Vertrauensstellung.
Wenn ein doppeltes Namenssuffix erkannt wird, wird das Routing für das neueste Namenssuffix standardmäßig deaktiviert. Weitere Informationen zum Routing von Namenssuffixen finden Sie unter Aktivieren oder Deaktivieren des Routings für ein vorhandenes Namenssuffix. Administratoren können das Dialogfeld „Eigenschaften der Gesamtstrukturvertrauensstellung“ verwenden, um manuell zu verhindern, dass Authentifizierungsanforderungen für bestimmte Namenssuffixe an eine Gesamtstruktur weitergeleitet werden.
Hinweise • Fügen Sie dem UPN-Suffix oder einem Benutzernamen kein @-Zeichen hinzu. Wenn Authentifizierungsanforderungen an eine vertrauenswürdige Gesamtstruktur weitergeleitet werden, werden alle Zeichen vor dem ersten @-Symbol als Benutzername und alles nach dem ersten @-Symbol als UPN-Suffix interpretiert.
• Die Local Security Authority (LSA) blockiert das Routing zu UPN-Suffixen, die keine gültigen DNS-Namen sind. Wenn Sie beispielsweise einem UPN-Suffix ein @-Symbol hinzufügen, wird es automatisch deaktiviert.