Jump to content

RPC over HTTP - volle MAPI Funktionalität?


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

Empfohlene Beiträge

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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ß

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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ß

Link zu diesem Kommentar

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 !

Link zu diesem Kommentar

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?

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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ß

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