Outlook Anywhere - Sicherheit

Hinweis:
Outlook Anywhere ist durch SSL sicher. Schwachpunkt ist der Client. Eine Postfach in einer OST-Datei ist nur so gut gesichert wie Windows selbst gesichert ist. Das wird noch wichtiger, wenn Tables und Slates Windows noch mobiler machen und Endgeräte nicht mehr zwingend Mitglied der Domäne sind.

Für die Betrachtung der Sicherheit dürfen Sie sich nicht nur auf den Server konzentrieren, sondern müssen zumindest drei Aspekte beleuchten:


Der Server		 Natürlich müssen Sie den Server "sichern". Selbst wenn sie einen kryptischen Namen gewählt haben, so wird der Zugang, welcher über den 443 seine Dienste anbietet, in der Regel nach kurzer Zeit "gefunden". Portscanner sind permanent auf der Suche nach Schwachstellen und so sollten Sie angemessen Mittel einsetzen, um ihren Server zu sichern.
Siehe auch OA Proxy

Die Verbindung		 Zwischen Client und Server werden alle Daten per HTTPS verschlüsselt. Wenn man mal davon absieht, dass diverse ältere SSL-Implementierungen Schwachstellen hatten oder früher zu kurze Schlüssellängen verwendet wurden, ist heute HTTPS ein relativ "sicheres" Protokolle, welches eine Ende zu Ende-Verschlüsselung gewährleistet, zumindest solange die ausstellenden Zertifizierungsstellen die Antragsteller prüfen und ungültige Zertifikate über die CRL vom Client erkannt werden können

Der Client		 Oft vergessen wird aber der Client. So "schön" die einfache Konfiguration (mit Autodiscover sogar automatisch) ist, so kann dies nicht darüber wegtäuschen, dass jeder Anwender mit Benutzername und Kennwort sich ein Profil auf einem beliebigen PC einrichten kann. Sie haben keine Kontrolle über den Desktop, lokale Kennworte, Schutz der OST-Datei etc.

Beachten Sie hier auf jeden Fall die "fehlende" Sicherheit von Clients, wenn Sie hier keine Beschränkung oder Regelung vorsehen.

Der Server

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.

Der Client

Kaum haben Sie als Administrator den RPC-Zugang per Zertifikat und Reverse Proxy gesichert, kann doch jeder Anwender auf seinem privaten PC zuhause einfach "Outlook Anywhere" einrichten. Mit funktionierender "Autodiscover-Konfiguration" muss er dazu nicht mal wissen wie es geht.

Und schon arbeiten die Anwender munter mit Outlook auf ihrem Server ohne, dass Sie überhaupt eine Möglichkeit haben, auf dem Client irgendwelche Richtlinien durchzusetzen. Der Client kann also "ohne Kennwort" und ohne Verschlüsselung betrieben werden. Selbst die Absicherung der OST.-Datei durch Verschlüsselung ist nicht von ihnen zu steuern. Der PC ist nämlich gar nicht in ihrer Domäne und schon gar keinen Gruppenrichtlinien unterworfen. Und dass darauf "nur" ihr Mitarbeiter sich anmeldet, ist auch nicht Vorauszusetzen. Und morgen sendet die Tochter, der Sohnemann oder wer auch immer im Haus eine Mail im Namen des Mitarbeiters ?. Und was passiert, wenn es sich um ein schickes privates Notebook handelt, welches so mobil ist, dass es nicht nur vom Mitarbeiter mal mit den Urlaub genommen wird, sondern auch sehr einfach anderweitig "Beine machen" kann ?.

Ein Dieb wird sich sicher über die Hardware freuen, besonders wenn Sie ungeschützt ist, aber noch interessanter können natürlich die Daten sein. Im Bereich mobiler Endgeräte gibt es zumindest ActiveSync Policies, die ein Kennwort erfordern, auch wenn dies kein 100% Schutz sein kann.

Es gibt keine 100% Lösung in diesem Bereich aber einige Dinge, die Sie überlegen könnten:

Microsoft selbst hat den ein oder anderen Artikel dazu schon beigesteuert

RPC/HTTP pro Benutzer steuern

Oft muss es ja aber gar nicht so aufwändig sein. Gerade im Mittelstand wird oft eine pragmatische Lösung gewählt und die Sicherheit aus einer Kombination von "Verpflichtung/Information" der berechtigten Mitarbeiter und einer Blockade aller "nicht relevanten" Postfächer umgesetzt. Den Zugriff per Outlook Anywhere können Sie nämlich pro Postfach steuern:

# OutlookAnywhere aktivieren
set-casmailbox -identity $mailbox -MAPIBlockOutlookRpcHttp:$false

# Outlook Anywhere deaktivieren
set-casmailbox -identity $mailbox -MAPIBlockOutlookRpcHttp:$true

Und damit die Clients das auch mitbekommen sehen Sie hier einmal eine Autodiscover-Auswertung mit aktiviertem (hinten) und deaktivierten (vorne) Outlook Anywhere.

Sobald auf der Mailbox der Zugriff per Outlook Anywhere blockiert ist, bekommt der Client die Information auch nicht mehr mit.

Ehe sie nun aber per Powershell erst mal bei allen Personen OA deaktivieren und danach wieder aktivieren, sollten Sie besser ein Skript einsetzen, welches nur die Benutzer deaktiviert, die z.B. nicht in einer Liste der "erlaubten Personen" enthalten sind. Das macht z.B. folgendes Skript

set-oaaccess.1.0.ps1

Sie können das Skript natürlich auch anpassen, dass es die Mitgliedschaft einer Windows Gruppe auswertet.. Wenn Sie aber eh schon eine Gruppe pflegen UND einen ISA/TMG haben, der eine Authentifizierung durchführt, dann können Sie zusätzlich auch hier die Veröffentlichung auf die Mitglieder dieser Gruppe beschränken. Sie sollten aber dennoch die Einstellungen am Postfach vornehmen, damit der Client per Autodiscover nicht in die Irre geführt wird.

Zertifikate und MSSTD

Outlook bekommt über Autodiscover die Einstellungen für Outlook Anywhere und per Default wird hier auch der Name des Zertifikats mit übermittelt. Der Client trägt dies dann sogar in der lokalen Konfiguration ein.

Das kann natürlich dann wieder zu Problemen führen, wenn der Namen nicht passt, z.B. weil das SAN-Zertifikat anders ausgestellt wurde oder ein Reverse-Proxy mit einem anderen Namen arbeitet. Und Outlook "warnt" dann natürlich sofort. Wenn ich bei mir manuell hier ein "msstd:owa.netatwork.local" eintrage und Outlook starte, dann erhalten ich folgenden Fehler:

Und natürlich fordert mich Outlook zur Eingabe der Anmeldedaten an, aber lässt mich dennoch nicht zu. Es ist daher wichtig, dass die Konfiguration auf dem Server entsprechend konfiguriert ist.

Empfehlung:
Adresse des RPCHTTP-Proxy-Zugangs ist gleich, egal ob der Zugriff von extern oder intern erfolgt.
Sollte das nicht gehen, dann bleibt ihnen nur die Prüfung des Zertifikatsnamens abzuschalten.

Das geht per Powershell

# Setzen eines anderen MSSTD-Namens
Set-OutlookProvider EXPR `
    -Server $null `
    -CertPrincipalName msstd:internal.company.local

# Leeren des Felds, damit keine Prüfung stattfindet
Set-OutlookProvider EXPR `
    -Server $null `
    -CertPrincipalName $null

Wenn Outlook den Namen nicht mehr prüft, dann fehlt natürlich ein Baustein bei der Sicherheit. Andererseits wird ein Angreifer, der ihnen ein anderes Zertifikat als "Man in the Middle" unterschiebt, sicher auch diese Hürde nehmen.

Weitere Links

Keywords:RPCoverHTTP Proxy Proxomitron