Microsoft Endpoint Manager Intune, Power Automate, and Microsoft Graph

One of my passions is working with customers and I’m fortunate to be able to speak with customers every day. Another passion of mine is automating tasks. A piece of customer feedback I receive is how to automate certain processes using the data within Intune, Microsoft 365, and 3rd party services.  Currently organizations may automate programatically by using the Microsoft Graph, however if you’re not familiar with using PowerShell or a developer it may be difficult to create a solution in the timeframe you need it by. Fortunately, there are Intune Graph samples available and if you’re intersted in viewing and utilizing the samples please visit: https://github.com/microsoftgraph/powershell-intune-samples.

Additionally, and the goal of this post, Microsoft Power Automate provides a robust set of templates and connectors to automate processes across Microsoft 365 and many other solutions.

For this post, using Microsoft Graph and Power Automate, I have automated end user email notifications after an end user has enrolled a device. The Power Automate (aka Flow) runs every hour and will send a mail to the end user who enrolled the device within the hour (or timeframe of your choice) of the last time the Power Automate process ran. From a security and user awareness perspective, an organization may want to notify users after a device enrollment completes, and if it wasn’t the user who actually enrolled the device, they could report it to their security and MDM teams.

Let’s get started

Requirements

  • Azure Active directory
  • Intune
  • Power Automate
  • SharePoint Online
  • Postman

Azure Active Directory

Register an application in Azure and creating and Power Automate connector for Microsoft Graph

We need to do several things to register an app in Azure AD and create a Power Automate connector, however registering an app in Azure AD and granting it permissions is several steps as is creating a Power Automate connector (because I use Postman to create the auth flow and query to Graph then save it out and import it to Power Automate as a custom connector). So to keep this focused on the automation piece, I found an individual online who published the following video who has a great walk through of how to do this in the first 30 minutes: https://www.bing.com/videos/search?q=graph+api+microsoft+flow&docid=608006419082446884&mid=DDFFFEB586D6DA665B5DDDFFFEB586D6DA665B5D&view=detail&FORM=VIRE

I recommend going through the steps in the video above and supplementing the perms and Graph call with the following:

To access Graph in Power Automate we to register a new application in Azure Active Directory so we can use it to make Graph calls to Intune. Once the application is registered we need to provide it the following application permissions to access Intune device objects:

Note: I have more perms granted than needed for this particular process, however the three above should be enough:

We also need to create a client secret and save it for later use in Postman:

Postman and Graph Explorer

If you don’t have Postman you can download it from: https://www.postman.com/downloads/

Use Graph explorer to come up with the query you’d like to use by visiting: https://developer.microsoft.com/en-us/graph/graph-explorer For this post I’m pulling all the managed devices from Intune: https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/

For reference, here is the authorization for the Flow connector collection I created in Postman.

You’ll save the collection out and import as a custom connector in Power Automate. Refer to the video above and it walks you through all this minus the uniqness of my query and app.


SharePoint Online

We need a method to look up when the last time the Flow ran and to do this I store one list item in a SharePoint list. The item I store is just the date, however what I really care about is the created time the list item was created because I call that in the Flow and compare it to when the devices were last enrolled. For example, if the Flow ran on 2020-04-03T20:22:15Z, the date is stored in SharePoint and for any device registered after that time, an email will be sent to the end user. It’s a simple process, however it works well.

The following is my SharePoint Online list where I store a formatted date in the Title fiel, however it really doesn’t matter what is stored in the Title field as the Flow looks for the “created” date for the single item. After the flow completes, I have a process in Flow that deletes the record and adds a new one so the next time it runs it has new date to reference.


Power Automate

At this point you should have an app registered with Azure AD, a connector created in Power Automate, and a SharePoint list to reference.  Now we can move on to the next step.

Let’s create the Power Automate process now:

In Power Automate select Create, name it, and as the trigger select “Manually trigger a flow”. We need a trigger, and for testing I recommend creating the Power Automate process with a manual trigger. When you’re ready to go live, delete the trigger and replace it with the Recurrence trigger, more on this later.

Here’s the Flow in it’s entirety, however I break it down in the next few steps:

First step in the Flow, beyond the manual trigger, is pulling the item from the SharePoint list.  Do to this, add a new action and search for SharePoint the select “Get items”. I’m not doing anything special in Get items as I’m just looking for that one item in the list so there is no need to limit or filter items:

Next add another action, select “Custom” and select the connector you created earlier:

Now we need to parse the JSON that was returned from the custom action above. Do this by adding an action and search for Parse JSON, then add it. As you can see in the image below I have a perfectly formatted JSON output, however this needs to be generated. To do this select “Generate from sample” and go to either Graph explorer or Postman and copy all the JSON query output and paste into the sample payload. Doesn’t matter if it’s a lot of data, once you select done in the sample payload prompt it will format properly and show something identical to what I have in the image below (provided you’re making he same Graph call).

Next I want to select only devices that have a UPN because we can’t send email if there is no UPN to sent it to.  If the device record has a UPN and was created after the timestamp we stored in SharePoint, the user will receive a mail (sample mail shown later on in this post). To do this add an action and search for “Select” and add it. In the “From” field add the value from the Parse JSON step above, and in the Map section, select the txt icon on the far right then choose userPrincipleName from the dynamic list:

This next step is a cascade of actions so pay close attention please:

  • Add an “Apply to each” action and select the Parse JSON value (just like you did in the Select step above).
  • Now add an embeded “Apply to each” action and add the value from the SharePoint step above.

  • Add an embedded “Condition” action (this is where we compare dates), and in the first box find and select “created” from the SharePoint items and select “is less than” and in the far right box select “enrolledDateTime”:

What I’m doing is comparing the single item created date pulled from SharePoint to the enrollment dates pulled from Intune:

SharePoint item created date

Device enrollment dates

  • In the “If Yes” box, add an action, then search and add “Send an email (V2)”. Then select from the dynamic items to craft a mail. We don’t need anything for “If no”.

The next three steps in the Flow are fairly self-explanatory so I expanded them for reference:

What’s occurring  in the “Apply to each 2” is a SharePoint value is selected from the SharePoint Get items step, then I delete the item. Next step is up to you, all I’m doing is converting the current date/time then adding it to the Title field of a new SharePoint list item, however you can do what you want in the middle step, just make sure the last step creates a single SharePoint list item as the created date needs to be referenced in a previous step in this Flow.

Testing the Flow

Once the steps above are complete, run a test to create an item in SharePoint, then register a device and make sure it shows up in Intune under device, then run another test.  So you’ll run two test, one to generate the SharePoint item, and other after the device is registered with Intune.

The following is the email Power Automate sends to the end user who enrolled the device:

When you’re ready to move this process into production, delete the manual trigger in the first step and replace it with the Recurrence trigger and run it on the interval that is best for your organization:

That’s it, we fully automated a process by using Power Automate to pull all enrolled device objects from Microsoft Intune, selecting only devices that have a UPN associated, and sending an email to end users who have enrolled their devices since the last time the Flow ran.

Intune, Android Enterprise Device Owner enrollments & system apps

With Android Enterprise Device Owner enrollments, have you ever wondered where all the system apps go when enrolling with Android Enterprise Device Owner? Well they’re there, however they’re not whitelisted and only apps whitelisted by your admin are available (depending on the device OEM, there may be some system apps that are automatically whitelisted, e.g. phone dialer app).

The good news is with the Intune 1909 release, system apps may be whitelisted as well! An example of a system app is the dialer or some OEM specific app such as a battery monitoring app or barcode scanner app.

To bring back System Apps individually, you’ll need to know the package ID. For example, on my Zebra device I’d like to whitelist the battery manager app and the desktop clock. The package IDs for those are: com.symbol.batterymanager and com.android.deskclock

