Verwalten von Exchange Activesync-Richtlinien bei Exchange 2010, Teil 2

Da Microsoft die EAS-Unterstützung in den eingebauten Mail-Client von Windows 8 und Outlook 2013 vorgesehen hat und weil es bereits eine enorme Basis an installierten EAS gibt, dürfte es sehr sicher sein, dass uns EAS noch lange erhalten bleibt. Es wird zudem interessant sein, zu sehen, wie das OWA-Team OWA bei Exchange 2013 positioniert.

Es ist zumindest so entworfen, dass es besser als frühere Versionen mit Tablet- und Mobilgeräten zusammenspielt – zudem wird die Offline-Funktionalität unterstützt. Da es von Microsoft einen umfassend ausgestatteten Mobilclient  gibt, sollten – hoffentlich – Apple und die großen Android-OEM-Hersteller sowie auch das Team von Windows Phone nachziehen und mehr Funktionalität unterstützen –wie es das Protokoll EAS bereits anbietet. Es gibt vielversprechende Zeichen, dass Windows Phone 8 eine bessere Unterstützung von EAS bringen wird. Aber Microsoft hat dazu noch keine konkreten Details genannt.

Es ist aber auch gut möglich, dass im Rahmen des Protokolls EAS zu Verbesserungen kommen wird – wie etwa dass EAS-Geräte den Zugriff auf die persönlichen Archive von Exchange bekommen. Aber egal, welche Änderungen Microsoft für das grundlegende EAS noch vorgesehen hat – der Administrator sollte sich gut mit der Verwaltung von EAS-Geräten auskennen. Denn das gehört mittlerweile zu einer modernen und gut funktionierenden Exchange-Organisation.

Bereits im ersten Teil wurde das Prinzip der Arbeitsweise von Exchange Activesync (EAS) verdeutlicht. Dieser Beitrag ist in der Februar-Ausgabe des E-Paper von NT4ADMINS erschienen, die für Abonnenten kostenlos zur Verfügung steht. Wer eine Leseprobe mit dem ersten Teil dieses Beitrags bekommen möchte, der braucht dazu nur seine Kontaktdaten in einer Mail mit Betreff „Leseprobe EAS“ an die Redaktion schicken. Im zweiten Teil geht es nun vor allem um das Arbeiten mit den EAS-Richtlinien. Dazu gehört unter anderen das Erzeugen und Verwalten der Richtlinien.

Auf der Seite von Exchange sind die EAS-Richtlinien klar strukturiert und einfach zu verstehen. Doch man sollte sich eines merken: Nicht jedes Gerät setzt auch jede Richtlinien-Einstellung um. Zudem schwindeln einige Geräte manchmal und behaupten, dass sie bestimmte Richtlinieneinstellungen umgesetzt haben – auch wenn das gar nicht stimmt. Auf einer halboffiziellen, englischsprachigen Wikipedia-Seite ist der aktuelle Zustand der Client-Unterstützung für eine Vielzahl von Geräten zu finden.

Generell gibt es drei Arten, wie mit einem EAS Richtlinienobjekt umgegangen wird:

• In der Exchange Management Console (EMC) lassen sich Richtlinien erzeugen und ändern. Dazu muss man zum Reiter „Exchange ActiveSync Mailbox Policies“ (auf einem englischsprachigen System) mit den EAS-Postfachrichtlinien gehen. Er befindet sich unterhalb des Organisationsobjekts beim Clientzugriffs-Knoten (Client Access).
• Im ECP (Exchange Control Panel) ist der Administrator in der Lage, EAS-Richtlinien zu erzeugen, sie zu ändern und sie zu löschen. Dazu gibt es unterhalb des „Phone & Voice“-Reiters des Organisationsobjekts den Bereich mit der „ActiveSync Device Policy“ (Activesync Geräterichtlinien).
• In der EMS (Exchange Management Shell) steht eine komplette Cmdlet-Familie (*-ActiveSyncMailboxPolicy) zur Verfügung. Damit lassen sich EAS-Richtlinienobjekte erzeugen (New-ActiveSyncMailboxPolicy), löschen (Remove-ActiveSyncMailboxPolicy) oder auch nur anzeigen. Zudem sind Änderungen der Einstellungen an einer bestehenden Richtlinie machbar, wenn man die Cmdlets Get-ActiveSyncMailboxPolicy und Set-ActiveSyncMailboxPolicy zusammen einsetzt.

Generell gibt es geringe Unterschiede in der Terminologie zwischen diesen drei Ansätzen und nicht jede konfigurierbare Option steht im Bereich des ECP zur Verfügung. Im weiteren Verlauf wird daher das EAS-Interface besprochen, wie es in der EMC erscheint.

