Conditional access for Exchange Online to the max

This week I want to show another look at conditional for Exchange Online. I want to do that by providing a scenario. That scenario will cover more than just conditional access. Mainly because conditional access simply blocks access to non-compliant devices, but what if I want to take it one step further? What if I also want to prevent potential data leakage? In that case I can’t just look at conditional access. In that case I also need to add mobile app management to the playing field. This post will address those subjects for Exchange Online.

Scenario

Now lets start with the scenario that I want to cover. Even though I know that I will use Microsoft Intune and related technologies to do the configuration, I want the scenario to describe functional requirements. The configuration should address the following requirements:

  • Email access is only allowed on managed and compliant devices;
  • Email data leakage must be prevented on managed and compliant devices;
  • Email access is available via the browser;
  • Email access is supported on iOS, Android and Windows 10.

Configuration

Now lets have a look at what I need to configure to address that scenario. The good news is that I can support this scenario with Microsoft Intune. However, the default configuration is not sufficient. I need to get creative. To address this scenario I need to make sure that email access is only available through browsers and apps that can be managed by mobile app management (MAM) policies or by Enterprise Data Protection (EDP)/ Windows Information Protection (WIP). No back doors allowed. That means that to address this scenario I need to add the following technical configurations on top of the standard conditional access and MAM (and WIP):

  • The OWA app for iOS and Android must be blocked;
  • ActiveSync apps that use basic authentication must be blocked;
  • The default browsers on iOS and Android must be blocked.

Block the OWA app

ADFS_DenyOWAThe first thing that I want to configure is a deny for the Microsoft OWA app. That specific app bypasses every form of conditional access. Luckily that doesn’t mean that there is nothing that I can do to block the app. I can use AD FS to deny specific client user agent claims for the Microsoft OWA app. 

The following example claim will deny every active claim that arrives via the AD FS proxy with a client user agent that contains MOWAHost. That should be distinctive enough to only deny the Microsoft OWA app. However, keep in mind that the Microsoft OWA app will only be blocked once it tries to verify the credentials.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “MOWAHost”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Block Exchange ActiveSync apps with basic authentication

The second thing I want to configure is a deny on every Exchange ActiveSync app with basic authentication, like the default mail app on iOS and Android. Those apps are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those apps can still leak data. The combination of the following three components allows me to only allow the Microsoft Outlook app, which is capable of working with MAM policies, on mobile devices.

1

ExchangeOnlinePolicy_EASThe first component that I need to address is the Exchange Online Policy for conditional access. I don’t want Microsoft Intune to control the access for the Exchange ActiveSync apps with basic authentication, I want Exchange Online to take care of those apps. Within Exchange Online I’ve got the ability to easily block or allow access to specific device families and models. Microsoft Outlook is available as a device family.

To achieve that Microsoft Intune doesn’t control those apps, I need to make sure that the setting Block non-compliant devices on platforms supported by Microsoft Intune and the setting Block all other devices on platforms not supported by Microsoft Intune are disabled in the conditional access policy for Exchange Online.

2

EA_AccessSettingsThe second component that I need to address are the Exchange ActiveSync access settings. Within these settings I can define the default behavior of Exchange Online when a device isn’t managed by a rule or personal exemption. In this case I want to block access to all mobile devices that are not part of the rule that I will define.

To achieve that every device is blocked when it’s not managed by a rule, I need to configure the Exchange ActiveSync Access settings to Block access.

3

EA_DeviceAccessThe third component that I need to address is the Device Access Rule. With a rule like this I can define which device families and models are allowed, blocked or quarantined. In this case I want to allow access to all mobile devices that use Outlook to connect.

To achieve that all mobile devices that use Outlook are allowed, I need to create a Device Access Rule with the Outlook device family and for All models.

Note: It’s even possible to specifically select Outlook for iOS and Android as model, but at this moment that cannot be enforced.

Block default browsers on iOS and Android

The third thing that I want to configure is a deny on the default browsers on iOS (Safari) and Android (Chrome). Those browsers are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those browsers can still leak data. Luckily that doesn’t mean that there is nothing that I can do to block those browsers.

ADFS_DenySafariDefault browser iOS (Safari)
I can use AD FS to deny specific client user agent claims for the Safari browser. However, the Safari browser is tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Safari. That isn’t only applicable to iOS, but also to Android and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Safari, but doesn’t contain Windows or Android. That should be distinctive enough to deny the Safari browser on iOS devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Safari/”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Windows|Android”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

ADFS_DenyChrome

Default browser Android (Chrome)
I can also use AD FS to deny specific client user agent claims for the Chrome browser. However, the Chrome browser is also tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Chrome. That isn’t only applicable to Android, but also to iOS and Windows.

The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Chrome and Android, but doesn’t contain PKeyAuth or ManagedBrowser. That should be distinctive enough to deny the Chrome browser on Android devices.

Claim
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Chrome/”])
  && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Android”])
  && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “PKeyAuth|ManagedBrowser|Windows”])
  => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”);

Result

The result is awesome, in my personal opinion. I’ve successfully tested this configurations on iOS, Android and Windows 10 devices with multiple browsers and apps. This configuration, in combination with conditional access and MAM (and WIP), provides the following results:

  • Email access is only available on managed and compliant iOS and Android devices via the Managed Browser and on managed and compliant Windows 10 devices via Internet Explorer and Microsoft Edge. These browsers can be managed via MAM and WIP to prevent data leakage. Other browsers will be blocked by conditional access, or AD FS;
  • Email access is only available on managed and compliant iOS and Android devices via the Microsoft Outlook app on managed and compliant Windows 10 devices via Outlook. These apps can be managed via MAM and WIP to prevent data leakage. Other apps will be blocked by Exchange Online;
  • Known back doors are closed. The OWA app will be blocked by AD FS.

More information

Fore more information about conditional access for Exchange Online and mobile app management, please refer to:

Conditional access for browsers

This week I’ll provide an overview about the latest addition to conditional access, which is conditional access for browsers. It’s a feature that many have been waiting for and a feature that is indeed a pretty welcome addition to conditional access. This post will provide the basics about conditional for browses, the configuration of conditional access for browsers and the end-user experience with conditional access for browsers. It will also be the introduction for something much better next week.

Introduction

Conditional access allows IT organizations to manage access to corporate email, files and other resources based on customizable conditions that ensure security and compliance. The addition of conditional access for browsers addresses the backdoor that still existed for end-users connecting to the Outlook Web App (OWA) and end-users using browser access to SharePoint and OneDrive for Business. It’s now possible to restrict Outlook Web App (OWA) and browser access to SharePoint and OneDrive for Business when accessed from a browser on iOS and Android devices. Access is only allowed from the following supported browsers, on compliant devices, while unsupported browsers are simply blocked:

  • Safari (iOS);
  • Chrome (Android);
  • Managed Browser (iOS and Android).

Note: Keep in mind that this does not block access via the OWA app. More about that in my post next week.

Configuration

Now let’s have a look at the configuration of conditional access for browsers. The configuration is the same for Microsoft Intune standalone and Microsoft Intune hybrid, as the configuration is part of the conditional access policies. It’s actually nothing more than one simple checkbox that belongs to one specific setting. That specific setting is Block non-compliant devices on the same platform as Outlook in the Exchange Online Policy and Block non-compliant devices on the same platforms as OneDrive for Business in the SharePoint Online Policy. That specific setting can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online SharePoint Online
OWAExchangeOnline OFBSharePointOnline

End-user experience

Now it’s time to look at the end-user experience, which is the most important part of this feature. Below I’ve got examples for compliant and non-compliant devices and supported and unsupported browsers. In all examples I’m trying to access https://outlook.office.com.

Android

Here is an example on an Android device using the supported Chrome browser and using the unsupported Firefox browser. The left column shows the non-compliant examples and the right column shows the compliant examples. Notice the clear message in the unsupported browser about using supported browsers for access.

Non-compliant Compliant
Screenshot_20160708-203644 Screenshot_20160710-181822
Screenshot_20160708-203757 Screenshot_20160708-204830

