RPC over HTTP - volle MAPI Funktionalität?

[lukin 10]

Hallo,

 

ich habe mich vorhin erst mal nur ein bisschen über RPC over HTTP informiert. Wenn ich Clients von einem völlig unabhängigen Standort in meine Exchange-Organisation einbinden möchte und dazu RPC over HTTP benutze, habe ich dann wirklich die volle MAPI Funktionalität? Theoretisch leuchtet mir das ein, da ja nun mal der RPC Verkehr über HTTP abgewickelt wird. Aber ich würde trotzdem gerne wissen, ob das auch wirklich so richtig funktioniert oder ob es Probleme gibt.

 

Es sollen nämlich Benutzer einer Domäne mit unserem Exchange arbeiten, die nicht in unserem Forest existiert. Die Benutzer sollen in unserer Domäne extra erstellt werden, um ihnen die Benutzung von Exchange zu ermöglichen. Dabei ist nun die Entscheidung, ob man das mit POP3, IMAP oder RPC over HTTP realisiert. Volle MAPI Funktionalität wäre natürlich das beste, vor allem weil Outlook 2003 inkl. aller weiteren Voraussetzungen für RPC over HTTP vorhanden sind. Nur, funktioniert das auch wirklich zuverlässig?

 

Kann mir dazu jemand mal was sagen?

 

Danke

[Velius 10]

Klar geht das, und zwar voll MAPI fähig. ;) Das, und dass dabei nur ein Port benötigt wird, ist ja der ganze Witz an der Sache (wenn nicht schon über VPN getunnelt wird, sonst ist's ja überflüssig...).

 

 

Am besten 'mal ausprobieren, kostet ja Nichts.

 

http://www.mcseboard.de/showthread.php?postid=294120#post294120

 

 

Gruss

Velius

[lukin 10]

Hallo,

 

wie ist das eigentlich, wenn es eine VPN zwischen beiden Standorten gibt und zwischen beiden Standorten die RPC Ports geöffnet sind. In Standort A gibt es ein Forest mit Exchange Organisation und in Standort B gibt es ein Forest ohne Exchange. Die Benutzer aus Standort B sollen das Exchange aus Standort A nutzen. Wenn ich die Benutzer in Standort A anlege und DNS zwischen beiden Standorten funktioniert und die Ports offen sind, kann ich dann nicht auf RPC over HTTP verzichten? Oder gibts dann das Problem, dass Anfragen von Outlook an das AD an das lokale Directory gehen und eben nicht zum richtigen in Standort A? Sorry, ich bin momentan noch ein bisschen verwirrt.

 

Gruß

[Velius 10]

Klar geht auch, aber das Design von RPC ist nicht gerade wirklich freundlich Firewall technisch. Beim inizialisieren von RPC's wird der Endpoint-Mapper Port 135 kontaktiert, und anschliessend wird für die eigentliche Übertragung ein Port irgendwo zwischen 1024-49*** ausgehandelt.

 

Wie du unschwer erkennen kannst, ist bei einer default Konfiguration von RPC das Konfigurieren von Firewall-Regeln gleich überflüssig.

 

 

Ausserdem, der Tunnel ist ja schon verschlüsselt, und getunnelt wird ja nur in zwei Richtungen....

 

 

Mein Rat wäre, entweder RPC over HTTPS zu verwenden, oder VPN-Tunneln ohne zusätzliche Portregeln innerhalb des Tunnels.

[zuschauer 10]

Hi !

@Velius: Soo ganz einfach geht das nicht - 2 verschiedene Forrest ! ;)

 

@lukin: Du kannst vom Standort B nur auf den ExchangeServer in Standort A zugreifen, wenn die User, die sich räumlich im Standort B befinden, sich an der Domäne im Standort A anmelden können. Dazu ist eine zumindest einseitige Vetrauensstellung der Domänen nötig.

 

Wenn die Vertrauensstellung existiert können sich User der Domäne A im Standort B als User der Domäne A authorisieren - und haben Zugriff auf ihren ExchangeServer.

[lukin 10]

Hi,

 

ok, danke für die Antwort. Eine Frage habe ich aber noch. Wenn ich im Standort B im Outlook eine Frage an das Directory stelle, woher weiß es dann, dass es das Directory in Standort A fragen soll? Ist das abhängig vom Standort des Benutzers? Denn in Standort B ist ja ein ganz anderes Forest vorhanden und da würde eine Anfrage ins Directory nichts bringen.

 

Gruß

[zuschauer 10]

Hi !

Ich hab das Gefühl, Du gehst von der falschen Seite an das Problem heran. Wenn es zwischen A und B keine Vetrauensstellung gibt, können sich User der Domain A nicht an einer WS der Domain B anmelden.

Daher kommt in diesem Fall auch nicht die Frage auf, "welches AD wird gefragt".

 

