Intune, Azure AD, and Zscaler Private Access

Securing the perimeter has become increasingly difficult with more and more services moving to the cloud and users needing, no, expecting, access from their personal devices. The days of relying on the walls of a network to “trust” access are fading fast, and some would say they’re long gone. This is why organizations are using Microsoft technologies to build out zero trust networks where they rely on device and user claims to evaluate access to resource both on and off network. As I’ve written about in the past, security comes in layers, and zero trust encompasses many layers of security behind the scenes.

Over the past few years, Microsoft has worked with many security and management vendors to integrate with Microsoft Intune and other solutions in EMS such as Azure Active Directory.

The following list is just an example of the many technology partnerships Microsoft has in place today.

To keep up to date with Microsoft security partners please visit: https://www.microsoft.com/en-us/enterprise-mobility-security/microsoft-intune?rtc=1

For this month’s post I’ll focus on Intune, Azure Active Directory, as well as a Microsoft security partner, Zscaler, particularly Zscaler Private Access and its integration with Azure AD and Intune.

What is Zscaler Private Access?

According to Christopher Hines, Head of Product Marketing at Zscaler:

“The Zscaler Private Access (ZPA) service provides users with seamless and secure access to private applications without placing them on the network and without exposing apps to the internet. Allowing enterprises to embrace a software-defined perimeter that supports all private apps and environments.”

More details about Zscaler may be found by visiting: : https://help.zscaler.com/zpa/getting-started/what-zscaler-private-access

Before we get started, I want to give special thanks to the following individuals I collaborated with for this post:

    • Tyler Castaldo – Microsoft Program Manager – Intune
    • David Creedy – Senior Product Manager – Web Security
    • Christopher Hines – Head of Product Marketing – ZPA and Zscaler App

Let’s get started

Zscaler SSO Setup

First, we need to set up Zscaler with Azure so we can provide SSO as users access the app. Once the user accesses the the Zscaler App on their device, they’ll be passed through to Azure AD for sign-on.

Setting up Zscaler Private Access (ZPA) requires a few steps so I won’t go through them, however the steps are well documented here: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/zscalerprivateaccess-tutorial

In addition, Zscaler has also created their own documentation that may be referenced as well:

Adding Zscaler App to Intune for deployment

For this post I focus on iOS and Android. However, Zscaler is also supported on macOS and Windows 10 (more details at the bottom of this post).

After SSO is set up with Zscaler and Azure AD, we now need to add the Zscaler App to Intune for deployment.

Navigate to portal.azure.com or devicemanagement.microsoft.com and select “Client apps -> Apps”

Select “Add” then App Type and from the dropdown select iOS. Search for Zscaler and select “Zscaler App” as shown below. Add the app and assign it to a group for deployment.

For Android, repeat the steps above, however for the “App type” select “Android“. Use Managed Google Play in the console to search for Zscaler, then add and assign the app to a group for deployment.

Note: if you haven’t set up Managed Google Play with Intune yet, you will find details steps on how to do so by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

When performing a search for “Zscaler” under apps in Intune you should see both assigned apps.

Configuring the Zscaler App using a VPN policy for iOS and app config for Android

Configuring Zscaler Private Access for iOS in Intune is straightforward as Intune has the settings available directly in the Intune adming portal UI as shown below.

Note: the “Organization’s cloud name” is case sensitive and FQDN and key/value pairs are optional, for more details please visit: https://docs.microsoft.com/en-us/intune/vpn-settings-ios#base-vpn-settings.

Select how the VPN will be launched:

Configure additional settings your organization requires to provide access to applications bridged by Zscaler:

For Android, we need to create an app configuration policy and assign it to the Zscaler App we added earlier.

https://docs.microsoft.com/en-us/intune/app-configuration-policies-use-android

Create an app configuration policy by navigating to “Client apps -> App configuration policies”

Select “Add”, provide the policy a name and from the “Device enrollment type” drop-down select “Android”.

Under “Associated app” select the Zscaler App added earlier.

Under “Configuration settings” select “Use configuration designer” from the drop-down and select all the options provided. Select ok to begin configuring the values.

Configure the values based on how your Zscaler environment is configured. In my case, my Zscaler environment is set up in Azure so I utilized the cloud name for the service in Azure as well as the domain my users log into. For username, I selected variable and chose “Partial UPN”.

Once all the settings are configured select “Ok” to complete the setup.

Note: you’ll notice the “deviceToken” value is set to “DummyValue”. This value isn’t needed when Azure AD is used as the identity provider (IdP), however it is needed in the profile, so just add it and type in whatever you like for the value. Also, please note the “Organization’s cloud name” is case sensitive.

After you’re finished with the app config policy, be sure to assign it to the same group you assigned the Zscaler App to.

Client experience

On first launch, the Zscaler App on iOS and/or Android it will redirect to sign-on using Azure AD, however subsequent launches of the Zscaler App will sign-in automatically.

Azure AD Conditional Access

To prevent access to an application Zscaler Private Access is securing access for, we need to create an Azure AD conditional access policy. The Azure AD Conditional Access policy will ensure the device and/or user meets compliance policies (e.g. Intune) before allowing access.

Navigate the Azure Active Directory in the Azure portal and select “Conditional Access”

Provide a name for the policy and under Cloud app add “Zscaler Private Access” and add the Zscaler cloud app used to access resources, i.e. the organization cloud name that points to the app we added earlier. The cloud app I utilize is called Zscaler ZSCloud as shown below.

