Android Enterprise fully managed devices and conditional access

This week is all about Android Enterprise fully managed devices. More specifically, the recently introduced functionality to use Android Enterprise fully managed devices in combination with conditional access. To support this functionality Microsoft introduced a new app, named Microsoft Intune app, and a new profile type for device compliancy policies for the Android Enterprise platform. Together these 2 features enable Android Enterprise fully managed devices to be registered as compliant device and to successfully work with conditional access. In this post I’ll provide some information about the Microsoft Intune app and I’ll show how to configure that app, followed by some information about the compliance policy for device owner scenarios and how to configure that policy. I’ll end this post by showing the end-user experience.

Keep in mind that Android Enterprise fully managed devices is still preview functionality. There are still scenarios that will not fully work at this moment. One of those scenarios is related to app protection policies. I specifically mention that scenario, as it can conflict with the scenario in this post. Apps with app protection policies assigned, will still prompt for the Company Portal app.

Microsoft Intune app

The first part in using Android Enterprise fully managed devices in combination with conditional access is the Microsoft Intune app. The Microsoft Intune app is a new modern and light-weight app that will enable the Company Portal app experiences for end-users on fully managed devices. That includes managing compliance for their device. Keep in mind that the Microsoft Intune app is only for the fully managed device scenario. As Android Enterprise fully managed devices require the Managed Google Play Store, the following 4 steps walk through the process of adding the Microsoft Intune app by using the Managed Google Play Store. After that the Microsoft Intune app can be assigned as any other app.

Keep in mind that after the May 2019 service roll out of Microsoft Intune, the Microsoft Intune app will automatically be added to the Intune admin console after connecting the tenant to managed Google Play.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, click Add to open the Add app blade;
3a MIapp-AddAppOn the Add app blade, provide the following information and click Sync;

  • App type: Managed Google Play;
  • Managed Google Play: See step 3b – 3f;
3b On the Search managed Google Play blade, search for the Microsoft Intune app;
MIapp-SearchApp
3c On the Search managed Google Play blade, select the required app and click Approve to open a dialog box with app permissions;
MIapp-ApproveApp
3d

MIapp-ApproveAppDB01On the dialog box with app permissions, click Approve to continue to the selection about handling new app permissions;

Important: Keep in mind that this will accept these permissions on behalf of the organization.

3e

MIapp-ApproveAppDB02On the dialog box about handling new app permissions, select Keep approved when app requests new permissions and click Save to return to the Search managed Google Play blade;

Important: Keep in mind that this decision might impact the future app permissions and/or the future user experience.

3f On the Search managed Google Play blade, click OK;
MIapp-ApproveAppOK
4 Back on the Add app blade, click Sync;

Note: These steps will approve the app in the Managed Google Play store and sync the approved app in to Microsoft Intune..

Compliance policy for device owner

The second part in using Android Enterprise fully managed devices in combination with conditional access is the compliance policies. Since recently it’s possible to create compliance policies for fully managed devices. The list of available compliance settings is smaller than other platforms. The main reason for that is because those settings are only applicable to fully managed devices. And fully managed devices are, as the name already implies, fully managed. In other words, fully managed devices already follow strict configuration policies. The following 5 steps walk through the process of creating a device compliance policy for Android Enterprise fully managed devices. After configuring the device compliance policy assign it to a user group like any other device compliance policy.

1 Open the Azure portal and navigate to Microsoft Intune > Device compliance > Policies to open the Device compliance – Policies blade;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3a

AEfmd-CreatePolicyOn the Create Policy blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Android Enterprise;
  • Profile type: Device owner
  • Settings: See step 3b and 3c;
  • Actions for noncompliance: Leave default (for this post);
  • Scope (Tags): Leave default (for this post);

Note: Configuring non-standard values for Actions for noncompliance and Scope (Tags), is out of scope for this post;

3b

AEfmd-DevicePropertiesOn the Device owner blade, select Device Properties to open the Device Properties blade. On the Device Properties blade, configure the required device properties and click OK to return to the Device owner blade;

3c AEfmd-SystemSecurityBack on the Device owner blade, select System Security to open the System Security blade. On the System Security blade, configure the required system security settings and click OK to return to the Device owner blade;
4 Back on the Device owner blade, click OK to return to the Create Policy;
5 Back on the Create Policy blade, click Create to create the policy.