System apps may be whitelisted and assigned by navigating to the Intune admin portal, selecting Client apps > Add > App type = Android Enterprise system app

Provide a Name, publisher and package name and save.

Under Assignments, assign the app to the device group where the device lives. In my case I use a dynamic Azure AD group to assign Zebra devices that are enrolled as Device Owner Dedicated (aka kiosk).

If you’re utilizing the Managed Home Screen, for the app populate so user can launch it you’ll also need to publish the app to the Managed Home Screen profile under device configuration as shown below.

Search for the app name, e.g. battery, and add it.

Policy sync should only take a few seconds and on the device the battery manager is whitelisted and is available for users to access from the Managed Home Screen.

That’s it, it’s that simple. Again, system apps can be whitelisted now using Intune.

Additionally, Line of Business (LOB) apps and Web app links may also be published right from the console.

To learn more about managing Android devices with Intune by visiting: https://docs.microsoft.com/en-us/intune/

Zebra, OEMConfig, Ivanti Velocity, and Microsoft Intune

I work with a lot of organizations who manage a wide range of devices including organizations who manage rugged devices.

Rugged devices are utilized in a variety of scenarios, including warehouses, big box stores, field engineering, logistics, emergency services, government, and so on.  Typically, these devices are locked down in modes where it’s dedicated to a specific use case, such as inventory scanning. Some organizations deploy multiple apps to a locked down screen where those apps are used in specific scenarios such as inventory look up and/or data entry.

For this month’s post I’m focusing on a specific scenario I run into quite a bit with rugged devices and an app called Velocity (powered by Wavelink) by Ivanti.

According to the Ivanti Velocity user guide:

Ivanti Velocity is an Android client that can connect to Telnet hosts (including IBM 5250/3270 and VT100/220), web apps, and Oracle SIM hosts. For Telnet and Oracle SIM hosts, it can present applications to your users in a modern touch interface, either with automatic, predictive reformatting or with a customized experience.

Source: https://help.ivanti.com/wl/help/en_US/Velocity/2.0.0/admin/velocityConsoleHelp.htm

The Velocity app may downloaded directly from Ivanti and is found on Google Play: https://play.google.com/store/apps/details?id=com.wavelink.velocity

So naturally I was curious about managing the Ivanti Velocity app on an Android device managed with Microsoft Intune. For the device, I chose to utilize a Zebra TC-57 rugged device.

Requirements for this scenario

  • Microsoft Intune
  • Zebra device
  • Zebra OEMConfig powered by MX app from Google Play
  • Ivanti Velocity app from Google Play
  • Ivanti Velocity deployment bundle (.wldep file)

Special thanks to Alex Evans from Ivanti who supplied me with a demo deployment bundle, thanks Alex!

Let’s get started

Device enrollment
I chose to enroll my Zebra device as a dedicated device under Android Enterprise Device Owner enrollment. Fortunately, I posted on this already, so I don’t have to re-create the steps. To learn more about enrolling a device as a Dedicated (kiosk) device please visit: https://uem4all.com/2018/08/06/android-kiosk-enrollment-and-microsoft-intune/

Ivanti Velocity app deployment
Let’s add the Velocity app to Intune.

  1. Navigate to the Intune admin portal via https://devicemanagement.microsoft.com and select Client apps from the left hand navigation.
  2. Select Apps > Add > App type > Managed Google Play and search for “Ivanti Velocity” and should look something like the image below. Go ahead and approve the app and chose your approval settings when prompted, then save.
  3. After the app info has synchronized to Intune, assign the app to the device group you created you went through the device enrollment steps above. This will ensure the app is deployed to the device.

 

