ActiveSync mit Zertifikaten -Grundlagen

Die meisten Firmen betreiben PDAs mit ActiveSync über eine Anbindung per http/https und einer Anmeldung mit Benutzernamen und Kennwort. Wird in dieser Konstellation nicht mindestens SSL genutzt, dann gehen Benutzername und Kennwort ungeschützt über die Leitung. Aber selbst beim Einsatz einer SSL-Verbindung werden die Anmeldedaten auf dem PDA reversibel gespeichert. Schließlich muss die ActiveSync Software auf dem PDA die Anmeldedaten ja an den Server übermitteln. Mit Windows Mobile 5 MSFP und höher und Exchange 2003 SP2 und höher ist es nun neben der Funktion Always up-to-date auch möglich, Zertifikate für die Anmeldung zu nutzen. So muss auf dem PDA kein Benutzername oder Kennwort mehr hinterlegt werden und die Sicherheit ist verbessert.

Überlegungen

Allerdings muss der Administrator nun dafür sorgen, dass das Zertifikat auf den Client gelangt und dass auch alle Clients eine zertifikatbasierte Anmeldung unterstützen. Selbst OEM-Geräte wie das Nokia E60 mit Mail für Exchange können dies noch nicht, so dass eigentlich alle Endgeräte OHNE Windows Mobile 5 MSPF erst einmal ausscheiden. Aber Sie könne ja alternativ zwei Zugänge veröffentlichen. Zugang 1 per Zertifikat für Windows Mobile und kompatible Geräte und den anderen Zugang für alternative Geräte, die noch keine Client Zertifikat unterstützen. für den Einsatz einer zertifikatbasierten Anmeldung sprechen zwei Dinge:

  • Höhere Sicherheit
    Ein Benutzername und Kennwort kann weiter gegeben werden. Ein auf dem PDA einmal abgelegtes Zertifikat kann (offizielle) nicht mehr von dort extrahiert werden, d.h. ist an das Gerät und seinen Besitzer mit der PIN gebunden
  • Kennwortrichtlinien
    Immer mehr Firmen zwingen den Benutzer dazu, sein Kennwort regelmäßig zu ändern. Er muss natürlich dann daran denken, dass er auch das Kennwort auf dem PDA wieder ändert. Im Extremfall schaltet der Benutzer nach ändern des Kennworts im AD den PDA mehrfach aus und an, weil er das Problem lösen will und bewirkt letztlich eine Sperrung des Kontos aufgrund zu vieler Fehlversuche.

Sie sehen also, dass ActiveSync mit Zertifikaten gar nicht nur eine nette Funktion für hochsichere Umgebungen sein muss, sondern in Verbindung mit einem etwas länger laufenden Benutzerzertifikat sogar eine Allgemeinfunktion werden kann.

Ehe Sie nun aber übermütig werden: Nicht jeder Zugang zu Exchange funktioniert auch mit Zertifikate. RPC/HTTP (also Outlook Anywhere) funktioniert z.B. nicht mit Client Zertifikaten.

Voraussetzungen

Die Microsoft Dokumentation beschreibt folgende Voraussetzungen:

  • Betriebssystem
    Exchange 2003: Windows 2000SP4 oder Windows 2003SP1
    Exchange 2007: jede unterstützte Version
    Speziell alte Server unter Exchange 2003 mussten früher erst einmal aktualisiert werden. Heute sollte das kein Problem mehr darstellen
  • Active Directory
    Damit die Kerberos Delegation funktioniert, muss das Active Directory im Windows 2003 Native Mode laufen, d.h. es darf keine Windows 2000 DCs mehr geben.
  • Exchange Version
    Exchange 2003 SP2 oder Exchange 2007/2010 (jede Version)
    Wer Exchange 2003 einsetzt, muss mindestens Servicepack 2 einsetzen.
  • Endgeräte
    Windows Mobile 5 MSFP2 und höher
    Heute sollten alle noch genutzten Mobiltelefone wohl mit Windows Mobile ausgestattet sein. Früher war es schon eine Problemstellung, ob es noch ein Update der Firmware für MSFP2 gegeben hat.
  • Interne Windows CA
    Zwingend für die Nutzung von Clientzertifikaten ist eine interne Windows Zertifizierungsstelle, damit die Active Directory Anwender intern ein Clientzertifikat anfordern können. Ich kenne keinen Weg, andere Zertifikate einzusetzen, das ActiveSync selbst das Zertifikat anfordert, Vielleicht ist es zukünftig einmal möglich auch andere Zertifikate einzusetzen, solange der UPN dem Feld Subject Name" übereinstimmt.
  • Active Directory mit Exchange zur Veröffentlichung der XML-Datei
    Sie benötigen zwingend ein Active Directory mit Schemaerweiterung. Mittlerweile können ja auch Notes und andere Server als ActiveSync Server agieren. Inwieweit hier mit Zertifikaten gearbeitet werden kann und wie der PDA entsprechend konfiguriert wird, entzieht sich meiner Kenntnis
  • Veröffentlichung per ReverseNAT oder ISA Server Publishing
    IIS muss SSL nutzen und Client Zertifikate erfordern.
  • Veröffentlichung über ISA 2006 Web Listener
    Wer den ActiveSync Zugang über einen ISA2006 Weblistener veröffentlicht, muss nach meinem aktuellen Kenntnisstand den ISA in die Domäne aufnehmen, das Zertifikat auf dem Listener annehmen und über Constaint Delegation dann auf den Exchange Frontend zugreifen. Dazu muss der ISA2006-Server Mitglied der Domain sein Die von mir getesteten mobile Geräte hatten Probleme, wenn die 403.7-Fehlermeldung vom ISA-Server generiert wurde. Daher muss der Tunnelmode genutzt werden oder die Zertifikatanmeldung am ISA erfolgen.