Note: To take full advantage of this device compliance policy configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Now let’s end this post by looking at the end-user experience. Below, from left to right, is an overview of the different steps in the Microsoft Intune app to get a device from a noncompliant state to a compliant state. When the user has a noncompliant device state, the user can start the process by clicking on “You need to update settings on this device”. That will bring the user to the screen to setup access to resources. On that screen the user can simply continue. The next screen will show the user the settings that need to be updated and by clicking on a setting the user will receive information to resolve the issue. Once all the issues are resolved, the device state will switch to compliant.

AEfmd-Experience01 AEfmd-Experience02 AEfmd-Experience03
AEfmd-Experience04 AEfmd-Experience05

Note: Keep in mind that this is still preview functionality. When using app protection policies, the protected apps will still prompt for the installation of the Intune Company Portal app.

More information

For more information regarding the Microsoft Intune app and Android Enterprise fully managed devices, please refer to the following articles:

Conditional access and registering security information

Similar like last week, this week is also still about conditional access. This week is about the recently introduced user action of Register security information (Preview).  A lot has been posted about that recently and I had my post ready, but I wanted to wait for an official blog post before publishing my version. Just to make sure that I’m using the right reasons for using this feature. Also, it simply fits the line of my recent post. This user action can be used to add conditional action to Azure AD security services that require information of the end-user. In this post I’ll start with a short introduction about this new user action and the behavior that the user action controls. After that I’ll show the configuration steps, followed by the end-user experience.

Introduction

Let’s start with a short introduction about the Register security information (Preview) user action. This user action can be used to add conditional access to Azure AD security service that require information of the end-user. That enables the administrator to require the end-user to be in a trusted location to register for multi-factor authentication (MFA) or self-service password reset (SSPR). At this moment this user action responds to the following:

  • https://aka.ms/setupsecurityinfo – The new, still in preview, combined security information registration page for MFA and SSRP;
  • https://aka.ms/mfasetup – The MFA security information registration page. With preview features enables for end-user, this will redirect to the new combined page;
  • https://aka.ms/ssprsetup – The SSRP security information registration page. With preview features enables for end-user, this will redirect to the new combined page;

Configuration

Let’s continue by having a look at the configuration options. Let’s do that by looking at a simple scenario that is focused on the Register security information user action. That scenario is to only allow users to register their security information, when connecting from a trusted location. The following seven steps walk through that scenario.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or navigate to Azure Active Directory > Conditional access > Policies to open the Conditional Access – Policies blade;
2 On the Conditional Access – Policies blade, click New policy to open the New blade;
3a

RSI-UserGroups-IncludeOn the New blade, provide a unique name and select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, on the Include tab, select All users and click Exclude to open the Exclude tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

3b

RSI-UserGroups-ExcludeOn the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

RSI-CloudAppsOrActionsOn the New blade, select the Cloud apps or actions assignment to open the Cloud apps or actions blade. On the Cloud apps or actions blade, select User actions, select Register security information (preview) and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is only applicable to user actions to register security information.

5a

RSI-Locations-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Locations to open the Locations blade. On the Locations blade, click Yes with Configure, on the Include tab, select Any locations and click Exclude to open the Exclude blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to any location.

.

5b

RSI-Locations-ExcludeOn the Exclude tab, select All trusted locations and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude trusted locations. As this conditional access policy should only be applied to untrusted locations.

6

RSI-GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block access for any location that is not trusted by the IT organization.

.

7 Open the New blade, select On with Enable policy and click Create;

Note: Keep in mind that the Register security information user action is still in preview.

End-user experience

Now let’s end this post by having a look at the end-user experience. When the end-user is connecting from a non-trusted location, the end-user will be blocked from accessing any of the earlier mentioned URLs. In that case the end-user will receive the message “You cannot access this right now” as shown below.

RSI-EndUserExperience

I did notice a few hick-ups when using this feature in it’s early preview state:

  • When using the new combined security information registration page for MFA and SSRP, the URL will re-direct via the Microsoft App Access Panel. That can trigger other conditional access rules that are configured for cloud apps;
  • Often I could initially sign-in shortly before getting tossed out by conditional access;