Intune Managed Home Screen config
After the Ivanti Velocity app is assigned, if it is a dedicated device, you’ll most likely be utilizing the Intune Managed Home Screen. Whether it’s a single- or multi-app add the app to the list so it’s available on the Managed Home Screen. Note: I covered this in the post I referenced above…

Once the apps are deployed to the Managed Home Screen you’ll see them populate. Again, assign the apps to device for installation purposes under “Client apps” and in addition, add the apps to the Managed Home Screen under device configuration, as shown above, so they’re available for users to launch and interact with.


Ivanti Velocity app configuration deployment
Next, we need to create an Intune profile to push the Ivanti Velocity deployment bundle to the device. For this I utilize Zebra OEMConfig, Zebra StageNow, and an FTP server to push the Ivanti Velocity deployment bundle to the device.

Oct 2019 UPDATE
Zebra OEMConfig now supports File Management.  Simply add the path to the source to the Source URI (ftp-p://username:password@0.0.0.0:21/Velocity_Demo.wldep) and the Destination Path and File Name will be /sdcard/com.wavelink.velocity/Your_Velocity_Bundle.wldep

2019-10-23_14-07-32

If you’re not familiar with OEMConfig please review my earlier post on the topic: https://uem4all.com/2019/07/09/intune-oemconfig/


With the Zebra OEMConfig now supporting File Management, the step below using StageNow is now optional and you would either use the step above or the one below, not both.

<Begin optional steps>
Let’s start with Zebra StageNow…

  1. Zebra StageNow is a Windows application and may be downloaded by visiting: https://www.zebra.com/us/en/products/software/mobile-computers/mobile-app-utilities/stagenow.html
  2. Open StageNow and create a new profile, select the proper MX version (e.g. MX 8.2) for your Zebra device, then select Xpert Mode and then Create.
  3. Give the profile a name and select Start
  4. From the Settings tab select FileMgr and select the + sign to add it under the CONFIG tab and select Add as shown in the example screenshot below.

  1. In the StageNow Config under File Action select Transfer/Copy File.
  2. Under Target Path and File Name add the following: /sdcard/com.wavelink.velocity/Your_Velocity_Bundle.wldep, this will add the .wldep file in a folder named com.wafelink.velocity on the device. The Velocity app knows to automatically look in that folder and apply the profile info in the bundle.

Note: you can rename the .wldep bundle to .zip to peek at the files if needed.

  1. Select File on a remote server if not already selected and select the … to open the dialog.
  2. Under Staging Server select “External” and for the Source Path and File Name add the ftp server info, Zebra has documented this well and can be viewed by visiting: http://techdocs.zebra.com/mx/filemgr/

The source path to my FTP server looks like the following: ftp-p://username:password@0.0.0.0:21/Velocity_Demo.wldep

  1. Once we’re finished with entering all the parameters select “Continue” until you see “Complete Profiles”.
  2. Select “Complete Profiles” and then select “Export for MDM” and save the .xml file.

Locate where you saved the .xml file and open it and it will look similar to xml output below. Copy the data beginning with <characteristic… to the last </characteristic> as outlined in red in the image below.

<End of Optional Steps>


Intune OEMConfig Configuration
Frist we need to add the Zebra OEMConfig app from Managed Google Play; to do that, from the Intune admin portal, select Client Apps > Apps > Add > App type > Managed Google Play and search for “Zebra oemconfig”.  It will look something like the images below.

Go ahead and approve the app and chose your approval settings when prompted, then save.

Note: Intune also supports Datalogic, Honeywell, and Samsung OEMCOnfig. If you’d like to test settings for OEMConfig with other OEMS, search Managed Google Play from Intune and add their specific OEMConfig apps. Stay tuned for Intune expanding support of additional vendors who offer OEMConfig.

Create OEMConfig profile in Intune
We now need to create an OEMConfig profile in Intune. Do this by selecting “Device configuration” in the Intune portal > Profiles > Create profile.

Give the profile a name, from Platform select Android Enterprise, from Profile Type select OEMConfig. From here select “Zebra OEMConfig powered by MX” app.

Intune_OEMConfig

Select Configure > select the three dots next to Transaction Steps > and then select Add setting.

From the list of settings select, Device Administration Configuration.


  1. Under Device Administration Configuration only two settings are required.
  2. Action = SubmitXML
  3. Submit XML = the .xml data we copied above. Paste it into this field.

     

    Note: If needed, switch to the JSON view to see what the full JSON looks like. JSON view is really helpful when troubleshooting as well.

     

  4. Select OK and Save.

When the device syncs with Intune the apps and the OEMConfig settings will deploy to the file and push the Velocity app config file to the directory we specified.


 

The following video displays the profile I deployed using Zebra OEMConfig from Microsoft Intune in the Velocity app.

 The Velocity profile was populated on the device in a folder called com.wavelink.velocity.  

Finally, the Velocity app automatically knows to look there so it’s added when the app is launched.  

Next I scan some bar codes using the app to show inventory and other data.  You can’t see it, however I’m actualy scanning those barcodes in the video.

2019-09-09_14-57-23

 

Couple if items to be aware of:

  • In the Intune admin console, device sync status for app deployment, policies, etc. will show as “pending”, this is known.
  • At this time, only one OEMConfig profile may be assigned to a device.

That’s it!  This is incredible… the Intune team has made monumental investments across device platforms supporting a variety of different scenarios, from rugged devices, information workers, and bring your own.

Stay tuned for future updates and posts about Intune right here on UEM4all.com!

 

Intune, Samsung Knox, and OEMConfig

I work with many organizations who are beginning to migrate from Android device admin enrollments to device owner (i.e. Android Enterprise). While migration to device owner requires a factory reset on the device, once enrolled with device owner, devices have a more standardized approach to management and consistency vs. the fragmented management experience device admin enrollments exhibit when multiple OEMs are being managed.

Realizing there was a need to standardize and secure devices beyond the device admin APIs, years back Samsung introduced Knox. Samsung Knox provides an additional set of security and management APIs built on top of Android and is included with many Samsung devices. EMMs, including Microsoft Intune, also took steps to integrate with Samsung Knox to provide a rich set of management capabilities where the device admin APIs didn’t cover (e.g. email profiles).

Google requires device OEMs wanting their devices to be Android Enterprise Recommended (AER) to meet certain requirements thus standardizing and provide consistency across the Android Enterprise device ecosystem.  However, Samsung Knox remains available and continues to provide security and management features, in some cases, beyond what Android Enterprise offers with their current set of APIs.  Although Android continues to update/add security and management features with every API version.

With Android device owner enrollments, Samsung and other OEMs support OEMConfig.  OEMConfig provides a set of OEM specific features EMMs can configure along with standard device settings.

What is OEMConfig?

“OEMConfig policies are a special type of device configuration policy very similar to app configuration policy. OEMConfig is a standard defined by the AppConfig community (opens another web site) that allows OEMs (original equipment manufacturers) and EMMs (enterprise mobility management) to build and support OEM-specific features in a standardized way. Historically, EMMs, such as Intune, manually build support for OEM-specific features after they’re introduced by the OEM. This approach leads to duplicated efforts and slow adoption.

With OEMConfig, an OEM creates a schema that defines OEM-specific management features. The OEM embeds the schema into an app, and then puts this app on Google Play. The EMM reads the schema from the app, and exposes the schema in the EMM administrator console. The console allows Intune administrators to configure the settings in the schema.

When the OEMConfig app is installed on a device, it can use the settings configured in the EMM administrator console to manage the device. Settings on the device are executed by the OEMConfig app, instead of an MDM agent built by the EMM.

When the OEM adds and improves management features, the OEM also updates the app in Google Play. As an administrator, you get these new features and updates (including fixes) without waiting for EMMs to include these updates.”

Source: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview

Although Samsung offers OEMConfig settings, some Samsung features/settings require a Samsung license, for more details please visit: https://www.samsungknox.com/en/blog/knox-platform-and-android-enterprise

Intune documention on OEMConfig may be found here: https://docs.microsoft.com/en-us/intune/android-oem-configuration-overview

Let’s get started with OEMConfig with Intune and a Samsung device

Samsung Knox Service Plugin

First, let’s add the Knox Service Plugin from the Managed Google Play store which is required to deploy OEMConfig policies to Samsung devices.

Assumptions: Intune is already connected to Managed Google Play, if it’s not you can find details on how to do this by visiting: https://docs.microsoft.com/en-us/intune/connect-intune-android-enterprise

We’ll do this by navigating to https://devicemanagement.microsoft.com -> Client apps -> Apps -> Add -> App type = “Managed Google Play” -> select Managed Google Play Approve

To learn more about Samsung OEMConfig settings, browse through the Knox Service Plugin (KSP) admin guide: https://docs.samsungknox.com/knox-service-plugin/admin-guide/welcome.htm

Creating an OEMConfig profile for Samsung in Intune

Navigate to Device configuration -> Profiles -> Create profile -> add a name -> Platform = Android Enterprise -> Profile type = OEMConfig

Associated app = Knox Service Plugin – this is the app added in the previous step.

Select OK after selecting Knox Service Plugin.

After selecting OK we’re taken to Settings where we’ll see a full page of JSON. Don’t be intimidated it’s straight forward once you understand the structure which are just key/value pairs.

Update: as of the Intune 1907 release there is now a configuration designer with a UI, so no need to edit JSON.

2019-07-30_10-28-52

Continue reading for additional details about these settings and details about JSON if you prefer to edit manually:

Either select all and copy or select Download JSON template and open in your favorite text editor.

There are a couple values I want to point out in the JSON:

I mentioned at the beginning some Knox features/settings may require an additional Samsung license, this is where the license key would be set:

We want to turn on the policies, do this by setting doPoliciesIsControlled to “true

Troubleshooting – everyone likes an easy method to troubleshoot a device and by setting verboseMode to “true” will enable you to view the policies deployed to the device via the Knox Service Plugin app. More on this later in the post.

There many settings that are controlled with OEMConfig, however for the purposes of this post I’m going to turn off face recognition and only allow fingerprint. Disable face recognition by setting doPasswordBioFace to “false“.

Note: blocking the ability to use Face unlock to unlock the phone doesn’t prevent the device user from adding their face recognition. They just won’t be able to log in with face recognition as password and fingerprint are allowed in the OEMConfig.

Once you’ve completed filling out the JSON, copy and paste into Intune where you originally copied the JSON from and select OK then Save.

Note: you don’t have to have every key/value in the profile present, feel free to delete key/values from the JSON, just make sure the formatting is correct.

Device view

Once the policy is targeted to device it should only be a few seconds or so before the policy gets pushed to the device through Google services.

We can check if the policy deployed by opening the Knox Service Plugin app and selecting “Configuration on yyyy/mm/dd” (e.g. “Configuration on 2019/07/08”)

Select the “Configuration results” dropdown and select “Policies received” and from here we see the same JSON that was deployed from Intune.

Look for the password policy in the JSON as shown below:

On the same Samsung device navigate to Settings -> Biometrics and security -> Face recognition -> enter your password if prompted and we see “Face unlock” is disabled.  Again, we can add face recognition, however we can’t use it to unlock the device, so it’s essentially benign.

Here’s a video of the process above:

C02937BC-C8ED-4E0A-A3B2-3915A014D37A

Android Enterprise Dedicated device – matching a physical device to a device record in Intune

I work with organizations who have 100’s to 1000’s of managed devices in Intune.  When it comes to Android there may be various Android OEMs and OS versions organizations are managing and a variety of use cases for those devices.  With more organizations migrating to Android Enterprise they must choose an enrollment method based on the scenario.  With Android Enterprise there are several methods of enrollment, Dedicated, Work Only, and Personally-Enabled.  For more details on Android enrollment options please visit: https://www.android.com/enterprise/management/

For digital signage, kiosks, barcode scanners, etc. those devices are typically enrolled as a “Dedicated” device where a single or multiple apps are the only apps accessible by the end user. In addition, dedicated devices do not have user affinity, meaning the device isn’t linked in an MDM to a specific user unless there some sort of tagging associated which identifies the user or location of the device.

Because there’s no user affinity assiated with dedicated devices, I’m often asked, “what’s the best method to identify an Android device enrolled as a dedicated device (e.g. kiosk) in the Intune admin portal with a physical device in hand?”

There’s a simple method of doing this and it’s identifying the device by serial number. Here’s how to do it without removing the battery:

1.  With the device turned on tap on the arrow key on the bottom left about 15 times to launch the options (btw, the screen with the app(s) you’re accessing is called the Microsoft Managed Home Screen). Depending on the app configuration for the managed home screen you may see “Logs” and/or “Exit Kiosk”.

2.  Select “Logs” and slide up on the Logs banner to expand

3.  Find the “deviceInfo” and tap the + until it expands

4.  Locate “serialNumber” and match it to the device serial number under “All devices” in the Intune admin portal. If you don’t see the “Serial Number” column select “Columns” at the top of the page and add “Serial Number” to the list.

Here’s a video showing the process in action:

7068B017-43B0-4070-BA94-3F8AD24A918F

In summary whether your organization manages 10 or even 1000’s of devices, having a simple method of identifying a physical device will save a lot of time during the process of troubleshooting.

To learn more about Android device enrollment with Intune please visit: https://docs.microsoft.com/en-us/intune/android-enroll

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.

Note: currently there is an issue with Conditional Access and Android Enterprise where the device is treated as not enrolled.  Zscaler is working through this and we’ll provide an update as soon as the issue is resolved.

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

Intune MacOS management capabilities

Back in 2015 I wrote a blog about Mac management with Intune, however it’s been a few years and I feel it’s time we re-visit Mac management with Intune to learn more about what’s changed. You’ll soon learn there’s been a significant amount of progress and since my first post Intune now has a lot of native Mac management capabilities built in.

First let’s look at MacOS enrollment options with Intune.

MacOS enrollment options

There are two methods to enroll MacOS with Intune, user driven or using Device Enrollment Program.

User driven enrollment

For user driven enrollment the end user will need to sign into the web based version of the company portal via https://portal.manage.microsoft.com

If the user already had a device registered it will show on the screen, if the Mac is the first device being enrolled, they will see the following:

Once the user selects “Add this one by tapping here” they’ll be prompted to download the Intune Company Portal app.

After the Company Portal is downloaded and installed, open it up and you’ll be asked to sign-in using your corporate credentials. These are the same credentials used to sign into Office 365 (derived from Azure AD).

After sign-in is complete the device will begin the enrollment process.

For more details on user driven Mac enrollment please visit: https://docs.microsoft.com/en-us/intune-user-help/enroll-your-device-in-intune-macos-cp

Apple Device Enrollment Program

The concept of the Apple DEP is to associate devices with an organization and to streamline the enrollment process, similar to enrolling Apple iOS devices. However, enrollment requires a different process by associating an Apple enrollment token with Intune. After the enrollment token is added and enrollment profile is created in Intune and associated with the enrollment token.

During the enrollment profile creation process you’ll be asked to select user affinity (i.e. userless or user associated). Once user affinity is selected, you’ll also select whether or not you’ll allow users to remove the enrollment profile via the “Locked enrollment” setting.  Finally, you’ll customize the setup assistance which allows for hiding setup screen, e.g. Apple Pay, Siri, Registration, etc.

For more details on the Apple enrollment token process with Intune please visit: https://docs.microsoft.com/en-us/intune/device-enrollment-program-enroll-macos

Conditional access

An exciting feature of Azure AD is the ability to target certain device platforms (e.g. MacOS) and set a series of conditions for access by creating conditional access policies in Azure AD.

Compliance

Azure AD and Intune compliance policies also play a role in access. Step through the compliance policies below to view the restrictions that may be enabled for the device to be compliant.

Device Health

System integrity protection prevents malicious apps from modifying protected files and folders.

Device Properties

Specify which OS version and builds you’ll allow before accessing corporate resources.

System Security

Configured password and password integrity, storage encryption, firewall, and gatekeeper to project against malware.

Actions to take for non-compliance

Take action when devices are not compliant with the compliance policy by sending the user a mail and/or locking the device.

Associating an Intune compliance policy with Azure AD conditional access policy

Create an Azure AD conditional access policy to require the device be compliant to access corporate resources.

Looking at device configuration for MacOS there are a number of settings, and in my opinion, those settings address a lot of organizations requirements for Apple Mac management.

Device features

Device restrictions








Endpoint protection

Looking to protect the device further by configuring the firewall and controlling where apps are installed from? Gatekeep will help with those requirements.


Further configure firewall settings to device what you’ll allow in and which apps are allowed and/or blocked.


Certificates

Intune supports PKCS certificates for general and S/MIME purposes.



Device and user-based certificates are both supported via SCEP


VPN

Many VPN settings are available including 3rd party VPN support.


Make note of On-demand and per-app VPN


Use a proxy server? No problem!


Wi-Fi

Both Basic and Enterprise Wi-Fi profiles are supported with various auth types.


Customize with Apple Configurator

Don’t see a setting in the UI, not to worry as you can create a custom profile using Apple Profile Manager and/or Apple Configurator and upload the payload for delivery through Intune.


App deployment

Both line of business and Office apps are supported right from the UI.


When selecting “Line-of-business app” the MacOS app must be wrapped using the app wrapping tool for Mac which will wrap the app and give it an extension of .intuneMac.

The tool is available on GitHub: https://github.com/msintuneappsdk/intune-app-wrapping-tool-mac

To learn more about Mac app deployment with Intune please visit: https://docs.microsoft.com/en-us/intune/lob-apps-macos

One of my peers Scott Duffey @Scottduf has a great post on this topic: https://blogs.technet.microsoft.com/microscott/deploying-apps-to-macs-using-microsoft-intune/

Note: as of this post only .pkg files are supported nor are conversions from .dmg to .pkg

Microsoft + Jamf partnership

Microsoft has also has a partnership with Jamf. Jamf also provides MacOS management and if your organization currently utilizes Jamf and would like to receive the benefits of integrating Jamf with Intune you can do this today with Jamf Pro. So, what does this mean?

MacOS devices managed by Jamf remain managed by Jamf when Intune comes into the picture (thus are only registered with Intune not enrolled) and integrating Jamf Pro with Intune provides a path for Jamf to send signals in the form of inventory to Intune. Intune will use compliance policies to evaluate the Jamf signals and in turn send signals over to Azure AD stating whether the device is compliant or not. The Azure AD conditional access policy will kick in and based on your configuration of the conditional access policy, will either block or further challenge the user to remediate before access company resources.

For more details about Intune and Jamf integration please visit: https://docs.microsoft.com/en-us/intune/conditional-access-integrate-jamf

Jamf also has a whitepaper about Intune integration: https://www.jamf.com/resources/technical-papers/integrating-with-microsoft-intune-to-enforce-compliance-on-macs/

That’s it for now, however Microsoft is always releasing updates for Intune.  Check back monthly with What’s new in Microsoft Intune and be sure to check which Intune features are under development by visiting: https://docs.microsoft.com/en-us/intune/in-development