RPC over HTTP

RPC over HTTP auf IWndows 2008 benötigt etwas Hilfe, da die Exchange Dienste nicht auf IPv6-Adressen lauscht, aber RCP/HTTP über Localhost die IPv6-Adresse nutzt
http://blog.aaronmarks.com/?p=65

Lösung: IPv6 in der Registrierung abschalten
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\ParametersDisabledComponents:DWord32 = 0xFF

Outlook kann am besten mit einer RPC-Anbindung an den Exchange Server genutzt wird. Allerdings ist das nicht ganz ungefährlich, da dazu der Portmapper Dienst au 135/TCP erreichbar und ohne besondere Vorkehrungen auch alle "High-Ports" erreichbar sein müssen. Niemand wird daher ohne besondere Gründe den Exchange Server ungesichert ins Internet stellen, sondern immer eine Firewall mit Authentifizierung davor stellen.

Leider gibt es mit Windows 32bit das 2/3/4 GB Limit und das gilt auch für den IIS, in dessen Kernelspeicher der RPC-Proxy geladen wird. Microsoft empfiehlt pro Front End Server ca maximal 2.000 simultane Anwender. Siehe auch http://technet.microsoft.com/en-us/library/bb124771(EXCHG.65).aspx

Beim Einsatz von Outlook 2007 und Exchange 2007 gehen (leider) nicht mehr alle Zugriff durch den RPC/HTTP-Tunnel. Zugriff auf das offline Adressbuch (OAB), Frei/Beleg-Zeiten etc. nutzen direkt die Exchange Webservice und Autodiscover

Outlook nutzt per Default IMMER die Port 80 oder 443. Andere Ports können über den Assistent leider nicht angegeben werden. Übereinen Trick und RegEdit geht es aber doch. Siehe http://www.d-fens.net/?go=kb&id=200023.

Direktes RPC

Daher muss diese Zugang besonders gesichert werden. Die Möglichkeiten sind vielfältig:

Auf jeden Fall kann nur davon abgeraten werden, einen Exchange Server per RPC ungesichert im Internet erreichbar zu machen.

RPC over HTTP

Outlook 2003 und höher erlaubt es, allein über HTTP/HTTPS eine gesicherte Verbindung zwischen Client und Server aufzubauen und sowohl aktiv zu arbeiten als auch zu replizieren. Dies kann eine sinnvolle Alternative zu einem VPN sein. Allerdings sind die Voraussetzungen zum Einsatz zu beachten:

Ehe Sie nun RCP over HTTP einsetzen können, muss Windows 2003 Server auf folgenden Systemen installiert sein:

Zusätzlich gilt:

Empfehlung

Insofern bedeutet die Einführung des ersten Outlook 2003 Benutzers mit RPC over HTTP eventuell eine weit reichende Aktualisierung ihrer Umgebung.

RPC over HTTP Prinzip

Die prinzipielle Funktionsweise ist auf dem folgenden Bild skizziert:

Outlook spricht per HTTPS mit dem IIS, auf dem es ein virtuelles Verzeichnis /RPC gibt. Auf diesem Server ist der RPC-Proxy installiert, was im wesentlichen eine DLL in einem virtuellen Verzeichnis des IIS ist.

Die komplette Outlook Kommunikation erfolgt dabei über HTTP, d.h. auch der Zugriff auf die GAL auf einem DC etc.

Achtung: Outlook 2007 erkennt, wenn es sich um einen Exchange 2007 Server handelt und nutzt dann für OOF, OAB und andere Zugriffe die Exchange Web Services (EWS) und benötigt dazu ebenfalls "Autodiscover"

RPC over HTTP auf dem Server installieren und konfigurieren

Auf der Gegenseite müssen Sie natürlich ihren Server noch "RPC over HTTP tauglich" machen. Dazu müssen Sie wissen, dass die Funktion "RPC-Proxy" selbst erst mal keine Funktion von Exchange ist, sondern eine Funktion des Windows 2003 Servers und demnach über die Systemsteuerung - Software - Windows Komponenten installiert wird:

Dieser Dienst ist auf dem Server zu installieren, welcher die Anfragen der Clients aus dem Internet annimmt.

Danach sollten Sie in ihrem Dienstmanager für den Webserver ein neues virtuelles Verzeichnis finden:

Das Verzeichnis "/RPC" enthält einfach nur eine DLL, die bei einer Verbindung auf diese URL aufgerufen wird und die RPC-Anfragen auspackt weitergibt.

