_______________________________
In This Chapter
- Mobile Device Policies
- Managing Devices
- Getting Devices for a Mailbox
- Device Wipe
- Reporting
_______________________________
Since the introduction of Exchange ActiveSync (EAS) in Exchange 2003 SP1, it has seen adoption over the years leading up to the current status that practically every mobile device has EAS capabilities.
There have been improvements every major build of Exchange Server, not just features but also in regards to access complacency and security. Regarding management, the adoption of PowerShell has been a welcome improvement, making admin control a lot easier than before.
To recap the whole process: A user has a device and a mailbox in Exchange Online. The user wants to access their mailbox from that device and it has EAS capabilities. The user enters his or hers email address and their corresponding password. In a lot of cases the connection is successful and a pop-up appears warning you about security policies that have to be implemented. After accepting the user can now access mail, calendar, contacts and sometime additional features like Tasks or setting the Out of Office reply.
There are variants when used with conditional access from Office 365 Mobile Device Management (MDM)/Intune or other MDM solutions or when certificate based authentication is required.
In the background, a device partnership has been made between the users’ mailbox and the device, which is manageable (locking, remote wiping, etc.) belonging to the users and admin’s capabilities. What is available depends on device capabilities and support.
In this chapter, we will go through device access, device policies, managing devices and some reporting. It’s important to note that as with Exchange Online, some cmdlets have been renamed from ActiveSync to MobileDevice, as the focus for Microsoft seems to be the Outlook app on iOS and Android and Outlook Mail app on Windows 10, which relies on the REST API for its connection to Office 365:
https://technet.microsoft.com/en-us/library/mt465746(v=exchg.150).aspx
The most important thing regarding Mobile Device Policies are the specific policies that define what features are available (such as Camera, downloads from the Store, etc.) and the level of security (password policy, remote wipe options). This is configured in the Mobile Device Mailbox Policy, which is assigned to mailboxes. You can have multiple policies which can be assigned to different mailboxes. However, an assigned Mobile Device Mailbox policy will be valid for all devices that have a device partnership with that specific account; you cannot have a different policy on the same mailbox for different devices.
Managing Mobile Device Mailbox Policies
The basis of controlling devices with Exchange is the Mobile Device Mailbox policy, previously known as the Exchange ActiveSync (EAS) Mailbox policy. The policy defines specific security settings the device might have to support and implement, and the user has to accept them in order to gain access to their mailbox.
You can have multiple policies in your organization, to cater different security policies. But a user (or mailbox) can only have one policy applied, which is valid for all devices connected to the mailbox.
For those who are wondering about users that have multiple mailboxes configured on their device: the policies are applied cumulative with the most restrictive setting being applied over less restrictive settings or undefined settings.
Listing
To get a listing of current Mobile Device mailbox policies you use:
Get-MobileDeviceMailboxPolicy
You would see at least the Default policy and its values in raw output:
** Note ** The cmdlet Get-ActiveSyncMailboxPolicy does the same as Get-MobileDeviceMailboxPolicy, but is deprecated and will be removed sometime in the future.
You can create additional Mobile Device policies via:
New-MobileDeviceMailboxPolicy -Name "VIP"
Without any parameters configured a default configuration will be used. You can add values at creation or adjust values after creating the policy. Example:
Set-MobileDeviceMailboxPolicy -Identity "VIP" -DeviceEncryptionEnabled $True
This will require Device Encryption on our previously created policy.
If a policy isn’t required anymore, you can remove it:
Remove-MobileDeviceMailboxPolicy -Identity "VIP"
Be sure that the policy isn’t assigned to any mailbox or are assigned to another policy, otherwise the mailboxes will revert to the Default policy. You can define the default Mobile Device mailbox policy in the policy itself (only one can be the default, obviously):
Set-MobileDeviceMailboxPolicy -Identity "VIP" -IsDefault $True
Assigning the MobileDevice Mailbox policy is done via Set-CASMailbox:
Set-CASMailbox [email protected] -ActiveSyncMailboxPolicy "VIP"
And if required you can assign a specific policy to all mailboxes, however you could just use the Default policy. It’s probably more common to have most mailboxes use the default policy and assign specific policy to specific users. One way is to use groups to determine who would require a certain policy:
(Get-Group -Identity "VIP").Members | Set-CASMailbox -ActiveSyncMailboxPolicy "VIP"
Now, this is just one possible way but it should give you an idea how to use and assign multiple Mobile Device Mailbox Policies.
** Note ** The cmdlets New-ActiveSyncMailboxPolicy, Set-ActiveSyncMailboxPolicy, Remove-ActiveSyncMailboxPolicy are the same as respectivly New-MobileDeviceMailboxPolicy, Set-MobileDeviceMailboxPolicy, Remove-MobileDeviceMailboxPolicy but are deprecated and will be removed in the future.
It depends on your organization and your stance on types of supported devices (non-managed or highly managed with conditional access), but most organizations agree on basic security with the below items:
Allow Non-Provisionable Devices
Allows devices to synchronize, even if it’s clear that they cannot apply certain policies; for instance Device Encryption. This is basically the "Best Effort" setting; if the device supports a set feature, it has to enable it. If the device does not support a feature, it will still be allowed to sync despite possible lower security. Disable (default) when you want to have a strict adherence to the device policy. But to enable it use:
Set-MobileDeviceMailboxPolicy -Identity Default -AllowNonProvisionableDevices $True
Required Password
With this setting a password is required. This means a user has to input a password or PIN at boot time and to unlock the device. In this way, access to company data can be protected. There are different choices to be made, a numeric PIN or alphanumeric password.
Set-MobileDeviceMailboxPolicy -Identity Default -PasswordEnabled:$True
You can set the minimal amount of characters required for the PIN:
Set-MobileDeviceMailboxPolicy -Identity Default -MinPasswordLength 4
In this case the PIN has a minimum of four numbers. You can have a forced minimum password length with a maximum of 16 (so passwords need to be at least sixteen, if so configured). However, four or six are common.
What about fingerprint access? This feature is dependent on the device OS as to how that is handled. In iOS you are required to enter the PIN the first time at start up and then fingerprint authentication via TouchID is possible. With Android, it’s very dependent on how it’s implemented, however a lot of pattern locks weren’t possible when requiring a PIN. Consider this when configuring this setting.
You can force an alphanumeric password, such as on Desktops.
Set-MobileDeviceMailboxPolicy -Identity Default -AlphanumericPasswordRequired:$True
If enabled, you can set the amount of complex characters, ranging from one to four.
Set-MobileDeviceMailboxPolicy -Identity Default -MinPasswordComplexCharacters 4
Where MinPasswordComplexCharacters can be one of the following values:
- Digits only
- Digits and lower case letters
- Digits, lower case letters, and upper case letters
- Digits, lower case letters, upper case letters, and special characters
However, on most mobiles a value of four is not very user friendly and it’s not very common, but due to more combinations and complexity of these kinds of passwords it does provide extra security. But you won’t make many friends with those kind of requirements (unless you’ll only allow devices with a physical or large on-screen keyboard).
Other ways to increase password security, is to limit the reuse of old passwords:
Set-MobileDeviceMailboxPolicy -Identity Default -PasswordHistory 2
With two in this example the previous two passwords are remembered and blocked from being reused and with zero no passwords are remembered. Determining an ideal number is dependent on how often the device password has to change. You can control that by adding a password age limit:
Set-MobileDeviceMailboxPolicy -Identity Default -PasswordExpiration ’90.00:00:00’
The value syntax is DD.HH:MM:SS, or days, hours, minutes and seconds.
As with Outlook clients, you will need to find a balance between usability and security.
Encrypted Device and Memory Card
These settings will make encryption mandatory for the device itself. Nowadays most modern mobile OS have device encryption enabled per default, but if it is not it might require the device to perform a reboot and additional configuration time. However, this will mean that the complete device is encrypted, which means any sensitive company data is secure from malicious attempts to access this when locked.
Set-MobileDeviceMailboxPolicy -Identity Default -RequireDeviceEncryption:$True
Some devices offer to extend the storage capacity via memory cards. Some OS's allow applications and their data to be moved to the memory card or data from within the app is stored on the card. When the card is not encrypted, that data is readable for anyone that has access to the card. For instance, when the device is stolen or lost. An encrypted card will prevent unintentional data leaks. However, some devices require the card to be formatted when encryption was not set initially. This could mean data loss. Warn your users when enabling this option, which you can in this way:
Set-MobileDeviceMailboxPolicy -Identity Default -RequireStorageCardEncryption:$True
Lock Device After x Minutes
Same idea with automatic locks on desktop computers, requiring users to authenticate in order to continue their session. Adds security when the device is (temporarily) left unattended or lost, narrowing the window the device and its data is accessible. With mobile devices, often a PIN is allowed for easily accessing the device. Some apps lock only the access to the app with a PIN, while most lock the whole device.
Set-MobileDeviceMailboxPolicy -Identity "VIP" -MaxInactivityTimeLock '00:15:00'
This example will lock the device after fifteen minutes of inactivity. In most cases this value is the same as the desktop lock policy, which makes sense as users are already use to those kinds of mechanism and makes explaining somewhat easier.
Wipe Device After x Failed Attempts
To prevent hammering and brute force attempts by just guessing the password and trying endlessly, this policy adds a self-destruct mechanism to the device or data in the app (depending on various mobile OS and other parameters).
Set-MobileDeviceMailboxPolicy -Identity "VIP" -MaxPasswordFailedAttempts 8
In this example the device will be wiped after eight failed attempts to access the contents of the device by trying to guess the password, this is an anti-hammering feature which can be useful when devices end up in the wrong hands. It does not require a connection to Exchange, so this will work even when the device has no Internet connection. This also means that an admin cannot override it remotely. The valid range is four to sixteen attempts.
Be sure that users are informed about this feature and its consequences when configured. Especially if the device is not company owned, it will surely contain personal data (like photos) which will most likely also be wiped. I’ve had cases that devices were wiped because their young children got hold of their device and pushed the screen buttons over and over, accidentally activating this feature.
Disable Camera etc.
Additional options are to disable certain hardware features of the device, such as Bluetooth, the camera or other requirements. Do note that these (and some other settings) require the use of an Exchange Enterprise Client Access License in addition to the Exchange Standard Client Access License.
This example would disable the camera (if present) on the device:
Set-MobileDeviceMailboxPolicy -Identity Default -AllowCamera:$False
In some cases, it even makes camera apps unavailable (for sure in iOS).
There are a lot more configurations possible, it depends on your requirements and the capabilities of the devices you require to adhere to these policies. Be sure to test these policies out with test devices before deploying to your users.
One of the improvements introduced in Exchange Server 2010 is Device Access Rules, sometimes referred to as ABQ which stands for Allow, Block or Quarantine.
This way it’s possible to either block or quarantine specific types of devices. Perhaps a specific DeviceOS has issues (which has happened in the past with iOS 6.x for instance) or you want to limit access to devices that are supported by your organization.
With Block, devices are permanently prohibited access to Exchange; you’d have to resolve the limitation (for instance DeviceOS version due to an update) and remove the blocked partnership and try again. As with Quarantine the partnership does not have to be removed from the mailbox, just the blocking issue has to be resolved (for instance updating the device OS to a supported version).
You can add a block with New-ActiveSyncDeviceAccessRule:
New-ActiveSyncDeviceAccessRule -QueryString "iOS 9.0.2 13A452" -Characteristic DeviceOS -AccessLevel Quarantine
As you can see, there are several parameters involved. Starting at the back is the AccessLevel; in this example the access rule will set the access level to Quarantine, other options are Allow or Block. This means that when the blocking issue has been resolved, the user can connect again without removing the partnership, resulting in a sort of temporary ban. For instance, if your organization doesn’t support a certain Device OS version because of known bugs (iOS has had some in the past), you should use this option.
The Characteristic parameter can be used to configure the specific device identifier which has to be handled by the Access rule, valid values are DeviceModel, DeviceType, DeviceOS, UserAgent and XMWSLHeader. Those values can be extracted from Exchange when those devices already have made successful partnership with the Exchange mailbox, use:
Get-MobileDevice | Format-List DeviceOS, DeviceModel, DeviceType, DeviceUserAgent
Which will result in something like this:
DeviceOS is the actual OS version and build, DeviceModel the specific model, DeviceType the major type (Android, iPad, iPhone, etc.) and finally DeviceUserAgent. DeviceUserAgent is the same as UserAgent. The XMWSLHeader is a new characteristic and its values aren’t found in Exchange. However, most of the times DeviceOS is used with ABQ. Alternatively, you could get (some) device information via Get-MobileDevice:
Get-MobileDevice | Ft DeviceType,DeviceModel
Which provides this kind of output:
Removing a device class is possible, this can be required if you want a lean list. This could be the case because you now require limited access to only a specific set of devices after allowing all device classes.
Remove-MobileDevice -Type 'UniversalOutlook'
Another option available is to change the default ActiveSync behavior with Set-ActiveSyncOrganizationSettings. You can set the default DefaultAccessLevel to Allow, Block or Quarantine. The default is Allow, setting it to Quarantine is probably the next user friendly setting. You can enable email requests via the multi valued property AdminMailRecipients, and add extra clarification in the email message users get when their devices are blocked/quarantined with OtaNotificationMailInsert (when a device update is required) and UserMailInsert (to add additional information in the notification mail).
As you can see in the above example the DeviceOS and DeviceUserAgent are version dependent. This means that you might have to add an additional rule if the DeviceOS changes. Therefore, you could focus on DeviceType if you want to regulate the different types of devices (no Windows Phone, just iPhones or something like this). However, you will probably already see some of the caveats of ABQ, if so you might want to invest in real MDM solutions.
** Note ** The cmdlet Get-ActiveSyncDevice does the same as Get-MobileDevice, but is being deprecated and will eventually be removed from Exchange Online.
In order to check whether there is already a Device Access Rule in place, use:
Get-ActiveSyncDeviceAccessRule
This would give you output like this (if there is a rule present):
In this case the access rule will Quarantine certain iPhone models.
When there is no requirement for the Device Access Rule anymore, you can remove it via:
Remove-ActiveSyncDeviceAccessRule -Identity "iPhone5C2 (DeviceModel)"
Or when the requirements change, you can change the AccessLevel to another value.
Set-ActiveSyncDeviceAccessRule -Identity "iPhone5C2 (DeviceModel)" -AccessLevel "Allow"
However, after changing this AccessLevel parameter, you might have to manually check whether all devices are now adhering to the new access level.
But what if you only want to allow one specific device (because it’s company owned) and block every other device? Even with multiple device access rules you cannot be certain only the specific devices have access to your Exchange organization.
Luckily you can set a default access level for mobile devices. To see the current configuration use:
Get-ActiveSyncOrganizationSettings
Which gives you an unformatted output, like below (with default values):
Changing the values can be done via:
Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Quarantine -UserMailInsert "Contact IT for access"
This will set the default access toward Quarantine and will send a mail to the user with additional information.
Do note, that you can then allow the specific device on a user level (without affecting other similar devices) or create a specific Device Access rule, which overrule the Organization settings. This is why if you already have users connecting with ActiveSync devices and you need to implement (or change) the default access level, in order to prevent current devices to be unable to access Exchange you have to create separate device access rules allowing those devices (if so required).
Allowing a Blocked/Quarantined Device
If a device has been blocked or quarantined, an admin can override this. You have to use the Set-CASMailbox in order to achieve this:
Set-CASMailbox -ActiveSyncAllowedDeviceIDs @('2FA6AB45DD32ECF337F603CBC6393ECB') -Identity [email protected]
Identity is the UserMailbox containing the specific device and with ActiveSyncAllowedDeviceIDs you can add devices in the allowed list. This is a multi-valued property as indicated by the formatting. Take that into account when the user has multiple devices that have had a block or quarantine.
The value is the specific device ID. This is found via the Get-MobileDevice cmdlet:
Get-MobileDevice | ft FriendlyName, DeviceID
Which results into this:
Mobile and ActiveSync devices are easily accessible in PowerShell via Get-MobileDevice. To manage an individual device, you must have the full distinguished name (DN) path of the object. A DN can be something like:
damianExchangeActiveSyncDevicesHx§UniversalOutlook§3863B909D1CF4738B795F593DD266C4
If you want to get devices for a specific user, use the Get-MobileDevice command with the -Mailbox parameter added with the correct identity:
Get-MobileDevice -Mailbox [email protected] | ft FriendlyName, DeviceID, Identity
Which would result into something like this:
Note that in this example you also see a TestActiveSyncConnectivity “device”, this is the Managed Availability test probe.
The most drastic security measure in order to prevent data leakage is of course the remote wipe. This feature has been available in EAS from the beginning and enables either the user or the admin to completely wipe the device and reset it toward a factory default. In recent years, some OSs or apps implemented a partial wipe, deleting only the account info and downloaded data for that app. Due to the rise of using your personal device for business purposes, the fact that EAS could wipe your device and all of your personal data became more and more controversial.
Some Device OS's or the app that are used only wipe the data obtained via the EAS synchronization and not for instance your precious pets or children’s photos. Do note that they report a successful wipe, but do not assume that the compete device has been reset to factory defaults. Saved attachments may be present on external storage, encrypted or not encrypted (depending on device policies). So, if you need guarantees, managing your devices via ActiveSync is probably not adequate and you should investigate Mobile Device Management (MDM) such as Microsoft Intune or use the Office 365 MDM solution. There are also third party solutions like AirWatch and MobileIron.
A user can also initiate a remote wipe from webmail (OWA), but an admin can do so as well using the Clear-MobileDevice cmdlet, using the full Identity value:
Clear-MobileDevice -Identity "Damian-PPExchangeActiveSyncDevicesWP8§A123A54AAF1FFF8BC014DA6BB8744D22" -NotificationEmailAddresses [email protected]
Please note that Identity defines the specific mobile device, not the mailbox ID as a user can easily have multiple (active) devices partnered with their mailbox. A notification email address is optional, but it can be a helpful indicator for the end-user as to what just happened.
The next time the device connects to Exchange Online via ActiveSync, the device notices the wipe request and will adhere according tp how the app or OS would handle it normally. This also means you get confirmation whether the wipe request was received.
Another consideration is when you want to re-introduce the previously wiped device to Exchange Online, the wipe command still stands and will wipe the device again as soon as you connect it to Exchange Online.
You can cancel the wipe request by adding the Cancel switch to the command:
Clear-MobileDevice -Identity "Damian-PPExchangeActiveSyncDevicesWP8§A123A54AAF1FFF8BC014DA6BB8744D22" -Cancel
Another option is to remove the device partnership. However, if the device was lost and in the hands of a malicious person, keeping wipe request in place even will be more secure way to remove data from the device and to prevent unsolicited access to Exchange. If your credentials are compromised, the device will be wiped again immediately after they connect to Exchange (if the device still matches the same partnership, a software update might break that relationship).
**Note ** The cmdlet Clear-ActiveSyncDevice does the same as Clear-MobileDevice, but is deprecated and will be removed in a future version of Exchange. The same is valid for Get-ActiveSyncDeviceStatistics which has its equivalent in Get-MobileDeviceStatistics.
There might be reasons to remove a mobile device, for instance if there are too many stale partnerships it can prevent users adding a new device; the device limit is per default 10.
You can remove the device with the same cmdlet as with removing the wipe command.
Remove-MobileDevice -Identity "Damian-PPExchangeActiveSyncDevicesWP8§A123A54AAF1FFF8BC014DA6BB8744D22" -NotificationEmailAddresses [email protected]
Note: The cmdlet Remove-ActiveSyncDevice does the same as Remove-MobileDevice, but is deprecated and will be removed in a future version of Exchange.
If you are accustomed to Exchange on-premises you might be concerned about limitations on ActiveSync devices and your Exchange Online mailboxes. However, unlike Exchange on-premises, the limitations for these device connections is much greater by default. The limit currently is 100 devices:
Also, there are no Throttling PowerShell cmdlets in Exchange Online, so no need to configure these settings.
To get a feel of where your company data resides, it’s common to create an overview of clients (and especially mobile devices). What kind of device types, Device OS builds, what was the last sync, etc. can be useful information to check on your BYOD implementation or perhaps even choosing a third party Mobile Device Management (MDM) solution. You may want to know what you have and whether you can manage them with a certain thirdparty product. Or maybe you just are a numbers geek and just want to know!
These examples tend to use Format-Table (or FT) to modify output. However, there’s a lot more (potentially) useful information in the output, so check that out and experiment with it.
Types of devices/OS etc.
If you require a list of used Devicetypes (in order to build a device access rule for instance), use the following:
(Get-MobileDevice -ResultSize Unlimited).Devicetype | Sort-Object |Get-Unique
If you want a list with all devices DeviceOS's, use the following:
(Get-MobileDevice -ResultSize Unlimited).DeviceOS|Select $_.DeviceOS -Unique
The ResultSize parameter is used in case there are more than 1,000 devices connected to Exchange.
Stale partnerships (last sync)
You might want to create a list with all devices and their last successful synchronization, using this cmdlet you can:
Get-MobileDevice | Get-MobileDeviceStatistics | FT DeviceFriendlyName, DeviceID, LastSyncAttemptTime, LastSuccessSync -Auto
This will give you all devices and their sync times. However, you might want to sort it on the sync date:
Get-MobileDevice|Get-MobileDeviceStatistics|Sort ($_.LastSuccessSync) | FT DeviceFriendlyName, DeviceID, LastSyncAttemptTime, LastSuccessSync -Auto
Note, both of these cmdlets may take a while to produce results.
As it stands now it will be sorted with the oldest date first in the table. Note that the ResultSize hasn’t been added, which might be required if you have more than a thousand devices.
Each device has a DeviceAccessState which shows whether the device has been Blocked or Quarantined. This makes it simple to make a list:
Get-Mobiledevice -Filter {DeviceAccessState -ne "Allowed"} | FT FriendlyName, DeviceAccessState, UserDisplayName -Auto
In this case the Get-MobileDevice cmdlet has a filter option, so we can use it to filter out what we don’t want to see. In this case Allowed devices.
This information is stored in the device statistics. To see whether devices have been successfully wiped, use this:
Get-MobileDevice | Get-MobileDeviceStatistics | Where {$_.Status -eq "DeviceWipeSucceeded"}
You can see something like this:
Note the different moments in time when the wipe request was requested, sent and actually performed by the device (if you trust the device or app being accurate). You can also see the Wipe requester, in this case the Administrator.
ActiveSync Enabled/Disabled Accounts
If you limit access to ActiveSync, it might be helpful to have an overview which mailboxes have this protocol (or client access protocols) enabled or not. You can see this as such:
Get-Mailbox | Get-CasMailbox -ProtocolSettings
Which will show this:
So, to only show ActiveSync disabled accounts the syntax would be:
Get-Mailbox | Get-CASMailbox -ProtocolSettings | Where {$_.ActiveSyncEnabled -eq $False}
Which would result in:
** Note ** Refer to Client Access Rules for more options when it comes to controlling this.