Frontend und Proxy

Solange Sie nur einen Exchange Server betreiben, sieht das Setup ja etwas einfach aus. Aber wie sieht es aus, wenn Sie davor einen Reverse-Proxy oder Loadbalancer nutzen oder mehrere Exchange Server genutzt werden. Auch die Migration von Exchange führt in der Regel dazu , dass am Anfang der Client Zugangspunkt auf die neue Version umgestellt wird.

Allen diesen erweiterten Herausforderungen ist gemein, dass das erste System, welche den SSL-Tunnel terminiert das Client-Zertifikat anfordern uns auswerden muss. Damit ist auch klar, dass dieses erste Systeme dann die Zugriffe auf die nachfolgenden Server mit einer entsprechenden Authentifizierung durchführen muss. Das Client-Zertifikat kommt in diesem Fall nicht beim Postfachserver selbst an. Insofern haben Sie nur die Wahl zwischen zwei Optionen:

  • Exchange fordert das Zertifikat an
    Das bedeutet natürlich, dass jede Art vorgelagerter ReverseProxy oder Loadbalancer auf Layer4-Ebene einfache die TCP-Verbindung weitergeben. Eine Inspektion der HTTP-Nutzdaten oder eine Pre-Authentication entfällt.
  • ReverseProxy fordert Zertifikat
    Wenn allerdings ein vorgelagertes System, d.h. Layer-7 Loadbalancer, MDM-Lösung, Reverse-Proxy die HTTP-Anfragen inspizieren soll, dann muss diese System auch das Client-Zertifikat anfordern. Wenn das System dann den Benutzer kenn, muss es nach hinten die Anmeldedaten weiter geben. Das Problem hierbei: Dieses System hat gar keine Kennwort. Es funktioniert also nur per "Kerberos" Delegation.

Beide Varianten sind möglich. Mit Exchange 2013 und neuer gibt es die klassischen Rollenteilung mit CAS und Mailbox nicht mehr. Alle Server machen nun alles aber im inneren gibt es schon noch die "Frontend" und "Backend"-Rolle. Das erkennen Sie schon an den zwei Webseiten im IIS eines Exchange 2013/2016 Servers. Mit einem Single-Exchange Server wird die zertifikatbasierte Anmeldung auf dem Frontend-IIS aktiviert. Auf dem Backend.-IIS hingegen bleibt die normale Anmeldung aktiv.

Für eine Migration von Exchange 2010 ist es dazu erforderlich, nach dem Wechsel des Client Access auf Exchange 2013/2016 auf den Exchange 2010-CAS-Servern die Authentifizierung wieder zurück zu stellen, damit die Funktion des CAS -Proxy funktionieren kann. Die Exchange 2013/2016-Server lesen übrigens die Konfiguration der anderen Servern aus und leitet ActiveSync-Anfragen gerade nicht an noch nicht umgestellte Exchange CAS-Server

Einschränkungen

Wo Licht ist, ist auch Schatten. So gibt es die ein oder andere Einschränkung, wenn Sie ActiveSync nur für Client mit Zertifikaten veröffentlichen.

  • Endgeräteauswahl
    Aktuell konnte ich nur Windows Mobile 5.0 MFP2, 6.0, 6,1, 6.5 und vermutlich auch neuere Geräte als "tauglich" überprüfen. Nicht jedes System, welches ActiveSync unterstützt (z.B. iPhone, Nokia Mail für Exchange, Google, etc) können sich per Zertifikat anmelden.
  • Initiale Synchronisation muss per ActiveSync Desktop-Verbindung erfolgen
    Das Mobilgerät muss "wissen", wie es die Zertifikate erhalten kann. Da Sie ihre CA sicher nicht aus dem Internet erreichbar machen wollen kann diese einmalige Verbindung nur über eine ActiveSync-Partnerschaft mit einem Desktop erfolgen, auf dem der Anwender auch als Domainbenutzer angemeldet und mit dem Active Directory verbunden ist (ein VPN ist auch ausreichend).
  • "nur ActiveSync", nicht RPC/HTTP
    Die Kennwortproblematik würde es prinzipiell auch für
  • Zwei Zugänge für Zertifikat undUsername/Kennwort
    Weder ein IIS noch ein ISA-Listener können die normale "Username/Kennwort"-Anmeldung und "Zertifkatanmeldung" zur gleichen Zeit unterstützen. Wenn sie beide Optionen anbieten wollen, müssen Sie zwei Zugänge mit jeweils eigenem DNS-Namen und Zertifikat veröffentlichen.
  • Exchange 2007 Dateifreigaben
    Windows Mobile können mit zertifikatbasierter Anmeldung per OWA nicht auf Dateifreigaben von Exchange 2007 zugreifen. Dies funktioniert aber auch nicht in Verbindung mit einem CAS-Proxy oder einen ISA mit NTLM-Authentifizierung.

Wenn Sie nu überzeugt sind, dass die Anmeldung von ActiveSync-Clients per Zertifikat der richtige Weg ist, dann sind die folgenden Seiten für sie interessant: