BYOD: Protect Corp Data on iOS and Android without Device Enrollment using MAM

November 23, 2016, 7:39 am

≫ Next: Protect Access to Email from Mobile Devices using Microsoft MDM Technologies

≪ Previous: Intune: User Replaces Mobile Device

$

0

0

In this post I provide information on how Microsoft Mobile Application Management (MAM) policies configured in the Azure portal can be used to protect your corporate data while being accessed from personal iOS or Android mobile devices without the need to enroll those devices in a Mobile Device Management (MDM) solution such as Microsoft Intune.

I provide concepts, "gotchas", requirements and illustrate using the Azure portal to configure a MAM policy, associate it to mobile apps, and deploy it to a group with two user members. One user has an iPhone enrolled in Intune, and the other one has an iPad not enrolled in any MDM solution. The MAM policy effectively applies to apps in both devices.

Concepts

MDM allows Information Technology (IT) to manage and protect mobile devices. Corporate users may need to access your corporate applications and data from their own personal devices (Bring Your Own Device or BYOD scenario) but may not want IT to manage their devices. IT still needs to protect corporate data. 

Although you can apply MAM policy settings using the Intune admin console if you have Intune (standalone or integrated with System Center Configuration Manager -SCCM), Microsoft recommends to use the Azure portal admin console instead because of the following reasons:

• MAM policy settings in the Azure portal can be applied to devices managed by Intune, managed by a 3rd party MDM solution or not managed by MDM
• The Azure portal is the new console to apply MAM policy settings, and new settings may be added to the Azure portal only and not to Intune

The corporate data is protected by settings in a MAM policy associated to specific apps, deployed to users, and enforced when the applications are used in the work context of an Azure AD user account. 

Data can be protected by restricting copy/paste operations, data transfer outside of the work context (i.e from a MAM protected app to a non-protected app), prompt for PIN or corp credentials when accessing the app, and have all URLs open using the Intune Managed Browser (iOS and Android versions available). Azure AD authenticates users when they open a protected application and provide their work credentials. You can also wipe corporate data without uninstalling the app or deleting personal data. 

For apps that support multi-identity, MAM policies apply only when apps are used in the work context and not when using a personal account. Microsoft Office mobile apps support multi-identity.

MAM policies don't support Windows devices but you can protect your corporate data on them using Windows Information Protection (WIP) with Microsoft Intune or SCCM.

"Gotchas"

• If both, Intune and Azure MAM policies are configured, the Azure policy settings take precedence and are applied to the apps (a known issue is that reporting in Intune or SCCM incorrectly report that Intune policies are applied)
• MAM policies must be deployed to user groups setup in Azure AD and not in Intune
• The Azure portal can't deploy apps (if you need this, you can enroll the device in Intune or any other MDM that supports it)
• MAM policies should not be used in conjunction with a 3rd party MAM or secured container solution

Requirements

• Intune subscription for each user (the user's device doesn't need to be enrolled in Intune, but it's OK if it is)
• Office 365 subscription
• Azure AD 
• Supported mobile applications

Supported Applications

A supported mobile app should incorporate the Microsoft Intune App SDK in order to understand MAM policies applied to it. Apps that connect to the Office 365 services are supported as they have the SDK built-in (not apps that connect to on-premises Exchange or SharePoint). Apps written incorporating the SDK are called Intune-enlightened apps. In this list you can see which Intune-enlightened apps support t MAM without enrollment. Note that Microsoft just announced MAM without enrollment support to the SDK Cordova plugin and Xamarin component.

If you have Line of Business (LOB) apps already written and don't want to modify the code (or don't have the source code), you can use the Intune App Wrapping Tool to make your existing mobile app compatible with MAM policies. However, this tool does not support apps in the Apple App Store or Google Play Store. You can download the tool's iOS and Android versions from GitHub.

Look at this article for information on how to use the tool to wrap iOS apps, and this one for information on how to wrap Android apps. The tool does not provide all the management features that the SDK does. You can see a comparison of the features here.

Creating Application Policy

Login to https://portal.azure.com, click on "More services", and select "Intune" in the "Monitoring + Management" section.

In the "Intune mobile application management", "Settings" blade, under "App Management",  click on "App policy".

Click on "Add a policy" in the "App policy" blade.

Name your policy, select the platform (iOS or Android) and click on "Select required apps". In this case I'm targetting my iOS devices.

Select the apps that the policy should target.

In the "Add a policy" blade, click on "Configure required settings".

The settings are divided in two sections: "Data relocation" and "Access".

Data Relocation

Access

Check this link for information about each setting.

Once you have configured the settings, you are ready to deploy the policy to users. 

Deploying Application Policy

Select your policy under "App policy", select "User groups" and click on "Add user group".

Select the Azure AD group to which you want to deploy the policy and click on "Select". In this case, I'm deploying it to my "All Users" group.

User Experience on Device not Managed by MDM

This is a user member of the "All Users" Azure AD group who's using an iPad not managed by any MDM solution. When the user signs in to use a protected app using her work account (Azure AD account), she gets the following notification: "Your organization is now protecting its data in this app. You need to restart the app to continue".

and a PIN is required to access the app, as configured in the policy.

PIN Setup

Prompting for PIN

As configured in the policy, the user, when using her work account, is restricted from copying/pasting data in the protected apps.

When the user's work account signs out, she gets the following "Wipe Alert" notification: "Your organization has removed its data associated with this app. To continue, restart the app. (607)".

User Experience on Device Managed by Intune

This is a user member of the "All Users" Azure AD group who's using an iPhone enrolled in Microsoft Intune. When the user signs in to use a protected app using his work account (Azure AD account), he gets the following notification: "Your organization is now protecting its data in this app. You need to restart the app to continue".

PIN Setup

and a PIN is required to access the app, as configured in the policy.

Prompting for PIN

As configured in the policy, the user, when using his work account, is restricted from copying/pasting data in the protected apps.

When the user's work account signs out, he gets the following "Wipe Alert" notification: "Your organization has removed its data associated with this app. To continue, restart the app. (607)".

Monitoring Application Policies

In the "Intune mobile application management", "Settings" blade, click on "Users" under "App reporting by user".

Click on "Select" user and select a user.

More Information

Microsoft two-minute demo
Protecting app data using MAM policies with Intune

ConfigMgr

---

Protect Access to Email from Mobile Devices using Microsoft MDM Technologies

December 10, 2016, 8:23 am

≫ Next: ConfigMgr Infrastructure to Support Internet Clients

≪ Previous: BYOD: Protect Corp Data on iOS and Android without Device Enrollment using MAM

$

0

0

In my previous post, I discussed protecting your corporate data from mobile devices not managed by IT. I then decided to write about protecting your data (particularly access to Exchange email) from devices managed by IT using Microsoft mobile device management (MDM) technologies. The result was a 30+ page document that I consider too long for a blog post.

This led to the publication of my first Kindle eBook. This is the link to the US store: https://www.amazon.com/dp/B01N2S9EKV.

Table of Contents
Introduction

Exchange ActiveSync

Office 365 MDM

Microsoft Intune Standalone

      Intune compliance policy

      Intune conditional access policy for Exchange Online

Intune Standalone with Exchange Connector

On-Premises SCCM

On-Premises SCCM with Exchange Server Connector

SCCM Integrated with Intune

Azure AD Premium

      Allow users to join and register devices in Azure AD

      Configure conditional access rules for Exchange Online

Compliance Rules

User Experience

      iPad not enrolled in Intune

      Android phone not enrolled in Intune

            Using Office 365 Outlook App

            Using Android phone's native email app

      Android phone enrolled in Intune but not compliant

      iPhone enrolled in Intune and compliant

Which Microsoft MDM Solution to Use

      Office 365 MDM vs Intune

      Intune standalone vs integrated with SCCM

      SCCM by itself vs with Intune vs with Exchange

      Azure AD by itself vs integrated with Intune

      Architecture matters

More Information

ConfigMgr Infrastructure to Support Internet Clients

July 9, 2013, 10:24 pm

≪ Previous: Protect Access to Email from Mobile Devices using Microsoft MDM Technologies

$

0

0

In this post I provide information that can be used to assist with the design of a ConfigMgr 2012 infrastructure to manage Internet-based clients.

Security must be taken into consideration when designing your ConfigMgr infrastructure.  Although PKI is used for authentication and encryption, the clients will be connecting to your on-premises ConfigMgr server(s) from a vast and unsecured public network: the Internet.

Before you start working on supporting Internet clients, you may want to verify that you'll be able to accomplish your goals.

Client Features Supported

• Inventory
• Software distribution
• Software updates
• Software metering

Client Features Not Supported

• Client deployment over the Internet, such as client push and software update-based client deployment. 
• Automatic site assignment.
• Network Access Protection (NAP).
• Wake-on-LAN.
• Roaming (clients non-deterministically select a site system regardless of bandwidth or location)
• Operating system deployment (but you can deploy task sequences that do not deploy an operating system)
• Remote control.
• Out of band management.
• Software deployment to users unless the Internet-based Management Point (MP) can authenticate the user in Active Directory Domain Services by using Windows authentication (and an Active Directory trust). 

Site System Roles Supported

• Management Point
• Distribution Point
• Fallback Status Point
• Software Update Point

Placement of ConfigMgr Servers

There are different ways to place your ConfigMgr servers to support Internet clients. Where you place them depends on the level of security you are required or willing to implement.  In all scenarios below, the site system servers supporting intranet clients were removed from the graphics for clarity.

The external firewall allows incoming HTTPS traffic to the site system servers supporting Internet clients (HTTP for traffic going to Fallback Status Point).  See this Microsoft article to determine what ports need to be open in the internal firewall for ConfigMgr-related traffic, and this article for Active Directory traffic.

Note that you can avoid opening the SQL port for communication between the Management Point in the DMZ and the SQL server hosting the ConfigMgr database if you place a replica of the site database on the Management Point system (but you must allow the traffic of the site server publishing the database replica).

When deploying site systems in an untrusted network, such as the DMZ, select the Require the site server to initiate connections to this site system option so the site systems don't initiate connections to your trusted network.  Note that a Site System Installation Accountis needed to deploy the site system.

DMZ Servers in a different Active Directory Forest

If Forest B trusts Forest A, then user policies are also supported.  The internal firewall would allow the one-way AD Trust traffic through, as well as communication between the ConfigMgr site server in the Intranet and the site system servers in the DMZ.

DMZ Servers in the same Active Directory Forest

This scenario is similar to the first one, with the main difference being that the site system servers in the DMZ belong to the same AD Forest as the primary site server in the intranet.  To protect domain controllers from being accessed from an untrusted network (by the ConfigMgr servers in the DMZ), a Read-Only Domain Controller (RODC) is placed in the DMZ (internal firewall must allow DC replication traffic from the intranet to the DMZ).

No ConfigMgr Servers in the DMZ

In this scenario the site systems supporting Internet clients are in the Intranet (except the Fallback Status Point), and their services are published to the Internet via a Web Proxy such as Microsoft ISA or Forefront Threat Management Gateway using SSL Bridging or Tunneling (SSL Bridging is recommended as it is more secure).  The site systems in the intranet can be configured to support only Internet clients or both Internet and intranet clients.

Fallback Status Point

The Fallback Status Point (FSP) requires special consideration because you can have multiple FSPs in a ConfigMgr site (such as one in the Intranet and one in the DMZ) but a ConfigMgr client only talks to one (the one that it talks to when the client is installed). 

If your ConfigMgr site supports clients when they are connected to the intranet or Internet, they'll attempt to talk to the same initial FSP regardless of their location.  In my opinion, if I have to choose, I prefer that they can talk to it from the Internet, otherwise if there are issues with the client we have no way to gather troubleshooting information unless we have access to the client system.  If you have Internet clients that never connect to the intranet then you could setup an independent ConfigMgr infrastructure in the DMZ with its own FSP.

SCCM