Applikation hängt mit Domain Usern von anderer Domäne (Trust)

[nrg21 0]

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?

bearbeitet 18. Juli 2020 von nrg21

[daabm 1.366]

Kerberos über Firewalls ist etwas "zickig", wenn da restriktiv geblockt wird. In Deinem Fall müssen wohl die RDS-Server von A die DCs aus B erreichen, weil der User ja aus B kommt. Grundsätzlich muß jeder Computer mit interaktivem Logon alle DCs erreichen, die
a) zu seiner eigenen Domain gehören
b) zu jeder Domain gehören, aus der ein trusted User kommen könnte

bearbeitet 18. Juli 2020 von daabm

[nrg21 0]

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?

[daabm 1.366]

Nein, ist nicht so und war auch nie so. DCs sind keine "Kerberos-Proxies", sondern sagen Dir nur, wo Du hingehen sollst ("Referral").

Immer lesenswert dazu: http://technet.microsoft.com/en-us/library/bb742433.aspx

Würde mich interessieren, wo im Netz Du das gefunden hast

[nrg21 0]

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.

bearbeitet 20. Juli 2020 von nrg21

[MurdocX 953]

vor 6 Stunden schrieb nrg21:

und die DCs keine Kerberos-Proxies sind

Mit Ausnahme eines RODCs, der hier aber nicht Thema ist.

 

vor 6 Stunden schrieb nrg21:

wie funktioniert das dann momentan?

Wenn du wissen möchtest wie Kerberos funktioniert, dann kann Dir die Dokumentation von MS empfehlen.

 

microsoft.com | Kerberos Authentication Overview

https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview

 

[nrg21 0]

vor 6 Stunden schrieb MurdocX:

Mit Ausnahme eines RODCs, der hier aber nicht Thema ist.

 

Wenn du wissen möchtest wie Kerberos funktioniert, dann kann Dir die Dokumentation von MS empfehlen.

 

microsoft.com | Kerberos Authentication Overview

https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-authentication-overview

 

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?

 

[MurdocX 953]

vor 5 Minuten schrieb nrg21:

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?

Bevor ich jetzt Schmarrn schreibe, lass ich´s lieber   Ehrlich gesagt, müsste ich mich auch nochmal genauer einlesen. Die Kommunikationswege bei einem Bidirektionalem-Trust kennt hier vielleicht der Ein oder Andere. Vielleicht schreibt @daabm noch bisschen was dazu.  

[daabm 1.366]

@MurdocX Bidi oder nicht ist egal, da geht's nur drum, wo User und Service (=Zielserver) zuhause sind (und nein, es gibt keine Ausnahmen - es geht bei den Trust Directions ausschließlich darum, wer wofür ein TGS haben will). Und wenn die Netzwerk-Firewalls (wie fast alle) die Pakete einfach droppen, dauert es natürlich einige Zeit bis zum Timeout und NTLM-Fallback. Das Paket wird ja verschickt, aber es kommt halt KEINE Antwort ala "no route" oder "destination unreachable", sondern einfach "nichts".

Soweit ich weiß - aber ohne Garantie - müßte 88 reichen. 464 ist Passwort Änderung, das wird da eher selten vorkommen. Und 389/3268 sollte nicht benötigt werden. Aber das unterschreibe ich niemals

[nrg21 0]

@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. 

bearbeitet 22. Juli 2020 von nrg21

[daabm 1.366]

Ich bin kein Netzer - aber ich habe bittere Erfahrungen mit erratischem Verhalten der Netzwerk-Infrastruktur inkl. VPN, Routing und Firewalls. "Immer identisch" wäre wünschenswert, entspricht aber nicht dieser Erfahrung...