Select the device platforms to target the Azure AD CA policy, since I’m focusing on iOS and Android in this post, I select iOS and Android from the devices platforms list.

Now grant access if the device is marked as compliant by Intune, enable the policy and save.

Note: additional conditions and access controls may be checked if needed.

If the device is compliant with Intune compliance policies, Zscaler will connect the user to the application. If the device isn’t compliant, Azure AD Conditional Access will block access to the application Zscaler provides access until the compliance issue is remediated.

Let’s see this in action

I’m testing with my Android device enrolled with Intune under Android Enterprise Device Owner as a fully managed device. The Zscaler Private Access (ZPA) App and ZPA App configuration is automatically deployed.

Intune_Zscaler.gif

Conclusion

In summary we learned how to set up Zscaler with Azure and provide SSO using Azure Active Directory. We also learned how to set up Zscaler Private Access App configuration and app deployment with Microsoft Intune. Finally, we learned how to set up an Azure Active Directory Conditional Access policy to further secure application access with Zscaler based on Intune device compliance.

I hope this post helps you and your organization further secure corporate applications, devices, users, and resources using Microsoft Intune, Azure Active Directory, and Zscaler Private Access. If you’re a Zscaler customer today, go out and give these steps a try.

Appendix

Information on setting up Zscaler for Windows and MacOS

Outlook app configuration – contact field export control

Organizations utilizing the Outlook app on iOS and Android may desire granular control of app behavior such as only allowing certain contact fields to be sync’d with the native contacts app on iOS. Fortunately, Outlook settings are available to further control the Outlook app on iOS and Android.

I’ve worked with organizations who have strict data protection and GDPR requirements and utilizing Intune we were able to protect data from leaking from users’ corporate email to unmanaged apps and storage while allowing limited contact attributes sync’d to the local contacts app so caller ID will show for callers residing in contacts. Some of the restrictions are enforced by the platform (i.e. iOS/Android) while other restrictions are controlled at the app and device layer by Intune.

To learn more about app config with Outlook please visit: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/outlook-for-ios-and-android-configuration-with-microsoft-intune#configure-contact-field-sync-to-native-contacts-for-outlook-for-ios-and-android

As you walk through the settings make note of the “Device Enrollment Type” for each configuration setting, e.g. “Managed devices”, “Managed apps”. The device enrollment type corresponds to the Intune “Device enrollment type” setting when adding a configuration policy (see screenshot below). It’s important to understand the differences as there are different settings for different types of profiles and if settings are used for an unsupported profile type, they simply will not deploy to the app. In addition to the contacts settings, there are also account configuration, wearable, and iOS notification settings that can be configured as well.

Let get started

The following example demonstrates syncing only certain contact fields to the local contacts app so the end user will see the caller ID for a contacts for phone numbers when calls are received.

Navigate to the Intune admin portal and select “Client Apps > App configuration policies > Add”

Give the configuration policy a name and select “Managed apps” as the Device enrollment type as I’m pushing this policy via an App Protection Policy.

Select “Associated app” and select Outlook for the platform(s) you’re interested in configuring Outlook for. For “Managed Apps” I recommend using a single policy for iOS and Android to maintain consistency across platforms.

Add configuration settings to configure the app configuration settings for contacts in Outlook as shown below. These are key/value pairs and are documented here: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/outlook-for-ios-and-android-configuration-with-microsoft-intune#configure-contact-field-sync-to-native-contacts-for-outlook-for-ios-and-android

I’m only allowing first name, last name, and mobile phone number. If other phone fields are required such as home, office, other, you may want to allow those as well. Note: these fields match up to the existing fields in Outlook contacts and the native contacts app.

Assign the policy to a group of users:

Syncing contacts to the native contacts app

For contacts to show up in the native contacts app, users need to manually select “Save Contacts” in Outlook settings to sync contacts to their device.

Note: if you don’t see “Save Contacts” an Intune App Protection Policy may be blocking contacts sync. To check APP settings install and open the Edge browser and type in: about:intunehelp in the search box and view Intune app status for Outlook. If block contact sync is enabled, it will be set to “1” disabled will be set to “0”. Also, the “Save Contacts” setting cannot be set by policy at this time.

As shown below, only the fields specified in the Outlook configuration policy show up when the contact is accessed from the native contacts app. All other fields are blanked out. Even if I add the additional data to the fields, such as a phone number, the field will show up populated in the native contacts app then disappear when the policy refreshes (the update to the field will retain in Outlook though).

If you continue to see the fields that are blocked, try waiting a few minutes and disabling and re-enabling contact sync in Outlook.

Finally, when the email profile is removed from Outlook so are the sync’d contacts from the native contacts app.

Additional info

For MDM enrolled iOS devices, if contacts do not sync with the native contacts app after going through the steps above, because of certain Apple restrictions, you may need to toggle these settings to “Not configured”. There is a support post on this topic that is worth reading with additional tips: https://blogs.technet.microsoft.com/intunesupport/2018/04/17/support-tip-ios-11-3-and-native-contacts-app/

NFC-based Android Enterprise device enrollment with Microsoft Intune

I am pleased to have Chris Baldwin from Microsoft as a guest blogger this month. Chris is a Principal PM for Android on the Intune Engineering team. Chris has been working in Android space for the past couple years and leads delivery of Android Enterprise features.

NFC-based Android Enterprise device enrollment with Microsoft Intune – By Chris Baldwin, Principal PM, Microsoft Corporation

