Jump to content

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


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 von nrg21
Link zu diesem Kommentar

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 von daabm
Link zu diesem Kommentar

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 von nrg21
Link zu diesem Kommentar
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

 

Link zu diesem Kommentar
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?

 

Link zu diesem Kommentar
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. :-) 

Link zu diesem Kommentar

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

Link zu diesem Kommentar

@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 von nrg21
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...