Wenn Sie den RPC-Proxy nicht auf Exchange laufen lassen und eine Verbindung aus dem Internet über weitere HTTP-Proxy Server nutzen (Siehe folgendes Kapitel), dann ist es unwahrscheinlich, dass die Standardanmeldung mit NTLM funktioniert. Sie müssen dann das virtuelle Verzeichnis /RPC für die Standardanmeldung freigeben.

Der Einsatz von dann natürlich angeraten, damit Kennworte nicht ungeschützt übertragen werden. Die NTLM-Anmeldung sollte auch aktiv sein, wenn Sie dies intern verwenden wollen.

RPC over HTTP auf dem Exchange Server 2003 konfigurieren

Achtung:
Exchange 2007 Einstellungen im folgenden Kapitel.

Seit Exchange 2003 SP1 findet sich im Exchange System Manager bei den Eigenschaften des Servers eine eine Karteikarte zur einfachen Konfiguration:

Allerdings vereinfacht diese Karteikarte nur die Konfiguration bei einer Frontend/Backend Konstellation. Bei einem einzelnen Server ist weitere Konfigurationen erforderlich. Die Einstellung "Back-End-Server" sorgt unter anderem dafür, dass auf dem Server folgende Schlüssel gesetzt werden:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem]
"Rpc/HTTP Port"=dword:00001771

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters]
"HTTP Port"=dword:00001772
"Rpc/HTTP NSPI Port"=dword:00001774

