Conditional access for managed apps

After a great MVP Summit and a session at a great Experts Live, it’s finally time for a new blog post. This blog post will be about conditional access for managed apps (MAM CA). About a month ago, I did a first post about this feature when it was still in preview. The good news is that the first part of this feature is now production ready for all tenants. In this post I’ll go through an introduction of MAM CA, the flow of MAM CA, the prerequisites of MAM CA, the configuration of MAM CA and the end-user experience of MAM CA.

Introduction

By now, I think, everybody should be familiar with the mobile app management without enrollment (MAM-WE, previously also referred to as MDM-less MAM) feature. MAM-WE helps with making sure that company data and resources are protected, even though the device is not managed. MAM CA adds an additional layer to that picture. MAM CA helps with making sure that only mobile apps that support Intune MAM policies are allowed to access Office 365 services (for now only Exchange Online). That enables us to allow access to Office 365 services, without the need to require enrollment and only for apps that can be managed.

Flow

Now let’s have a look at the flow that is used by MAM CA, by going through the steps in the picture shown below.

CA_MAMWE

Note: In the above picture CP is referring to the Company Portal app on Android and AA is referring to the Azure Authenticator app on iOS.

  1. Start: The end-user signs in to a managed app;
  2. App Approved?: When the end-user is restricted with MAM CA policies, a check is done to see if it’s an approved app. The approved apps are stored on a list in Azure AD and during the sign-in the app is validated with that list. When the app is not on the list, the end-user will be prompted that it’s not allowed to sign in via the app;
  3. CP/AA Present?: When it’s an approved app, a check is done to see if the broker app is installed on the device. On iOS this is the Azure Authenticator app and on Android this is the Company Portal app. When the broker app is not installed on the device, the end-user will be prompted to install the app;
  4. AAD Registered?: When the broker app is installed, and the end-user is signed in, a check is done to see if the device is registered in Azure AD. When the device is not registered in Azure AD, the end-user will be prompted to register the device.
  5. Approved: When the device is registered in Azure AD, the end-user can access Exchange Online via the managed app.

Note: The device registration in Azure AD will create a device record and certificate against which tokens are issued. There is no management profile installed on the device and there are no policies applied to the device. The device record in Azure AD only contains the alternativeSecurityIds, the deviceOSType, the deviceOSVersion and the displayName properties.

Configuration

After knowing what MAM CA is and knowing how MAM CA works, it’s time to look at the perquisites and the configuration.

Prerequisites

Before starting looking at the configuration, it’s good to be aware of the following prerequisites/ requirements/ limitation.

  • The end-user must be licensed for Enterprise Mobility + Security or Azure Active Directory premium;
  • At this moment MAM CA is only available for Exchange Online;
  • The end-user must install the broker app on their device;
  • MAM CA relies on modern authentication.

Configuration options

Now let’s have a look at the configuration options for MAM CA. The MAM CA polices contain three different configuration sections. These three sections together are the targeted MAM CA policy. Let’s go through these three section and see how they can be used.

1

MAMCA_AllAppsThe first configuration section is Allowed apps. The Allowed apps is used to select the mobile apps for iOS and Android that are allowed to access Exchange Online.

MAMCA_ManagedAppsTo allow apps to connect to Exchange Online the administrator can choose between selecting Allow all apps and Allow apps that support Intune app policies. The latter selection currently contains Skype for Business, Excel, PowerPoint, Word, OneNote, Outlook, Microsoft SharePoint and OneDrive for Android and iOS.

2 MAMCA_RestrUsGrThe second configuration section is Restricted user groups. The Restricted user groups section is used as the targeting mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be restricted by the MAM CA policy, immediately after saving the MAM CA policy.
3 petervanderwoude.nlThe third configuration part is Exempted user groups. The Targeted apps section is used as an exemption mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be exempted from the MAM CA policy, immediately after saving the MAM CA policy.

Additional considerations

An additional consideration for MAM CA is to close the gap for apps that don’t support modern authentication. Without closing that gap, apps that don’t support conditional access might still be able to connect. Let’s go through a method to close that gap.

4

ADFS_ModernAuthAn additional consideration is to use AD FS to block non-modern authentication. This can be achieved in AD FS 2016 by creating an Access Control Policy and assigning it to the Microsoft Office 365 Identity Platform Relying Party Trust.

That Access Control Policy must contain at least a rule to Permit users with Endpoint Path contains (/adfs/ls)|(/adfs/oauth2) in the request. This will make sure that only apps, using modern authentication, can connect to any cloud services that uses the Microsoft Office 365 Identity Platform Relying Party Trust.

End-user experience