For corp-owned Android Enterprise devices (technically referred to as devices in “device owner” mode) there are a number of streamlined enrollment methods available. Depending on your Android version it’s possible to enroll devices with a QR code, by manually entering a short enrollment string, through Google’s Android zero-touch enrollment service (basically, Android’s answer to Apple’s Device Enrollment Program). It’s also possible to use NFC to perform enrollment, which makes provisioning devices as easy as tapping them on a specially formatted NFC tag. This blog will explain how you can use a couple inexpensive and readily available tools to program your own NFC tags to use for Intune device enrollment.

Android Enterprise for BYOD and corp-owned devices
There are two core ways to manage Android Enterprise devices depending on whether the device belongs personally to the end user of the device (BYOD) or if the device is corp-liable, an asset owned by your organization. Those modes are:

    • Work profile – in this mode of management the end user self-initiates enrollment with a device they own. The enrollment process creates a new, MDM-managed work profile on the device that sits alongside the user’s personal profile. The work profile is managed by the IT admin and the personal profile is not. This provides both privacy assurances to end users because their personal profile remains unmanaged, and data protection assurances to the IT admin because the work content is containerized and manageable.

 

  • Device owner – in this mode the device is fully managed (it is analogous to supervised mode on an iOS device). Device owner mode is unique in that there are two main deployment scenarios that can be configured when devices are in this mode: Dedicated devices, which are userless, heavily-locked down kiosk-style devices ideal for task worker usage, and Fully Managed devices which are associated with and user’s AAD account and are intended for core productivity usage (calling, messaging, Outlook, Office apps, and so on). Enrollment of device owner devices is also unique in that the device must be fully factory reset to be enrolled.

As of the writing of this blog, Intune supports work profile mode and the Dedicated (kiosk) device owner deployment scenario. Fully Managed support is currently being built and we expect it to be in public preview by the end of 2018, with general production support available in Q2 of 2019.

Why use NFC?
There are a couple reasons why using NFC-based enrollment might be useful for your scenario. First, it’s the only device owner enrollment mechanism that is supported on Android version 5.1. If you are using 6.0 and up there are additional options. Second, it’s very easy to use. You can program your NFC enrollment tag with Wi-Fi connection information, so you don’t need to perform any steps to enroll the device beyond tapping it. As a reminder, NFC enrollment is available on device owner devices only, and won’t work for work profiles.

What you’ll need
For NFC-based enrollment, you’ll need two items:

    1. Blank NFC tags. I used NTAG216 NFC tags, however you may use any tags that you’d like. One thing to remember is NFC cards come with varying amounts of capacity in bytes. You’ll want to be sure that you buy ones with enough byte capacity to store all the NFC data necessary for enrollment. The amount of capacity you’ll need varies depending on how many options you put into your NFC data, but at minimum you’ll need 561 bytes. More will be required if you add Wi-Fi connection options. The NTAG216 tags I used have a usable capacity of 888 bytes.

 

  1. Once you have the blank tags, you’ll need something to imprint/write the correct data onto the tags. You may use any NFC tool that you choose as long as it’s capable of writing NFC tags with an arbitrary mimetype. I demonstrate the process later in this post using the NFC Tools PRO app from the Play Store.

Steps to follow
Guidelines

  • The NFC data that will be written to the NFC tags needs to be of a very specific format and will contain a lot of boilerplate data.
  • There is a portion of the tag data that you can copy and paste directly from this post because it will be identical for every Intune enrollment.
  • There is also part of the tag data that must be changed to match the enrollment token generated in your Intune tenant.
  • Finally, there are optional NFC data parts that you can choose to use if you want to use the tag to automatically turn on Wi-Fi during the NFC provisioning process.

Step 1: Format your NFC data
Tag data that must be copy-pasted as-is
The following NFC data lines must be entered precisely as they appear here. These lines tell the device where to download the MDM agent from and ensure that it is installed properly:

android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https://play.google.com/managed/downloadManagingApp?identifier=setup
android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM=I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg
android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME=com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver

Tag data you must change for your tenant
The line below must be copied precisely as it appears, except you must change the highlighted text to match the enrollment token you want to use for the device enrollment. This should match the token text that is displayed in the Intune admin console. This is what will associate your NFC enrollment with your Intune tenant.

android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE=com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN=NMEFNXHOVYMEMSSLBRSR

Optional tags you can use for Wi-Fi connections
Optionally, you can use these lines to tell the device to automatically connect to a W-Fi network that it’ll use to perform enrollment. For example, these are the lines I used to connect to an open authentication network in my office called “MSFTGUEST”:

android.app.extra.PROVISIONING_WIFI_SSID=”MSFTGUEST”
android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE=NONE
android.app.extra.PROVISIONING_WIFI_PASSWORD=

Note: I have observed that the PROVISIONING_WIFI_PASSWORD line must be included even if there is no password required for the network. It seems like a quirk that shouldn’t be necessary, however I have seen devices fail provisioning without it. The valid options for security type are NONE, WPA, and WEP.

Step 2: Configure the app with the tag data
As a reminder, I’m using the NFC Tools PRO app to demonstrate the enrollment process, however you may use your tool of choice for writing NFC data.

  1. Under the Write tab, select Add a record
  2. Scroll to the bottom and select Data: Add custom record
  3. In the content-type field enter “application” in the first text box and then “com.android.managedprovisioning” in the second (without the quotes)

Take the all the tags above and put together to look like the following and past it into the data section of the app:

android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION=https://play.google.com/managed/downloadManagingApp?identifier=setup
android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM=I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg
android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME=com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver
android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE=com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN=LSKDINVIGHNCTXNZQDIS
android.app.extra.PROVISIONING_WIFI_SSID=”MSFTGUEST”
android.app.extra.PROVISIONING_WIFI_SECURITY_TYPE=NONE
android.app.extra.PROVISIONING_WIFI_PASSWORD=
  1. In the Data: field enter the big NFC data blob that you formatted in the step above. It should look close to this:
  2. Tap OK

Step 3: Write your NFC data to the tags

  1. Tap Write
  2. Bump your device against your blank NFC tag

Step 4: Enroll devices!
Now that you have your properly formatted and programmed NFC tag from Step 3, the only thing left to do is to enroll devices. You can do this on any Android 5.1 or above device:

  1. Factory reset the device (this is a necessary step for any device owner provisioning)
  2. Once the device is reset and is on the initial welcome screen, bump the device against your NFC tag
  3. Tap OK

From this point on, the device will enroll into Intune using the enrollment token your specified in your NFC data. You can use the same NFC tag again and again to quickly bulk provision a large number of devices. If needed, you may reprogram the tags with different enrollment tokens as well.

Conclusion
NFC is one of the lesser known enrollment techniques for Android Enterprise, however it can also be one of the most powerful because of how easy it is to kick off device enrollment once you get the tags properly programmed. I hope you found this useful!

Android Kiosk Enrollment and Microsoft Intune

Last month I wrote about the different Android enrollment scenarios Microsoft Intune supports. For this month’s post, I’m focusing on the Android enterprise enrollment process, specifically single purpose device enrollment (e.g. kiosk) using a factory reset device.

Note: the device must be factory reset to enroll using Android enterprise.

Let’s get started

Create an Azure AD Group

Create a group in Azure AD that will dynamically add Android enterprise devices to it. This group will be associated with the Android enterprise enrollment profile. To do this,

  1. Navigate to portal.azure.com, locate and select Azure Active Directory
  2. Select Groups > New group
  3. Group type should = Security
  4. Provide a name for the group such as “Android Enterprise Kiosk Profile”
  5. Membership type = Dynamic device
  6. Select Dynamic device members

Use a simple rule using the “enrollmentProfileName” attribute to create the dynamic rule as shown below:

Create Android enterprise device enrollment profile

  1. Find and select Microsoft Intune from portal.azure.com
  2. Under device enrollment > Android enrollment select “Kiosk and task device enrollments”
  3. Create a new enrollment profile by selecting “Create”
  4. Provide a name and select an expiration date for the Token (this can be used to register devices with a token or QR code if necessary)

Add apps from Managed Google Play

  1. Navigate to the Managed Google Play account by selecting Mobile apps > Managed Google Play > Open the managed Google Play store
  2. Search for and add the “Managed Home Screen” app and additional apps you’d like on the locked task screen for the device.
  3. Sync with Managed Google Play within Intune and assign the apps and/or weblinks to the kiosk group created earlier.

For the apps to show up on the locked task screen (i.e. kiosk device) we must do two things:

  1. Under Mobile apps in Intune, assign the apps to the Azure AD group we created earlier (“Kiosk and task device enrollments” in my case), including assigning the Managed Home Screen.
  2. In the configuration profile we’ll create next, under kiosk add the same apps, except the Managed Home Screen (leave the Managed Home Screen out of the configuration profile).

Creating an Android enterprise kiosk configuration profile

  1. Within Intune select Device configuration > Profiles > Create Profile
  2. Select Properties > Platform = Android Enterprise, Profile type = Device restrictions
  3. Under settings select Kiosk > Kiosk mode: either select Multi-app or Single app kiosk. For this post I’ve selected Multi-app kiosk.
  4. Select Add and add the apps previously added to Managed Google Play that were synced with Intune. Remember, do not add the Managed Home Screen app (otherwise it will show up as an app on the screen of the kiosk device which isn’t necessary).

For the remaining settings, feel free to configure the other settings to match your business requirements.

Enrolling devices

There are various methods for enrolling a device shown in the table below:

Enrollment method Minimum Android OS supported
NFC (Near Field Communication) 5.1+
Token entry (manual setup) 6.0
QR Code 7.0
Zero Touch (ZTE) 8.0

For more details about Android kiosk device enrollment with Intune please visit: https://docs.microsoft.com/en-us/intune/android-kiosk-enroll#set-up-android-kiosk-management

Below are the series of steps performed when my Pixel 2 device is enrolled with Intune with Android enterprise as a multi-app kiosk using a QR code, of course if you prefer, zero-touch is available on supported Android (8.0+) devices as well:

 

Tap on the screen six times

I tapped 5 times and it’s asking me for 1 more tap

 

Needs to download the QR reader app before QR code scan

 

Connect to Wi-Fi so we can download the QR reader

 

Once connected to Wi-Fi the device checks for updates

 

Downloading Google Play Store

 

Checking device info…

 

Installing QR Reader

 

Once the QR Reader is installed it will use the camera to scan the QR code under the Android enterprise enrollment profile created earlier

 

QR code is accepted and we’re prompted to continue setting up the device.

 

Updating the Google Play Store again which is connecting to the Managed Google Play store

 

Downloading Google Play services…

 

Uploading Google Play services…

 

Finish device updates

 

Registering the device with Intune

 

Intune device configuration policy we created earlier is now applied

 

The Managed Home Screen is applied and the apps we assigned earlier are shown on the locked down kiosk screen.