iOS

Here is an example on an iOS device using the supported Safari browser and using the unsupported Firefox browser. The left column shows the non-compliant examples and the right column shows the compliant examples. I haven’t been able to receive the same clear messages yet, as shown on my Android device, but the access is definitely blocked.

Non-compliant Compliant
IMG_0058 IMG_0056
IMG_0059 IMG_0057

Windows 10

I’ve also managed to successfully test conditional access for browsers on Windows 10, with Internet Explorer and Microsoft Edge, in combination with Microsoft Intune standalone and Microsoft Intune hybrid. Even in combination with Windows 10, fully managed by ConfigMgr. More about those awesome scenario’s once it’s listed as a supported platform with supported browsers.

More information

Fore more information about conditional access for browsers with Exchange Online and SharePoint Online, please refer to:

Quick tip: Available token types for app configuration policies

This is a quick and short blog post to create awareness about the existence of token types. Token types are basically just variables that can be used within a property list of an app configuration policy in Microsoft Intune hybrid and Microsoft Intune standalone. This blog post will provide a quick overview about the available token types with example values.

Overview

The following table contains the currently available token types for Microsoft Intune hybrid and Microsoft Intune standalone. Before going through this table, it’s good to know that the {{ and }} characters are used by token types only and should not be used for other purposes.

Token type Example value
{{userprincipalname}} pvanderwoude@petervanderwoude.nl
{{mail}} pvanderwoude@petervanderwoude.nl
{{partialupn}} pvanderwoude
{{accountid}} fcc00012-123e-f479-aabe-abe2a1123b45
{{deviceid}} c7d01dd3-136f-40c5-b843-711e958c4eef
{{userid}} 2dda638e-28b7-4bdc-a4fd-70faaa811010
{{username}} Peter van der Woude
{{serialnumber}} F9FPVD86FCM5
{{serialnumberlast4digits}} FCM5

More information

For more information about iOS apps with mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

Microsoft Intune and the AppConfig Community

This week I would like to write about Microsoft Intune and the AppConfig Community. I want to create some awareness about what the AppConfig Community is and I want to show how even Microsoft Intune can, and will, benefit of that great alliance.

What is the AppConfig Community?

Let’s start with what the AppConfig Community actually is. I could do that by providing my own explanation about the AppConfig Community, but to prevent any possible misinterpretation from my side, I will provide the good and clear explanation as provided on the AppConfig Community website.

The AppConfig Community is a collection of industry leading Enterprise Mobility Management (EMM) solution providers and app developers that have come together to make it easier for developers and customers to drive mobility in business. The community’s mission is to streamline the adoption and deployment of mobile enterprise applications by providing a standard approach to app configuration and management, building upon the extensive app security and configuration frameworks available in the OS. Working together, the members of the AppConfig Community are making it simpler for developers to implement a consistent set of controls so that enterprise IT administrators can easily configure and manage apps according to their business policies and requirements.

Historically, developers used proprietary software development kits (SDKs) to enable configuration and management features of their apps through EMM. This required app developers to build different versions of their apps for each EMM vendor. Now, with the AppConfig Community tools and best practices, developers do not require EMM-specific integrations for many enterprise use cases. End users also benefit from automated features such as an out-of-the-box experience to give the users instant app access without requiring cumbersome setup flows or user credentials.

Microsoft Intune and the AppConfig Community

Let’s continue with how Microsoft Intune works with the AppConfig Community. Well, it’s good to know that, at this moment, Microsoft Intune is not part of the collection of industry leading EMM solution providers that started the AppConfig Community. However, that doesn’t mean that the apps, created with the AppConfig Community standards, won’t work with Microsoft Intune. The XML format used by the AppConfig Community is similar to the XML format used by Microsoft and the Microsoft Intune app partners. In other words, the apps created by the partners, of the AppConfig Community, should also work with Microsoft Intune.

Microsoft Intune example