More information

For more information regarding conditional access and sign-in frequency, please refer to the following article:

Conditional access and persistent browser sessions

Like last week, this week is also about conditional access. This week is about the recently introduced session control of Persistent browser session (preview). It was already possible to configure the persistence of browser sessions by using the company branding configuration, but this new session control provides the administrator with a lot more granularity. In this post I’ll start with a short introduction about this new session control and the behavior that the session control controls. After that I’ll show the configuration steps, followed by the administrator experience. 

Introduction

IMG_0029 1Now let’s start with a short introduction about the Persistent browser session (preview) session control. A persistent browser session allows the end-user to remain signed in after closing and reopening their browser window. The default configuration for browser session persistence, allows the end-user on a personal device to choose whether to persist the session by showing a “Stay signed in?” prompt after successful authentication.

The “Stay signed in?” prompt can be controlled on tenant-level, by editing the company branding, or by using the Persistent browser session (preview) session control. The session control provides a lot more flexibility, as it enables the administrator to differentiate on persistent browser sessions, based on the location, the sign-in risk, the location, the client app and the device state conditions that are applicable to the sign-in of the end-user. That and of course based on the end-user itself.

Configuration

Let’s continue by having a look at the configuration options. Let’s do that by looking at a simple scenario that is focused on the Persistent browser session access control. That scenario is to never have persisting browser sessions on any platform, for accessing any cloud app, on personal devices. The following seven steps walk through that scenario.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or navigate to Azure Active Directory > Conditional access > Policies to open the Conditional Access – Policies blade;
2 On the Conditional Access – Policies blade, click New policy to open the New blade;
3

KMSI-UserGroupsOn the New blade, provide a unique name and select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade,, on the Include tab, select All users and click Done to return to the New tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

4

KMSI-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select All cloud apps and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all cloud apps. This is also a required condition for the Persistent browser session (Preview) session control.

5

On the New blade, there is no need to select the Conditions assignment;

Explanation: This configuration will make sure that this conditional access policy is applicable to all platforms, locations, client apps and device states. That will also make sure that only personal devices are affected, as the “Stay signed in?” prompt is only shown on personal devices.

6

KMSI-SessionControlOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Persistent browser session (preview), select Never persistent and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will never persist browser sessions for the assigned users, to the assigned cloud apps.

Note: This Persistent browser session (preview) session control, will overwrite the “Stay signed in?” configuration in the company branding pane.

7 Open the New blade, select On with Enable policy and click Create;

Note: Keep in mind that the Persistent browser session control is still in preview.

Administrator experience

Now let’s end this post by having a look at the administrator experience. I’m deliberately not showing the end-user experience, as the configuration of this post will suppress the “Stay signed in?” prompt that was shown at the beginning of this post. A successful configuration would mean that the end-user no longer receives the “Stay signed in?” prompt. From an administrator perspective, this can be simply verified by looking at the Sign-ins report that is available in Azure Active Directory. That report will show the conditional access result for the applied conditional access policies and their session controls.

KMSI-SignIn

More information

For more information regarding conditional access and persistent browser sessions, please refer to the following article

Conditional access and requiring app protection policy

This week is focused on conditional access and the recently introduced grant control of Require app protection policy (preview). I already tweeted about it a couple of weeks a go, but I thought that it would be good to also write a little bit about this grant control. The Require app protection policy (preview) grant control could be seen as the successor of the Require approved client app grant control. The main difference is that the new Require app protection policy (preview) grant control will be more flexible. In this post I’ll start with a short introduction about this new grant control, followed by a configuration example. That example will be about a scenario for accessing Exchange Online. I’ll end this post by showing the end-user experience.

Introduction

Now let’s start with a short introduction about the Require app protection policy (preview) grant control. This grant control is not static and will be flexible as it will simply require that the user received an app protection policy for the app that is used for accessing the respective cloud app. That immediately checks a couple of boxes, as it will require the user to have an Intune license, it will require the user to receive app protection policies and it requires apps to be configured to receive an app protection policy. Besides that, this will also enables organizations to start using third-party apps and line-of-business apps in combination with conditional access. That should be a big advantage compared to the Require approved client app grant control.

