Domaintrust

Vertrauensstellungen zwischen Windows Domänen und Active Directory Forest sind schon ein alter Hut. schon mehrere Jahrzehnte kann ich meine Domäne mit anderen Domänen verbinden, um deren Anmeldekonten für Authentifizierung zu nutzen. Ziel ist ja immer "Ein Anwender ein Account eine Anmeldung". So hat es der Anwender bei der Anmeldung einfach, weil er nur ein Konto und Kennwort wissen muss und auch die Firma hat es besser, wenn es nur eine Identität gibt. Besonders wenn jemand sein Kennwort ändert oder jemand ausscheidet. In beiden Fällen ist die Funktion quasi "sofort" aktiv bzw. gesperrt. Eine Doppelverwaltung ist nicht erforderlich.

Allerdings gibt es für Exchange und Lync Ausnahmen. Hier kann ein Trust zwar helfen, dass die Anwender nur ein "SingleSignOn" nutzen, aber dennoch müssen Sie zumindest in dem Forest mit Exchange/Lync ein AD-Konto für die Ablage der Konfigurationsinformationen anlegen. Dieses Konto sollte dann aber deaktiviert sein. Weitere Informationen dazu finden Sie auf:

Trusting und Trusted

Viel Verwirrung gibt es immer bei den Begriffen "Vertraute" und "Vertrauende" Domain, insbesondere wenn Deutsch/Englisch gemischt wird und es auch noch eine bidirektionale Vertrauensstellung ist. Es ist aber ganz einfach und anhand von zwei Domänen A und B und einem einseitigen Trust  A "vertraut" B" beschrieben.

Domäne Bezeichnung Bedeutung

A

Vertrauende Domain
Trusting Domain

Diese Domäne kann auf die Benutzerinformationen von Domäne B zugreifen und die Benutzer und globalen Gruppen aus B nutzen, um diesen Rechte auf Ressourcen in A zu geben. Zudem erscheint auf den Computern der Domäne A auch die Domäne B als Auswahl im Anmeldebildschirm.

Wenn dies nur ein einseitiger Trust ist, dann muss der Administrator von A bei der Auswahl der Benutzer aus der Domäne B aber Anmeldedaten für die Domäne B angeben.

Der Administrator aus B muss also einen Benutzer mit Kennwort anlegen, den der Admin aus A verwenden kann. B vertraut ja nicht A.

B

Vertraute Domain
Trusted Domain

Diese Domäne stellt ihre Benutzerdatenbank der Domäne A bereit. Die Anwender sehen bei einer einseitigen Vertrauensstellung nichts von der Domäne A. Sie können aber entsprechend ihrer Berechtigungen auf Ressourcen in der Domäne A zugreifen.

Und wenn Sie nun eine bidirektionale Vertrauensstellung einrichten, dann gilt alles auch in die Gegenrichtung. Sie sparen sich dann aber unter umständen auch das gesonderte Konto, welches der Admin der anderen Domäne zur Auswahl der Benutzer explizit eingeben musste.

Beachten Sie auch die Informationen auf Windows Gruppen bezüglich der Mitgliedschaft von Gruppen in Gruppen

One-Way oder Two-Way

Meist wird die Frage gestellt, ob der Trust in beide Seiten oder nur in eine Richtung eingerichtet werden soll. Das hängt zum einen natürlich davon ab, auf welcher Seite die Dienste sind und auf welcher Seite die Anwender sich anmelden. In vielen Fällen ist es aber so, dass die Anwender eines Forest auf Dienste in einem anderen Forest zugreifen müssen. Technisch würde es dann reichen, wenn die Ressourcendomäne der Anmeldedomäne vertraut.

Genau das bedeutet der Begriff "Vertrauen". Die Ressourcendomäne mit den Diensten vertraut der Authentifizierung (und dem Administrator) , die durch die Anmeldedomäne durchgeführt wird.

Allerdings muss natürlich der Administrator in der Ressourcendomäne die Personen und ggfls. Gruppen aus der Anmeldedomäne bei sich auch berechtigen. Die Berechtigungen selbst auf Objekte werden in der Regel als SID hinterlegt. Sie sehen dies z.B. wenn Rechte auf einem Objekt vergeben wurden und die SID nicht aufgelöst werden kann:

Im Hintergrund versucht hier der Explorer mit den Rechten des angemeldeten Benutzers die SID aufzulösen. Wenn Sie nun aber Administrator einer Ressourcen Domäne sind und diese Ressourcen Domäne einseitig einer Accountdomäne vertraut, dann können Sie als Benutzer in der Ressourcendomäne erst mal nicht die Account-Domäne anschauen. Schließlich vertraut der DC in der Accountdomäne ja nicht den Anmeldedaten der Ressourcendomäne.

Wenn Sie das einmal verinnerlich haben, dann können Sie auch verstehen, warum dann ein Dialog erscheint, in der Sie Anmeldedaten für die Account-Domäne eingeben können. Das passiert auch, wenn Sie in der Ressourcen Domäne Berechtigungen erweitern wollen und jemand aus der Accountdomäne addiert werden soll.

Da diese häufige Eingabe von Anmeldedaten natürlich nervt, machen es sich viele Administratoren einfach und richten einen bidirektionalen Trust ein. "Unsicher" ist dies erst mal nicht, zumindest solange sie kein Problem damit haben, dass ein Benutzer einer vertrauten Domäne in ihrer Domäne Informationen aus dem Active Directory lesen kann und solange Sie bei sich die Berechtigungen nicht für "authentifizierte User" oder Everyone vergeben. Denn auch Konten einer vertrauten Domäne haben dann diese Rechte.

Namensauflösung

Eingerichtet ist so ein Trust relativ schnell, wenn die Vorarbeiten erfolgt sind. Zwischen den beiden Domänen sollten Sie eine funktionierende Namensauflösung etablieren. Nur dann wird der Trust stabil laufen. Zudem möchten Sie den Anwendern einer Domäne doch nicht zumuten über eine IP-Adresse auf Server in der anderen Domäne zuzugreifen. Als Minimalfunktion müssen aber bei einem "External Trust" erst mal nur die DCs miteinander kommunizieren können. Erst wenn Sie einen "Kerberos-Trust" zwischen Forests einrichten, wir der Client auch die DCs auf dem Weg zum Ziel alle erreichen müssen.

  • WINS
    Wenn Sie noch WINS einsetzen, dann ist es am einfachsten, die WINS-Datenbanken zu replizieren. Beachten Sie, dass ein "flacher" Name immer nur einmal existieren darf. Das könnte ein Problem sein. Alternativ kann man die DCs und Services der jeweils anderen Domäne manuell als statische WINS-Einträge anlegen. Das ist aber mehr Arbeit und Änderungen von IP-Adressen müssen auch mitgeteilt werden
  • DNS
    Mit dem Active Directory Forest sind die Domänen ja mit einem FQDN auflösbar und wenn Sie nicht gleich die kompletten Zonen der anderen Seite als sekundäre Zone bereit stellen wollen, dann bieten sich seit Windows 2008 selektive Forwarder an. Der eigene Windows 2008 DNS-Server fragt dann die Daten für die angegebenen Zonen nicht bei seinem "Default Forwarder" ab, sondern beim DNS-Server der vertrauten Domäne. In früheren Versionen konnte man über die Delegation den Client auf den DNS-Server in der anderen Domäne senden. Der musste per IP-Routing aber dann auch für alle Clients erreichbar sein. Es gibt also drei Optionen die DNS-Namensräume zu koppeln.

Eine korrekte Namensauflösung inklusive der _MSDCS-Teilbäume ist für die Funktion von Trusts wichtig. Sie können dazu dem DNS-Server der anderen Domäne eine sekundäre Kopie zulassen oder über "Conditional Forwarder" Abfragen auf die andere Domäne an die dortigen autoritativen DNS-Server weiterleiten. Gerade wenn viele Anfragen kommen und man durch den Trust ehr enger verbunden ist, ziehe ich eine sekundäre Zone vor, weil man so als Admin auch schnell man sehen kann, welches "Wissen" über die Zone besteht. Es ist ansonsten mühseliger, wenn in einer Zone falsche IP-Adressen auftauchen.
Ein Sonderfall ist der Aufbau einer eigenen primären Zone für die andere Domäne mit manuell statisch gepflegten DC-Adressen. Das ist "mühseliger" aber erlaubt eine sehr genaue Vorgabe, welches DCs für den Trust genutzt werden. "Stub-Zonen" oder "Pinpoint"-Zonen hingegen sind nicht optimal, da hier die MSDCS-Einträge nicht mit kommen.