Android + Intune = Android management

When I speak with organizations who are considering Android devices there’s usually the question of, “which management option should we choose?”. The answer to the question requires a clear understanding of the scenarios the organization would like to bring under management such as personal devices or corporate devices or even purpose-built devices (e.g. inventory scanners, digital signage, etc.).

There are many different versions of Android from many different OEMs and choosing and supporting each version can be challenging. However, as I’ll discuss later in this post, Android enterprise aims to address OEM fragmentation while providing a variety of management options. Fortunately, Microsoft Intune will address various Android management methods available today including those offered with Android enterprise, so let’s look at how Android management is accomplished with Intune.

The table below walks through each available Android device management scenario, how Microsoft Intune supports it, as well as items to evaluate when considering each option.

Device Management Type Enrollment Type Intune Management
Android Device Admin
Considered legacy administration, the Android device administration API has provided APIs to manage the Android device since Android 2.2. The issue with device admin is there are only so many management APIs available, the user experience is challenging, and according to Google, device admin will be depreciated in 2019. With Android Q, device admin will not be available at all.Device Admin requires an Android device to be enrolled via an MDM and requires various administrator permissions during certain enrollment scenarios. As such, device admin offers insufficient privacy for BYOD, insufficient management capabilities for corporate owned devices, and a poor user experience all around. In addition, device admin is less secure than Android enterprise and device admin is not ideal for an environment requiring minimal or no touch enrollment.To learn more about device admin deprecation please visit: https://developers.google.com/android/work/device-admin-deprecation
Intune supports devices enrolled with device admin on Android 4.4+

To enroll a device to Intune using device admin please visit: https://docs.microsoft.com/en-us/intune-user-help/enroll-your-device-in-intune-android

In addition, Intune App Protection policies are supported with device admin (or without enrollment): https://docs.microsoft.com/en-us/intune/app-protection-policy

For BYOD, Intune App Protection policies are a great choice as the policies protect the corporate data at the app layer without requiring the user to enroll their device.

Samsung KNOX Standard
With Samsung devices, Samsung added their own management APIs which expands the management capabilities for devices enrolled with device admin.  An example is managing the email profile for the native email app on a Samsung device.KNOX is only available with certain Samsung devices so utilizing other OEM devices would require device admin or Android enterprise.Note: Samsung has announced the unification of KNOX and Android enterprise. More details may be found here: https://www.samsungknox.com/en/blog/android-enterprise-and-samsung-knox-your-questions-answered-hereSamsung also offers KNOX Mobile Enrollment (KME) which allows for automatic enrollment of devices even after a reset. KME is supported starting with Android 2.4 and KME is beneficial for mass enrollment of devices without having to touch each one. Devices may be manually and/or added through a carrier to an MDM. After which, users will experience a streamlined enrollment process which removes the touch points required by device admin.KNOX Mobile Enrollment is only available with Samsung devices so if no touch enrollment is needed for other device OEMs, Android enterprise may be an option.To learn more about KNOX Mobile Enrollment please visit: https://www.samsung.com/us/business/solutions/samsung-knox/mobile-security-solutions/knox-mobile-enrollment/
Intune supports KNOX standard without additional licensing for KNOX. However, KNOX also requires Device Admin enrollment as well. Once a device is enrolled with an MDM the end user will also see prompts about KNOX after which both device admin and KNOX policies may be deployed to the device. KNOX Mobile Enrollment streamlines the enrollment process by enrolling the device automatically.

To learn more about enrolling a device that supports Samsung KNOX with Intune please visit: https://docs.microsoft.com/en-us/intune/android-enroll#end-user-experience-when-enrolling-a-samsung-knox-device

In addition, Intune App Protection policies are supported with Samsung KNOX: https://docs.microsoft.com/en-us/intune/app-protection-policy

Intune supports KME and to learn more about setting up KME with Intune please visit: https://docs.microsoft.com/en-us/intune/android-samsung-knox-mobile-enroll

In addition, Intune App Protection policies are supported with devices enrolled with KME: https://docs.microsoft.com/en-us/intune/app-protection-policy

Up to this this point we’ve reviewed traditional management methods available on Android as well as enrolling and managing Android devices with Intune. However, if you’ve noticed, there seems to be a theme throughout and it’s around Android enterprise. It appears all paths are leading to Android enterprise so let’s learn about what Android enterprise is and how Intune will assist with managing devices enrolled using Android enterprise.

Android enterprise

There are two primary modes of management under Android enterprise (AE). Work profiles for BYOD and Device Owner for corporate owned devices.  More details on Android Enterprise device ownership please visit: https://developers.google.com/android/work/requirements 

Android enterprise
Android enterprise (AE) offers a variety of management scenarios for certified devices providing more robust management APIs over device admin. Although Android enterprise is supported on Android 5.0+, Google recommends 6.0 or later.Once a device is enrolled in an MDM such as Intune, Android enterprise has the concept of a work profile (formerly Android for Work) that separates or containerizes corporate applications and data on a personal device. The managed profile contains corporate data and allows only applications within the work profile to access the data within while leaving personal data separate. To learn more about work profiles please visit: https://support.google.com/work/android/answer/6191949?hl=enIn addition to work profiles, Android enterprise offers Device Owner mode where corporate owned devices are enrolled with an MDM and managed based on the purpose their intended for. To learn more about Android enterprise management for company-owned devices please visit: https://www.android.com/enterprise/management/To provision the device owner mode the device must be factory reset, unfortunately there are no migration paths to device owner mode from device admin. The provisioning process may be driven by NFC, QR code, or zero-touch. Previous versions of Android such as 5.0 and 5.1 can use an activation code to begin the enrollment process.For more details about device provisioning please visit: https://developers.google.com/android/work/prov-devicesTo learn more about AE management scenarios please visit: https://www.android.com/enterprise/management/Note: as stated previously, moving from device admin to Android enterprise requires a factory reset. Consider the ramifications of already deployed devices to end users and in the workplace before beginning a migration. A strategy of enrolling new devices with device owner while continuing to manage existing devices enrolled with device admin may be an option. Through attrition, devices will onboard using Android enterprise. As mentioned earlier, with Android Q, device admin will not be an option.
Intune supports Android enterprise purpose-built device management including single-use and work profiles which aligns with many organizational use cases.