After configuring MAM CA, it’s time to have a look at the end-user experience. I’m going to show the end-user experience of an end-user signing in to an approved app. However, before showing that experience it’s good to mention a few important facts about the end-user experience.

  • Every Exchange Active Sync mail client, including the built-in mail clients on iOS and Android, will be blocked. Instead end-users receive an email informing them that they need to use the Outlook mail app (see also this post);
  • If an end-user is targeted with MAM CA and “normal” conditional access (Device CA) policies, the end-user must meet one of the two requirements:
    • The used app is allowed by MAM CA;
    • The used device is managed by Microsoft Intune (hybrid or standalone) and compliant, or it’s a domain-joined PC.

Now let’s have a look at the Microsoft Outlook app and the flow that I described earlier. The end-user signs in to the Microsoft Outlook app and is prompted to install the Azure Authenticator app (see first screenshot). Once the end-user signs in to the Microsoft Outlook app and the Azure Authenticator app is installed, the end-user is prompted to open the Azure Authenticator app (see second screenshot).

Azure Authenticator app not installed Azure Authenticator app is installed
IMG_0098 IMG_0099

After switching to, and signing in to, the Azure Authenticator app, and the device is not registered, the end-user is prompted to register the device (see first screenshot). Once the device is successfully registered, and the end-user is successfully signed in, the end-user will be allowed access and receive the configured MAM policies (see second screenshot).

Device is not registered Device is registered
IMG_0100 IMG_0101

More information

Fore more information about MAM CA and related components, please refer to:

Share

Managing browser settings via Windows 10 MDM

This week a short blog post about managing browser settings via Windows 10 MDM. Most of these settings are not very special and are very well documented in the Policy CSP. However, the configuration of the home page is a small exception. Not just because the documentation is slightly off, but also because of an important change with the anniversary update of Windows 10. As most of the settings are very well documented, this post will be focused on managing the home page. I’ll provide basic information, the configuration information and show the end-user experience.

Information

Before starting about the configuration of home pages, via Windows 10 MDM, it’s good to mention a few important notes:

  • Browser settings for Microsoft Edge can be managed;
  • Browser settings for Internet Explorer cannot be managed;
  • HTTP is the default for home pages;
  • Multiple home pages can be enforced;
  • Home pages are supported on all Windows 10 for desktop editions;
  • Starting the anniversary update of Windows 10, the end-user cannot change the enforced home page.

Configuration

With this information in mind, let’s have a look at the options for configuring the home page in Microsoft Edge. The home page can be configured with a single page and with multiple pages. Per configured home page, a new tab will be opened. When a single home page must be configured, the URL alone is enough. When multiple home pages must be configured, the URLs must be separated by using the XML-escaped characters < and >.  Below is the required OMA-URI and example values, including configuration examples for Microsoft Intune standalone and Microsoft Intune hybrid.

  • OMA-URI: ./Vendor/MSFT/Policy/Config/Browser/Homepages
  • Values (single home page): petervanderwoude.nl
  • Values (multiple home pages): <petervanderwoude.nl><https://petervanderwoude.nl>
Microsoft Intune hybrid Microsoft Intune standalone
MIH_W10_Homepages MIS_W10_Homepages

End-user experience

Now let’s end with the end-user experience, starting with the anniversary update of Windows 10. When the end-user starts Microsoft Edge, the configured home page will show. When the end-user navigates to the settings of Microsoft Edge, the Open Microsoft Edge with setting is grayed out and shows the configured home page. Below are examples of that setting with a single home page and with multiple home pages.

Single homepage Multiple homepages
CSP_Homepage CSP_Homepage_2

More information

Fore more information about configuring browser settings via Windows 10 MDM, please refer to the documentation about the Policy CSP.

Share

Use PowerShell and Microsoft Graph to access data in Microsoft Intune

This week a short blog about using PowerShell to access data in Microsoft Intune. This can be achieved by using Microsoft Graph. A couple of weeks ago there was a blog post on the Microsoft Intune Support Team Blog about Using the Microsoft Graph API to access data in Microsoft Intune. That post triggered me to look at the PowerShell possibilities, as the Microsoft Graph has an API and an API can be used with PowerShell.

In this blog post I’ll provide the high-level prerequisites for connecting to the Microsoft Graph API and I’ll provide a few examples for querying Microsoft Intune data.

Prerequisites

This blog post is really focused on the queries to the Microsoft Intune data. However, to successfully connect with the Microsoft Graph API there are a few prerequisites that should be in place.

Examples

Now let’s have a look at the PowerShell versions of the published Microsoft Graph Explorer commands and the results of them. I’ll go through all of them and provide the required input and show an example result

User

The first example is to get data related to a single user. This requires a user principal name (UPN), in my case pvanderwoude@petervanderwoude.nl, and the token as input.

Invoke-RestMethod https://graph.microsoft.com/v1.0/users/$UPN ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

userUPN

Owned devices

The second example is to get data related to the devices of a single user. Thee information is about the compliance state of the devices of the user. This requires a user principal name (UPN), in my case pvanderwoude@petervanderwoude.nl, and the token as input. The returned information is stored in a hash table.

Invoke-RestMethod https://graph.microsoft.com/v1.0/users/$UPN/ownedDevices ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

registeredDevices

Registered owners

The third example is to get the owners of a device. This requires a device GUID and the token as input. The returned information is stored in a hash table.

Invoke-RestMethod https://graph.microsoft.com/v1.0/devices/$GUID/registeredOwners ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

registeredOwners

Registered users

The fourth example is to get the users of a device. This requires a device GUID and the token as input. The returned information is stored in a hash table.

Invoke-RestMethod https://graph.microsoft.com/v1.0/devices/$GUID/registeredUsers ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

registeredUsers

Applications

The fifth example is to get a list of uploaded applications in Microsoft Intune. This requires the token as input and the returned information is stored in a hash table. However, based on the returned  information, it currently seems to return the applications registered in Azure AD.

Invoke-RestMethod https://graph.microsoft.com/beta/applications ` -Method Get ` -Headers @{"Authorization" = "Bearer $accessToken"}

petervanderwoude.nl

More information

Fore more information about the Microsoft Graph API, in combination with Microsoft Intune and the different tokens, please refer to:

Share

Blocking non-modern authentication is getting easier and easier

This week a short post about blocking non-modern authentication protocols. I’ve already provided many examples throughout the blog post I’ve posted regarding conditional access, but the release of Windows Server 2016 triggered me again. The main reason for that are the the additions to Active Directory Federation Services (ADFS) in Windows Server 2016. The main addition to ADFS, for this cause, is the addition of Access Control Policies.  During this blog post I want to slightly touch that subject, as it’s getting a pretty easy and common addition to the default conditional access policies of Microsoft Intune and Azure AD.

The funny thing is that I’m not even speaking about the ability to block legacy authentication protocols directly on SharePoint Online, which is of course easier compared to using ADFS. However, it’s not a complete solution, at this moment, as it’s not available for Exchange Online. As long as it’s not a complete solution for blocking non-modern authentication, ADFS will stay really important for completely closing conditional access.

Active and passive authentication

Before I’m going to look at Access Control Policies, I think it would be smart to mention something about active versus passive authentication. I’ve been mentioning it a lot, but I’ve never even tried to explain the differences. When I’m mentioning modern authentication, I’m actually referring to passive authentication protocols and when I’m mentioning non-modern authentication, I’m actually referring to active authentication protocols. The main difference between these two are, in a very simplistic way, the following.

  • Passive authentication: Passive authentication uses the browser to do redirects to the identity provider to request a token. The protocol that is used is WS-Federation;
  • Active authentication:  Active authentication uses direct connection to request a token and login. In this case the protocol that is used is WS-Trust.

Access Control Policies

ADFS now supports the use of Access Control Policy templates. By using Access Control Policy templates, an administrator can enforce policy settings by assigning the policy template to a relying party or a group of relying parties. The administrator can make updates to the policy template and the changes will be applied automatically to the relying parties.

Access Control Policy templates replace the old model where administrators had to configure issuance authorization rules using claims language. The old PowerShell cmdlets of issuance authorization rules still apply but it is mutually exclusive of the new model. Administrators can choose to either  use the new model or use the old model. The new model allows administrators to easily control when to grant access, including enforcing multi-factor authentication.

Access Control Policy templates use a permit model. This means that by default no one has access and that access must be explicitly granted. However, this is not just an all or nothing permit. Administrators can add exceptions to the permit rule. Within a rule, of an Access Control Policy, if an administrator selects multiple conditions, they are of an AND relationship. Actions are mutually exclusive and for one policy rule an administrator can only choose one action. If the administrator selects multiple exceptions, they are of an OR relationship.

Configuration options

With all this information it’s time to look at some policy rule examples. Let’s say that I want to permit everything on the intranet and block legacy apps on the Internet. That can be configured in a pretty easier manner, without really getting in to the claims language. There are two different methods to achieve the same result. Both methods start with a rule Permit users from intranet network. Let’s look at the second rule for both of them.

  • Permit everything except active authentication: In this approach I use a second rule Permit users from Internet network except with Endpoint Path equals /adfs/services/trust/2005/usernamemixed in the request. This can be achieved by selecting from specific network and with specific claims in the request in the rule editor.
  • Permit only passive authentication: In this approach I use a second rule Permit users from Internet network and with Endpoint Path contains (/adfs/ls)|(/adfs/oauth2) in the request. This can be achieved by selecting from specific network and with specific claims in the request in the rule editor.
Except active authentication Permit passive authentication
ADFS_ACP01 ADFS_ACP02

More information

Fore more information about Active Directory Federation Services and active versus and passive authentication, please refer to:

Share

Conditional access for managed apps (preview)

This blog post is about an Azure preview feature. A preview may include preview, beta, or other pre-release features, services, software, or regions. Previews are subject to reduced or different service terms. In other words, previews are for early testing and should not be considered as fully production ready.

During the session Secure access to Office 365, SaaS, and on-premises apps and files with Azure AD and Intune, at Microsoft Ignite, a nice new feature for mobile app management without enrollment (MDM-less MAM) was shown. That new feature is conditional access for managed apps. During that session they showed the URL to that new feature. What makes it even better, that specific URL already works with existing tenants. It simply brings the administrator to a public preview feature.

During this blog post I’ll provide some information about this new feature, I’ll go through the currently available configuration options of this new feature, I’ll show the end-user experience with this new features and I’ll provide my first impression with this new feature.

Information

This new feature will enable an administrator to restrict access to Exchange Online and SharePoint Online so that access can come only from managed apps such as Outlook, Word, Excel, PowerPoint and OneDrive. This new feature also pairs up perfectly with Intune mobile app management (MAM) policies, as it enables the administrator to block access to built-in mail clients or other apps that have not been configured with the Intune MAM policies.

During my first tests with this new feature I noticed that on iOS the Microsoft Authenticator app is required and on Android the Microsoft Intune Company Portal app is required.

Configuration in the Azure portal

Now let’s have a look at the configuration of this new feature. The conditional access policies are configured through the Azure portal, just like the MDM-less MAM policies. I’ll first go through the different configuration options followed by the basic step-by-step configurations.

Different configuration options

The conditional access policies in the Azure portal, contain three different configuration sections. These three sections together are the targeted conditional access policy. Let’s go through these three sections and see how they fit together.

1

CA_EXOThe first configuration section is Allowed apps. The Allowed apps is used to select the mobile apps for iOS and Android that are allowed to access Exchange Online and SharePoint Online.

CA_SPOAt this moment, Outlook is the only selectable app for iOS and Android with Exchange Online. For SharePoint Online there are more selectable apps. It has the option of Skype for Business, Excel, PowerPoint, Word, OneNote and Outlook for iOS and Android, Microsoft SharePoint, OneDrive for iOS only and OneDrive for Android only.

2 CA_RestrUsGrThe second configuration section is Restricted user groups. The Restricted user groups section is the same for Exchange Online and SharePoint Online. It must be used as the targeting mechanism for the conditional access policy. Every available group in Azure AD can be selected here.
3 CA_ExUsGrThe third configuration part is Exempted user groups. The Targeted apps section is the same for Exchange Online and SharePoint Online. It can be used as an exemption mechanism for the conditional access policy. Every available group in Azure AD can be selected here.

Basic steps

After getting familiar with the different configuration options, it’s time to look at the creation and the targeting of a conditional access policy. The following 10 straight forward steps will guide anyone through the configuration and targeting.

1 Open the Azure portal via this link and navigate to Intune mobile application management > Settings to open the Settings blade;
2 In the Settings blade, click Exchange Online to open the Exchange Online blade;
3 In the Exchange Online blade, click Allowed apps to open the Allowed apps blade;
4 In the Allowed apps blade, select the allowed apps.
5 Back in the Exchange Online blade, click Restricted user groups to open the Restricted user groups blade;
6 In the Restricted user groups blade, click Add user group to open the Add user group blade;
7 In the Add user group blade, select an user group and click Select to save the changes and to return to the Restricted user groups blade.
8 (Optional) Back in the Exchange Online blade, click Exempt user groups to open the Exempt user groups blade;
9 (Optional) In the Exempt user groups blade, click Add user group to open the Add user group blade;
10 (Optional) In the Add user group blade, select an user group and click Select to save the changes and to return to the Exempt user groups blade.

Note: The same steps are applicable to the configuration for SharePoint Online. The only real difference is the selection of SharePoint Online instead of Exchange Online.

End-user experience

Now it’s time to have a look at the end-user experience. When an end-user is targeted with a conditional access policy for managed apps and the end-users wants to use one of the blocked apps, the end-user will get the messages below after providing company credentials. The first message will show after adding a company email account to the native mail client and the second message will show after using a blocked app.

Native mail client Blocked app
IMG_0088 IMG_0089

First impressions

My first impressions of this new feature are mixed, from a great addition to leaving room for improvements. The idea of blocking apps that are not managed is great and is something that would be an awesome addition to the product. Especially when looking specifically at MDM without enrollment. However, at this moment it’s not blocking everything. There are three section that I can see a need for improvement:

  1. Only the native mail client on Android and iOS is blocked with Exchange Online. Other mail apps, not using modern authentication, are a hit-miss exercise;
  2. Only apps using modern authentication are blocked with SharePoint Online. Other apps can still connect and sync data;
  3. Browser access is not blocked.
Share

