Exchange 2016: Wird RPCoverHTTP noch benötigt?

RPCoverHTTP, besser bekannt als Outlook Anywhere wurde mit Exchange Server 2003 eingeführt. RPCoverHTTP wird genutzt, um Outlook ohne VPN an Exchange Server anzubinden, allerdings war es nicht immer problemlos umzusetzen oder zu implementieren.

Im Wesentlichen werden bei RPCoverHTTP die Remote Procedure Calls über das http Protokoll getunnelt um RPC über das Internet zu transportieren. Die unterschiedlichen Protokolle (RPC und http), sorgten dabei für ein paar Probleme. http ist ein Halb-Duplex Protokoll, wohingegen RPC ein Voll-Duplex Protokoll ist, welches synchrone eingehende und ausgehende Verbindung voraussetzt. Outlook nutzt daher zwei http Verbindungen, eine für eingehende Daten (RPC_IN_DATA) und eine für ausgehende Daten (RPC_OUT_DATA). Diese beiden http-Verbindungen eines Clients mussten Firewalls und Loadbalancer immer zum gleichen Zielserver leiten (Session Affinity), da sonst keine Verbindung zu Stande kam. Manche Firewalls und Loadbalancer bekommen das heute leider noch nicht ordentlich auf die Reihe.

Das nächste Problem betrifft die modernen Firewalls, die das zugrundeliegende Protokoll genauer analysieren um Angriffe abzuwehren. Diese Firewalls fanden im http Protokoll plötzlich nicht nur die http Kommandos (get, head ,put, post), sondern eben Remote Procedure Calls und kappten die Verbindung wegen Protokollanomalien oder filterten die Verbindung entsprechend. Das Resultat war meistens keine Verbindung mit Exchange via Outlook Anywhere.

Mit Exchange dem Service Pack 1 für Exchange 2013 wurde das MAPIoverHTTP Protokoll eingeführt. MAPIoverHTTP kommt im Gegensatz zu RPCoverHTTP ohne Remote Procedure Calls aus, welches die oben genannten Nachteile eliminiert. Da auch alle aktuellen Outlook Versionen MAPIoverHTTP unterstützten, könnte man darüber nachdenken das klassische Outlook Anywhere (RPCoverHTTP) abzuschalten und nur noch das moderne Outlook Anywhere (MAPIoverHTTP) zu benutzen. Die Firewall Regeln könnten wieder enger gezogen werden und auch die Loadbalancer müssen keine Session Affinity mehr beachten.

Hier eine Übersicht der Clients die MAPIoverHTTP unterstützen:

RPCoverHTTP MAPIoverHTTP

Quelle: Microsoft Technet

Im Bild aus dem Technet Artikel ist allerdings ein kleiner Fehler: Outlook 2007 wird von Exchange 2016 überhaupt nicht unterstützt, egal mit welchem Protokoll. Die Mac Versionen bleiben hier außen vor, denn Outlook für Apples Betriebssystem nutzt die EWS Schnittstelle und ist nicht von RPCoverHTTP oder MAPIoverHTTP abhängig.

Leider kann man RPCoverHTTP nicht getrennt von MAPIoverHTTP ein- oder ausschalten. MAPIoverHTTP lässt sich beispielsweise bei Exchange 2013 und Exchange 2016 ein- und abschalten. RPCoverHTTP ist immer aktiv und lässt sich nicht ohne weiteres abschalten. Vielleicht wird diese Funktion ja noch mit einem CU nachgereicht.

Wer aber nur noch Outlook Versionen einsetzt die MAPIoverHTTP verstehen, könnte aber das Regelwerk an seiner Firewall wieder deutlich enger ziehen. An einer Sophos UTM Web Protection sind beispielsweise viel weniger Ausnahmen nötig. Ich konnte das Regelwerk soweit zusammen stampfen, dass nur noch eine Ausnahme für “Statisches URL Hardening” übrig bleibt:

UTM

Bei einer neuen Exchange Organisation, könnte man ebenfalls drüber nachdenken, ob RPCoverHTTP noch benötigt wird. Ein kompletter Artikel für die Konfiguration der UTM ohne RPCoverHTTP folgt noch.

Wie seht ihr das Thema? Lieber MAPIoverHTTP? Lieber RPCoverHTTP? Oder beides?

7 Replies to “Exchange 2016: Wird RPCoverHTTP noch benötigt?”

  1. Guter Artikel! Danke!
    Leider bleibt noch das Problem das Outlook 2013/2016 im MAPIoverHTTP-Modus und im Domänennetzwerk den User des öfteren mal nach den Zugangsdaten fragt. Das ist mir bei Verwendung von RCPoverHTTP bisher noch nie passiert und hält mich bisher von einer MAPIoverHTTP Nutzung ab, leider…
    Gruss

  2. Hi Frank,

    was hast du denn bei dir für AuthenticationMethods für das MapiVirtualDirectory konfiguriert, damit die Authentifizierung durch die UTM WAF geht? Wir haben bei uns nur Negotiate konfiguriert (als Internal und External AuthenticationMethods). Über die WAF akzeptiert Outlook aber das Passwort nicht und im Log der UTM wird ein HTTP 401 (Unauthorized) geloggt. Bei direktem Zugriff ohne WAF funktioniert MAPIoverHTTP einwandfrei. WAF Ausnahmen helfen leider auch nicht weiter.

    Danke und viele Grüße,
    Markus

  3. Hi Markus,

    meine Auth. Methoden:

    IISAuthenticationMethods : {Ntlm, Negotiate}
    InternalAuthenticationMethods : {Ntlm, Negotiate}
    ExternalAuthenticationMethods : {Ntlm, Negotiate}

    In meiner Umgebung funktioniert der Zugriff ohne Probleme (WAF ohne ReverseAuth).

    Gruß, Frank

  4. Hi Frank,

    danke für die Rückmeldung :-)
    Habe herausgefunden, dass es mit einem einzigen Exchange Server unter „real webservers“ funktioniert (auch mit Negotiate). Sobald ich einen zweiten dazuschalte klappt die Auth wieder nicht. Genau das selbe Problem hab ich auch bei OWA. Da kann man das Kennwort 1000x eingeben aber immer HTTP 401. Wohl ein Bug in der UTM.

    Gruß,
    Markus

  5. Hi Markus,

    mehrere Exchange Server als Real Server hinter der WAF funktioniert leider nicht. Soweit ich weiß, ist das schon mehrfach an Sophos als Bug gemeldet worden, aber leider immer noch nicht behoben.

    Gruß,

    Frank

  6. Derzeit funktioniert es nur mit der Option „Enable hot-standby mode“ unter der jeweiligen Site Path Route:
    Enable hot-standby mode: Select this option if you want to send all requests to the first selected real webserver, and use the other webservers only as a backup. The backup servers are only used in case the main server fails. As soon as the main server is back working, the sessions will switch back—unless you selected the Enable sticky session cookie option.

    Dass es auch im Loadbalancing sauber funktioniert behandelt Sophos als Feature Request und es nicht absehbar, wann daran weiter gearbeitet wird :-(

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.