Details on how to configure Intune to and manage devices supporting Android enterprise are below.

Management of Android enterprise managed profiles and other details may be found here: https://docs.microsoft.com/en-us/intune/android-enterprise-overview

Connect Intune to Android enterprise:

https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

Android enterprise single-use (Kiosk) devices Intune enrollment: https://docs.microsoft.com/en-us/intune/android-kiosk-enroll

In addition, Intune App Protection policies are supported with Android enterprise: https://docs.microsoft.com/en-us/intune/app-protection-policy

Applications, including LOB apps are published through managed Google play.

Selecting an enrollment option

Choosing an enrollment option really depends on the scenario and what your business requires. For example, if your devices require minimal or no touch enrollment you may consider KNOX Mobile Enrollment and/or Android enterprise. Since Android enterprise appears to be OEM agnostic, if the plan is to have various device OEMs deployed, devices supporting Android enterprise may be an option. However, if devices are used for kiosk, digital signage, ticket printing, inventory scanning, Android enterprise would be something to investigate as well. If devices are personal devices (BYOD), I recommend looking at Intune App Protection for unenrolled devices and/or Work Profiles. Lastly, before selection consider the short- and long-term ramifications of one option over another.

That’s it! We’ve reviewed the options available for Android enrollment and Intune, documentation on how to enroll Android devices, and the future of Android management through Android enterprise.

Microsoft Flow and Azure AD – let’s automate!

 

When I speak with organizations we often discuss scenarios such as having an onboarding process that is in need of a front-end utility and automation.  Many organizations have cloud services and on premises applications where the user onboarding process in some cases is still a manual procedure.  To assist with these processes and many others, Microsoft offers as service called Microsoft Flow.  I’m always looking for creative uses of applications and Microsoft Flow offers just what we need to help automate processes such as account management across applications and services.  In addition, Microsoft Flow goes well beyond just automating a user management processes (e.g. onboarding) as discussed below.

 

What is Microsoft Flow?

“Microsoft Flow is a service that helps you create automated workflows between your favorite apps and services to synchronize files, get notifications, collect data, and more.”

Source: https://docs.microsoft.com/en-us/flow/getting-started

Microsoft Flow allows you to create workflows to automate tasks, for example, when files are added to a folder in a cloud storage environment such as OneDrive or Box, notify a user. Or create an approval workflow process to manage tweets before they’re posted to Twitter.

 

Microsoft Flow offers connectors to connect to either cloud applications or on premises environments.

To view a list of Microsoft Flow connectors, please visit: https://us.flow.microsoft.com/en-us/connectors/

 

In addition, there are many pre-defined templates that may be utilized such as starting an approval process when a new item is added to SharePoint or save tweets to an Excel file or sync files between cloud drives or a file server via FTP.  The list goes on and on…

To view a list of Microsoft Flow templates, please visit: https://us.flow.microsoft.com/en-us/templates/

 

Microsoft Flow Licensing

Some features are free and require premium Flow sku.  For more details about Microsoft Flow licensing please visit: https://flow.microsoft.com/en-us/pricing/

Microsoft Flow FAQ: https://docs.microsoft.com/en-us/flow/frequently-asked-questions

 

For this post, I will utilize Microsoft Flow to create users in Azure AD as well as provide custom bonus flows! so let’s get started…

As an administrator, the first thing we need to do is access Microsoft Flow and create a new workflow.

Navigate to https://flow.microsoft.com and sign-in.

Search for Azure AD in the search box provided as shown below:

image

 

From the results page, locate and select “Create Azure AD User From Button”

image

 

From there select “Continue” to add the template:

image

 

For more details about the Microsoft Flow Azure AD connector and templates, please visit: https://us.flow.microsoft.com/en-us/connectors/shared_azuread/azure-ad/

 

From here you can use the template as is and select Create flow, or you change the name and edit the steps in the template provided:

image

 

I chose to edit the “Send an email” step in the flow as I wanted a little more detail, I began the editing process by selecting “Send an email”:

image

 

The default template only offers a one-line sentence of info, however I changed it to add information the manager and the end user would need:

image

 

We can also edit each flow step or add more if necessary by deleting or adding fields (if the field is used downstream in the flow you’ll need to delete the field first downstream):

image

image

 

“Adding an Azure AD User” Flow in action

The great thing about Microsoft Flow is a flow may be run on a schedule, via an event or trigger, or manually from the web or the Mobile app. 

Additionally, Flow templates may be shared out to other users to access as well, so administrators don’t always need to be in the process.  Ultimately a Flow template configuration is up to you and what works best for your processes within your organization

 

Flow Web App

To manually start the newly created Flow template, when in the Flow template select “More” from the top and then select “Run now”