Was zu einer Richtlinie gehört

Die grundlegende Kategorisierung der verfügbaren Richtlinieneinstellungen zeigen sich in den Reitern der Dialogbox mit den Eigenschaften der Richtlinien. Sie sind in der  EMC zu finden. Bild 1 zeigt auf einem englischsprachigen System die Eigenschaften der EAS-Postfachrichtlinien.

Der Reiter „General“ (Allgemein) weist in diesem Zusammenhang nur drei Bereiche auf, die von Interesse sind. Dazu gehört ein Feld, in dem man den Namen für die Richtlinie ändern kann (den Exchange selbst allerdings nicht verwendet). Ein weiteres Element ist die Checkbox „Allow non-provisionable devices“ (Nicht bereitstellbare Geräte zulassen). Sie kontrolliert, welche Geräte sich synchronisieren können, selbst wenn sie keine Richtlinie akzeptieren. Wenn diese Funktion aktiviert ist, kann das zu einem Risiko führen. Vor allem wenn man das für alle („any“) Geräte aktiviert.

Der dritte Bereich bezieht sich auf die Checkbox und das Textfeld „Refresh interval (hours)“ – zu Deutsch: Aktualisierungsintervall (Stunden). Damit lässt sich vorgeben, wie oft der Server dem Gerät vorgibt, dass es Richtlinienaktualisierungen abrufen soll. Dieser Wert ist standardmäßig nicht belegt – damit wird vorgegeben, dass der Server keine zeitlichen Vorgaben für eine erzwungene Aktualisierung vorgibt. Allerdings kann der Administrator hier Werte wie etwa 24 Stunden eingeben, wenn das in seiner Konfiguration erforderlich sein sollte.

Der Reiter Kennwort (Password): Die größte Gewichtung bei den Einstellungen ist beim Reiter zu den Kennworten zu finden (siehe Bild 2, es zeigt den Reiter „Password“ auf einem englischsprachigen System). Hier werden die Vorgaben für die Kennwortrichtlinien angegeben – darunter auch die Angabe, ob überhaupt ein Kennwort zum Einsatz kommen muss

Die meisten Organisationen, die den Mobilzugriff auf das Unternehmensnetzwerk zulassen, setzen sinnvollerweise voraus, dass ein Kennwort zum Einsatz kommen muss. Auch wenn das Eingeben eines Kennworts bei vielen Anwendern eher ungeliebt ist, so sollte man es aus Gründen der Sicherheit unbedingt verwenden. Dazu gibt es auf diesem Reiter die folgenden Einstellungen:

• Require password (Kennwort anfordern): Ist diese Checkbox aktiviert, setzt die EAS-Richtlinie durch, dass für dieses Gerät ein Kennwort angegeben werden muss. Ist diese Checkbox aber zurückgesetzt (also leer), dann ist keine der folgenden Optionen für das Kennwort aktiv. Setzt man dagegen sein Häkchen nur in dieser Checkbox und gibt man in den anderen Bereiche nichts mehr an, so möchte diese Richtlinie nur die Eingabe eine vierstelligen PIN haben.
• Require alphanumeric password (Alphanumerisches Kennwort anfordern): Möchte man nur Kennwörter im Einsatz haben, die nicht nur aus Zahlen bestehen, kann man diese Richtlinie aktivieren. Damit muss der Anwender außer zahlen irgendein anderes Zeichen oder Symbol in dem Kennwort verwenden. Der größte Nachteil dieser Variante: Wenn man auf seinem Gerät nur Zahlen eingeben muss, ist die Tastatur auf dem Gerät am einfachsten zu nutzen (sprich es muss nicht zu den Buchstaben umgeschaltet werden). Sind Schriftzeichen einzugeben, ist es für den Benutzer somit etwas schwieriger zu handhaben.
• Minimum number of character sets (Minimale Anzahl von Zeichensätzen): Diese Bezeichnung führt leider ein wenig in die Irre – es geht dabei eher um die Komplexität des Kennworts. Diese Richtlinie gibt vor, wie komplex das Kennwort sein muss und nutzt dazu die „Zeichensätze“. Darunter versteht das System Großbuchstaben, Kleinbuchstaben, Zahlen und Symbole – das wären dann vier „Zeichensätze“. Wird hier der Wert 2 eingegeben, dann muss der Anwender ein Kennwort wählen, das aus Zeichen von mindestens zwei dieser Zeichensätze besteht – also zum Beispiel Groß- und Kleinbuchstaben. Die Standardvorgabe lautet hier 1 – somit kann er Kennwörter ohne Einschränkungen nehmen und muss keine Komplexitätsvorgaben beachten.
• Enable password recovery (Kennwortwiederherstellung aktivieren): Ist diese Box angeklickt, können die Benutzer OWA (Outlook Web App) verwenden, um ein gerätespezifisches Wiederherstellungs-Kennwort zu ermitteln. Geben sie dann dieses Kennwort auf ihrem Mobilgerät ein, wird das zuvor gesperrte Gerät wieder entsperrt. Exchange-Administratoren sind allerdings auch in der Lage, mit Hilfe der EMC die Wiederherstellungskennwörter herauszubekommen. Windows Phone, Apple iOS und die meisten der Android-Clients unterstützen diese Einstellung allerdings nicht – leider. Denn das wäre eine nützliche Funktion.
• Require encryption on device (Verschlüsselung auf dem Gerät anfordern) und Require encryption on storage card (Verschlüsselung auf der Speicherkarte vorschreiben): Diese zwei Vorgaben für den Einsatz der Verschlüsselung geben vor, ob das Gerät die eigene Verschlüsselungsfunktion verwenden soll, um alle lokalen Daten zu verschlüsseln. Damit werden die lokalen Daten besser geschützt. Dabei handelt es sich um einen Bereich, in dem die Client-Software – vor allem die von Apple – so ihre Schwierigkeiten mit dem Verschlüsseln auf dem Gerät hatten. Doch mittlerweile scheinen alle großen Hersteller diese Richtlinie gut umsetzen zu können.
• Allow simple password (Einfaches Kennwort zulassen): Ist diese Checkbox aktiviert, kann man als Kennwort eine einfache, vierstelligen Zahl als PIN einsetzen.
• Number of failed attempts allowed (Anzahl zulässiger fehlerhafter Versuche): Im Active Directory (AD) kann man angeben, nach wie vielen fehlerhaften Anmeldeversuchen ein Konto gesperrt wird. Bei EAS gibt es sogar die Option, nach einer gewissen Anzahl von Fehlversuchen bei der Kennworteingabe, das Gerät komplett zu löschen.
• Minimum password length (minimale Kennwortlänge): Wie es die Bezeichnung schon vermuten last, kann man einen Wert für diese Option angeben. Er kann zwischen 4 und 18 Zeichen liegen.
• Time without user input before password must be re-entered (in minutes) (Zeitraum ohne Benutzereingabe, bis das Kennwort erneut eingegeben werden muss (in Minuten)): Diese Option legt fest, wie lange ein Mobilgerät untätig sein darf, bis der Benutzer es wieder mit einem Kennwort entsperren kann. Auf den meisten Clients kann es zu Konflikten kommen, etwa wenn man diesen Wert zunächst auf zehn Minuten setzt, und der Benutzer seinerseits die Sperre für das Gerät auf beispielsweise fünf Minuten setzt. In jedem Fall wird dann die „strengere“ Variante herangezogen.
• Password expiration (days) (Kennwortablauf (Tage)): Diese Einstellung gibt vor, wie lange das vom Benutzer gewählte Kennwort gültig bleibt, ehe er es wieder ändern muss. Diese Einstellung hat es in sich: Denn der normale Benutzer hasst es, gezwungenermaßen die PIN seines Geräts zu ändern. Daher kann sich eine allzu strenge Vorgabe auch wieder kontraproduktiv auswirken: Viele Benutzer schreiben ihre komplexen Kennwörter auf, vor allem wenn sie sie häufig wechseln müssen – und das ergibt wieder eine Sicherheitslücke.
• Enforce password history (Kennwortverlauf erzwingen): Damit kann man es den Benutzern unmöglich machen, dass sie frühere Kennwörter erneut verwenden. Da es aber keine Möglichkeit gibt, dass ein Kennwort für ein Gerät zeitlich abläuft (wie das bei den Kennwörtern im AD der Fall ist), hilft einem diese Option nicht sonderlich.

Der Reiter Synchronisierungseinstellungen (Sync Settings)

Im Bereich des Reiters zu den Synchronisierungseinstellungen (siehe Bild 3) wird vorgegeben, was das betreffende Gerät ausführen darf, wenn es zu einer Synchronisation kommt. Dabei lässt sich vorgeben, wie viele Tage an Kalendereinträgen und Mails mit dem Gerät synchronisiert werden dürfen. Allerdings besitzen die meisten Geräte bessere Kontrollmöglichkeiten für das Auswählen, wie viel Mails synchronisiert werden sollen und aus welchen Ordnern.

Die beiden interessantesten Optionen auf diesem Reiter gehört zum einen „Allow Direct Push when roaming“ (Direct Push beim Roaming zulassen). Damit lässt sich vorgeben, ob Geräte, die nicht mit ihrem normalen Mobilfunknetzwerk verbunden sind, die Funktionalität des „Push Email“ verwenden dürfen. Zum anderen ist noch „Allow attachments to be downloaded to device" (Das Herunterladen von Anlagen auf das Gerät zulassen) zu nennen, mit dem man Benutzern das Herunterladen von womöglich sensiblen Anhängen verbieten kann.

Der Reiter für die Geräte (Devices)

Die Hardware der Mobilgeräte hat in den letzten Jahren vielfältige Neuerungen erfahren. Selbst die Billiggeräte besitzen eine hochauflösende Kamera, Audio-Streaming via Bluetooth und andere Funktionalitäten, die früher dem absoluten High-end vorbehalten waren. Doch nicht jedes Unternehmen möchte, dass sämtliche Features für die Benutzer verfügbar sind.

Einige Organisationen, wie etwa die amerikanische Bundesregierung, lösen das Problem, indem sie nur derartige Geräte kaufen, die die unerwünschten Funktionen gar nicht besitzen. Daher kann man auch ein modernes Smartphone kaufen, bei dem die Kamera entfernt wurde. Aber im Regelfall gibt die entsprechende Organisation den Anwendern vor, bestimmte Dinge nicht zu tun – wie etwa Mobiltelefone nicht mit in ein Labor zu nehmen. Der andere Ansatz lautet, dass die Unternehmen technische Vorkehrungen ergreifen, um die unerwünschten Aktionen blockieren zu können.

Mit den Optionen auf dem Reiter zu den Geräten (siehe Bild 4) kann man den letztgenannten Weg einschlagen. Im Rahmen von EAS gibt es Richtlinien, die bestimmte Gerätefunktionen blockieren – aber nur wenn das Gerät diese Richtlinien auch unterstützt.

Viele Mobilgeräte machen das allerdings nicht – entweder weil die Richtlinieneinstellung keinen Sinn macht (wie etwa das Erlauben von Infrarot-Einstellungen bei iOS-Geräten, die über keine Infrarot-Ports verfügen), oder weil sich der EAS-Client-Hersteller sich nicht darum gekümmert hat, die betreffenden Einstellungen zu unterstützen. Daher sollte man sich genau informieren, wenn man diese Einstellungen im Zuge seiner Sicherheitsvorgaben für Mobilgeräte zum Einsatz kommen lassen will.

Die zwei verbleibenden Reiter

Device Applications und die „Anderen“ sind in gewisser Weise verkümmert. Microsoft hat sie vor allem eingeführt, um ein Grundgerüst zu bieten. Damit sollen Richtlinien regulieren, welche Applikationen auf den verwalteten Mobilgeräten laufen dürfen.

Allerdings unterstützen keine Clients – Stand heute – dieses EAS-Feature. Unternehmen möchten aktiv verwalten und kontrollieren, welche Apps die Benutzer verwenden können. Dazu kauft man heutzutage eigene Lösungen im Bereich des MDM (Mobile Device Management). Daher gibt es so gut wie keinen Bedarf für eine umfassende Unterstützung dieser EAS-Funktionalität.

EAS und Remote Wipe

Wird ein Mobilgerät gestohlen oder geht es verloren, so erweist sich das „Fernlöschen“ des Geräte (auch als „Remote Wipe“ bezeichnet) als eine wichtige Sicherheitsfunktionalität. Allerdings setzt das voraus, dass man es in Kauf nimmt, dass das komplette Gerät und nicht nur die Daten, die zum Unternehmen gehören, gelöscht werden.

Es gibt zwei Möglichkeiten, um ein Remote Wipe auszuführen. Der Benutzer kann es über das ECP auslösen oder der Administrator macht es in der EMC. In beiden Fällen wird vorausgesetzt, dass das Gerät das betreffende Kommando auch übermittelt bekommt. Das bedeutet, dass das Remote Wipe erst dann eintritt, wenn das Gerät das nächste Mal „aufwacht“ und sich mit dem Server synchronisieren will.

Sollte ein verlorenes Gerät entladen sein, dann kann das Remote Wipe auch erst anlaufen, wenn es wieder geladen ist. Das Gerät sollte dem Benutzer keine Möglichkeit geben, die Löschaktion zu unterbinden. Exchange kann zwar anzeigen, dass das Fernlöschen angefordert wurde, doch es wird nur dann eine Bestätigung zurück gemeldet bekommen, wenn das Gerät diese Information zurück liefert.

Paul Robichaux