Predeclaring corporate-owned devices

This week something related to last week. This week will be about predeclaring corporate-owned devices. In other words, making sure that the Device Owner of the specified devices is set to Company after enrollment. It’s also a much easier solution, for a scripted solution that I created more than year ago, for automagically setting the mobile Device Owner to Company. In this blog post I’ll provide some information about this feature, I’ll show the configuration of this feature and I’ll show the administrator experience of this feature. Please note that this functionality is only available for Microsoft Intune hybrid.

Information

Predeclaring corporate-owned devices allows organizations to identify corporate-owned devices by importing the International Mobile Equipment Identity (IMEI) numbers, or, for iOS devices, by importing the serial numbers. It’s possible to upload a comma-separated values (.csv) file containing device IMEI numbers, or to manually enter device information. Imported information will make sure that the Device Owner will be set to Company for the devices that are in lists of devices. Keep in mind that this is only applicable to devices that still need to enroll. Already enrolled devices that are on the list will not change the Device Owner.

Configuration

Before I’m going through the required configuration steps, it’s good to mention the format of the csv files that can be used. The lines in the csv file can contain a maximum of 4 columns with the following items in the following order: IMEI number, iOS serial number, Platform (iOS, Windows, Android), Details. Each row must contain an IMEI number, or iOS serial number, and a Platform. The Details are optional. An example would look like the following.

,F9FFFFFFFFK9,iOS,Company-owned iOS device
357777777777748,,Android,Company-owned Android device

With this information, I can go through the required configuration steps. During these steps I’ll use the example csv information. It’s good to keep in mind that it’s also possible to manually add a single IMEI number or iOS serial number. In that case the wizard will simply skip the import page, mentioned below.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > All Corporate-owned Device > Predeclared Devices;
2 On the Home tab ,click Create Predeclared Devices to open the Create Predeclared Devices wizard;
3 CPD_GeneralOn the General page, select Upload a CSV file containing IMEI or serial numbers and details, select the csv file and click Next;
4 On the Import page, click Next;
5

CDP_EntryOn the Entry page, verify the information and click Next:

Note: This page is similar to when a single IMEI number or iOS serial number, is added, using this wizard. It’s even possible, at this point, to still manually add an additional IMEI number, or iOS serial number.

6

CDP_ProfileOn the Profile page, select an iOS enrollment profile and click Next:

Note: This is an optional page that will only show when an iOS device is imported. The refresh button can be used to update the selection box for newly created iOS enrollment profiles.

7 On the Summary page, review the summary and click Next:
8 On the Completion page, review the results and click Close.

Note: After completing the wizard, the Configuration Manager administration console will not automatically refresh. This requires a manually activity.

Administrator experience

Now it’s time to look at a few interesting places in the Configuration Manager administration console. When I now navigate to Assets and Compliance > Overview > All Corporate-owned Devices > Predeclared Devices, I can see the predeclared devices, including the enrollment status of those devices. Once a device is enrolled the status will reflect in the Configuration Manager administration console, as shown below.

PD_Overview

When the predeclared devices also contained iOS devices, the iOS devices are assigned to the selected iOS enrollment profile. When I now navigate to Assets and Compliance > Overview > All Corporate-owned Devices > iOS > Enrollment Profiles, I can select the iOS enrollment profile and see the related device count, as shown below. If I want to see even more information, I can select the iOS enrollment profile and click Show Assigned Devices.

EP_Overview

When I enroll the predeclared devices, the devices will show in the Configuration Manager administration console with the Device Owner set to Company. I can easily see this information when I navigate to Assets and Compliance > Overview > Devices, as shown below.

DS_Overview

Keep in mind that the Device Owner will only be set to Company when the predeclared devices are imported before the devices are enrolled. The Device Owner will not change for already enrolled devices.

More information

For more information about predeclaring company-owned devices, please refer to this article about Predeclare devices with IMEI or iOS serial numbers.

Share

Categorizing devices

This week something completely different as the last couple of weeks. This week no conditional access and nothing specifically related to Windows 10 devices. This week it’s all about categorizing devices. Within Microsoft Intune hybrid this functionality is named Device Categories and within Microsoft Intune standalone this functionality is named Device Group Mapping. Both of these functionalities can be used to achieve the same goal. In this post I’ll provide some more information, I’ll describe the configuration in Microsoft Intune hybrid and Microsoft Intune standalone and I’ll show the end-user experience.

Information

Categorizing devices can be useful to differentiate between device categories. For example, to differentiate between devices used by users of the sales department and the users of the human resources department. When categorizing devices, the following workflow is applicable.

  1. Create collections, or device groups, for each required category;
  2. Configure collection membership rules, or device group mapping rules, that map the categories to the collections, or device groups;
  3. When end-users enroll their device, they must choose a category from the configured categories. After they choose, their device will be automatically added to the corresponding collection, or device group;.
  4. Use the collections, or device groups, when deploying policies and apps.