There are also a couple of things keep in mind; the Require approved client app grant control only supports iOS and Android and the apps should be using the Intune App SDK. Also, at this moment, this grant control only applies to Microsoft OneDrive and Microsoft Outlook.

Configuration

Let’s continue by having a look at the configuration options, by looking at a simple scenario that is focused on the Require approved client app grant control. That scenario is requiring an app protection policy on any platform, for accessing Exchange Online. Not supported platforms should be blocked. The following seven steps walk through that scenario.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies to open the Conditional Access – Policies blade;
2 On the Conditional Access – Policies blade, click New policy to open the New blade;
3

RAPP-UsersGroupsOn the New blade, provide a unique name and select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade,, on the Include tab, select All users and click Done to return to the New tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

4

RAPP-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select Select apps and click Select to open the Select blade. On the Select blade, select the Office 365 Exchange Online cloud app and click Done to return to Cloud apps blade and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is only applicable to Exchange Online.

5

On the New blade, there is no need to select the Conditions assignment;

Explanation: This configuration will make sure that this conditional access policy is applicable to all platforms, locations, client apps and device states. That will also make sure that platforms, which are not supported by this grant control, will be blocked.

6

RAPP-GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access, select Require app protection policy (preview) and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will grant access for the assigned users, to the assigned cloud apps, when using an app with app protection policy applied.

7 Open the New blade, select On with Enable policy and click Create;

Note: Keep in mind that the Require app protection policy control is still in preview.

End-user experience

Now let’s end this post by having a look at the end-user experience on an iOS device. Specifically in scenarios when the end-user will be blocked. When the end-user wants to configure their email in the native iOS mail app, the end-user will receive a notification as shown below. It basically explains the end-user that this app is not approved.

IMG_0026

When the end-user wants to configure their email in the Outlook app, but no app protection policy is assigned to the app, the end-user will receive a notifications as shown below. It simply explains the end-user that no app protection policy is applied.

IMG_0027

Note: Keep in mind that this is still a preview feature. In some of my test I would receive the (returning) message in the Outlook app, but I could still send and receive email.

More information

For more information regarding conditional access and requiring app protection policies, please refer to the following articles:

Using the power of ConfigMgr together with Microsoft Intune to determine device compliance

This week is all about device compliance. More specifically, about using the combination of ConfigMgr and Microsoft Intune for device compliance. In a cloud-attached scenario, in which ConfigMgr is attached to Microsoft Intune, it’s possible to use the ConfigMgr client in combination with a MDM enrollment. This is also known as co-management. In that scenario it’s possible to slowly move workloads from ConfigMgr to Microsoft Intune, like the compliance policies workload. In that scenario Microsoft Intune will become responsible for the compliance state of the device. However, switching that workload to Microsoft Intune, also limits the available device compliance checks. In case the organization still needs to verify the availability of certain apps, or updates, there’s a solution. Even when the workload is switched to Microsoft Intune. That solution is: Configuration Manager Compliance. In this post I’ll start with an introduction about Configuration Manager Compliance and using that in combination with Microsoft Intune, followed by the configuration in Microsoft Intune. I’ll end this post by showing the end-user experience.

Introduction about Configuration Manager Compliance

Now let’s start with an introduction about Configuration Manager Compliance. Configuration Manager Compliance is a recently introduced configuration option in a device compliance policy in Microsoft Intune. That configuration options enables the administrator to use the device compliance policy in Microsoft Intune together with the device compliance state send from Configuration Manager. That enables the administrator to still use the configuration options from a compliance policy in Configuration Manager, even though the workload is switched to Microsoft Intune. In other words, it enables the administrator to still verify if specific required apps are installed, or that the device has the latest updates installed. End-to-end the following happens for the user/device:

  • Device is managed by Configuration Manager;
  • Device is enrolled with Microsoft Intune;
  • Configuration Manager evaluates the device compliance;
  • Configuration Manager sends the compliance state to Microsoft Intune;
  • Microsoft Intune evaluates the device compliance;
  • Microsoft Intune generates a combined compliance report;
  • Azure AD enforces conditional access;
  • Azure AD allows (or blocks) access for (non)compliant devices;
  • End-user receives a friendly remediation experience via Microsoft Intune and Configuration Manager (see the section about the end-user experience).

Note: This configuration option requires Configuration Manager 1810, or later.

