Ich habe mehrere Büros, die über verschiedene Kombinationen von IPsec-VPNs und einem MPLS-Netzwerk miteinander verbunden sind. Die meisten Standorte bilden mithilfe der VPNs eine Mesh-Konfiguration, aber Standort B hat nur ein einziges IPsec-VPN zu Standort A – Standort B kann keinen der anderen Standorte (Standorte C und D) erreichen.
Die Standorte A, C und D nutzen alle eine Active Directory-Domäne, beispielsweise „companya.com“. Domänencontroller für companya.com befinden sich an allen drei Standorten und alle verwenden Windows Server 2012 R2.
Standort B betreibt seine eigene Active Directory-Domäne, beispielsweise „companyb.com“. Domänencontroller für companyb.com befinden sich ausschließlich an Standort B. Einer betreibt Windows Server 2019, der andere Windows Server 2012 R2.
Wir haben eine bidirektionale Vertrauensstellung zwischen den AD-Domänen companya.com und companyb.com eingerichtet. Dies wurde mithilfe einer bedingten Weiterleitung in den AD-DNS-Servern für companyb.com erreicht, die auf beide Domänencontroller an Standort A für companya.com verweist. Darüber hinaus haben wir eine Stub-Zone in companya.com eingerichtet, die auf beide Domänencontroller an Standort B für companyb.com verweist.
Wie erwartet können beide Domänencontroller an Standort A zuverlässig einen Domänencontroller an Standort B kontaktieren. Beide Domänencontroller an Standort B können jedoch nur zuverlässig Domänencontroller an Standort A kontaktieren - da wir einen bedingten Forwarder bereitgestellt haben, liefern DNS-Lookups für SRV-Einträge, die Domänencontroller an Standort B beschreiben, manchmal Ergebnisse für die Standorte C und D, auf die Standort B überhaupt nicht zugreifen kann. Dies verursacht sporadische Fehler wie:„Das System kann keinen Domänencontroller kontaktieren, um die Authentifizierungsanforderung zu bearbeiten. Bitte versuchen Sie es später erneut.“
Ich muss sicherstellen, dass, wenn Domänencontroller in companyb.com Suchvorgänge durchführen, um Domänencontroller auf companya.com zu finden, nur Domänencontroller in Site A zurückgegeben werden.
Ich habe versucht:
- Konfigurieren einer AD-Site für Site B unter Verwendung des Subnetzes, mit dem die Domänencontroller companyb.com verbunden sind. Ich glaube jedoch nicht, dass dies funktioniert, da im DNS nichts konfiguriert ist, das angibt, dass Site B nur Ergebnisse für Site A bereitgestellt werden sollen.
- Ersetzen des bedingten Forwarders auf DCs in companyb.com durch eine Stubzone. Das gleiche Problem blieb bestehen, nur schlimmer, weil die Stubzone Lookups bei DNS-Servern an den Standorten C und D verursachte, die nicht erreichbar sind.
- Manuelles Hinzufügen einer primären AD-integrierten Zone für companya.com auf den DNS-Servern von companyb.com und Hinzufügen von Datensätzen, die alle auf Domänencontroller auf Site A verweisen:
- Mehrere A-Einträge für companya.com.
- Mehrere _gc._tcp.companya.com-Einträge.
- Mehrere _ldap._tcp.companya.com-Einträge.
- Mehrere _kerberos._tcp.companya.com-Einträge.
Ich kann keine IPsec-Tunnel zwischen Standort B und den Standorten C und D aufbauen und auch den Verkehr zu den Standorten C und D nicht über den vorhandenen Tunnel von Standort B zu Standort A weiterleiten.
Ich vermute, dass die DNS-Richtlinienfunktion von Windows Server 2016 in dieser Situation Abhilfe schaffen könnte, aber ich habe keinen Zugriff auf DCs, auf denen Windows Server 2016 ausgeführt wird. Ich vermute außerdem, dass ich möglicherweise einige Datensätze übersehen habe, als ich manuell eine DNS-Zone auf den Servern von companyb.com eingerichtet habe.
Ich wäre für jede Einsicht dankbar.