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