Configuration of Configuration Manager Compliance

Let’s continue by having a look at the configuration. The configuration assumes that a Configuration Manager compliance policy is already available. The following 3 steps walk through the configuration of the Configuration Manager Compliance policy setting in a device compliance policy. Nothing more, nothing less. After creation, the device compliance policy can be assigned like any other device compliance policy. The created device compliance policy is applicable to all targeted users and/or devices. The Configuration Manager Compliance policy setting is only applicable to co-managed devices.

1 Open the Azure portal and navigate to Microsoft Intune > Device compliance > Policies to open the Device compliance – Policies blade;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3a

CMC_CreatePolicyOn the Create Policy blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Settings: See step 3b;
  • Actions for noncompliance: Leave default (for this post);
  • Scope (Tags): Leave default (for this post);

Note: Configuring non-standard values for Actions for noncompliance and Scope (Tags), is out of scope for this post.

3b

CMC_Windows10CompliancePolicyOn the Windows 10 compliance policy blade, select Configuration Manager Compliance to open the Configuration Manager Compliance blade;

Note: Configuring non-standard values for the Device Health, Device Properties, System Security and Windows Defender ATP, is out of scope for this post.

3c On the Configuration Manager Compliance blade, select Require with Require device compliance from System Center Configuration Manager and click OK to return to the Windows 10 compliance policy blade;
CMC_ConfigurationManagerCompliance
3d Back on the Windows 10 compliance policy blade, click OK;

Note: To take full advantage of this device compliance policy configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Let’s end this post by having a look at the end-user experience. As a starting point for the example below I’ve created a compliance policy that requires all applications (and software updates) with a deadline older than 30 days to be installed. When one (or more) of the required applications is not installed, the end-user will receive a message in Software Center as shown below. It clearly explains the end-user that not all required applications are installed. Mentioning the required applications would be a nice addition.

CMC_Example_SoftwareCenter

Via the Company Portal app the message will be a little less clear. The end-user will simply receive the message that some changes need to be made. A referral to Software Center could be a nice addition.

CMC_Example_CompanyPortal

The administrator can always see the status in the different consoles. Microsoft Intune will show a not compliant message for the Require with Require device compliance from System Center Configuration Manager setting and Configuration Manager will show a not compliant message for the specific rule of the compliance policy.

More information

For more information regarding Configuration Manager Compliance, please refer to the section Configuration Manager Compliance in the  Add a device compliance policy for Windows devices in Intune article.

The conditional access policy flow

This week is still all about conditional access. However, this week it’s not about a specific configuration. This week it’s about the conditional access policy flow. The flow that will help with determining if a conditional access policy is applicable to the user’s attempt to access a cloud app and if access will be allowed or blocked. The idea is similar to the What if tool. The big difference is that the What if tool does a technical check to see which conditional access policy is applicable and this flow can help with determining why a conditional access policy is applicable, or not. Also, almost as important, this flow will clearly show how many options are available to exclude specific users and devices. This is important to know, because if no conditional access policy is applicable, the user’s attempt to access a cloud app (which means company resources) will be allowed. The flow is shown below.

TheConditionalAccessFlow

Note: The sign-in risk condition is left out of this flow, as it requires Azure AD Identity Protection. The idea for that condition would be similar to the other conditions. Also, the session controls are left out of this flow. The idea for that control should be similar to other controls, except that this control will not directly block access as it will only provide a limited experience.

The main idea of this flow is to make it very clear that there can be many reasons for a conditional access policy to not be applicable (see all the yellow ovals in the flow above). The flow goes through the following conditions and controls:

  • Conditions (can be used to filter):
    • Users and groups: Required condition, which is captured in this flow with “Is the policy assigned to the user?”. This should be the result of the included and excluded user groups;
    • Cloud apps: Required condition, which is captured in this flow with “Is the policy assigned to the cloud app?”. This should be the result of the included and excluded cloud apps;
    • Sign-in risk: Condition not part of this flow (see note);
    • Device platforms: Optional condition (“Is the device platform condition enabled?”), which is captured in this flow with “Does the policy include the device platform?”. This should be the result of the included and excluded device platforms;
    • Locations: Optional condition (“Is the device locations condition enabled?”), which is captured in this flow with “Does the policy include the location?”. This should be the result of the included and excluded locations;
    • Client apps: Optional condition (“Is the client app condition enabled?”), which is captured in this flow with “Does the policy include the client app?”. This should be the result of the included and excluded client apps;
    • Device state: Optional condition (“Is the device state condition enabled?”), which is captured in this flow with “Does the policy include the device state?”. This should be the result of the included and excluded device states;
  • Controls (can be used to set an action)
    • Grant: Optional control that can be used to block or grant access, which is captured in this flow with “Does the policy grant access?”, and when used to grant access it must set requirements, which is captured in this flow with “Does the device and/or app meet the requirements?”.
    • Session: Control not part of this flow;