Nach dem die Daten eingetragen sind, sollten Sie die Funktion genau prüfen. Sie sollten also die Domäne, die fraglichen DCs und Memberserver und die SRV-Records (_ldap._tcp) der anderen Domäne zuverlässig auflösen können.

Kommandozeilen zum Trust

Auch wenn ein Trust sehr einfach in der GUI eingerichtet werden und sogar überprüft kann, so sind Kommandozeilen für schnelle Prüfungen oder automatisierte Checks sehr hilfreich.

REM  Zeige alle Trusts mit ihrem Status an
nltest /domain_trusts /v 

REM  Prüfe die angegebene Domäne
nltest /sc_query:%trusted_domain%

REM Frage den DC der vertrauten Domäne ab.
nltest /dsgetdc:resource.local /FORCE

REM DNS-Anfrage auf die DCs der vertrauten Domäne
nslookup -debug -type=srv _ldap._tcp.dc._msdcs.%domainFQDN%

Für einen Windows Domänentrust reicht es nicht, wenn man einfach nur den Domänenname oder den DC-Namen auflösen kann. Bei Windows NT4 konnte Windows noch mit Broadcasts und WINS arbeiten aber bei Windows 2000 und höher sind DNS-Anfragen maßgeblich.

Fehlermeldungen

Gerade wenn man mal einen "dir \\server\share" in einer CMD-Boy ausführt, sind die Fehlermeldungen aussagekräftiger als die Windows Explorer Meldung.

Fehlermeldung ursache

The trust relationship between the primäry domain and the trusted domain failed.

Beim Einrichten des Trust wurden nicht übereinstimmende Kennworte eingetragen.

Access Denied

Der Trust scheint in Ordnung zu sein, aber der Benutzer hat keine Rechte im Ziel.

Logon Failure: The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine.

Selective Access aktiv und auf dem Zielsystem hat der Benutzer keine "Anmelden"-Rechte

Natürlich ist auch weiterhin das Eventlog eine immer wieder wichtige Quelle für Fehler

NETLOGON Debugging

Die Anmeldefunktionen eines Trusts werden durch den Anmeldedienst (NETLOGON) durchgeführt. Auch dieser Dienst kann angewiesen werden, ausführlicher zu protokollieren. Bei Windows 2008 und höher werden die Änderungen sofort ohne Neustart aktiv und erfordern auch keine "Debug-Version" mehr der netlogon-DLLs.

REM Aktiviere logging für NETLOGING

Nltest /dbflag:0x2280FFFF

REM DEaktivieren der Protokollierung
Nltest /dbflag:0x0

REM Anzeige des DebugLogs in Notepad
notepad %windir%\debug\netlogon.log

External Trust

Dieser Trust entspricht im wesentlichen der "alten NT4-Technik" bei der kein Kerberos beim Zugriff über die Domaingrenzen hinweg zum Einsatz kommt. Er ist aber auch mit den aktuellen Windows Server Versionen weiterhin aktuell, wenn Sie keinen transitiven Foresttrust (Kerberos) einrichten sondern nur zwei Domänen verbinden wollen.

Die Einrichtung ist bei erfolgter DNS-Konfiguration über den Assistenten sehr einfach und birgt eigentlich nur das Risiko, dass sich die beiden Administratoren bei der Eingabe der Trust-Kennwort vertippen. Interessanter ist hier das Ablaufdiagramm der Netzwerkpakete. Anhand dieser Abfolge lässt sich schnell Schritt für Schritt durchgehen und der Erfolg überprüfen:

Sie sehen hier, dass der Client links direkt per DNS das Zielsystem auflösen und dann im Beispiel per SMB erreichen will. Der Zielserver bekommt den Zugriffe mit aber bittet dann seinen eigenen DC darum, die Anmeldung zu überprüfen. Der eigene DC fungiert als Proxy und stellt die Anfrage an den DC des Benutzers. Es ist also gar nicht so wichtig, dass der Client den DC der Zieldomäne auflösen und erreichen kann, sondern dass der DC im Ziel den DC der Quelle auflösen und erreichen kann. Sie sehen aber auch, dass hier sehr viel Pakete sequentiell ablaufen und bei jedem neuen Zugriff mit Authentifizierung wieder durchlaufen wird. Die "Anmeldung" kann also etwas länger dauern.

Hinweis:
Dieses Ablaufbild behandelt nur die "Authentifizierung". Wenn Sie auf einem Ressourcenserver auf die Liste der Benutzer und Gruppen der Userdomäne zugreifen wollen, sind weitere Ports erforderlich. Dies gilt auch wenn Authentifizierungen nicht die Windows Bordmittel nutzen, sondern selbst z.B. per LDAP den User-DC abfragen.

Standorte und Dienste

Solange sich alle DC in einem Standort mit guter Netzwerkverbindung und ohne Firewalls befinden, ist die Wahl des DCs weniger wichtig. Interessanter wird es, wenn die Domänen sich über mehrere Standorte erstrecken und Sie z.B. sicherstellen wollen, dass  der "optimale" DC genutzt wird. Innerhalb eines Forests nutzen die Clients und Server die "AD Sites & Services", um einen naheliegenden DC zu erhalten. Über die Grenzen eines Forest hinaus aber pflegt jeder Forest seine eigenen Subnetze. Das gilt um so mehr, wenn z.B. in einem Ressourceforest die Exchange Server an wenigen Standorten stehen aber die Anmeldekonten entfernt sind.

Eine Lösung des Problems besteht natürlich darin, bei jeder Operation auch den Ziel-DC gleich mit anzugeben. Das geht z.B. mit der Exchange PowerShell bei der Verwaltung von Linked Mailboxes über den Parameter "LinkedDomainController". Aber damit ist immer noch nicht gesteuert, zu welchen DCs einer per Trust verbundenen Domäne andere Prozesse eine Verbindung aufbauen.

Wenn wir mal NT4-Trusts mit kurzen Namen weg lassen, dann nutzt Windows DNS um einen DC zu finden.

_ldap._tcp.<Computer Site Name>._sites.dc._msdcs.<User Domain>.com: type SRV, class IN

Interessant ist hier, dass der anfragende Client seine eigene AD-Site addiert und damit auf der anderen Seite nach einem DC sucht. In dem obigen Beispiel sind die Namen der Sites natürlich nicht übereinstimmend und so passiert, was passieren muss.

Erst die zweite "generische" Anfrage liefert dann einen der DCs. Dummerweise natürlich die Liste aller DCs ohne Rücksicht darauf, welcher "in der Nähe" ist und welcher nicht. Ein Windows Server kann zwar die Systeme anpingen aber speziell Firewalls und fehlende Leitwege kosten einfach Zeit.

Es gibt gleich mehrere Wege, wie Sie dieses Problem lösen können. Der statische Eintrag in LMHOSTS/HOSTS-Dateien gehört aber genau nicht dazu, da über diesen Weg leider nur A-Records lokal aufgelöst werden können aber eben keine SRV-Records. möglich ist aber:

  • Anpassen der Site-Namen
    Wenn der User-Forest mehrere DCs hat und vielleicht sogar eigene DCs "beim" Ressource Forest, dann bietet es sich an, diese Site entsprechend identisch zu benennen und so die Server aus dem Ressource Forest zu diesen DCs zu leiten
    Es ist nur in den seltensten Fällen ein Lösung die Site-Namen des Resource Forest auf die Namen des User-Forest zu ändern, da in so einem Model in der Regel viele User Forests existieren.
  • Stub-DNS/Pinpoint DNS (Siehe PinpointDNS / Geo-DNS)
    Der Admin des Ressource Forest kann es sich natürlich zunutze machen, dass seine Server den eigenen Site-Namen addieren. Über eine DNS-STuB-Zone "RZ._sites.dc._msdcs.User.dom" kann er selbst abweichende Einträge für _ldap._tcp pflegen. Er muss nur eben sicherstellen, dass die hinterlegten Namen auf DNS-Server verweisen, die auch gültig sind.
  • Applikation
    Letzte Option ist natürlich die explizite Angabe von Servernamen als FQDN an allen Stellen, die so einen Zugriff erfordern. viel Exchange Commandlets erlauben z.B. die Angabe eines Domain Controllers. Dies ist besonders beim Provisioning sogar hilfreich bei mehreren Schritten immer den gleichen DC zu nutzen, um Probleme durch die Replikation zu vermeiden. Aber bei vielen Diensten und Programmen ist so eine Vorgabe nicht möglich. Dann muss DNS den richtigen Weg weisen.