Now I want to show how Microsoft Intune works with an app, of a partner, of the AppConfig Community, to proof my previous statement. As an example app I use the amazing Nacho Mail app. Not only is it a great email app, it also has a great support team and some awesome configuration options. The support team is more than willing to help with providing the required information to apply app configurations to the Nacho Mail app.

Configuration

As I’m currently looking at multiple mail apps, with one of my customers, I’m also looking at the Nacho Mail app. One of the big pros, of the Nacho Mail app, is the fact that it allows the configuration of the app. It has the ability to configure a mail profile and it even has the ability to apply custom branding to the app. After contacting the support team, of the Nacho Mail app, they provided me with the following configuration key-value-pairs.

Type Key Description
String AppServiceHost Name of server
Integer AppServicePort Port number
String UserName User name
String UserDomain Domain name
String UserEmail User email address
String BrandingName Name of app to be displayed
String BrandingLogo Link to image to be displayed with app

I could use those key-value-pairs to create a mail profile for Office365, including custom branding. It’s not required to specify AppServiceHost with outlook.office365.com, as the Nacho Mail app is intelligent enough to figure it out based on the provided mail address. However, I noticed that it would save me a certificate warning. Below is the configuration that I’ve created and to use this configuration, please refer to my post about App Configuration Policies for iOS.

<dict>
   <key>AppServiceHost</key>
   <string>outlook.office365.com</string>
   <key>BrandingName</key>
   <string>petervanderwoude.nl</string>
   <key>BrandingLogo</key>
   <string>[Specify URL to logo]</string>
   <key>UserEmail</key>
   <string>{{userprincipalname}}</string>
</dict>

Note: I used the {{userprincipalname}} token type that is supported by Microsoft Intune to provide the user principal name of the end-user. However, at this moment Microsoft Intune hybrid seems to be having problems with the supported token types. Microsoft Intune standalone works like a charm.

End-user experience

After creating the app configuration, it’s time to look at the end-user experience. This time I will show the first two screens of the Nacho Mail app, after installation. That will provide a clear picture about how app configuration policies can be helpful for an end-user. The screenshots on the left show the default start of the Nacho Mail app and the screenshots on the right show the start of the Nacho Mail app after deploying the app together with the app configuration policy.

On the second screenshot, on the right, it clearly shows the complete configuration of the mail profile and my custom branding. I love it!

Before After
IMG_0034 IMG_0030
IMG_0035 IMG_0033

More information

For more information about the AppConfig Community and mobile app configuration policies, in Microsoft Intune standalone and Microsoft Intune hybrid, please refer to:

The new ability on iOS devices to send diagnostic information

This week a short blog post about the new ability in the updated Microsoft Intune Company Portal app, for iOS, to send diagnostic information. Before it was always fun to explain somebody the method to get the Company Portal Diagnostic Information, as it would require the end-user to open the Microsoft Intune Company Portal app and simply start shaking the device. Actually, this is still a possibility to get the Company Portal Diagnostic Information.

New in the latest update of the Microsoft Intune Company Portal app, for iOS, is the ability to send the Company Portal Diagnostic Information via the menu of the Microsoft Intune Company Portal app. This is a new Microsoft Intune Company Portal app ability and is not related to the iOS version.

End-user experience

Now let’s have a look at what the new end-user experience looks like. The end-user has to open the Microsoft Intune Company Portal app and simply walkthrough the following two steps.

Step 1 Step 2
IMG_0017 IMG_0018
The first step is to click on the username and to select About. The second step is to click on Send Diagnostic Report.

Note: After selecting Send Diagnostic Report an email will open, like with shaking the device, that includes the Company Portal-Log.log.

More information

For more information about the new features released in November, please refer to the following article: http://blogs.technet.com/b/microsoftintune/archive/2015/10/28/coming-soon-new-intune-features-including-windows-10-edp-policies.aspx

The new managed app installation experience on iOS 9 devices

This week a short blog post about the new managed apps installation experience for end-users on iOS 9 devices, as it was a huge pain. One of the most heard complaints with managed apps, on iOS, was about the fact that the end-user would have to manually uninstall their personally-installed apps. After that the managed app could be installed and it would really work and act like a managed app.

New in iOS 9 is the ability to convert a personally-installed app to a managed app. This allows Microsoft Intune (standalone and hybrid) to take the management of a personally-installed app and turn it into a managed app. Of course, only after the users’ permission. This is really an iOS 9 ability and does not affect devices with iOS 8 and earlier.

End-user experience

Now let’s have a look at what the new end-user experience looks like. This experience is the same for required and available deployed managed apps. At the moment of the installation of the managed app, the end-user will get the following behavior depending on their situation. When the app is not yet installed the Install managed app behavior is applicable and when the app is already personally-installed the Manage managed app behavior is applicable.

Install managed app Manage managed app
InstallWord ManageWord
“i.manage.microsoft.com” is about to install and manage the app “Word” from the App Store. Your iTunes account will not be charged for this app. Would you like to let “i.manage.microsoft.com” take management of the app “Microsoft Word”? Your app data will become managed.

Note: Keep in mind that after allowing the management of the personally-installed app, the app will be a fully managed app. That also means that the app and its data will be removed after the removal of the management profile.

More information

For more information about the new iOS 9 features, please refer to the following article about the Day Zero Support for iOS 9 with Intune.

Store accounts and the Microsoft Intune Company Portal app

CompanyPortalAppLogo_thumb9In this blog post I will answer a question that I get, with a lot of customers, and that’s if it’s required for end-users to have an account for the app store, of their platform, to download the Microsoft Intune Company Portal app. The app store that I mean here is can be the Google Play app store, the Apple app store,  the Windows Phone app store or the Windows app store. All these stores match with their platform and require their own store account to download apps.

Before I can answer the initial question, I first have to answer another question. That question is if it’s required to use the Microsoft Intune Company Portal app, simply because a store account is not required if the Microsoft Intune Company Portal app is not required. In this post I’ll try to answer both of these questions by providing tables for a nice overview of the requirements per platform. In general this is applicable for both Microsoft Intune standalone and Microsoft Intune integrated with ConfigMgr 2012.

Microsoft Intune Company Portal app

Now let’s start with the first question, is the Microsoft Intune Company Portal app required? In almost all the scenario’s the answer to this question will be, yes. Also, keep in mind that the advised scenario for every platform is to install the Microsoft Intune Company Portal app  and to enroll the mobile device. To be complete the following table lists the functional requirements for the Microsoft Intune Company Portal app  for every platform.

 Platform Enrollment and policies Application deployment
Android Yes Yes
iOS Yes1 Yes
Windows Phone 8.0 No Yes
Windows Phone 8.1 No Yes
Windows No Yes

1 It is possible to enroll iOS devices without using the Microsoft Intune Company Portal app. That can be achieved by either using portal.manage.microsoft.com on an iOS device, or by using the corporate device enrollment feature with Microsoft Intune standalone.

Store account

That brings me to the second question, is the store account required to get the Microsoft Intune Company Portal app? Well, this also differs per platform. To make it easy I can say that it’s required for the non-Microsoft platforms. The following table provides a quick overview per platform, including the alternatives for the Microsoft platforms.

Platform Store account required Alternative
Android Yes N/A
iOS Yes N/A
Windows Phone 8.0 No Microsoft Intune Company Portal app for Windows Phone
Windows Phone 8.1 No Microsoft Intune Company Portal app for Windows Phone 8.1
Windows No Microsoft Intune Company Portal app for Windows 8.1

Conclusion

At this moment the best method for end-users to enroll their device is to use the Microsoft Intune Company Portal app, if possible. In case the Microsoft Intune Company Portal app is not required for the enrollment, like with Microsoft platforms, it’s still advised to install the Microsoft Intune Company Portal app to better manage devices and applications.

Back to the original question, this would mean that, at this moment, a store account is always required for non-Microsoft platforms. For Microsoft platforms it depends on how the Microsoft Intune Company Portal app is deployed. Like I mentioned in my previous post, I like to use the Microsoft Intune Company Portal app for the Microsoft App store, if possible, and in that case a store account is required.