Prüfen Sie diese Einträge, denn ich habe es schon erlebt, dass diese Werte NICHT gesetzt wurden oder irrtümlich lokalisiert warten (also RPC/HTTP-Anschluss" und "HTTP-Anschluss".

Diese Einträge müssen auf jedem Backend Server durchgeführt werden und werden erst nach dem Neustart der Exchange Dienste aktiv. Die Funktion sollten Sie dann mit dem Befehl NETSTAT prüfen:

netstat -a -o | find "600"
TCP nawsv001:6001 srv01.msxfaq.test:0 ABHÖREN 3996
TCP nawsv001:6002 srv01.msxfaq.test:0 ABHÖREN 3152
TCP nawsv001:6004 srv01.msxfaq.test:0 ABHÖREN 476

Dieser Server "lauscht" also auf den Port 6001,6002 und 6004.

Auf dem RPC-Proxy-Server muss nun der Zugriff auf eben diese Server ebenfalls eingetragen werden. So muss der bei einer Single Server Installation der Eintrag "ValidPorts" gepflegt werden:

HKLM\Software\Microsoft\Rpc\RPCproxy\ValidPorts:String = srv01:6001-6002;srv01.msxfaq.test:6001-6002;srv01:6004;srv01.msxfaq.test:6004

Hier muss sowohl der "kurze" NETBIOS-Name als auch der lange FQDN eingetragen werden. Nach der Installation und dem Start sollten Sie im Eventlog kontrollieren, ob der RPC-Proxy korrekt gestartet ist.

Weiterhin müssen Sie natürlich ihrem Domaincontroller eventuell den Port für RPC/HTTP eintragen, wenn diese zugleich Exchange Backend Server ist.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\NSPI interface protocol sequences: Multi_SZ = ncacn_http:6004

Diese Änderung wird erst nach einem Neustart des Servers erforderlich. Auch Microsoft liefert einige sehr viel aussagekräftigere Informationen z.B. auf:

Wenn man all die Parameter und Ports mal zusammen stellt, dann ergibt sich folgendes Bild:

RPC over HTTP Ports

In Exchange 2007 agiert der MSExchangeSA auf Port 6004 als NSPI-Proxy zum DC. Daher ist es für Exchange nicht mehr erforderlich, dass der RPCProxy auch auf den DC zugreifen muss.

Die RPCPRoxy.DLL nutzt drei Ports die zum Teil vom Exchange Server Informationsspeicher, von der Systemaufsicht aber auch vom Domaincontroller bereit gestellt werden. In den Beispielen ist der DC und Exchange Server der gleiche Server namens SRV01. Wenn Sie die Funktion auf mehrere Server verteilen, dann müssen Sie natürlich die Namen entsprechend anpassen.

RPC over HTTP und Exchange 2007

Exchange 2007 wird "ähnlich" konfiguriert. Hier sind die Einstellungen beim Server der CAS-Server-Rolle durchzuführen. Hier müssen Sie einfach "Outlook Anywhere" aktivieren.

Mehr gibt es hier eigentlich nicht zu konfigurieren. Für den Zugriff aus dem Internet sollte man auf dem IIS natürlich ein SSL-Zertifikat einrichten. Das ist dann wieder eine Einstellung in der MMC für den IIS.

Der Assistent erfragt dann zusätzlich den externen Namen, die Authentifizierungseinstellungen und die SSL-Absicherung.

Neu ist, dass die RPCProxy-DLL bzw. Exchange nun auch im Eventlog Warnungen und Fehler protokolliert, so dass ein Blick ins Eventlog durchaus lohnenswert bei der Fehlersuche ist. Holen Sie das dann einfach nach. Nach der Installation der RPC/HTTP Proxy-Komponente und Änderungen an der Exchange Konfiguration sehen Sie ebenfalls entsprechende Meldungen im Eventlog.

Sie müssen aber dennoch den "RPC over HTTP Proxy" installieren. (Auch bei Windows 64 Bit). Hier ist die Fehlermeldung, wenn Sie "Outlook Anywhere" aktivieren aber auf dem darunter liegenden Windows vergessen haben, den RPC/HP Proxy zu installieren.

 RPC2007 Fehler RPC2007 Konfiguration

RPC und DC

RPC over HTTP spricht aber nicht nur mit Exchange, sondern muss natürlich auch den Domain Controller erreichen.

In Exchange 2007 agiert der MSExchangeSA auf Port 6004 als NSPI-Proxy zum DC. Daher ist es für Exchange nicht mehr erforderlich, dass der RPCProxy auch auf den DC zugreifen muss.

Ansonsten verbindet sich der RPCProxy mit dem Port 593 auf dem Windows Domain Controller. Auch dies kann mit einem TELNET geprüft werden.

telnet servername 593

Der Globale Katalog Domaincontroller muss sich, wie im Bild sichtbar, melden.

RPC auf dem Client einstellen

Nachdem die Einrichtung auf dem Server erfolgt ist, können Sie auf den Client die Funktion RPC over HTTP nutzen. Dazu müssen folgende Voraussetzungen auf dem Client erfüllt sein:

Erst dann können Sie in Outlook die entsprechenden Einstellungen vornehmen.

Es ist problemlos möglich, auch die Erstinstallation mit RPC/HTTP zu konfigurieren, auch wenn dies immer wieder bezweifelt wird. Aber Sie müssen auf dem Client natürlich erst einmal ein paar Fehlermeldungen wegklicken, da der Outlook bei Eingabe des Servernamens und Usernamens direkt eine Verbindung versucht, die natürlich nicht geht. Die muss man übergehen und dann in den erweiterten Einstellungen erst den RCP-Proxy eintragen, damit es dann geht.

Beim Einsatz von HTTPS muss natürlich sichergestellt sein, dass die Zertifikatskette steht. Speziell bei privaten Zertifizierungsstellen muss auf dem Client dann auch diese StammCA als vertrauenswürdig installiert sein. Outlook bietet keinen Warndialog an, wenn die Zertifikate nicht stimmen

In Outlook werden zwei Servernamen gepflegt:

Wenn Sie in der Taskleiste bei gedrückter "STRG-Taste" mit der rechten Maus auf das Outlook Icon klicken, können Sie sich den Verbindungsstatus anzeigen lassen und hier erkennen, dass Outlook tatsächlicher über HTTPS kommuniziert.

RPCHTTP

 Auch auf dem Server können Sie im IISLog erkennen, dass nun sehr viele Anfragen mit der URL "/RPC" protokolliert werden.

RPC und Kennwort

Wer nun über Outlook und RPC/HTTP sich am Exchange Server anmeldet, wird vielleicht feststellen, dass er bei jedem Start immer wieder nach dem Kennwort gefragt wird. Outlook merkt sich das Kennwort nicht und eine Checkbox, um dies zu erlauben, ist auch nicht vorhanden.

Es gibt aber einen Trick, da man auf dem PC ja mit einem Benutzer angemeldet ist. man muss den RPC/HTTP-Endpunkt im Exchange Netz nur dazu bringen, dass man nicht nicht nur per der "Klartextauthentifizierung" anmelden kann, sondern auch per NTLM. Die Einstellung ist auf der virtuellen Webseite im Verzeichnis RPC durchzuführen.

Als zweites muss man auf dem Client natürlich noch einstellen, dass überhaupt NTLM auch erlaubt wird. Da geht über folgenden Registrierungsschlüssel:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"Lmcompatibilitylevel"=dword:00000002

Alternativ können sie auch "3" nutzen.

Das ganze funktioniert natürlich nur soweit, wie Proxy Server etc. die Anmeldung per NTLM passieren lassen. Da durch diese Einstellung das Kennwort "schwächer verschlüsselt" übertragen wird, sollten sie natürlich wie bei der Klartextanmeldung unbedingt SSL nutzen.

Die Einstellung ist leider nicht allein auf Outlook bezogen, sondern auf den kompletten PC und schwächt damit auch die interne Kommunikation, da Angreifer sich als "alter NT4 Client" ausgeben könnten und der PC dann das NTLM-Kennwort mit einer schwächeren Verschlüsselung absendet. Es gibt entsprechende Programme, die solche Pakete gezielt suchen und knacken (Stichwort Cain&Abel und andere)

Achtung: Mit Windows 2008 als DC "soll" dieser Trick mit einer schwächeren Authentifizierung gar nicht mehr gehen.

RPC und Absicherung

Natürlich haben Sie erst mal ein schlechtes Gefühl, einen IIS direkt am Internet zu betreiben, nur damit Clients auf das virtuelle Verzeichnis "/RPC" zugreifen können. Aber hier können Sie dann mit einer Firewall die Sicherheit erhöhen, welche die HTTPS-Verbindung annimmt und nach innen weiter gibt.

So kann z.B. der ISA-Server über eine Webveröffentlichung gezielt Verbindungen zu dieser URL passieren lassen, während alle anderen Zugriffsversuche (z.B. nach /MSADC, /Scripts, /CGI-BIN etc.) von außen blockiert werden.

RPC und Checkpoint

Eine "Besonderheit" ergibt sich, wenn Sie zwischen den Exchange 2007 CAS-Servern und den Exchange 2007 Mailbox Servern eine Checkpoint Firewall steht, dann richten viele Admin einfach eine Regel  ein, dass der CAS-Server alle Ports des Mailbox Servers erreichen kann. Vergessen wird dabei oft die Funktion, dass eine Checkpoint bei einem "ANY" trotzdem nicht alle Ports freigibt, sondern einige vordefinierte Ports weiterhin geblockt werden. So definiert Checkpoint die Port 6000-6069 als "Unix X11 Server" und verhindert den Zugriff. Ich Checkpoint Administrator sollte aber wissen, wie er dies korrekt einstellt.

RPC und ausgehende Proxies

Sie können in Outlook keine HTTP-Proxies einstellen. Outlook nutzt einfach die gleichen Einstellungen, die Sie auch im Internet Explorer konfiguriert haben. Um Outlook daher über einen Proxy arbeiten zu lassen, müssen Sie die Proxyeinstellungen des Internet Explorers konfigurieren.

So schön das alles ist mit dem HTTP, aber es gibt immer noch weitere Aspekte, die betrachtet werden müssen. So können sich ja mehrere Proxies in der Verbindung befinden. So kann es sein, dass:

und vieles mehr. mit folgenden Ketten habe ich bislang Erfahrung gemacht:

">Offizielle IP
Client zum Internet Internet zum Exchange Server Server Ergebnis

Outlook		 Direkt

ISA-ReverseProxy->RPCProxy
Exchange 2003
Private IP) -> Router/NAT ISA-ReverseProxy->RPCProxy
SQUID-Proxy ohne Auth ISA-ReverseProxy->RPCProxy
ISA-Proxy ohne Auth ISA-ReverseProxy->RPCProxy
SQUID-Proxy-mit-auth ISA-ReverseProxy->RPCProxy
Jana-Server mit AUTH an SQUID-Proxy(Auth) ISA-ReverseProxy->RPCProxy

Die Verbindung über einen HTTP-Proxy mit expliziter nicht integrierter Anmeldung funktioniert nicht, da Outlook mit RPC over HTTP keine Möglichkeit bietet, zusätzlich zur Anmeldung an Exchange selbst auch noch eine Anmeldung an einem Proxy-Server zu machen. Der Zugriff über einen Proxy funktioniert also nur dann, wenn der Proxy die "integrierte Anmeldung" (ISA-Server, Microsoft Proxy 2.0) unterstützt oder auf eine Anmeldung verzichtet.

Um dieses Manko zu umgehen gibt es weitere Möglichkeiten:

Schade dass es nicht auch von Microsoft ein VPN über HTTP gibt. Kritisch kann sein, dass RPC over HTTP auf einen Timeout läuft. Dann kann mit Regedit ein entsprechender Eintrag vorgenommen werden.

Einfacher ist es, einfach folgende Datei in Notepad als REG-Datei zu speichern und zu importieren:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\RPC]
"ConnectTimeout"=dword:000493e0
"ConnectTimeoutLow"=dword:000493e0
"RFRTimeout"=dword:000493e0

RPC über fremden Proxy mit Proxomitron

Im vorherigen Abschnitt habe ich erläutert, dass Outlook RPC over HTTP nur nutzen kann, wenn der Proxy entweder keine oder eine integrierte Authentifizierung nutzt und damit ihr PC keine weitere Authentifizierung erfordert. Verlangt der Proxy jedoch beim Zugriff auf das Internet zusätzliche Benutzerdaten, dann ist eine Nutzung mit Outlook ohne Hilfsmittel ausgeschlossen. Aber nur weil Outlook keine zusätzliche Authentifizierung für den Zugang per HTTP über das Internet zum Exchange Server unterstützt, heißt das noch lange nicht, dass es überhaupt nicht geht. Die Lösung funktioniert so, dass wir zwischen Outlook und dem Proxy, der eine Authentifizierung erfordert, einen weiteren Proxy schalten.