Wenn eine Vetrauensstellung besteht, kann sich ein User der Domain A an einem PC der Domain B anmelden - aber in seiner Domain A - mit allem was es da gibt, LoginScript, GPO´s und auch Zugriff auf den Exchange in A. Auf Ressourcen der Domain B hat er dann nur soviel Zugriff, wie ihm als User der Domain A erlaubt ist.

 

Von der anderen Seite gesehen: Ein User der Domain B, der sich an einem PC der Domain B anmeldet, hat bei existierender Vetrauensstellung nur soviele Zugriffsrechte auf die Domain A, wie ihm erlaubt ist. Er kann aber nicht auf ein Postfach des Exchange der domain A zugreifen (auch bei gleichen Namen/Paßwort nicht), weil er nicht zur Domain A gehört.

 

Der gemeinsame Zugriff auf einen ExchangeServer funktioniert nur, wenn beide Domänen in einem Forrest stecken - was bei Dir nicht der Fall ist !

[Velius 10]

@Zuschauer

 

Schon gesehen! ;) Dachte, ich zeige 'mal den richtigen Weg, wir wohlen ja nicht gleich alle 7 MOC Ordner durchkauen, oder? :D

[Velius 10]

P.S.: Wenn es sich um einen Exchange 2003 handelt, dann müsste er beim unauthentifizierten Verbindungsversuch die Login Daten anfordern. So wäre es theoretisch möglich, mit Outlook von einem Forest zum änderen zu verbinden.

[lukin 10]

Hallo,

 

erst mal danke für die Antworten. Entweder habe ich etwas falsch verstanden, oder es liegt noch ein kleines Missverständnis vor:

 

Ich möchte die im Standort B räumlich vorhandenen Benutzer ausschließlich für die Nutzung von Exchange in der Domäne von Standort A einrichten. Die Benutzer im Standort B sollen also mit ihrem dortigen Account weiter einloggen. Im Falle von POP3/IMAP könnte man dann im Outlook von Standort B die entsprechenden Benutzerdaten des extra in Standort A erstellten Benutzers eintragen. Das muss dann so funktionieren, unabhängig von der Windows-Anmeldung. Aber halt nur POP3 und IMAP, und das reicht ja leider nicht.

 

Ich dachte nun, mit RPC over HTTP gäbe es eine ähnliche Möglichkeit, um MAPI so von überall aus nutzen zu können. Aber ich glaube mittlerweile verstanden zu haben, dass das so nicht richtig ist. Denn wenn ich richtig verstehe, geschieht die Authentifizierung bei MAPI über die Windows-Anmeldung und es muss also in jedem Fall der entsprechende Benutzer angemeldet sein. So kann ich das jedenfalls mit der Vertrauensstellung nachvollziehen. Also, dass sich die Benutzer in Standort A auch in Standort B an der Domäne von Standort A anmelden können und somit Zugriff auf ihr Exchange haben. Und anderes geht es dann eben nicht. Oder gibt es nicht eine Möglichkeit, die Authentifizierung am Exchange von der Windows Anmeldung zu trennen? Bei Outlook WebAccess gebe ich zum Beispiel auch meine Benutzerdaten explizit an.

 

Sehe ich das jetzt richtig?

[Velius 10]

Nicht ganz richtig, denn, wenn ich mich bei unserem Exchange auf ein Konto connecte, worauf ich keine Rechte habe, dann kommt ein Fenster ähnlich dem Fenster, als wenn man versucht, als nicht lokaler Admin auf einen $Share zuzugreiffen.

 

 

Wenn ich dann natürlich das Passwort kenne, dann kann ich Outlook trotzdem benutzen.

 

 

Versuch es 'mal.

[lukin 10]

Hallo,

 

ich habe noch mal ein bisschen darüber nachgedacht. Selbst wenn das mit der Authentifizierung so funktionieren würde, gäbe es nicht trotzdem Probleme? Soweit ich weiß, nutzt Exchange u.a. zum Zustellen von Nachrichten den globalen Katalog. Der ist ja in zwei Forests nun mal unterschiedlich. Und selbst wenn ich mich dann am Exchange-Server anmelden könnte, problemfrei alles nutzen kann ich das doch sicher nicht.

 

Oder?!

 

Ich vermute mal, es wird auf eine schöne Migration des einen Standorts in den anderen hinauslaufen und in der Zeit davor werden wir erst mal WebAccess fahren. Vermutlich ist das die sauberste und einfachste Lösung. Immerhin sind es ja nur 20 zu migrierende Benutzer und Arbeitsstationen. Und aus politischer Sicht spricht auch nichts dagegen.

 

Gruß

[Velius 10]

Kann ich dir nur beipflichten. Migration hätte ich dir von Anfang an vorgeschlagen, aber man kann ja nie wissen, was für Sonderfälle dahinter stecken. ;)