Configuration

Now it’s time to start with the configuration of device categories. I’ll walk through the configuration steps for Microsoft Intune hybrid and standalone and I’ll provide the configuration options.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to create custom device categories and I’ll show how to use a device category.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Device Collections;
2 On the Home tab ,click Manage Device Categories to open the Manage Device Categories dialog box;
3 ManageDC_MIHIn the Manage Device Categories dialog box, click Create to open the Create Device Categories dialog box;
4 CreateDC_MIHIn the Create Device Categories dialog box, provide an unique name and click OK to return to the Manage Device Categories dialog box;
5 Back in the Manage Device Categories dialog box, click OK.

Now that I’ve created device categories, I can use them as a collection membership rule. Assuming a collection is already available, the device category can be added by performing the following steps.

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Device Collections;
2 Select the required collection and on the Home tab ,click Properties to open the Properties of the collection;
3 Within the Properties of the collection, click Add Rule > Device Category Rule to open the Select Device Categories dialog box;
4

SelectDC_MIHIn the Select Device Categories dialog box, select a device category and click OK to return to the Properties of the collection;

Note: This will actually create a query collection membership rule that simply queries on the MDMDeviceCategoryID property of a device.

5 Back in the Properties of the collection, click OK.

Note: An administrator can add an additional column, named Device Category, to the devices overview (and any device collection), to get a quick overview of the used device categories for the devices.

Microsoft Intune standalone

Let’s continue with similar configuration within Microsoft Intune standalone. I’ll walk through the required steps to create a device group mapping. Assuming the required device groups are already available, the device group mapping rule can be add by performing the following steps.

1 In the Microsoft Intune administration console, navigate to ADMIN > Mobile Device Management > Device Group Mapping;
2 On the Device Group Mapping page, enable Device Group Mapping;
3 DGM_MISOn the Device Group Mapping page, with Step 2: Mapping device group mapping rules click Add to open the Add device group mapping rule dialog box;
4 AddDGM_MISIn the Add device group mapping dialog box, provide an unique name, select a device group and click Add to return to the Device Group Mapping page;
5 Back on the Device Group Mapping page, click Save.

End-user experience

After the configurations of the device categories are completed, it’s time to have a look at the end-user experience. During the enrollment of an iOS or Android device, the end-user will receive an additional message to choose a device category. Once completed that category will display in the Company Portal app and the Company Portal web app. On Windows devices the configuration can be completed after the enrollment, via the Company Portal web app.

Company Portal app Company Portal web app
IMG_0086 IMG_0087

More information

Fore more information about categorizing devices, please refer to:

Share

Conditional access for published ConfigMgr reports

This week another post about the world of conditional access in Azure AD. Last week I started with looking at conditional access for Yammer. This week I’ll add-on to that idea by publishing a custom application, in this case my ConfigMgr reports, and apply conditional access to that configuration. To make it even better, it even allows a single sign-on configuration. In other words, I can use pre-authentication on Azure AD and use that token for the single sign-on experience of the end-user in the published application. Really nice!

Prerequisites

Before starting with the configuration, it’s important to know that his post does require two important prerequisites to be in place, which are not part of this post.

  1. Azure AD Application Proxy: This component is used for publishing an on-premises application. The steps to enable the Azure AD Application proxy are documented here;
  2. Windows Authentication: This is required to be able to use single sign-on in combination reporting services. The steps to configure Windows authentication on the report server are documented here.

Configuration

The configuration of conditional access, with single sign-on, for ConfigMgr reporting services contains four steps. The first step is to add the application, the second step is to configure the application, the third step is to enable device access rules and the fourth step is to configure the compliance policy.

Step 1: Add an application

Let’s start with the first step, which is publishing an application that will be accessible outside my network. This requires that the Azure AD Application Proxy is enabled and installed. The publishing of the application can be done via the Azure portal and the Azure Management portal. At this point I’m still using the Azure Management portal, as I can’t do every required configuration via the Azure portal, yet.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS and click ADD;

To publish the ConfigMgr Web Portal, select Publish an application that will be accessible from outside your network and provide the following information.

  • AzureADApp_CRNAME: [Specify a unique name for the published application]
  • INTERNAL URL: [Provide the internal ConfigMgr Web Portal URL]
  • PREAUTHENTICATION METHOD: Azure Active Directory

Step 2: Configure the application

The second step is to configure the application with a single sign-on experience for the end-user. As I’m using pre-authentication on Azure AD, to enable the option for conditional access, I don’t want to require the end-user to provide the credentials again. That’s why I want to configure single sign-on for the published application.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS > [New application] > CONFIGURE;

To enable single sign-on for the ConfigMgr Web Portal, provide at least the following information.

  • AzureADApp_CRAuthINTERNAL AUTHENTICATION METHOD: Integrated Windows Authentication
  • INTERNAL APPLICATION SPN: [Provide the internal SPN]
  • DELEGATED LOGIN IDENTITY: User principal name

Step 3: Enable device access rules

The third step is to configure the application with a conditional access experience for the end-user. As the application is now configured with pre-authentication on Azure AD, it’s a small step to enable a device access rule, which is enabling conditional access. That will make sure that all access attempts, from a device that doesn’t meet the configuration, will be denied.

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

In the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS > [New application] > CONFIGURE;

To enable conditional access for the ConfigMgr Web Portal, switch ENABLE ACCESS RULES to ON and select with APPLY TO the users which the rules should apply.

AzureADApp_CRCATo make sure that all the devices must be compliant to access the ConfigMgr Web Portal, make sure to configure the applicable platforms with DEVICE RULES and click SAVE.

Note: With custom applications this configuration will be enforced for browsers and native applications.

Step 4: Configure compliance policy

The fourth and last step, an optional step, is to configure a compliance policy in Microsoft Intune standalone and Microsoft Intune hybrid. This configuration part hasn’t changed and is still the right addition to require additional settings on a device. A compliance policy defines the rules and settings that a device must comply with in order to be considered compliant. The configuration of the compliance policy differs between Microsoft Intune standalone and Microsoft Intune hybrid. After creating the compliance policy, it can be deployed to users like any other policy. It’s not required to configure and deploy a compliance policy. When no compliance policy is configured and deployed, the device will automatically be considered compliant.

Environment Configuration
Microsoft Intune standalone

CustomApp_MISIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Compliance Policies and click Add….

To configure a compliance policy,  choose, based on the requirements, between the applicable available Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version settings.

Microsoft Intune hybrid

In the Configuration Manager administration console navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies and click Create Compliance Policy.

CustomApp_MIHTo configure a compliance policy, choose, based on the requirements, during the Create Compliance Policy Wizard the Supported Platforms and choose between the applicable Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version Rules.

Note: Compliance policies can be used independently of conditional access. When used independently, the targeted devices are evaluated and reported with their compliance status.

End-user experience

After the configurations of adding the application, enabling the device access rules and configuring the compliance policy, it’s time to look at the end-user experience. This time I’ll go through all the common scenario’s that the end-user can end up with. Starting with the initial configuration of the application in Azure AD. Once the application is created in Azure AD and the end-user tries to access them without being licensed, or without being assigned to the application, the end-user can expect the messages shown below.

Not licensed Not assigned
IMG_0080 IMG_0083

Once the end-user is licensed and is assigned to the application, the end-user reaches the conditional access checks of Azure AD. When the device of the end-user is not enrolled, or not compliant, the end-user can expect the messages shown below.

Not enrolled Not compliant
IMG_0079 IMG_0082

Once the end-user has the device enrolled and compliant, the end-user reaches the published application. In this case the ConfigMgr reports. When the end-user has no permissions within the ConfigMgr reports, the end-user will still be able to sign-in. However, the end-user will receive a message, as shown below, about missing the necessary permissions. When the end-user has the required permissions, the end-user will be able to browse through the reports as shown below.

No permissions All requirements met
IMG_0081 IMG_0084

Note: During my tests I’ve upgraded from SQL Server 2014 to SQL Server 2016. Even though SQL Server 2016 looks much better, my mobile devices like to display the reports from SQL Server 2014 much more. In other words, I could simply display my reports when using SQL Server 2014 and my reports wouldn’t display information when using SQL Server 2016. The permission setup works in both configurations.

More information

For more information about conditional access, applications in Azure, compliance policies in Microsoft Intune and Windows authentication for reporting services, please refer to:

Share

Conditional access for Yammer

This week I’ll open a new world of conditional access. The world of conditional access in Azure AD. I’ll open that world of conditional access by looking at conditional access for Yammer. Conditional access for Yammer cannot be configured through the Microsoft Intune administration console. However, that doesn’t mean that conditional access for Yammer doesn’t exist. The configuration of conditional access for Yammer is available through the Azure Management portal. In this post I’ll go into more detail about conditional access via Azure AD, the required configurations and the end-users experience.

Introduction

About a month ago Microsoft released conditional access policies as a preview feature in Azure AD for iOS, Android and Windows (Windows 7, Windows 8.1 and Windows 10, build 1607). These policies can help IT organizations with controlling data, by restricting access to managed devices only. Policies can be applied on a per-application basis to require that devices are managed by the IT organization and that devices are configured correctly.

In case that conditional access functionality sounds familiar, that’s possible. At this moment this conditional access functionality creates an overlap with the conditional access policies that can be configured through Microsoft Intune. Conditional access configurations done via Microsoft Intune will reflect to the configurations in Azure AD and vice versa. However, Azure AD already provides more configuration options and supports a lot more applications. Every application, that authenticates with Azure AD, is supported!