image

 

From there the template with a list of fields will open for a user to manually fill in:

image

 

Once all the fields are filled in properly, select “Run flow” and a new user will be created in Azure AD.  I show more details and results below using the mobile app.

 

Mobile App

I find the Microsoft Flow mobile app very easy to use, especially when on the go.  In fact, flows may be created and edited directly from the Microsoft Flow app.

Download the Microsoft Flow app from your favorite app store, in my case I have the iOS app installed on my device.  The first time Microsoft Flow app is launched you’ll need to sign into your Azure AD tenant (be sure that user has rights to create users, groups, access apps, etc.).

 

Select “Buttons” at the bottom of the app:

SNAGHTML4c3e814e

 

Locate the the button that will create the Azure AD User:

image

 

Fill out the form and submit:

image

 

Here are my inputs from my Flow template process, when finished select “Done” at the top of the app and the Flow will run:

imageimage

 

Once the Flow has completed, we can look at the run history and the details of each flow process (great for troubleshooting as well):

imageimage

 

Expanding the “Send an email” flow we see the following:

image

 

Below is the customized email received by a user or manager after the user is created (including a randomly generated password):

image

 

Lastly, below is the user that was created by the Flow process in the Azure AD admin portal:

image

 

Dynamic groups

Once users are created, dynamic group memberships may be used to automatically assign users to group, for example, any user may be dynamically assigned to Group A. Group A can also be assigned to licenses, SaaS applications or assigned to SharePoint Online/OneDrive, so as soon as a user is assigned to a group they’ll have access to the licenses and apps assigned to it.

Dynamic group membership eases the management process of adding and removing users to applications. Simply assign a group to the application permission and use dynamic group rules to automatically assign and remove users. You can even use attributes such as employeeId, mail, or companyName as attributes to look for, however there are many more attributes to choose from and depending where the users originates from, you may want to get creative.  Finally, for applications that support provisioning, users may be automatically provisioned and provisioned to SaaS applications which provides full user lifecycle management.

For more details about Azure AD Dynamic Groups please visit: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-groups-dynamic-membership-azure-portal

 

BONUS FLOWS 

Need to disable or enable sign-on for a user quickly in Azure AD (i.e. O365, Dynamics365, etc.) from your mobile device?  I created Flows to do that.

 

Current sign-in state of the user shown in Azure AD and O365 Portals (it’s the same setting btw) shown below:

imageSNAGHTML13b5bc02

 

I created a button in Microsoft Flow and filling out the following fields in red:

image

 

When the flow is run, type in the UPN (email address) of the users and flow will disable sign-on for that user.

image

image

 

New sign-in state of the user shown in Azure AD and O365 Portals (it’s the same setting btw) now blocked shown below:

imageimage

 

Enable sign-on for an Azure AD user

Follow the Flow creation process above to create a Flow to enable a user to sign-on, however change the “Account Enabled” setting to “Yes”.  Note: Flows may be copied, to copy a flow select Save As for the flow you’d like to copy in the Flow portal and modify from there.

As a result we’ll end up with two flow as shown below:

image

 

And the flow buttons on my mobile device:

SNAGHTML14328189

 

Delete Azure AD Users

Now a question you may have is “can we delete Azure AD Users using a button?”  You could, however there is nothing built in with Flow or connectors today.  A custom app would need to be developed with the proper permissions to the Microsoft Graph to delete an account then added to flow.  So this would be more of a custom development approach that what I demonstrated in this post.  As a result, using Microsoft Flow we can create a custom connector that will call into the app registered with Azure AD to make calls to delete users using a button flow in Microsoft Flow.  Same holds true for resetting user passwords.

With Microsoft Flow, the possibilities are endless with the predefined templates and built-in connectors to services, you don’t have to be a developer to automate processes and workflows!

Windows Information Protection Explained – Windows 10 Creators Update

 

With the release of Windows 10 Creators Update there have been many enhancements to Windows 10. For this post, I’ll focus on an expanded feature that is only available in version 1703 (i.e. Creators Update).

In Windows 10 version 1607 we released Windows Information Protection where devices that are enrolled with Microsoft Intune (or SCCM) may receive policies that protect corporate application content from data leaks. In Windows 10 1703 (i.e. Creators Update) a new feature called Mobile Application Management or MAM is available. If you’re familiar with MAM policies for Intune for iOS and Android we’ve brought similar functionality to Windows 10 Creators Update for non-managed devices. This means that non-managed devices such a home user PC with Creators Update can access corporate data without risking data leakage because the MAM policy will prevent cutting and copying data to unmanaged applications.


Requirements

  • Intune licenses
  • Global Admin for Azure Active Directory
  • Windows 10 Creators Update (any version)

Getting started

Service setup

  1. Navigate to portal.azure.com from a browser
  2. Select Azure Active Directory
  3. Select Mobility (MDM and MAM)
  4. Add or select Microsoft Intune

 

clip_image002

 

Verify the settings look similar to those in the image below. Add a group as well to make sure the policies flow to the proper individuals:

Note: if the MAM Discovery URL is missing, select “Restore default MAM URLs”

clip_image004

Policy setup

From the Azure portal locate the Intune Mobile Application Management (MAM) service. It will look similar to the following:

clip_image006

 

Select “App Policy” and “Add a policy” at the top. Give the policy a name and select Windows 10 under Platform.

clip_image008

 

Now we need to configure what apps the MAM policy will apply to. Do this by selecting “Allowed apps” and then “Add app” at the top of the blade:

clip_image010

Fortunately, many Microsoft applications are already published to select from, for the purposes of this post I’m going to select Microsoft Edge, Notepad, and IE11. The apps in this list are what we call “enlightened apps” where they know about MAM policies. Refer to the links at the end of this post for how non-enlightened apps are supported.

Note: For custom apps, desktop apps, etc. that need to be added, information about these apps is easily found using App Locker via the local policy editor on the device where the apps are installed. More details: https://docs.microsoft.com/en-us/windows/threat-protection/windows-information-protection/app-behavior-with-wip

clip_image012

 

Data Protection

After selecting apps from the list, in my case Notepad, Edge, and IE11 we now need to configure the behavior of when protected data is moved from those apps to non-protected environments (e.g. WordPad).

Select “Required settings” from the policy. The only change I made is to select “Allow Overrides” which means the user will be prompted when they attempt to relocate corporate data outside of the managed app (very similar to how MAM works with iOS and Android):

clip_image014

 

Now move to “Advanced settings” where there are a number of options to further restrict and identify boundaries.  For this post I’ll keep it simple by adding a cloud resource as a network boundary, in this case SharePoint Online and turn on “Show the enterprise data protection icon” for the protected enlightened apps:

clip_image016

Note: Once service and client are configured, you may encounter site access issues, to remediate, add the Value “|/*AppCompat*/” (no quotes) string to the end of the URL string, more details here: https://docs.microsoft.com/en-us/windows/threat-protection/windows-information-protection/app-behavior-with-wip

 

Once the boundaries are set and saved, we need to assign the policy to a group of users.  Feel free to create any group you want in Azure AD, I created one called MAM-WE_Users:

Note: users may be dynamically assigned to Azure AD groups as well for auto assignment to apps, licenses, etc., more details here: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-with-advanced-rules

clip_image018

Client setup

The end user will need to attach their non-managed (e.g. personal) Windows device with Creator Update to their workplace by selecting “Settings” then “Access work or school” and then “Connect” as shown below.

Note: Non admin users may enroll in MAM.

clip_image020

 

The user will then be prompted to sign on to their corporate account (i.e. O365, Azure AD, Intune, etc. if available) account as shown below (do not join Azure AD or local AD, typically this is performed only for corporate issued/owned devices).

To summarize, there are two steps, add your email and select next.

clip_image022

 

Once the account is verified, and the device is registered, select the account and the Info:

clip_image024

 

The “Info” button will show the last time the device had a successful sync. Also make sure the Management Server Address is populated. Keep this in mind as we’ll refer to this process after we have the MAM policy set up.

clip_image026

End User Experience

Because I’m protecting “.cbenterprisemobility.sharepoint.com” and selected both IE11 and Edge (they’re both enlightened apps) when I navigate to them we see a little briefcase icon show up.  When I navigate away from this site, the briefcase will go away.

clip_image028

clip_image030

 

For example, when I download a file from SharePoint Online, it will contain a little briefcase on the file icon as well as state the ownership of the file in “File ownership” column.  Additionally, the MAM policy can use either a custom EFS certificate or and Azure Information Protection template (RMS) to protect files.

clip_image032

 

When I open the file in a managed app (i.e. Notepad) and because the file is protected by policy, the app shows it’s managed by displaying a briefcase icon on the app itself:

clip_image034

Clicking on the briefcase icon we see the following:

clip_image036

 

When I attempt to cut, copy, and even open the file in an unmanaged app such as WordPad I receive the following prompt.  I can choose to give access in which case that action is logged to event viewer or cancel.  This prompt may be hidden from the user completely by changing the policy in Intune.  Separate policies may also be created and targeted at specific groups of users as well.  For example maybe you want to allow Executives to override as shown below and block certain users such as contractors, etc.

clip_image038

 

Closer look at the prompt:

clip_image040

 

If you need to change the file ownership, I right click on a file and change the file ownership to Personal if needed:

clip_image042

 

That’s all, we configured Mobile Application Management for a non-managed or domain enrolled Windows 10 client and successfully protected corporate content from leaking outside of corporate sanctioned applications.

Troubleshooting

  • First place to look is to make sure the settings are correct and sync’s are successful under Windows 10 Settings/Accounts/Access work or school
  • Next steps are to look in event viewer under: Application and Services Logs/Microsoft/Windows/Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin
  • MAM policies also land under: c:windowssystem32AppLocker folder and you can open the “policy” files in notepad.
  • You’ll also find the MAM policy settings populated under the following registry keys: HKEY_LOCAL_MACHINESOFTWAREMicrosoftPolicyManagercurrentdevice
  • When adding apps to protect, the prepopulated apps should be adequate, however if you’re adding protected apps by hand make sure the format is correct or the MAM policy will not take effect on that app.
  • When users upgrade from MAM to MDM on Windows Home edition, they lose access to WIP. On the Home edition, we do not recommend pushing MDM policies to enable users to upgrade.  More details here: https://msdn.microsoft.com/en-us/windows/hardware/commercialize/customize/mdm/implement-server-side-mobile-application-management

Closing thoughts

With all the data theft that happens daily, it’s better to have increased security for non-managed devices than simply guessing if your data is secure from those devices.  Whether your users have iOS, Android, or Windows devices, Intune MAM will protect all three.

Another option is to block unmanaged devices completely and Azure Active Directory Premium with or without Intune will address this scenario via Conditional Access.

For additional details about MAM with and without MDM as well as supporting desktop and custom apps, please refer to: