Jump to content
nrg21

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

Recommended Posts

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?

Edited by nrg21

Share this post


Link to post

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

Edited by daabm

Share this post


Link to post

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?

Share this post


Link to post

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.

Edited by nrg21

Share this post


Link to post
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

 

Share this post


Link to post
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?

 

Share this post


Link to post
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. :-) 

Share this post


Link to post

@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 :-)

Share this post


Link to post

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

Edited by nrg21

Share this post


Link to post

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

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


Werbepartner:



×
×
  • Create New...