Ich werd' verrückt - Vertrauensstellung schlägt fehl

[dr_wahnsinnig 10]

Hi Liebes Forum!

 

Ich bin hier mittlerweile seit ein paar Tagen am Verzweifeln!

Vielleicht sehe ich einfach den Wald vor lauter Bäumen nicht mehr:

 

Folgende Voraussetzungen sind gegeben:

 

Subnetz_A

Subnetz_B

Subnetz_C

Subnetz_D

 

Server_A_2008R2

Server_B_2008R2

Server_C_2012R2

Server_D_2008R2

 

Server_A_2008R2 hat Vertrauensstellungen in viele externe Domänen (zurzeit 27), die alle in anderen Subnetzen unterwegs sind (ein Router dazwischen).

 

Jetzt gibt es einen neuen Server_C_2012R2 (Subnetz_C), der ebenfalls eine Vertrauensstellung in die Domäne des Server_A_2008R2 (Subnetz_A) herstellen soll.

Bedingte Weiterleitung im DNS für die andere Domäne ist jeweils eingerichtet und lässt sich via NSLOOKUP auch auflösen (in beide Richtungen). Die Firewall ist auf beiden Systemen deaktiviert und der Router zwischen den beiden Systemen soll jeden Verkehr auf allen Ports zulassen (any).

 

Wenn ich jetzt versuche eine Bidirektionale Vertrauensstellung (exakt wie die anderen Zig Vertrauensstellungen auch) einzurichten, schlägt diese fehl, wenn versucht wird von dem einen Server auch gleich die Vertrauensstellung auf den anderen Server einzurichten (im Assistenten „Für diese Domäne und die angegebene Domäne“).

 

Fehler beim Vorgang: Der Remoteprozeduraufruf (RPC) wurde abgebrochen.

 

 

Wenn ich die Vertrauensstellung erst auf dem einen und dann auf dem anderen Server manuell einrichte, kann diese anschließend nicht überprüft werden und schlägt nach ca. 5 Minuten mit der Meldung fehl:

 

Beim erneuten Festlegen des sicheren Kanals auf dem Active Directory-Domänencontroller „server.testdomain.local“ der Domäne „testdomain.local“ mit Domäne „testdomain-2.local“ ist folgender Fehler aufgetreten: Der Remoteprozeduraufruf (RPC) wurde abgebrochen.

 

Ich kann allerdings so Benutzer der fremden Domäne auf einen Ordner berechtigen (dies funktioniert auf beiden Servern). Wenn ich dann anschließend die Eigenschaften -> Sicherheit dieses Ordners öffne, werden nur die SIDs angezeigt (nach eine Weile löst Windows die Benutzer der eigenen Domäne auf, der Benutzer aus der fremden Domäne bleibt allerdings als SID…)

 

Wenn die Server sich im selben Subnetz befinden, geht alles wie es soll!!

Nur, wenn die Server in unterschiedlichen Subnetzen unterwegs sind, klappt es nicht.

 

Kurios: Wenn ich eine BESTEHENDE Vertrauensstellung auf beiden Seiten lösche (Server befinden sich ebenfalls in unterschiedlichen Subnetzen), kann diese wie gewohnt eingerichtet werden - ohne Fehlermeldung

 

Ich habe jetzt auch noch einen neuen Server_B_2008R2 (in Subnetz_B) und einen neuen Server_D_2008R2 (in Subnetz_D) erstellt - AD Rolle drauf, DNS und Domäne eingerichtet, Weiterleitung eingerichtet und getestet, Firewall deaktiviert, Vertrauensstellung versucht einzurichten - das selbe Ergebnis!

Auf der Firewall sehe ich alle Pakete von Server_B_2008R2 nach Server_D_2008R2 und umgekehrt den Router verlassen (packet passed, Permitted by policy).

 

Gab es ein Windows Update, welches nun Vertrauensstellungen in Domänen anderer Subnetze nicht mehr zulässt (Registry Setting)?!

 

Ich beiß mir an dieser Sache zusammen mit einem Kollegen echt die Zähne aus…

 

Bin für jeden Hinweis dankbar!

 

Gruß

Andy

[Squire 265]

Kannst Du Systeme in Domäne A von Domäne C aus pingen? Zum einen über IP und dann über den Namen? Ich denke mal, dass irgendwas im Routing im Argen liegt

[dr_wahnsinnig 10]

Ping, NSLOOKUP, SMB alles funktioniert.

Ich sehe auf dem Router zwischen den beiden Netzen ja auch, dass die Pakete korrekt geroutet werden.

Ich habe jetzt Server_C in das Netz gebracht, von dem ich - wie oben beschrieben - die Vertrauensstellung jederzeit löschen und neu aufbauen konnte, um das Routing auszuschließen.

 

Server_A befindet sich im Netz 192.168.1.0/24

Server_C befindet sich im Netz 192.168.2.0/24

Es funktioniert einfach nicht.

 

Der Server, der ohne Weiteres den Trust löschen und neu aufbauen und anschließend auch überprüfen kann (auch ein Server 2008R2) befindet sich ebenfalls in dem Netz 192.168.2.0/24

Zwischen den Netzen gibt es den einen Router, der über EINE Regel für jede Richtung Netzwerkverkehr zulässt - wie oben beschrieben Port "Any" -

 

Das ist doch nicht normal! Was übersehe ich denn hier?!?

[Jim di Griz 13]

Hallo,

hast du dazu eine oder mehrere Eventids und am besten noch den Errorcode? (0x800xxxx)

Mir kommt die RPC-Abbruch Meldung komisch vor. Wäre das Netz die Ursache wäre die Meldung eher der remote-Host ist nicht erreichbar.

Mit der Meldung denk ich eher an einen Fehler auf den DCs. Ist das erste 2012 DC in dem Gewebe?

Ich habe so etwas noch nicht selber gesehen oder konfiguriert in diesem Umfang, obendrauf noch bedingte Weiterleitung? Vielleicht findet der neue DC nicht alle notwendigen Resourcen im DNS?

und während ich drüber nachdenke, die Zuordnungen der secondary ports bei RPC in so einem Konsrukt kann sicher recht tricky sein, vor allem wenn noch mehr RPC-Kram in dem Netz läuft.

RPC ueber Port 135 funktioniert noch, aber der 2012 nimmt dann als secondary Port einen anderen Port als ein 2008er Server (als kurze Umschreibung wo es vielleicht hängt)

gugg doch mal im netzwerkmonitor was da genau abbricht.

Ausserdem : ist Standorte und Dienste korrekt konfiguriert? Wie hast du den 2012 in die Domäne gebracht?

bearbeitet 15. Oktober 2017 von Jim di Griz

[dr_wahnsinnig 10]

Sobald ich versuche die Vertrauensstellung zu erstellen, klettert die CPU Last auf 50% und die MMC reagiert nicht mehr (siehe Screenshot)

 

bearbeitet 16. Oktober 2017 von dr_wahnsinnig

[MurdocX 953]

sfc.exe /scannow

Würde ich mal probieren. Schaden tut es nicht.

[4zap 17]

80% dieser Art von Problemen sind DNS basiert. Die DC's müssen sich sehen können und DNS muss beidseitig in beiden Netzen funktionieren. Trust wird verweigert wenn die Hostnamen bzw. die netbios namen der DC's gleich sind. (was häufig vorkommt). Normalerweise kommt beim Herstellen des Trust die Login Afbrage für den anderen Domänenadmin. Wenn der schon nicht erscheint und der RPC Fehler ausgegeben wird ist es meistens ein DNS oder Firewall Problem. DNS läuft bei unseren Trusts über bedingte Weiterleitung im DNS...

bearbeitet 16. Oktober 2017 von 4zap

[daabm 1.366]

Schließe mich 4zap an, favorisiere aber ganz klar "Firewall"... Warum? Leidvolle jahrelange Erfahrung :)

[Doso 77]

Schließe mich 4zap an, favorisiere aber ganz klar "Firewall"... Warum? Leidvolle jahrelange Erfahrung :)

 

Würde ich auch sagen.

[dr_wahnsinnig 10]

So, sorry für die späte Antwort.

Die Lösung des Problems:

Ja, es war die Firewall ;-)

 

Die Juniper Firewall kommt hier mit ALGs (Application Layer Gateways) um die Ecke, die per default aktiv sind.

Es handelte sich hierbei um das ALG MSRPC.

Hat nun ja auch jahrelang funktioniert. Ob jetzt MS was geändert hat, oder die Juniper auf einmal meint einige Pakete wegzuschmeißen, weil die nun nicht mehr passen... keine Ahnung.

Wir haben nun das ALG deaktiviert (set security alg msrpc disable) - und schlagartig funzt das wieder.

Danke für die Unterstützung!