ActiveSync Quarantäne

Seit Exchange 2010 gibt es schon die Quarantäne für ActiveSync und seit SP1 gibt es sogar die Steuerung über das Exchange Control Panel (ECP). Trotzdem scheinen die meisten Administratoren diesen neuen Weg der Clientidentifizierung noch gar nicht zu können oder scheuen die Umsetzung.

Hintergründe

"Plug and Play" und "Bring your own device" sind Schlagworte, die auch dem Exchange Administrator geläufig sind. Um die Anzahl der Hindernisse klein zu halten, erlaubt ein Exchange Server per Default erst mal, dass jeder Benutzer mit einem beliebigen ActiveSync-tauglichen Endgerät sich an sein Postfach zu verbinden. Es gibt nur eine Obergrenze von maximal 10 Geräten pro Benutzer. Zudem schreibt die per Default vorhandene ActiveSync Richtlinie weder eine Sperrung nach Inaktivität noch eine PIN auf dem Gerät vor. Ein Administrator muss es also nur erreichen, dass auf dem Exchange Server ein Zertifikat installiert wird und der Server über Port 443 aus dem Internet erreichbar ist. Eine solche "Veröffentlichung" kann mittlerweile jeder DSL-Router. Sicher ist das aber alles nicht.

Schon seit Exchange 2003 kann eine Firme über die ActiveSync Policies bestimmte Einstellungen auf dem Client durchsetzen. Am wichtigsten sind hierbei die Forderungen nach einem Kennwort und einer automatischen Sperre auf jedem Gerät. Aber damit wird noch nicht kontrolliert, welches Gerät genutzt werden kann. Denn nicht alle Geräte unterstützen alle Richtlinien viele Firmen beschränken die Geräte auf bestimmte Familien oder Typen, um Support und Testfeldprüfungen zu beschränken.

Exchange Version ActiveSync Policies DeviceBlock/Allowlist Quarantäne

2003

Eine globale Richtlinie

Nein

Nein

2007

Eine pro Anwender

Ja

Nein

2010

Eine pro Anwender

Ja

Ja

2013

Eine pro Anwender

Ja

Ja

2016

Eine pro Anwender

Ja

Ja

Exchange 2003 konnte gar keine Endgeräte filtern oder limitieren. Erst Exchange 2007 ist zumindest imstande über eine DeviceID pro Benutzer Geräte zu sperren oder zuzulassen. Das ist aber auch nicht sonderlich effektiv, weil die Firma beim Benutzer per PowerShell die DeviceID eintragen musste. Um den Default abzuschalten, musste man z.B. die CAS-Mailbox erst für ActiveSync sperren und nach Eintragung einer DeviceID wieder zulassen.

Einsatz der Quarantäne

Mit der Exchange 2010 Quarantäne kann der Server angewiesen werden, Geräte, die weder auf einer Systemausnahmeliste noch einer Benutzerausnahmeliste stehen, erst mal in einer Quarantäne liegen. Exchange sendet eine Informationsnachricht an konfigurierte Empfänger und an die Person, die das Mobilgerät mit ihrem Postfach verbinden will.

Nun liegt es am Betreiber auf diese Mail zu reagieren und das Gerät nach einer Prüfung zuzulassen. Das Gerät bekommt in der Zwischenzeit schon die ActiveSync Policies und kann sogar lokale Elemente in den Postfachspeicher hochladen. Aber Exchange erlaubt keinen Abgleich zum Gerät hin.

Quarantäne einschalten

Standardmäßig ist die Quarantäne nicht aktiv. Sie kann über die Optionen im Exchange Control Panel aktiviert werden.

In der Exchange Management Console gibt es kein Gegenstück. Aber natürlich kann auch die PowerShell dazu genutzt werden.

#Quarantäne einschalten
Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Quarantine -AdminMailRecipients={eas@netatwork.de}}

# Quarantäne ausschalten
Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Allow

Die Quarantäne wird immer global aktiviert. Allerdings können Sie im zweiten Schritt weiter unten auf der Seite über ein Regelwerk bestimmte Geräte oder Typen per Default "zulassen".

Sie können auch Benutzer entsprechend mit Ausnahmen versehen.

Events und Meldungen

Wenn ein Gerät nun sich erstmalig verbindet und nicht durch eine gerätespezifische Allow/Block-Regel schon abgedeckt wird, dann landet es in der Quarantäne. Exchange sendet an die angegebenen Benutzer eine entsprechende "Mail".

Zudem landet natürlich eine Warnung im Eventlog, die auch überwacht werden kann.

Log Name:      Application
Source:        MSExchange ActiveSync
Event ID:      1021
Task Category: Requests
Level:         Warning
Keywords:      Classic User:          N/A
Computer:      srv01.msxfaq.net
Description:
A non-compliant phone is trying to connect with Exchange 
ActiveSync. However, the Exchange ActiveSync mailbox policy für User [User1@msxfaq.net] and device ID [1232212] requires 
phones to be compliant before they synchronize with Exchange ActiveSync.

Diese Informationsnachrichten werden von einem Systemobjekt versendet, welches in der Configuration-Partition liegt.

objclass: CN=ms-Exch-Exchange-Server-Recipient,CN=Schema,CN=Configuration,DC=msxfaq,DC=net
Mail:MicrosoftExchangeae1329e881c36ab6ce09e471ec615bb4@msxfaq.net
msExchHideFromAddressLists:True
Displayname: Microsoft Outlook

Das Objekt hat aber weder eine Weiterleitung (AlternateRecipient) noch eine TargetAddress und auch kein Postfach (Kein HomeMDB). Wenn also jemand auf diese Mail antworten sollte, dann verschwindet sie einfach. Sollten Sie diese Mail daher benötigen, dann wäre z.B. eine Transportregel, um die Mails umzuleiten.

Speicherort der Quarantäne

Natürlich bin ich neugierig, wo Exchange diese "Quarantäne" wohl abspeichert. Ich habe daher mit aktivierter Quarantäne einfach ein Gerät zugelassen und im Exchange Management Eventlog nachgeschaut und wurde fündig:

Log Name:      MSExchange Management
Source:        MSExchange CmdletLogs
Event ID:      1
Task Category: General
Level:         Information
Keywords:      Classic
Description:
Cmdlet succeeded. Cmdlet Set-CASMailbox, parameters {Identity=Carius, Frank, '
ActiveSyncAllowedDeviceIDs={Applxxxxxxx}}.

Wenn ich also ein Gerät über das Exchange Control Panel zulasse, dann wird im Hintergrund ein "SET-CASMAILBOX ausgeführt. Also mit Get-CASMAILBOX einfach mal nachgeschaut und hier sieht man schön bei einem Vorher/Nachher-Vergleich, dass Exchange die Information über zugelassene Geräte am Benutzer hinterlegt.

# vorher
[PS] C:\ >Get-CASMailbox fcarius  | fl name,*device*
Name                           : Carius, Frank
ActiveSyncAllowedDeviceIDs     : {}
ActiveSyncBlockedDeviceIDs     : {}
HasActiveSyncDevicePartnership : True

#Nachher
[PS] C:\ >Get-CASMailbox fcarius  | fl name,*device*
Name                           : Carius, Frank
ActiveSyncAllowedDeviceIDs     : {Applxxxxxxx}
ActiveSyncBlockedDeviceIDs     : {}
HasActiveSyncDevicePartnership : True

Dann liegt der Verdacht natürlich nahe, dass ein "Get-ActiveSyncDevice" einen sinnvolle Liste liefert. Und dem ist auch so:

[PS] C:\ >Get-ActiveSyncDevice | ft DeviceID,DeviceIMEI,DeviceAccessState

DeviceID   DeviceImei    DeviceAccessState
--------   ----------    -----------------
Device1    123456781     Allowed
Device1    123456782     Blocked
Device1    123456783     Quarantined

Es gibt also keinen besonderen Bereich, sondern das Gerät wird direkt an den Benutzer "angebunden", der das Gerät versucht hat, einzurichten. Die Konfiguration ist ein Container unter dem Benutzer und kann per PowerShell aber auch per LDAP einfach ermittelt werden:

(&(objectclass=msexchactivesyncdevice)(msexchdeviceaccessstate=3))

1 = Allowed
2 = Blocked
3 = Quarantined

Eleganter ist natürlich in einer Exchange-Welt direkt die PowerShellabfrage mit einem serverbasierten Filter.

Get-ActiveSyncDevice -filter {deviceaccessstate -eq 'quarantined'}

Management - Aktiv entfernen

Neben den Regel können Sie natürlich auch pro Mailbox einzelne Partnerschaften zulassen oder blockieren. Das geht über das Exchange Control Panel aber auch per PowerShell. Relevant sind dazu die Einträge "ActiveSyncAllowedDeviceIDs" und "ActiveSyncBlockedDeviceIDs" bei der Mailbox:

Get-CASMailbox | ft Identity,ActiveSyncAllowedDeviceIDs,ActiveSyncBlockedDeviceIDs

Mit Set-CASMailbox können Sie die Werte auch setzen. Denken Sie daran, dass sie immer eine Liste übergeben oder erweitern, da ansonsten die bestehenden Partnerschaften entfernt würden. Wenn ein Gerät neu aufgesetzt wird und die DeviceID identisch bleibt, dann ist das Gerät automatisch wieder freigegeben. Also muss man das Gerät explizit für den Benutzer blocken oder die entsprechende Device ID bei der CAS Mailbox aus der Liste "ActiveSyncAllowedDeviceIDs" entfernen.

Set-CASMailbox `
   -Identity $easUser.identity `
   -ActiveSyncAllowedDeviceIDs $devicelist

Migration

Interessant ist bei dem Einsatz der Quarantäne auch die Migration von Exchange 2003/2007 nach Exchange 2010. Einige Dinge sollte man dazu wissen:

  • Exchange 2010 CAS Server können für ActiveSync als ReverseProxy auch Exchange 2007/2003 Postfächer bedienen
    (Siehe CASProxy 2010)
  • Nur Exchange 2010 Postfächer können die Quarantäne nutzen
    D.h. Benutzer auf Exchange 2007/2003 unterliegen nicht der Quarantäne, auch wenn Sie einen Exchange 2010 CAS nutzen. Das ist auch sinnvoll, schließlich könnte man ja auch immer noch einen Exchange 2003/2007 CAS-Server nutzen, der die Einstellungen nicht versteht.
  • 7 Tage "Grace Period" für bestehende Partnerschaften
    Hat ein Anwender unter Exchange 2007 schon eine Partnerschaft, dann wird durch die Migration nach Exchange 2010  werden mitgenommen. Wird ein Benutzer auf Exchange 2010 verschoben, dann werden Geräte die sich innerhalb von 7 Tage verbinden automatisch "Approved". Danach greifen wieder die Regeln der Quarantäne

When a mobile device is in the mailbox upgrade access state, it's granted full access to the User's mailbox. The mailbox upgrade access state is the same as the allowed state, except that it lasts no more than seven days from the first time the device connects to an Exchange 2010 server after a mailbox move from an earlier version of Microsoft Exchange. This state is necessary to give mobile devices time to correctly upgrade their information and communication protocols to the latest Exchange ActiveSync version and be recognized by the device access management system. As soon as a mobile device is recognized, Exchange applies the appropriate access based on the Exchange 2010 configuration
Quelle: http://technet.microsoft.com/en-us/library/ff959225.aspx#determining it says

Nachträgliche Aktivierung der Quarantäne mit Approve-EASDevice.PS1

Dieses kleine PowerShell-Skript unterstützt die Migration einer Exchange ActiveSync Umgebung von einer Konfiguration ohne Quarantäne zur Quarantäne. Sobald Sie nämlich die Quarantäne einschalten, werden alle Geräte erst mal ausgesperrt und sind durch die zuständige Person erst frei zu schalten. Das ist natürlich kein Problem bei einem neuen Rollout mit von Anfang an aktivierter Quarantäne. Wer bereits Exchange 2010 installiert hat und nachträglich die Quarantäne einschalten will, wird vielleicht alle Bestandsgeräte gerne zulassen. Das ist die Aufgabe von "Approve-EASDevice.ps1.

Das Script wird von einem privilegierten Exchange Admin auf der Exchange PowerShell aufgerufen. Optional kann eine Mailbox übergeben werden. Ansonsten liest das Skript alle Postfächer aus, die im Forest vorhanden sind.

approve-easdevice.1.0.ps1

Das Skript arbeitet erst mal "ReadOnly". Erst durch Angabe des Parameters "Write" schreibt es tatsächlich die aktuell vorhandenen Partnerschaften als "AllowedDevices" an die Mailbox. Bestehende Einträge werden dabei überschrieben.

Delegierung der Verwaltung

Normalweise muss derjenige, der solche Geräte aus der Quarantäne entsperrt in den Gruppen “Organization Management” und “ Server Management“ sein (vergleiche „Client Access Permissions” auf http://technet.microsoft.com/en-US/library/dd638131.aspx). Das mag in kleinen Firmen mit einem Admin in Personalunion noch möglich sein, aber größere Firmen werden diese Rolle gerne delegieren wollen.

Als Administrator muss man sich nun entscheiden, ob man gemäß RBAC eine komplette Struktur aus RoleGroup, ManagementRole, ManagementRoleEntry und ManagementRoleAssignment aufbauen will, oder ob man vielleicht schon auf bestehende Elemente zurückgreifen kann, die das Exchange Setup bereits vorbereitet hat. Gerade die Nutzung von Standardrollen hat den Vorteil, dass zukünftige Updates von Microsoft diese Rollen eventuell Ausbauen und auf aktuelle Exchange Versionen anpassen. Mit eigenen Objekten müssen Sie bei Updates in der Regel nacharbeiten.

Aus dem vorherigen Abschnitt wissen wir, dass "Set-CASMailbox" das Schlüssel-Commandlet ist. Über folgenden Befehl kann man einfach prüfen, ob es vielleicht schon einen passenden RoleEntry gibt.

[PS] C:\>Get-ManagementRoleEntry  "*\set-cas*" | where {$_.parameters -like "*deviceid*"} | `
   fl name,role,parameters

Name       : Set-CASMailbox
Role       : Organization Client Access
Parameters : {ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs, Confirm, Debug, `
DomainController, ErrorAction, ErrorVariable, Identity, OutBuffer, OutVariable, Verbose, '
WarningAction, WarningVariable, WhatIf}

Und tatsächlich gibt es mit dem RoleEntry "Organization Client Access" bereits einen perfekt passenden Eintrag, der von Microsoft auch dokumentiert ist.

Ich habe natürlich versucht nun schnell eine RoleGroup für diesen RoleEntry anzulegen. Aber damit allein konnte ich mich an ECP nicht anmelden. Es fehlen also noch ein paar PowerShell-Befehle um zu arbeiten. Statt lange zu suchen habe ich den Helpdesk-Benutzer einfach in die gruppe "Help Desk" aufgenommen. Damit konnte ich dann wunderbar arbeiten.

Dabei habe ich es dann auch belassen. Diese vordefinierte Gruppe ist für Mitarbeiter des Help Desk wie geschaffen und ich empfehle diese auch zu nutzen. Ich würde die Gruppe aber nicht anpassen, um spätere Updates nicht zu erschweren. Vielleicht möchten Sie ja auch zwischen "Helpdesk" und "Helpdesk mit ActiveSyncManagementRecht" unterscheiden. Daher rate ich zu einer neuen RoleGroup, die zum einen den RoleEntry verbindet und zusätzlich in "Help Desk" Mitglied ist. Dann können Mitarbeiter die nur in "Help Desk" sind, keine ActiveSync-Geräte entsperren während die privilegierteren Benutzer ausreichende Rechte haben.

# Scope auf den Forest einstellen
Set-ADServerSettings -ViewEntireForest:$true

# Neue Exchange Management Gruppen anlegen
New-Rolegroup `
   -name "MSXFAQ EASManagement" `
   -Description "Allow management of ActiveSync Devices in Quarantine"

# Role "Organization Client Access" an die Gruppe zuweisen
New-ManagementRoleAssignment `
   -Name "MSXFAQ EASManagement" `
   -SecurityGroup "MSXFAQ EASManagement" `
   -Role "Organization Client Access"

# Gruppe "MSXFAQ EASManagement" in Helpdesk aufnehmen
Get-RoleGroup "Help Desk" `
| add-rolegroupmember `
     -member "MSXFAQ EASManagement"

# "Helpdesk"-Benutzer in " MSXFAQ EASManagement " aufnehmen
Get-RoleGroup "MSXFAQ EASManagement" `
| add-rolegroupmember `
     -member "msxfaq\helpdesk1"

Ich habe nicht geschrieben, dass dies der einzige und richtige Weg zur Delegierung von Berechtigungen ist. RBAC ist sehr flexibel in der Erstellung von Berechtigungen, so dass Sie eine für ihr Umfeld passenden Struktur entwerfen sollten.

Clear-ActiveSyncDevice

Wenn wir schon beim Delegieren von Berechtigungen sind, dann fehlt natürlich noch die Berechtigung, dass der Helpdesk auch Geräte "löschen" kann. Ein kurzer Blick in die verschiedenen RoleEntries offenbart folgendes:

[PS] C:\>Get-ManagementRoleEntry "*\clear-*"
 
Name                           Role                      Parameters
----                           ----                      ----------
Clear-ActiveSyncDevice         Mail Recipients           {Cancel, ...
Clear-ActiveSyncDevice         User Options              {Cancel, ...
Clear-ActiveSyncDevice         MyBaseOptions             {Cancel, ...
Clear-TextMessagingAccount     MyTextMessaging           {Confirm, ...

Die beiden ersten Einträge sind für administrative Verwendung während die mit "my" beginnenden Einträge für die Selbstverwaltung verwendet werden. Schaut man nun sich z.B.: die Zuweisung von "User Options" an, dann erkennen Sie, dass "Help Desk" bereits dieses Recht hat.

[PS] C:\>Get-ManagementRoleAssignment -Role "User options" | ft name,roleassigneeNa*
 
Name                                                        RoleAssigneeName
----                                                        ---------------- 
User Options-Organization Management-Delegating             Organization Management 
User Options-Organization Management                        Organization Management 
User Options-Help Desk                                      Help Desk

Insofern benötigen Sie keine weiteren Rechte außer "Helpdesk" um gestohlene oder verlorene Endgeräte aus der Ferne zu löschen.

Weitere Links