Hi Everyone!

As I have written in other blog posts, the frustration of working with an unmanaged aka app-level managed email client can be a real challenge today. The first problem (being fair) is that most of them suck. It’s truly amusing how people after the fact think Good for Enterprise (GFE) was the greatest thing that ever lived after its dead (as opposed to hating and cursing its name the entire time it existed).

Many pretenders have existed over the years with some of them “decent” and others not so much. Usually the problem we have is it only being decent on one platform i.e. solid on iOS and a walking dumpster fire on the “others.” Sorry yes I’m sort of talking about you Boxer, Touchdown, and every other one of you. It’s not entirely their fault. The platforms’ engineer their  own interpretation of ActiveSync. As much as I don’t love Apple, they do a fairly solid job of building ActiveSync via the APIs whereas Android is ridiculously sensitive and often ineffective.

The problem we mainly have today is the focus on Exchange Online. Most vendors are splitting their focus on two different technologies (O365 and On-Premise) which behave quite differently with their own sets of headaches. Sometimes this does a major disservice for end users. I’m going to cover a deep dive into the Outlook Mobile application with primarily a focus on using it with an On-Premise Exchange Sever. I will also show you how to properly build it out and ensure you aren’t giving “too much” without considering the compensating controls.

Outlook Mobile Architecture for On-Premise Exchange

The Outlook mobile experience can be very confusing so it’s important to break it into parts. Those parts are the synchronization, caching, and attachment delivery. We will break down each of them to help understand how it works.

Outlook Client Pre-Reqs

Before we can talk about setting up the application itself, you will want to lay out some ground work. Most of the people I know are AirWatch customers so we’ll primarily focus on that. If you are an AirWatch customer and using On-Premise Exchange, you should ABSOLUTELY be using a SEG. Its debatable in O365 if you just do Powershell integration, but for On-Premise I will focus on a standard build using a SEG. The value is just too high if you build it correctly.

The requirements to be able to properly use Outlook without causing a security incident come down to:

• Allow the Outlook Client through your SEG
• Use EAS Policies in Exchange that will ONLY allow the device types you want to use Outlook
• Deploy the proper MAM identifiers to the application as is the best practice (EMS Licenses required)

Whitelist the Outlook Client on your SEG

The first distinction to understand is managed vs unmanaged. The major issue with the Outlook client is that this will be an “unmanaged” client literally because we can’t push a Email Payload Configuration to it. For you to address this and help it go smoothly, you are going to whitelist the Outlook Client on your SEG.

In Email > Compliance Policies, you need to enable the “EAS Device Type” and add the type Outlook as you see below. Once you set this, you just click “Run Compliance” and the first bullet is done.

Configuring Exchange for your Outlook Client

You can setup Exchange to either Allow iOS and Block Android or vice versa. It’s likely that most people will go that route, but of course you can skip this step if you decide to allow both. The concern is, which I have mentioned before is that you do not have a ton of visibility when you allow both clients. It uses a shared User Agent for both called “Outlook-iOS-Android/1.0. The steps are really easy to set.

You can block Android and allow iOS with this command:

New-ActiveSyncDeviceAccessRule -Characteristic UserAgent -QueryString "Outlook-Android/2.0" -AccessLevel Block
New-ActiveSyncDeviceAccessRule -Characteristic UserAgent -QueryString "Outlook-iOS/2.0" -AccessLevel Allow

You can block iOS and allow Android with this command:

New-ActiveSyncDeviceAccessRule -Characteristic UserAgent -QueryString "Outlook-Android/2.0" -AccessLevel Allow
New-ActiveSyncDeviceAccessRule -Characteristic UserAgent -QueryString "Outlook-iOS/2.0" -AccessLevel Block

Deploying the MAM App Keys

The App Keys are the same as they are with any of the other Office Apps. The HUGE distinction that most people won’t tell you is that you only get MAM-enabled after you add OneDrive as a storage account when you aren’t using Exchange Online. That’s okay for the most part. The real key is ensuring that Outlook is pushed automatically to devices so it is a managed application for DLP compliance

Outlook Client Synchronization

NEW! AppConfig Keys for OnPremise Outlook