The main message of this flow is awareness. Be aware of which users and devices are excluded from the conditional access policy. Those users and devices should be assigned to separate conditional access policies, to make sure that the conditional access configuration creates a secure environment without any (unknown) backdoors.

More information

For more information about conditional access, please refer to the docs that are available here: https://docs.microsoft.com/en-us/intune/conditional-access

Block access to all cloud apps for unsupported platforms

This week something different compared to the last couple of weeks. This week is all about conditional access, but not about particular new functionality. This week I want to show a relatively simple method to make conditional access policies as secure and complete as possible. By using device platforms as an example, I want to show how to make sure that only device platforms supported by the IT organization can access company data. And really only those device platforms. In this post I’ll provide a short introduction of this method, followed by the related configurations. I’ll end this post by showing the end-user experience.

Introduction

Let’s start with a short introduction about this method to make sure that only specific device platforms, supported by the IT organization, can access company resources (with company resources I’m referring to all the cloud apps, used by the organization, that are integrated with Azure AD). When creating conditional access policies, it’s possible to apply the conditional access policies only to specific device platforms. However, that will make sure that the conditional access policies are not applicable to any other device platform. That might create a backdoor in the conditional access setup. To prevent this type of backdoors, it’s the best to use at least two conditional access policies:

  1. Block access: The block access conditional access policy is used to block access for all device platforms with the exclusion of specific device platforms supported by the IT organization;
  2. Grant access: The grant access conditional access policy is used to grant access for the device platforms, excluded from the block access policy, supported by the IT organization. This can also be multiple conditional policies, when it’s required to differentiate between device platforms.

Note: Similar constructions can be created for basically any configuration within a conditional access policy that can differentiate between include and exclude configurations.

Configuration

Now let’s continue by looking at the actual configuration. The configuration contains at least two conditional access policies, which are explained below.

Block configuration

The first and main configuration is the block access configuration. This conditional access policy will be used to make sure that device platforms, that are unsupported by the IT organization, are not allowed to access company resources. Simply follow the seven steps below.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;;
2 On the Policies blade, click New policy to open the New blade;
3a

CAB-UsersGroups-IncludeOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade,, on the Include tab, select All users and click Exclude to open the Exclude tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

3b

CAB-UsersGroups-ExcludeOn the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

CAB-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all connected cloud apps.

5a

CAB-DevicePlatforms-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device platforms to open the Device platforms blade. On the Device platforms blade, click Yes with Configure, on the Include tab, select All platforms (including unsupported) and click Exclude to open the Exclude blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all platforms.

5b

CAB-DevicePlatforms-ExcludeOn the Exclude tab, select Android, iOS and Windows and click Done to return to the Conditions blade. On the Conditions bade, click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude specific device platforms that are supported by the IT organization and that will be covered with different conditional access policies. Keep in mind that every device platform that is excluded from this conditional access policy should be part of a separate conditional access policy (include).

6

CAB-Grant-BlockOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block access for all device platforms that are not supported by the IT organization and that are not part of a separate conditional access policy (include).

7 Open the New blade, select On with Enable policy and click Create;

Allow configuration

The second configuration is the allow access configuration. This conditional access policy (or conditional access policies) will be used to make sure that the device platforms, excluded from the block configuration and that are supported by the IT organization, are allowed access to company resources when those devices meet specific requirements. To configure a conditional access policy like this simply follow the seven steps below.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;;
2 On the Policies blade, click New policy to open the New blade;
3a