Ich würde bei Problemen mit dem Trust zu anderen Domänen und schwer erreichbaren DCs als Hoster den Weg über Stub-Zonen gehen, um für meine Umgebung pro Kunde die DCs vorzugeben, die meine Produkte verwenden. Natürlich bietet es sich an, diese DCs dann auch in die Überwachung einzubeziehen.

NT4-Style Trust

Schon mit Windows NT 4 und früher konnte man Domänen per "Trust" miteinander verbinden, um die Anmeldedaten der jeweils anderen Domäne zu nutzen. Damals waren aber Active Directory und DNS noch nicht bei Windows angekommen und stattdessen wurde der einfache NetBIOS-Name genutzt und als Namensauflösung kam WINS oder die LMHosts zum Einsatz.

Die durchgängige Namensauflösung mit WINS machte die Verwaltung zwar einfach, aber es war damit auch erforderlich, das sich alle DCs gegenseitig erreichen konnten, damit der Trust "zuverlässig" funktionierte. Wer aber nun mehrere Standorte hatte und der Trust nur durch bestimmte Ziel-DCs bearbeitet werden sollte, musste z.B. per LMHOSTS dafür sorgen, das die DCs der einen Domäne eben nur gewünschten DCs der anderen Domäne auflösen konnten. Der Schwerpunkt liegt auf "Auflösen" und nicht auf "Erreichen". Hat ein DC versucht einen anderen DC anzusprechen, den er auflösen auf aufgrund von IP-Routing oder Firewalls nicht erreichen konnte, dann schlug diese Anmeldeüberprüfung fehl.

Verwechseln Sie in diesem Zusammenhang nicht die Funktion des Domain Trust mit der Auflösung der Namen mittels Browserdienst in der NetzwerkUmgebung oder der Namensauflösung WINS

Auch wenn NT4 mittlerweile schon uralt und "out of Support" ist, so kommt dieser Art "Trust" auch bei Windows 2000 und Windows 2003 optional zum Einsatz.

Die Kommunikation entspricht im wesentlichen der vorhergehend bei "External Trust" beschriebenen Kommunikation, nur dass natürlich die LDAP-PING-Anfragen unterbleiben und anstelle der DNS-Anfragen eben WINS zum Einsatz kommt.

  • 889030 Trust between a Windows NT domain and an Active Directory domain cannot be established or it does not work as expected
  • 325874 How to establish trusts with a Windows NT-based domain in Windows Server 2003
  • 139410 "There are currently no logon servers available" error message
  • 175025 How to build and reset a trust relationship from a command line
  • 255551 Cannot set up trust in Window 2000 domain from Windows NT 4.0
  • 278259 Everyone group does not include anonymous security identifier
  • 308195 How to establish trusts with a Windows NT-based domain in Windows 2000
  • 102725 Lmhosts file information and predefined keywords
  • Create trust relationship between NT4 and Windows 2003 domains
    http://www.winfrastructure.net/article.aspx?BlogEntry=Create-trust-relationship-between-NT4-and-Windows-2003-domains

Transitiver Trust

Wer mehrere Domänen oder insbesondere zwei AD-Forests verbinden will, kann auch einen Trust über Kerberos machen. Der Vorteil ist dabei, dass der Client vom Zielserver wieder die Anforderung zur Anmeldung bekommt aber der Client dann sich ein Kerberos Ticket besorgt. Der Client geht also zu seinem DC, bekommt einen Verweis auf den DC des Ziels und bekommt von dort ein Ticket, welches er dann dem Server vorweist. Der Zielserver selbst muss also nicht den Authentifizierungsweg zurück laufen und hat damit weniger Last und Sockets offen. Der Client macht einmalig die Arbeit aber kann in der Folge mit den bereit erhaltenen Tickets direkt Ressourcen anfordern.

Ein Ablaufbild hierzu habe ich noch nicht erstellt.
Allerdings wändert hier der Clients von DC zu DC bis er von dem DC im Ziel ein Kerberos-Ticket für den gewünschten Server bekommen hat. Im Bezug auf DNS und Firewall ist dies anspruchsvoller, da im Extremfall alle DCs von allen möglichen Clients angesprochen werden könnten.

Selektive Authentifizierung

Früher war es so dass ein Trust quasi "allumfassend" war. Wenn Domäne A der Domäne B vertraut hat, dann war auf einen Schlag jeder Benutzer in der Domäne B berechtigt, auf Server und Ressourcen in der Domäne A zuzugreifen. Wurden dort leichtsinnigerweise dann Berechtigungen an "Jeder" oder "Authentifizierte Benutzer" gegeben, dann war dies durchaus ein Risiko. Wer kann heute schon sagen, dass alle Ressourcen auf allen Server in der eigenen Domäne "korrekt" gesichert sind ?

Daher gibt es seit Windows 2008 die selektive Authentifizierung bei der Einstellung zum Trust.

Wenn diese Option aktiv ist, dann müssen die Anwender der vertrauten Domäne noch explizit auf jedem Server gesondert berechtigt werden. Dazu muss man unter "Active Benutzer und Computer" auf das entsprechende Computerobjekt des Servers gehen, auf den die Konten einer vertrauten Domäne zugreifen sollen und dort den Benutzern oder Gruppen der vertrauten Domäne das Recht "Allowed to Authenticate" geben.

Erst dann können die Benutzer die ihnen erteilten Rechte auch ausüben. Der Hintergedanken ist wirklich, dass früher allein der Trust dafür gesorgt hat, dass die Konten aus der vertrauten Domäne schon mal "Jeder" und "Authenticated" User waren und sich, wenn Namensauflösung, IP-Routing und Firewall-Regeln dies zuließen, zu dem Server verbinden konnten. Die selektive Authentifizierung verhindert dies.

Ich habe noch nicht genau nachgeschaut, wie dies technisch dann umgesetzt ist, aber ich gehe mal davon aus, dass der Windows 2008 DC der vertrauenden Domäne (Ressource) die Anfrage vom Member-Server überprüft und nur dann zum DC der vertrauten (Account-) Domäne weiter gibt. Eine Umsetzung auf dem DC der vertrauenden (Account-)Domäne könnte der Admin der Ressourcendomäne nicht sicherstellen und eine Prüfung auf dem Member-Server ist ebenfalls nicht sinnvoll. Eine Quelle oder Detailinformationen dazu habe ich aber noch nicht gefunden.

NAT und Trusts