Bei mir hat sich dazu das kostenfreie Programm Proxomitron bewährt, welches einmal gestartet als kleines Icon in der Systemsteuerung liegt und als Proxy fungiert. In Proxomitron stelle ich nun den Firmenproxy als "Upstream Proxy" ein. Hier kann ich auch die Anmeldedaten hinterlegen. Nun muss ich meinen Internet Explorer nur noch so einstellen, dass er als Proxy "localhost:8080" verwendet. Proxomitron selbst erlaubt per Default nur den Zugriff vom lokalen PC selbst und fordert keine Anmeldung an. So kann ich dann auch in Umgebungen mit unfreundlichem Proxy doch RPC over HTTP nutzen. Nur wenn der Upstream Proxy keine BasicAuth anbietet, ist auch dieser Weg verbaut.

HTTPS über entschlüsselnde Proxies

Als Dienstleister darf man sich das ein oder andere Mal natürlich auch beim Kunden anschließen und bekommt freundlicherweise einen Zugang über einen Proxy. Natürlich nutze ich für alle Zugriffe SSL, damit eine echte Verschlüsselung von Ende zu Ende erfolgt. Leider können damit normale Proxies nicht in den Traffic rein schauen. Aber es gibt Proxy-Systeme, die dann sich behelfen und mir meinen Webserver mit einem anderen Zertifikat vorgaukeln, um den SSL-Tunnel aufzubrechen. Da solch ein Proxy natürlich kein "offizielles" Zertifikat für den Namen bekommt (und bezahlen kann), muss er mit einer eigenen CA arbeiten. Auf meinem Notebook fällt das natürlich auf:

Auf Clients in einer Firma können diese Meldungen natürlich einfach unterdrückt werden, indem die "WebWasher Root CA" einfach als "Trusted" automatische (-> Gruppenrichtlinien) eingetragen wird. Insofern kann man als Mitarbeiter in einer Firma bei der Verwendung von SSL keineswegs sicher sein, dass es wirklich eine Ende zu Ende Verschlüsselung ist.

Fehlersuche

Sollte RPC over HTTP dann jedoch immer noch nicht funktionieren, dann ist eine weitere Analyse erforderlich. Hier sind zuerst folgende Punkte zu prüfen:

2004-05-19 14:13:30 192.168.0.1 RPC_IN_DATA /rpc/rpcproxy.dll srv01.msxfaq.local:6001 80 - 192.168.100.12 MSRPC 401 2 2148074254
2004-05-19 14:13:30 192.168.0.1 RPC_OUT_DATA /rpc/rpcproxy.dll srv01.msxfaq.local:6001 80 - 192.168.100.12 MSRPC 401 2 2148074254

2005-03-06 00:03:22 192.168.0.12 39393 192.168.0.10 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?srv01.msxfaq.local:6004 400 1 BadRequest
2005-03-06 00:03:28 192.168.0.12 39397 192.168.0.10 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?SRV01:6004 400 1 BadRequest

Versuchen Sie z.B. RPC over HTTP einfach erst einmal von intern ohne Firewall, Router, NAT und andere möglichen Problemen. Auch ein zweiter PCs kann hilfreich sein, wenn nur eine Unstimmigkeit auf dem einzigen Testsystem Sie auf die falsche Fährte schickt.

Links

Keywords: RPCoverHTTP Proxy Proxomitron