On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade,, on the Include tab, select All users and click Exclude to open the Exclude tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users. Keep in mind that this can also be any user group that should be assigned, as long as in the end picture every user, using an excluded platform, is part of a conditional access policy. Also, when using Azure AD Sync it might be useful to exclude the service account, to enable the Azure AD synchronization.

3b

On the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select All cloud apps and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all connected cloud apps. Keep in mind that this can also be any specific cloud app that should be assigned, as long as in the end picture every cloud app, that can be accessed by an excluded platform, is part of a conditional access policy. Also, when assigning all cloud apps it might be useful to exclude the Microsoft Intune Enrollment app, to enable enrollment for the devices.

5

On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device platforms to open the Device platforms blade. On the Device platforms blade, click Yes with Configure, on the Include tab, select Select device platform and select Android, iOS and Windows and click Done to return to the Conditions blade. On the Conditions bade, click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all the earlier excluded device platforms. Keep in mind that this can also be any specific device platform, as long as in the end picture every device platform, that was initially excluded, is part of a conditional access policy.

6

On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access, select Require device to be marked as compliant and select Require Hybrid Azure AD joined device, select Require one of the selected controls and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will grant access for the different device platforms, as long as the device meets the selected requirements. Keep in mind that this can be any of the available requirements.

7 Open the New blade, select On with Enable policy and click Create;

Note: This configuration is not showing any screenshots as the screenshots are similar to the screenshots used within the block configuration.

End-user experience

Now let’s end this post by looking at the end-user experience. To make it a bit confusing, I’ll use a Windows 10 device to show the experience of a blocked user. Assuming Windows was not excluded by the block configuration, the end-user will receive a message similar to the message shown below. It doesn’t provide the end-user with the option to register the device, as the device is simply blocked.

CAB-Windows10

A good place to look for the end-result, from an administrator perspective, is to look at the sign-in information in the Azure portal (Azure Active Directory > Sign-ins). That will provide a failure message with a clear reason “Access has been blocked due to conditional access policies”.

CAB-Windows10-AAD

More information

For more information regarding conditional access, please refer to the following articles:

Conditional access and Outlook on the web for Exchange Online

This week a blog post about conditional access. More specifically, about conditional access and enforced restrictions with Outlook on the web for Exchange Online. This can be used to provide users with access to Outlook on the web, but still protect company data. That can be achieved by configuring a limited experience for users with regards to attachments. The enforced restrictions can enable a read only option for attachments in the browser and can completely block attachments in the browser. In this post I’ll walk through the required configurations, with the focus on conditional access, and I’ll show the end-user experience.

Configuration

Let’s start with looking at the configuration. The main focus in the configuration is conditional access, but as that configuration has no use without configuring the Outlook on the web mailbox policies, I’ll also provide the main configuration options from an Exchange Online perspective.

Exchange Online configuration

The most important and only configuration, from an Exchange Online perspective, is to configure the Outlook on the web mailbox policy. That configuration must be done by using PowerShell. When there is an Outlook on the web mailbox policy, the required cmdlet is Set-OwaMailboxPolicy. That cmdlet contains the parameter ConditionalAccessPolicy. That parameter can be used to specify the Outlook on the web mailbox policy for limited access and can have the following values:

  • Off: This value means that no conditional access policy is applied to Outlook on the web;
  • ReadOnly: This value means that users can’t download attachments to their local computer, and can’t enable offline mode on non-compliant computers;
  • ReadOnlyPlusAttachmentsBlocked: This value means that all restrictions from ReadOnly apply, but that users can’t view attachments in the browser.

Note: In the end-user experience section, I’ll show the experience for both values.

Conditional access configuration

Once the conditional access policy configuration is in place for the Outlook on the web mailbox policy, it’s time to look at the actual conditional access configuration in Azure AD. The following eight steps walk through the steps to create a conditional access policy that will require multi-factor authentication and enforce a restriction on Outlook on the web, for devices that are not hybrid Azure AD joined and that are not compliant.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;;
2 On the Policies blade, click New policy to open the New blade;
3

OOTW-UsersGroupsOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

4

OOTW-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps > Office 365 Exchange Online and click Done;

Explanation: This configuration will make sure that this conditional access policy is applicable to Exchange Online.

5a

OOTW-DevicePlatformsOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device platforms to open the Device platforms blade. On the Device platforms blade, click Yes with Configure, select All platforms (including unsupported) and click Done to return to the Conditions blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all platforms.

5b

OOTW-ClientAppsBack on the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Browser and click Done to return to the Conditions blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to browser sessions.

5c

OOTW-DeviceStateBack on the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, select Device Hybrid Azure AD joined and Device marked as compliant on the Exclude tab and click Done and Done;

Explanation: This configuration will make sure that this conditional access policy is applicable to unmanged devices, by excluding hybrid Azure AD joined and compliant devices (which are both considered managed).

6

OOTW-GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access > Require multi-factor authentication and click Select;

Explanation: This configuration will make sure that this conditional access policy will require multi-factor authentication .

7

OOTW-SessionOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Use app enforced restrictions and click Select;

Explanation: This configuration will make sure that this conditional access policy will enforce the configured restrictions in Outlook on the web for Exchange Online..

8 Open the New blade, select On with Enable policy and click Create;

End-user experience

Let’s end this post by looking at the end-user experience, for both configurable values for the Outlook on the web mailbox policy for limited access. When using an unmanaged device the user must user multi-factor authentication, which will be followed by the experiences showed below.

The first value is the ReadOnly value, which forces read only restrictions to any email attachment. Besides that it also prevents users from saving the attachments locally, as it only allows the user to save the attachments to OneDrive. Below is an example of that behavior. It also shows on top of the mail that the user is notified about the limited experience.

OutlookOTW-ReadOnly

The second value is the ReadOnlyPlusAttachmentsBlocked value, which forces email attachments to be blocked from being opened via Outlook on the web. Basically it prevents any interaction with the attachment. Below is an example of that behavior. It also shows on top of the mail that the user is notified about the limited experience.

OutlookOTW-ReadOnlyPlusAttachmentsBlocked

Note: This behavior does require disciplined users, as these type of limitations in the user experience might trigger users to forward messages to another account.

More information

For more information about conditional access in combination with Outlook on the web for Exchange Online, please refer to the following articles:

Block access to company resources if certain apps are installed

This week is all about device compliance. More specifically, this week is all about the just introduced capability to block access to company resources if certain apps are installed. This enables organizations to truly blacklist specific apps that are not allowed when using devices to access company resources. In this case it’s not about the apps used for accessing the company resources, but it’s really about the apps installed on the device. In this post I’ll provide the configuration steps, by using OWA for iPad as an example, followed by the end-user experience.

Configuration

Before starting with the actual configuration, it’s important to get the bundle ID of the iOS app that cannot be installed. These steps are very clearly documented here. I will use OWA for iPad as an example, which has the following bundle ID: com.microsoft.exchange.ipad.

Now let’s continue by having a look at the configuration steps. The following five steps walk through the creation of a device compliance policy with at least the configuration of OWA for iPad as a restricted app. Within a device compliance policy a restricted app is what was earlier described, in this post, as blacklisted apps. After the creation of the device compliance policy, simply assign it to the applicable user group.

1 Open the Azure portal and navigate to Intune > Device compliance > Policies;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3

On the Create Policy blade, provide a Name, select iOS with Platform and select Settings to open the iOS compliance policy blade;

Note: This is currently an iOS only configuration. Android is expected a bit later.

4 On the iOS compliance policy blade, select System Security to open the System Security blade;
5

On the System Security blade, navigate to the Device Security section, provide the App name, the App Bundle ID and click Add, followed by and clicking OK, OK and Create.

Note: The provided App name will be mentioned in the potential non-compliance message to the end-user and the App Bundle ID is in this example the id of the OWA for iPad app.

MSI-RestrictApp

Note: To complete this configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Now let’s end this post with the end-user experience. Let’s do that by looking at the end-user experience on an iOS device with OWA for iPad installed. On the left is the default message that is displayed to the end-user when trying to access company data on a non-compliant device. On the right is the message that the end-user will receive in the Company Portal app related to the compliance state of the device. In this case it will provide the end-user with a list of disallowed apps that should be uninstalled. The list shows the name of the app, as provided in the compliance policy.

IMG_0143 IMG_0144

More information

For more information about blocking access if certain apps are installed, refer to the documentation about adding a device compliance policy for iOS devices in Intune.