Bei der Verbindung von Firmen werden meist sehr früh die Netzwerke gekoppelt. Da aber viele Firmen natürlich mit "privaten IPv4-Adressen" arbeiten, sind Überlappungen nicht zu vermeiden. auf IP-Level kommt man denn schnell auf den Gedanken per NAT die Adressen umzustellen. Das ist aber nicht mit einem Consumer-NAT zu vergleichen, bei dem z.B. ein DSL-Router viele Clients hinter einer offiziellen IP-Adresse verbirgt. Hier geht es um SNAT/DNAT, denn wenn beide Netzwerk die gleichen Subnetze nutzen, müssen Sie das jeweils andere Netzwerk hinter einem virtuellen Subnetz verbergen. Das bringt einige Probleme mit sich, z.B.:

  • OneWay/TwoWay
    funktioniert mit einfachen Protokollen wie HTTPS, TELNET, POP in der Regel noch sehr gut, bei denen ein Client eine Verbindung aufbaut und hält. Bei einem Trust ist die Verbindung aber meist bidirektional, d.h. die Server sprechen miteinander und dann wird es für NAT kniffliger.
  • Namensauflösung
    Server lösen zudem per DNS ihre Gegenstelle auf. DC1 im Forest1 trägt dazu seine "reale IP-Adresse" im DNS ein und wenn DC2 in Forest über eine Shadow-Adresse mit dem DC1 sprechen muss, dann muss der Administrator von Forest2 eine eigene DNS-Zone pflegen, in dem DC1 und alle anderen AD-relevanten Einträge unter "_msdcs.<domain>" auf die virtuellen IP-Adressen umgesetzt werden. Hier muss also eine sehr enge Abstimmung erfolgen
  • RPC-Callback
    Das größte Problem ist aber die RPC-Funktion die Windows immer noch nutzt. Auch wenn DC1 aus Forest1 eine gültige IP-Adresse auflösen kann, die vom NAT-Router dann wieder auf die private Adresse auf der anderen Seite umgesetzt wird, so antwortet der DC2 im RPC-Protokoll mit seiner realen Adresse, die von DC1 nicht erreicht werden kann.
    Siehe dazu auch RPC-Firewall

Insofern ist es sehr unwahrscheinlich, dass Kopplungen von Windows Netzwerken mit dem Protokoll RPC über einfache NAT-Umsetzungen funktionieren. Interessant ist hier aber, dass Microsoft explizit einen eigenen Artikel zu NAT mit Active Directory geschrieben hat:

Normalerweise gilt die Aussage von Microsoft: „Was wir dokumentiert haben, ist auch getestet und supportet“. Alles was nicht beschrieben ist, wird nicht unterstützt und muss nicht funktionieren. Selbst wenn es heute geht, kann es mit einem Updates oder nächsten Version brechen. Es ist also keine sichere oder stabile Konfiguration. Aber es ist schon eine seltene Situation, dass Microsoft öffentlich ein „NAT ist nicht getestet“ dokumentiert.

  • Active Directory over NAT has not been tested by Microsoft.
  • We do not recommend Active Directory over NAT
  • Support for issues related to Active Directory over NAT will be limited and will reach the bounds of commercially reasonable efforts quickly.

Nun können Sie selbst überlegen, ob sie immer noch versuchen wollen, RPC und insbesondere Unternehmenskopplungen und Trusts über NAT zu routen. Ich kann davon nur abraten

Wenn ein Trust über NAT nicht funktioniert, dann muss es wohl doch eine geroutete Verbindung sein. Wenn Sie nun nicht direkt alle Netzwerke auf IPv6 umstellen wollen und so durchgängiges Routing betreiben können, gibt es wohl keinen anderen Weg, mit eigenen routingfähigen Netzwerken die Domaincontroller sowohl für die Clients als auch die Server erreichbar zu machen. So wäre es denkbar, dass die DCs direkt miteinander und von allen anderen Clients und Servern ohne NAT erreichbar sind. Wobei auch das nicht problemlos ist. Es könnte ja sein, dass auch Clients in beiden Firmen die gleichen Subnetze nutzen. Ob lassen Sich aber per DHCP vergebene Subnetze von Clients deutlich schneller umstellen oder es könnte auch reichen, wenn die Clients mit ihren DCs ohne NAT kommunizieren. Aber spätestens, wenn die ersten Führungskräfte bei einem Merger auch im Standort der anderen Firma mit den Heimatdiensten arbeiten wollen, fliegt ihnen ihre Konstruktion um die Ohren. Sie dürfen ja nie vergessen, dass auch die Server und DCs über Routen den Weg zurück zum Client finden müssen.

Dennoch "kann" es funktionieren, wenn es nur um die Anmeldedienste geht und die genutzten Dienste auf RPC verzichten. Das ist gar nicht mal so unwahrscheinlich, da auch Exchange mittlerweile RPC/HTTP oder MAPI/HTTP nutzt statt MAPI/RPC und auch viele andere Dienste nutzen HTTPS oder verzichten auf den RPC-Portmapper.

Weitere Links