nrg21

@daabm Das klingt logisch, was aber überhaupt nicht in das Bild passt ist, dass es nicht immer hängt oder langsam ist. Es ist von Fall zu Fall unterschiedlich. Manche Arbeitsplätze hängen permanent, andere nur hin und wieder, andere laufen gut. Wenn er in einen Kerberos-Timeout läuft aufgrund von Paket-Drop, müsste es doch immer identisch sein.

Vielen Dank, habe mir das gerade mal durchgelesen. Verstehe ich das also richtig, dass in der jetzigen Konfiguration Kerberos gar nicht genutzt werden kann, und somit automatisch der Fallback auf NTLM stattfindet? Also der RDS spricht NTLM mit Domain Controller aus Domain A, um den jeweiligen User aus Domain B zu authentifizieren?

Vielen Dank für die Info. Kannst Du mir auch sagen, welche Kommunikation denn zwischen Client (also in dem Fall RDS) und Trust-Domain-Controller stattfinden muss? Nur Kerberos - also tcp-udp/88 und tcp-udp/464? Was mich aber wundert: Es funktioniert ja - nur eben langsam. Wenn er die direkte Kommunikation benötigt und die DCs keine Kerberos-Proxies sind - wie funktioniert das dann momentan? Die direkte Kommunikation ist nicht gegeben.

Das verwundert mich gerade sehr, denn im Netz habe ich gelesen dass eben nicht jeder Computer aus A (in dem Fall die RDS) mit den DCs aus B sprechen müssen, sondern bei einem Trust der Weg immer über die DCs aus der eigenen Domäne (A) geht und der DC aus A die Anfrage dann an den DC aus B stellt. Ist dem nicht so?

Hallo zusammen, ich habe ein sehr seltsames Phänomen und hoffe, dass jemand bei der Lösung helfen kann. Die Umgebung sieht wie folgt aus: 2 Firmen, sagen wir Firma A und Firma B mit eigenen separaten IT-Infrastrukturen Beide haben ein eigenes Netzwerk, eigenes Active Directory, etc. Firma A hosted eine RDS Terminalserverfarm mit einer Branchensoftware. Firma B benötigt Zugriff auf diese Terminalserverfarm und der Applikation. Zwischen Firma A und Firma B existiert ein Site-to-Site-VPN. Es existiert ein Active Directory Domain Trust zwischen den 2 Firmen. Der VPN-Traffic wird mittels Firewall gefiltert, und zwar: -> Die Domain Controller von Firma A und Firma B dürfen miteinander sprechen in beide Richtungen mit folgenden Ports: tcp-udp/389, tcp-udp/464, tcp-udp/88, tcp-udp/53, tcp/135, tcp/3268, tcp/3269, tcp/445, tcp/49152-65535, tcp/636, tcp/139, udp/123. -> Die PC-Clients von Firma B dürfen auf die Terminalserver von Firma A mit tcp/3389. -> Alles andere wird mittels Firewall geblockt auf beiden Seiten. Das Problem: Von den PCs in Firma B ist ein Login auf die Terminalserver von Firma A mit den eigenen Domänenaccounts aus Firma B möglich. Die Applikation kann auch verwendet werden. So weit so gut. Das Problem ist, dass die Applikation sehr träge ist und oft hängt. Wenn ich mich von den PCs in Firma B jedoch mit einem Domänenuser aus Firma A auf den Terminalservern von Firma A anmelde, habe ich diese Probleme nicht! Es sieht also so aus, als ob das Problem nur mit den Domänenusern aus Firma B auftritt. Vielleicht ein Problem mit dem Trust? Ich habe versucht herauszufinden, was die Applikation genau macht in dem Moment, wenn sie träge ist oder hängt. Ich habe mal TcpView von Sysinternals bemüht und kann sehen, dass der lsass.exe-Prozess mehrfach nacheinander neu in der Liste erscheint (in dem Moment, wenn die Applikation hängt). Das kann ich eigentlich jedes Mal so reproduzieren und beobachten. Vielleicht ist das ein Hinweis? Aber ich komme hier nicht wirklich weiter und bin etwas ratlos, wie ich das Problem weiter analysieren kann. Hat jemand eine Idee?