nrg21

Hallo zusammen, ich habe eine Frage bzgl. Exchange Linked Mailbox bei AD-Trusts. Es existiert ein Trust zwischen zwei Domänen (Vertrauenstyp Extern, Bidirektional, nicht transitiv, Selective Authentication). Domäne A hostet den Exchange (2016), Domäne B die Userkonten. Wenn ich eine Linked Mailbox (Verknüpftes Postfach) auf dem Exchange in Domäne A anlegen möchte, werde ich aufgefordert, Admin Credentials der Domäne B anzugeben. Laut Microsoft KB dürften diese bei einem bidirektionalen Trust nicht abgefragt werden, siehe: https://docs.microsoft.com/de-de/exchange/recipients/linked-mailboxes?view=exchserver-2019#use-the-eac-to-create-a-linked-mailbox Dort steht: Versuche ich ein neues Postfach anzulegen, werde ich jedoch nach einem Administrator aus Domäne B gefragt: Was mich noch mehr verwundert ist, dass in dem Dialog auch ein ganz normales Konto aus Domäne B akzeptiert wird , auch ohne Admin-Rechte! Der Wizard läuft ganz normal durch, das Postfach wird auch erstellt. Ein Test-Login im OWA mit den Credentials aus Domäne B funktionierte auch. Hat jemand eine Erklärung dafür, wieso ein Administratorkonto aus Domäne B verlangt wird? Spricht etwas dagegen, hier einen normalen User statt Administrator zu verwenden? Mir ist gerade im kurzen Test nicht aufgefallen, dass etwas nicht funktioniert. Trotzdem würde ich diese Abfrage gerne gar nicht bekommen. Was muss hierfür noch konfiguriert werden? VG

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