Send Intune security task notifications to Microsoft Teams, email, etc. using Microsoft Flow

There’s a feature within Microsoft Defender Advanced Threat Protection (MDATP) and Microsoft Intune where MDATP security recommendations can be sent to Intune as a security task. This is helpful if security admins and MDM admins are separate and need to pass information for endpoint management teams to work on. Even if you work on a small team or are a one-person shop, sending security tasks to Intune provides a work item, so if you’re forgetful or get pulled in many directions, you’ll have a task sitting for you. For more details on this feature please visit: https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Microsoft-Intune-security-tasks-extend-Microsoft-Defender-ATP-s/ba-p/369857

The purpose of this post is to create a method to signal and/or alert that there is a new pending security task in Intune. Currently admins need to access the Intune console and check for tasks which is a manual process. I prefer automation and I created a Flow to post a message in a Teams channel and send an email about new, pending Intune tasks sent from WDATP. If you’re thinking, “I’m not a developer…” well the good news is, neither am I! I love Microsoft Flow because it makes creating workflows and automation easy (and I create a lot of Flows to automate tasks).

Let’s get started

Requirements

  • Microsoft Defender ATP
  • Microsoft Intune
  • Microsoft Flow
  • Microsoft Teams
  • A Windows 10 device enrolled with Intune and managed by Microsoft Defender ATP

Viewing a security recommendation and sending a task to remediate to Intune

Navigate to https://securitycenter.windows.com/tvm_dashboard (note if you don’t have a subscription or haven’t set up MDATP, you’ll need to do this first). Look at the Top security recommendation on the right and select one.

Here I see a list of security recommendations.

When “Update Chrome” is selected we can see the number of devices exposed and CVEs (Common Vulnerabilities and Exposures) the update will address.

Select “Remediation options”

Check the box next to “Open a ticket in Intune (for AAD joined devices)”, select a due date, and add notes if necessary.

When finished, select “Submit request”

Head over the devicemanagement.microsoft.com > Security baselines > Security tasks and there should be a pending task. In this case I have two that have a status = Pending.

Select a task and Assign or Reject it, however, don’t do this yet, because we want to get a notification of pending security task in Intune.

Notifications of new pending tasks

Now we know how to send a task from MDATP to Intune, however what would be better is to be informed a task is waiting for us to address, and to set up notifications I use Microsoft Flow.

Creating a new Flow

Navigate to https://flow.microsoft.com, select My flows from the left hand navigation and select New -> Instant-from blank. Give the Flow a name and select create.

Schedule the Flow to run

Search for the “Recurrence” trigger and add it to the beginning of the Flow. Populate the fields to meet your requirements. I set my schedule to kick off everyday at 8 AM mountain time.

Azure AD Authorization to call Graph

This process requires multiple steps so I’ll refer you to a couple sources that may be utilized to configure the authorization steps:

Query Graph

Search for and add the HTTP Flow action. Method = GET, URI = https://graph.microsoft.com/beta/deviceAppManagement/deviceAppManagementTasks

In the header I utilize the authorization info compiled in previous steps.

The next three Flow actions take the information from the graph call and parse it out based on the JSON schema

  1. Search for and add a Compose action and as the “Input” add the Body from the Http action above.
  2. Search for an add a Initialize variable action, Name = JSONObject, Type = Object, Value is the Value from the Compose 2 output in the previous action.
  1. Next we need to parse the JSON so we can select JSON fields to be added to an email and Teams posts. Search for an add a Parse JSON action, Content = JSONObject from the variable above the Parse action. The Schema is generated easily by going to Graph Explorer and querying Graph as shown below. Copy the JSON returned from the response preview pane and in the Parse JSON action, select “Use sample payload to generate schema” and past the JSON output and select done. This will construct your schema.
Use the JSON output from graph explorer (as shown below) to populate the sample payload to generate the schema.

Send to Teams and/or email

Here I walkthrough sending to Microsoft Teams; however, an email trigger is roughly the same process.

  1. Search for and add a “Apply to each” trigger, Select an output from previous steps = the value from the Parse JSON action above.
  2. I only want task with a status of “Pending” so I added a Condition trigger where search for a status equal to “pending”. The Status object comes from the JSON we parsed above.
    • If status of pending = yes, I send an email and post to Teams, if status is anything other than pending, the Flow terminates.
  3. Search for and add “Post a message” action. Search for the Team site, Channel, and then craft your message. More on this below.

The reason we need to add a schema and parse the JSON returned from the Graph call is so we can select the variables returned individually. Below is an example of the fields I selected for my messages sent to Teams.

Viewing Teams posts

The following is an example of an Intune Task sent to teams with the Flow constructed above. If there is more than one pending task, the Flow will post individual messages for each pending task (same goes for emails). As shown below, I happen to have two tasks that are pending, one to Update Chrome and the other to Update Windows 10, lucky me!

That’s it! If you’re utilizing Microsoft Defender ATP and Intune, integrate the two and start sending tasks to Intune today. Use Flow to schedule notifications and send to Microsoft Teams, email, or whatever method Microsoft Flow supports.

Additional References

Logic apps docs: https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-perform-data-operations#join-action

Use data operations with Microsoft Flow: https://docs.microsoft.com/en-us/flow/data-operations

Follow me on Twitter @mscloudinfa

Entire Flow

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

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

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.

Add Windows Defender Browser Protection to Chrome with Intune

I recently read a really great post by Martin Bengtsson about utilizing Configuration Manager (SCCM) to force installation of the Windows Defender Browser Protection extension for Chrome. So I decided to take a different approach and deploy the extension utilizing a PowerShell script deployed through Microsoft Intune.

To learn more about the Windows Defender Browser Protection for Google Chrome please visit: https://chrome.google.com/webstore/detail/windows-defender-browser/bkbeeeffjjeopflfhgeknacdieedcoml

Assumptions

Windows 10 device enrolled in Intune


Let’s get started

I created the following PowerShell script to add the Defender Chrome extension as a registry entry:

New-Item -Path HKLM:SoftwarePoliciesGoogleChrome -Name ExtensionInstallForcelist –Force

$RegKey =”HKLM:SoftwarePoliciesGoogleChromeExtensionInstallForcelist”

Set-ItemProperty -path $RegKey -name 1 -value “bkbeeeffjjeopflfhgeknacdieedcoml;https://clients2.google.com/service/update2/crx”

I saved the script as a .ps1 file and added to Intune utilizing the steps below:

clip_image001

Name the script, upload, and save

clip_image002[4]

Assign the script to a group

clip_image003

Sync your Windows 10 device with Intune

clip_image004[4]

Sync the device with Intune 

clip_image005

Registry Before sync

clip_image006[4]

Chrome without Defender browser protection

clip_image007

Registry after sync

clip_image008[4]

Chrome with Defender browser protection

Once Chrome is launched, the extension is automatically downloaded to the extension directory and added to Chrome.

clip_image009

Chrome extension directory

clip_image010[4]

In addition to configuration, Configuration Manager will also perform remediation if this is something you’re more concerned with, SCCM is the best path to go currently. Again read Martin Bengtsson’s detailed post for insight on deploying and remediating for the Windows Defender Browser Protection for Chrome extension through SCCM.