EAS Absicherung

Die meisten Firmen werden vermutlich Exchange ActiveSync einfach über die Anmeldung mit Domäne/Benutzername/Kennwort verwenden. Aber es gibt ja auch die Möglichkeit einer Anmeldung mit Zertifikaten. Die Umsetzung dieser Lösung ist aber komplexer und wird auch nicht von allen Endgeräten unterstützt. Daher stellt sich die Frage, welche andere Optionen noch möglich sind. 

Schwächen von Benutzername und Kennwort

Zuerst schauen wir uns die Gründe an, Sie eine Veränderung der Anmeldung sinnvoll erscheinen lassen. Denn nur weil viele etwas tun, heißt es ja noch lange nicht, dass es richtig ist. Wo liegen denn die Einschränkungen, wenn Sie ActiveSync mit "Benutzername/Kennwort betreiben ?

  • Reversibles Kennwort auf dem PDA
    Damit sich ein Endgerät per "Basic Authentication" über SSL am ActiveSync Server anmelden kann, muss das Kennwort auf dem PDA eingegeben und für Push sogar "gespeichert" werden. Auch wenn das Kennwort an einem "sicheren Ort" hinterlegt wird, so muss eine Softwarekomponente das Kennwort dort auslesen und bei jedem HTTP-Befehl mit an den Webserver senden. Es ist also "auslesbar". Zusatzprodukte wie z.B. Nokia Mail für Exchange sind theoretisch genauso schwach. Sie sollten also auf jeden Fall eine Geräte-PIN vorschreiben, damit diese das Gerät schützt und bei Verlust des Geräts das Kennwort umgehend ändern. Hoffentlich verwenden Sie ihr Active Directory Kennwort nicht noch bei anderen Diensten.
  • Man in the Middle mit SSL
    Es ist aufwendig aber nicht unmöglich, sich zwischen den PDA und den ActiveSync Server zu schalten. Auch wenn die Verbindung per SSL gesichert ist, so könnte ein Angreifer über DNS-Spoofing o.ä., die Anfragen der Clients auf seinen Webserver umlenken, auf dem nur ein passendes Zertifikat installiert sein muss. Es gibt leider immer wieder offizielle Zertifizierungsstellen, die bei der Überprüfung des Antragstellers schlampen oder andere Schwächen bei der Zertifikatsüberprüfung. (z.B. /0hex im DN des Zertifikats oder Clients die nach einer Warnung einfach fortsetzen. Dann sendet der Client wirklich das Kennwort schwach mit BASE64 codiert an einen fremden Webserver
  • Kennwortrichtlinien und Kennwort ändern
    In den meisten Firmen müssen Anwender ihr Kennwort immer mal wieder ändern. Das betrifft natürlich auch den PDA, d.h. wann immer ein Anwender das Kennwort im Active Directory ändert, wird der PDA auf einen Fehler laufen. ältere Versionen der Nokia Data Suite haben es sogar immer wieder bis zur Sperrung des Kontos versucht. Mit der zertifikatsbasierten Anmeldungen bleibt der PDA von KennwortÄnderungen verschont. Allerdings muss das Zertifikat natürlich zu gegebener Zeit aktualisiert werden.
  • "Wilde Installation"
    Wenn die Anmeldung an ActiveSync per Benutzername/Kennwort nicht mehr möglich ist, muss erst das Zertifikat auf das Endgerät kommen. In Verbindung mit der passenden Rollout-Policy auf der Zertifizierungsstelle kann eine Firma sehr gut kontrollieren, welche Endgeräte ein Zertifikat bekommt. Allerdings erschwert dies natürlich auch ein "mobiles" Einrichten, d.h. wenn ein Mitarbeiter unterwegs einen PDA verliert, dann kann ein Ersatzgerät nur über einen Notebooks mit VPN unterwegs eingerichtet werden.

Insofern kann es durchaus sinnvoll sein, über andere Anmeldeverfahren nachzudenken. Die von Microsoft als Alternative bereit gestellte Funktion von Exchange ActiveSync mit Zertifikaten erlaubt den Betrieb ohne lokales Kennwort und die Authentifizierung mittels Zertifikaten. Ein Hersteller kann per Hardware z.B. sicherstellen, dass ein Zertifikat nicht wieder ausgelesen werden kann. Allerdings schweigen sich alle Hersteller hier aus, wie sicher das Zertifikat auf dem Gerät letztlich ist. Zudem müssen sie genau prüfen, ob der Zwang zur Anmeldung mit Zertifikaten nicht eine Reihe von Clients "aussperrt", die dieses Verfahren nicht unterstützen. Auch sollten Sie den zusätzlichen Aufwand für Endbenutzersupport Aufwand für Wartung, Einrichtung, Pflege nicht unterschätzen. Sie benötigen auch einen PKI für den Einsatz im Netzwerk.

Da all diese Einschränkungen könnten Sie sich natürlich auch nach Alternativen umsehen. Hier ein paar Optionen:

Absicherung mit VPN

Sie könnten den Zugang zum Exchange Server einfach nicht über das Internet öffentlich erreichbar machen, sondern nur von "intern". Wer dann mit dem Mobilgerät sich verbinden will, muss immer erst ein VPN aufbauen oder permanent aufgebaut lassen.

Damit greifen natürlich alle Schutz und Filtermechanismen der eingesetzten VPN-Lösung. Allerdings müssen Sie auch sicherstellen, dass alle gewünschten und zukünftig gewünschten Endgeräte auch diese VPN-Lösung nutzen können. Und da es neben Windows Mobile mittlerweile auch noch iPhones, Symbian, Android und vielleicht noch andere Systeme gibt, muss die VPN-Lösung schon sehr umfassen sein.

Einen solchen Ansatz geht z.B. der Mobile Device Manager 2008, dessen Lösung ein IPSec-VPN aufbauen und darüber sämtliche weitere Kommunikation nutzt.

Eine permanente VPN-Verbindung kann aber eventuell dazu führen, dass die Laufzeit der PDA's reduziert wird und Sondereinstellungen bezüglich "Roaming" nun in der

Absicherung mit Token

Eine abgewandelte Art der Absicherung ist die zusätzliche Sicherung über ein Token (z.B.: RSA o.ä.). Es würde hier also auch nicht ausreichen, wenn ein Angreifer das Kennwort erhält, da das Token sich immer ändert. Nachteilig ist, dass ActiveSync erst ab 6.1 bemerkt, wenn auf die HTTP-Anfrage eine Anmelde-Webseite kommt. ältere Versionen und andere ActiveSync Lösungen sind diesbezüglich entsprechende zu prüfen.

Da der Angreifer aber das Kennwort hätte, könnte er natürlich andere Zugänge (z.B. OWA, RDP) nutzen, wenn diese nicht auch durch ein Token "hochsicher" ausgelegt sind.

Da Tokens und die damit bereit gestellten Cookies immer nur eine gewisse Zeit gelten, muss der Anwender eventuell mehrfach pro tag ein neues Token eingeben. Zudem muss die Gültigkeit des Tokens verlängert werden, damit der Anwender nicht nach 2 Minuten Inaktivität sich wieder neu anmelden muss. Vermutlich werden schon viele Anwender fluchen, wenn sie nach jeder Ruhezeit (Nachtabschaltung, Flugmodus) immer erst wieder den Token aus der Tasche kramen und auf dem PDA die Daten eingeben müssen.

Anmeldung mit "extra Account"

Als Firma könnten Sie ja generell lein Problem damit haben, dass die Anmeldedaten für den Desktop, das VPN, den Dateiserver etc. auch für den Zugriff per ActiveSync und OWA genutzt werden. Es ist daher auch eine Konstellation möglich, bei der ein Anwender zwei Konten im Active Directory bekommt:

  • User1
    Dies ist das primäre Anmeldekonto, mit dem sich der Anwender auf seinem Desktop etc. anmeldet und damit arbeitet. Dieses Konto hat aber keine Exchange Mailbox.
  • User1-MAIL
    Dieses Konto ist ebenfalls aktiviert und hat eine Exchange Mailbox. Dieses Konto taucht also auch in der GAL auf. Das primäre Anmeldekonto bekommt auf diese Postfach ebenfalls "Vollzugriff", so dass der Anwender sich mit dem Anmeldekonto anmelden aber auf das Postfachkonto zugreifen kann. für ActiveSync kommt aber das Postfachkonto mit dem eigenen Kennwort zum Einsatz. Ab Windows 2008 können ja pro OU unterschiedliche Kennwortrichtlinien gelten, so dass z.B. diese Konten seltener ihr Kennwort ändern müssen. Denn dieses Postfachkonto sich dann sonst nirgends anmelden darf, dann kann ein Angreifer, welcher dieses Kennwort ausspäht wirklich nur Mail per ActiveSync machen.

Der Anwender greift also mit Outlook auf sein Postfach selbst über delegierte Berechtigungen zu. Allerdings hat diese Option auch Nachteile, dass der Anwender das Kennwort des MAIL-Users nicht einfach ändern kann und Autodiscover nicht funktioniert. Das Anmeldekonto hat ja keine Exchange-Daten. Knifflig wird das auch, wenn der Office Communication Server ins Spiel kommt. da hier der primäre Benutzer ja die OCS-Eigenschaften aber keine Exchange Eigenschaften hat.

Ein nützlicher Nebeneffekt wäre hierbei aber, dass sie beim Anmeldekonto die kompletten Stammdaten pflegen könnten aber beim Postfachkonto sich auf die Felder beschränken können, die in der GAL erscheinen sollen. Dennoch ist auch diese Option wenig zukunftssicher.

Absicherung mit Zertifikaten

Siehe dazu Exchange ActiveSync mit Zertifikaten

Absicherung per IMEI

Auch wenn es genau genommen nicht zu den verschiedenen Authentifizierungsverfahren zählt, ordne ich die Filterung anhand der IMEI dort mit ein, denn ein Stück weit kann man das Mobilgerät als "Hardwaretoken" ansehen. Über die IMEI wird sicher gestellt, dass eben nur dieses Endgerät auf das entsprechende Postfach zugreifen kann. Insofern haben wir hier auch "Benutzername, Kennwort, IMEI".

Die IMEI bekommen Sie am einfachsten heraus, wenn ein Benutzer schon einmal synchronisiert hat:

get-ActiveSyncDeviceStatistics

Diese Zahl können Sie mit dem Befehl "Set-CAS-Mailbox" beim Benutzer eintragen:

# Setzen einer einzelnen IMEI
Set-CASMailbox fcarius -ActiveSyncAllowedDeviceIDs C06F963D5734ABCDEFGHABCDEFGH123456

# Mehrere Geräte setzen
Set-CASMailbox fcarius -ActiveSyncAllowedDeviceIDs {IMEI1, IMEI2, IMEI3}

# Löschen des Eintrags damit wieder alle Geraete erlaubt sind
Set-CASMailbox fcarius -ActiveSyncAllowedDeviceIDs $null

Im IISLog findet sich die entsprechende Meldung "Error:DeviceIsBlockedForThisUser". Hier ein verkürztes Log.

2009-10-09 15:02:39 192.168.100.18 OPTIONS /Microsoft-Server-ActiveSync/default.eas user=fcarius&DeviceId=C06F963D5734C3496&DeviceType=SmartPhone
&Log=V120_LdapC1_LdapL15_RpcC0_RpcL0_Pk394026268_Error:DeviceIsBlockedForThisUser_ 443 NETATWORK\fcarius 192.168.100.12 MSFT-SPhone/5.2.402 403 0 0 1482

2009-10-09 15:02:45 192.168.100.18 POST /Microsoft-Server-ActiveSync/default.eas user=fcarius&DeviceId=C06F963D5734C3496&DeviceType=SmartPhone&Cmd=FolderSync
&Log=V120_LdapC0_LdapL0_RpcC9_RpcL15_Ers1_Pk394026268_Error:DeviceIsBlockedForThisUser_ 443 NETATWORK\fcarius 192.168.100.12 MSFT-SPhone/5.2.402 403 0 0 1060

Der Anmeldeversuch mit einer falschen IMEI wird auch im Eventlog sichtbar:

Protokollname: Application
Quelle: MSExchange ActiveSync
Ereignis-ID: 1019
Aufgabenkategorie:Anforderungen
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: nawsv003.netatwork.de
Beschreibung:
Ein geblocktes Gerät von Benutzer [NETATWORK\fcarius], Geräte-ID = [C06F963D5734C34xxxxxxxxxxxx], versucht, die Synchronisierung mit Exchange ActiveSync durchzuführen.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">entfernt</Event>

Event Type: Warning
Event Source: MSExchange ActiveSync
Event Category: (1)
Event ID: 1019
Date: 09.10.2009
Time: 17:02:39
User: N/A
Computer: nawsv003.netatwork.de
Description:
A blocked device of user [NETATWORK\fcarius], device id = [C06F963D5734C34xxxxxxxxxxxx], is attempting to synchronize with Exchange ActiveSync.

Insofern können Sie natürlich auch einfach auf diese Events "warten" und dann das Gerät frei schalten. Auf dem Endgerät bekommt der Anwender ebenfalls eine Fehlermeldung mit dem Unterstützungscode 0x85010004

PDA Fehler bei falscher IMEI

Auch wenn der Server an den Client sicher eine komplette Fehlermeldung ausliefert, so zeigt mein Windows Smartphone nur einen generischen Text an.

Praktisches Ergebnis

Auch wenn viele Optionen immer wieder beleuchtet werden, so ist der Zugriff vom PDA auf die Mailbox per ActiveSync mit Benutzername und Kennwort die häufigste Art der Anbindung, da sie einfach ist, mit vielen Endgeräten funktioniert und die Sicherheit per SSL gegeben ist. Natürlich muss man der Software auf dem PDA (Sei es nun Windows Mobile oder eine Addon Software wie "Nokia Mail für Exchange" oder einem Betriebssystem wie dem iPhone derart vertrauen, dass das hinterlegte Kennwort auch wirklich nicht ausgelesen oder "aus Versehen" an andere Dienste versendet werden kann.

Der zusätzliche Schutz durch Zertifikate auf dem PDA begrenzt die Auswahl der Endgeräte und erfordert den Aufbau einer internen PKI, was nicht mal schnell erfolgt, selbst wenn es "nur" eine interne private PKI ist.

Von den Alternativen sehe ich maximal die VPN-Lösung als praktikabel an, da hierbei oft der Zusatznutzen vorhanden ist. Wenn das Endgerät ein VPN aufgebaut hat, kann es auch andere internen Dienste, die mit ActiveSync nichts zu tun haben, ebenfalls nutzen. z.B. ERP oder CRM Anwendungen o.ä.

Weitere Links