Outlook Anywhere - Client

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:

  • Windows XP mit Service Pack 2
    Früher konnte auch SP1 mit einem Hotfix genutzt werden, aber Sie sollten gleich mit SP2 starten
  • Outlook 2003
    Frühere Versionen von Outlook unterstützen kein RPC over HTTP

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.

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

Spaß und ärger mit Telekom
Wer an einem T-DSL-Anschluss hängt, kann mit einer Funktion "T-Online Navigationshilfe" in Kontakt kommen. Wenn ein Anwender einen ungültigen Hostnamen im Browser eingeben, dann bekommen Sie keine "nicht erreichbar" sondern landen auf einer Webseite der Telekom mit Empfehlungen. Technisch funktioniert das so, dass der DNS-Server der Telekom nicht auflösbare Adressen eben auf "ihren" Webserver auflösen.
Das ist dann ungeschickt, wenn Outlook "zuerst TCP statt RPCHTTP" nutzt und extern den internen CAS-Namen auflösen will.

Eigentlich sollte er nicht auflösbar sein, so dass Outlook wechselt. Nun aber "findet" Outlook einen Server, der aber sicher keine Exchange RPC-Pakete versteht. Je nach Outlook Version dauert es "länger" bis ganz lang, dass die Verbindung dann doch zustande kommt.
Abschalten kann der Anschlussinhaber im Kundencenter (https://kundencenter.telekom.de/kundencenter/kundendaten/navigationshilfe/)

In Outlook werden zwei Servernamen gepflegt:

  • Exchange Server

    Dieser Servernamen ist der interne Name des Exchange Mailboxservers, wie er vom RPC-Proxy intern aufgelöst werden kann. Es ist also nicht erforderlich, dass dieser Name per DNS aus dem Internet erreichbar ist.
  • RPC-Proxy-Server
    Diese Adresse ist der Name des RPC-Proxy Servers, welchen Outlook per HTTPS anspricht.

    Dieser Name muss aus dem Internet auflösbar und erreichbar sein.

Wenn Sie eine gegenseitige Authentifizierung möchten, dann sollten Sie diese in Autodiscover auch eintragen, z.B.: mit:

Set-OutlookProvider -Identity EXPR -CertPrincipalName "*.domain.com"

Wenn Sie dies wieder rückgängig machen wollen, dann geht dies per

Set-OutlookProvider -Identity EXPR -CertPrincipalName $null

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 Offline Adressbuch

Mit Outlook2007 und Exchange 2007 bzw. höher gibt es einen "Seiteneffekt" mit RPC/HTTP, der oft so nicht erkannt wird. In der Konfiguration können Sie folgende einstellen:

Wenn Sie nun parallel einmal "Autodiscover" durchführen, dann sehen Sie hier trotzdem zwei Einträge:

Wenn Sie nun in der RPC/HTTP-Konfiguration beiden Checkboxen aktiv machen, dann kann Outlook immer nur "HTTP" sprechen und damit kommt aber auch für den Download des OABs immer die "ExternalURL" zum Tragen. Stellen Sie daher sicher, dass auch Anfragen von Intern auf dem passenden Server ankommen.

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 Authentication

Verwirrend sind die Optionen für die Verfahren zur Anmeldung am RPCProxy. Zwei Einstellungen sind bei "Get-OutlookAnywere" erreichbar

  • ClientauthenticationMethod
    Damit wird eingestellt, welche Anmeldeverfahren dem Client per Autodiscover mitgeteilt werden
  • IISAuthenticationMethods
    Dies sind die Anmeldeverfahren, die der Exchange auf dem IIS des CAS-Servers auf dem virtuellen Verzeichnis "/RPC" einstellt. Zur Auswahl stehen dabei eigentlich nur Basic und NTLM. Kerberos wird nicht unterstützt

Die Einstellungen können durchaus unterschiedlich sein. So können Sie zwischen Internet und Exchange CAS ja eine Firewall haben, die die Authentifizierung umsetzt, z.B. extern per "Basic" oder "Form" anmelden, aber dann intern per NTLM weiter gehen.

Use Basic Authentication or Windows Integrated Authentication to authenticate to the RPC Proxy?
 RPC over HTTP currently supports only NTLM – it doesn't support Kerberos. Also, if there is an HTTP Proxy or a firewall between the RPC over HTTP client and the RPC Proxy which inserts the via pragma in the HTTP header, NTLM authentication will not work. When that is not the case, organizations can choose between Basic and NTLM authentication. The advantage of Basic authentication is that it is faster and simpler, and therefore offers less opportunity für denial of service attacks. But NTLM is more secure. Depending on an organization's priorities, it can choose Basic, NTLM, or allow its Users to choose between the two. If only one is chosen, it is best to turn off the other from the RPC Proxy virtual directory to reduce risk of attack.
http://msdn.microsoft.com/en-us/library/aa378641(v=vs.85).aspx

Eine zweite Komponente ist dabei natürlich der Client, welcher auch nicht alle Authentifizierungsverfahren unterstützt oder je nach Internetzone und Verbindung (z.B. Proxy des Providers) nicht alle Verfahren nutzen kann.

Am universellsten ist BASIC-Auth, die aber zwingend per SSL gesichert sein muss aber vom Anwender dann die Eingabe der Anmeldedaten erfordert.