We can now push Managed App Keys to Outlook to help automate the configuration portion. Otherwise, you can also set it up manually with the Legacy Setup. The keys and values are below:

Configuration Keys

The configuration keys can be found below. I’m using the AirWatch lookup value concepts for simplicity. Once these are used and tap “Add Account” you will find it automatically located. This will only require you to input the password.

Key: com.outlook.accountName        Value: Text string for the account

Key: com.outlook.emailAddress         Value: {EmailAddress}

Key: com.outlook.emailServer            Value: Email Server Name

Key: com.outlook.username                 Value: {EnrollmentUser}

Key: com.outlook.domain                      Value: Email Domain

Legacy Setup

The Outlook Mobile Client which sits on a user’s mobile device is primarily designed for logging into Microsoft/Office 365 services with its Modern Authentication login interface you are accustomed to through their fleet. For On-Premise customers, you can easily just tap “Setup Manually” and go through the steps you know obviously.

Once your account is setup, you can feel free to add storage accounts to complete your integration. Previously, when you log into your OneDrive account on the Outlook App it would force Outlook to become MAM-enrolled. This does not appear to be the case at this juncture. You can combat these issues with IRM or a CASB solution to monitor and manage these situations. It’s something that I will be running down with Microsoft personally as its a huge DLP concern. Typically when an app is being a jerk, you do an open-in from OneDrive to that app to force that MAM policy. Sadly, you can’t do that with Outlook.

The Focused Inbox

Most people don’t actually know what the Focused Inbox is. I thought I’d explain it to help provide context for the rest of this blog. The Focused Inbox will sort your email by putting important emails in a Focused tab and the other stuff in “Other” A user can benefit from those on both their corporate and personal mailboxes. This uses an algorithm to look at your account emails, contacts you talk to, etc. It will then filter out the crap to help you manage your inbox more efficiently. With use, it learns and improves along with your ability to move stuff from “Other” to the focused inbox. The biggest thing to know is that your notifications and badge count are that of the focused inbox specifically.  You can certainly change that yourself via Settings > Notifications but I think it’s a good rule of thumb.

The Outlook Service

The Outlook Service, which is basically the Accompli acquisition rebranded is now at a point where On-Premise customers can “almost” trust it. They have officially moved it to Azure. The Outlook Service is a caching mechanism that provides you with a more efficient experience. Some of the things you gain with this service are:

• Powers the categorization for the Focused Inbox
• Ability to unsubscribe from pesky mailing lists
• Much faster searches (think cached exchange mode)
• Ability to work with attachments without needing to download them locally

The caching mechanisms behind the Outlook Service are very fascinating. The service will cache about a month of content. The algorithms take these things into account when deciding what to cache:

• Size of the mailbox
• How often you are accessing a folder
• Tends to cache most email, calendar items, and contacts
• Level of importance a folder has to you

Another key thing to be aware of is where the data is cached. Today, if the Client IP is in the US, it will be cached in the US Azure Site otherwise the data is being cached in Europe. Once this service is moved to Office 365, it will use a regional data center strategy based on the location specified during user account creation. This is based on the Office 365 Trust Center strategy Microsoft has in place today.

Outlook Service’s Attachment Capabilities

The Outlook Service’s most underrated capability might be how you now request attachments. The process goes:

1. User taps on Attachment in Outlook
2. The Outlook Service requests the attachment from Exchange and stores it temporarily
3. The Outlook Service delivers the attachment to the device
4. Data is flushed automatically after a month

A seldom-known fact is when you forward an attachment to someone it downloads that to the device locally first. With the attachment caching of the Outlook Service, you can now eliminate the local downloading of the files, which provides a huge improvement in performance.

Purging Cached Data from the Outlook Service

The biggest concern with the Outlook Client is how it caches the data and the compliance requirements for organizations around that.

You have three ways to purge the data from the Outlook Service:

1. Sending a wipe command from the Exchange Control Panel for that EAS Partnership
2. Have the user delete the Outlook App (this purges the content in 3-7 days)
3. Have the user remove the account from the Outlook App (this will cause that to get purged much more immediately)

Outlook Mobile Security Mechanisms

There are a few areas from a security aspect we will want to focus on. They are:

• ActiveSync Policies and how you can leverage them with Outlook
• Password/Credential Management with the Outlook Mobile Client

Password Management

Mobile apps build their security foundation on a few guiding principals:

• Encryption Keys
• End-to-End Encryption
• Data at Rest Encryption

When you run Outlook for the first time, it will generate a 128-bit AES encryption key. This is called the “Device Key” and is the most important aspect of Outlook’s encryption on an iOS or Android device. It is unique to the device itself and cannot be stored elsewhere. Let’s talk more about that key now.

When you connect to Exchange for the first time, it will send your credentials wrapped with the device key over a TLS connection to the Outlook Service as shown in the diagram below.

Next, a series of processes occur on the Outlook Service to secure the user’s password on the Outlook Service:

1. The Device Key is held in runtime memory on the Outlook Service
2. The Service verifies the password is correct with Exchange
3. The password is wrapped with the device key and stored on the Outlook Service
4. The Device Key is wiped from the Outlook Service (meaning the only copy of it remains on the local device).
5. The next attempt to sync the mailbox will result in the device key being sent to the Outlook Service to decrypt the password.
6. The service connects to Exchange again to synchronize the .mailbox.
7. The password will be kept on the service in decrypted form until the timeout interval passes.

Speaking of inactivity, the Outlook Service will flush the cached account data and the password from runtime memory after three days of inactivity. The flushing is not an exact science. Typically the service works on a weekly schedule where it will purge inactive accounts. So the question now is: What makes it inactive? There are a few things that will lead to that:

• Outlook App is deleted
• Background App Refresh is disabled and the app is closed
• No data connection on the device

With all of this in mind, the reason the security of this is so strong is a prime example of separation of duties. You may have heard of that before! The user’s password is NEVER stored on the device and the device key is never stored on the Outlook Service. As we have discussed, those two are very important to each other. This provides a very strong security model to help thwart attacks.

There are a number of hidden gems with this architecture. If your environment blocks Android devices, when the Outlook Service tries to authenticate your account and fails because of the block it will flush the password. This will ensure your password is never stored anywhere. On the other side of the coin, if the user fails to delete the account prior to deleting Outlook, the Outlook Service will continue to try to sync the user’s account with Exchange until you hit the inactivity timeout mentioned earlier. It’s a bit of an annoyance to be aware of, but it will inevitably be transparent.

Using ActiveSync Policies with Outlook Mobile

Obviously, we have a few minor concerns with using the Outlook application. The main question we need to ask ourselves is: “Can this replace Good?” or “Could this replace Boxer?”

The answer is “maybe” but a strong maybe. You need to understand how the EAS Policies affect the Outlook application and the value it gives you. The primary policy that matters is forcing PIN lock. The kicker is that you can only enforce this at the device level. That might complicate things a bit for you since you can’t force the app itself to have a PIN, but its a whole device password. This might make your more privacy-conscious users a bit leery. The problem is that you DO need to do something. I think it’s about setting expectations. They can keep using their legacy app or they can upgrade to the better experience with Outlook albeit with a device passcode.

On iOS this also gives you encryption, which is very helpful obviously. On Android, it is a bit different. You get the following things with enforcing the PIN lock:

• Outlook enforces screen lock rules on the device
• Allows you to force complexity, length, and number of failures before a device wipe

One issue on Android is that it will recommend that the user enable encryption, but they can refuse it. That is a bit of a concern, but Outlook does have some mitigation for that. With an enabled device PIN, the Outlook database is inaccessible. This is even true with a rooted device using USB debugging. You would only be able to access the data if the device was already rooted prior.

A few other things to be aware of around policies:

• Outlook uses a shared agent for ALL devices by that user, which means a remote wipe via EAS will remove the data from EVERYWHERE
• Add/Block/Quarantine can only be done at the user level because of the shared model
• Device Wipes via EAS will wipe both the content in the Outlook Service and the Outlook Apps running on devices

Well in conclusion, my review and deep dive into the Outlook App has a few findings that I want to call attention to:

• MAM Policies are not reliable with Outlook so you better make sure that you are covering the gaps in Outlook. That means you need to have visibility into your assets and their accessibility with cloud services
• You need to work on a sound communication strategy to roll this out for unmanaged devices