Configuration

The configuration of conditional access for Yammer contains two steps. The first step is to enable device access rules for Yammer and the second step is to configure the compliance policy.

Step 1: Enable devices access rules for Yammer

Let’s start with the first step, which is the configuration of the device access rule in the Azure Management portal. This configuration will make sure that all access attempts from a device that doesn’t meet the configuration will be denied. The configuration has to be done through the Azure Management portal and takes effect immediately after saving the configuration,

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

Yammer_DBARIn the Azure Management portal navigate to Active Directory > [Organization] > APPLICATIONS > Office 365 Yammer > CONFIGURE;

To enable conditional access for Yammer, switch ENABLE ACCESS RULES to ON and select with APPLY TO the users which the rules should apply.

To make sure that all the devices must be compliant to access Yammer, make sure to configure the applicable platforms with DEVICE RULES and click SAVE.

Note: With Yammer this configuration will be enforced for browsers and native applications.

Step 2: Configure compliance policy

The second step is the configuration of the compliance policy in Microsoft Intune standalone and Microsoft Intune hybrid. This configuration part hasn’t changed and is still the right addition to require additional settings on a device. A compliance policy defines the rules and settings that a device must comply with in order to be considered compliant. The configuration of the compliance policy differs between Microsoft Intune standalone and Microsoft Intune hybrid. After creating the compliance policy, it can be deployed to users like any other policy. It’s not required to configure and deploy a compliance policy. When no compliance policy is configured and deployed, the device will automatically be considered compliant.

Environment Configuration
Microsoft Intune standalone

Yammer_MISIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Compliance Policies and click Add….

To configure a compliance policy,  choose, based on the requirements, between the applicable available Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version settings.

Microsoft Intune hybrid

Yammer_MIHIn the Configuration Manager administration console navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies and click Create Compliance Policy.

To configure a compliance policy, choose, based on the requirements, during the Create Compliance Policy Wizard the Supported Platforms and choose between the applicable Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Device Security Settings, Jailbreak and Operating System Version Rules.

Note: Compliance policies can be used independently of conditional access. When used independently, the targeted devices are evaluated and reported with their compliance status.

End-user experience

After the configuration of the device access rule and the compliancy policy is completed, it’s time to look at the end-user experience. An enrolled and compliant device will give the end-user the normal experience. A not enrolled device, or a not compliant compliant device, will give the end-user a message based on the status of the device, when the end-user is trying to access Yammer. Those messages are shown below, using an iOS device using the default browser as an example.

Not enrolled Not compliant
IMG_0073 IMG_0074

More information

For more information about conditional access, related to applications in Azure AD and compliance policies, please refer to the following articles:

Share

Simplify enrollment for Windows 10 devices

This week a small blog post about simplifying the enrollment experience for Windows 10 devices. When enrolling a Windows 10 device, for mobile device management (MDM), the end-user has to perform a specific enrollment procedure. That enrollment procedure can be simplified by providing the end-user with a deep link. This blog post will provide the configuration for that deep link and the end-user experience.

Configuration

The configuration is fairly simple, but, to many people, unknown. Providing the configuration, as part of this blog post, is mainly for creating awareness about the available configuration option. Windows 10 devices can be connected to MDM by using a deep link. In that case end-users will be able to click, or open, a link, from anywhere in Windows 10, and be directed to the MDM enrollment experience. The link, used for connecting a Windows 10 device, must always use the following format: ms-device-enrollment:?mode={mode_name}. Within this format the following parameters and values are available.

Parameter Value Description
mode mdm Specifies which mode will be used in the enrollment app

Note: Starting with Windows 10, version 1607, deep linking is only supported for connecting devices to MDM. It will not support adding a work or school account, joining a device to Azure AD, and joining a device to Active Directory.

This enables the IT administrators to provide the end-user with a link to directly launch the built-in enrollment app. The link should contain the URI ms-device-enrollment:?mode=mdm. Together with a user-friendly display text it can look like this Click here to enroll the Windows 10 device.

Note: When reading this from a Windows 10, version 1607, device, simply click on the link to experience the end-user experience.

End-user experience

The end-user experience is also fairly simple. The end-user can receive an email that contains a similar URI as mentioned in the configuration. Once the end-user clicks on the URI, the end-user will be directed straight to the place to enroll the Windows 10 device in device management. That would be the first screen shown below. When the end-user provides the right information and clicks Next, the end-user will be redirected to the identity provider. After providing the right information the end-user will get the second screen shown below. That’s it. That’s the complete enrollment experience.

EUE_1 EUE_3

More information

For more information about MDM enrollment and Windows 10, please refer to this article about MDM enrollment of Windows-based devices.

Share