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

Conditional access and blocking downloads

This week is all about using conditional access for blocking downloads. I already did something similar before by using app enforced restrictions for Exchange Online and SharePoint Online. This time I’m going to take it one step further by looking at recently adjusted functionality for Conditional Access App Control. Conditional Access App Control enables administrators to control user sessions by redirecting the user through a reverse proxy instead of directly to the app. From then on, user requests and responses go through Cloud App Security rather than directly to the app. This creates an additional layer that can be used to filter actions. In this blog post I’ll start with a short introduction about Conditional Access App Control, followed by the configuration steps and the end-user experience.

Note: Cloud App Security can be licensed as part of EMS E5 or as a standalone service.

Introduction

Now let’s start with a short introduction about Conditional Access App Control. Conditional Access App Control uses a reverse proxy architecture and is directly integrated with conditional access. Conditional access enables administrators to route users to Cloud App Security, where data can be protected. That can be achieved by applying Conditional Access App Control session controls. That created route enables user app access and sessions to be monitored and controlled in real time, based on access and session policies in Cloud App Security. Those policies can also be used to further refine filters and set actions to be taken on a user. In other words, Conditional Access App Control enables administrators to control user sessions by redirecting the user through a reverse proxy instead of directly to the app.

Configuration

Let’s continue by having a look at the configuration options, by looking at a specific scenario. That scenario is blocking downloads on unmanaged devices, for any supported cloud app. The following seven steps walk through that scenario. After the creation of the conditional access policy, it can be assigned to a user group like any other conditional access policy.

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;
3a

CAS-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

CAS-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.

4

CAS-CloudApps-IncludeOn 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.

5a

CAS-DeviceState-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. 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, on the Include tab, select All device state and and click Exclude to open the Exclude tab;;

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

5b

CAS-DeviceState-ExcludeOn the Exclude tab, select Device Hybrid Azure AD joined, select Device marked as compliant and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude managed and compliant devices.

6

CAS-Session-CAACOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Use Conditional Access App Control, select Block downloads (preview) and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block downloads for the assigned users, from the assigned cloud apps, on unmanaged devices. The latest options within this configuration are the built-in options Monitor only and Block downloads, which are both still in preview and Use custom policy…. The latter option requires a custom policy within Cloud App Security. The other options two basically provide preconfigured options, of which Block downloads provides the behavior that I need for this scenario.

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

Note: Conditional Access App Control supports any SAML or Open ID Connect app that is configured with single sign-on in Azure AD, including these featured apps.

End-user experience

Now let’s end this blog post by having a look at the end-user experience. Below are example for the behavior with SharePoint Online and Exchange Online. I deliberately choose those apps, to show the difference in end-user experience compared to using app enforced restrictions (which I mentioned in the beginning of this post). The big difference is that app enforced restrictions are handled by the app, while this configuration is handled by Cloud App Security.

Below on the left is an example of the end-user accessing SharePoint Online on an unmanaged device. The end-user receives a clear message that the access is monitored. Below on the right is an example of the end-user trying to download a file from SharePoint Online, while being directed via Cloud App Security. The end-user receives a clear message that the download is blocked.

CAS-Example-SPO01 CAS-Example-SPO02

Below are similar examples for Exchange Online. On the left the message that the end-user receives when access Exchange Online on an unmanaged device and on the right the message that the end-user receives when trying to download an email attachment.

CAS-Example-EXO01 CAS-Example-EXO02

More information

For more information regarding Cloud App Security and conditional access, please refer to the following articles:

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:

Offline Windows Autopilot deployment profile

This week is all about Windows Autopilot. More specifically, about offline Windows Autopilot deployment profiles. The use case for an offline Windows Autopilot deployment profile is simple, a migration from Windows 7 to Windows 10 for existing devices. It enables organizations to reimage devices for one last time and provide those devices with an offline Windows Autopilot deployment profile. That will make sure that those devices will contact the Windows Autopilot deployment service, without first being registered. In this post I’ll look at getting the offline Windows Autopilot deployment profile, followed by a look at the explanation of the attributes in the offline Windows Autopilot deployment profile. I’ll end this post by looking at the usage of the offline Windows Autopilot deployment profile and a method to group the devices that are deployed via an offline Windows Autopilot deployment profile.

How to get the offline deployment profile

Let’s start by having a look at how to get the offline Windows Autopilot deployment profile. The following five steps walk through the process of downloading the required PowerShell cmdlets, connecting to the correct services and saving the Windows Autopilot deployment profile as a JSON-file.

1 Open a Windows PowerShell command box, as an administrator, on an Internet connected device
2 Install the Azure AD module by using Install-Module AzureAD -Force
3 Install the Windows Autopilot module by using Install-Module WindowsAutopilotIntune -Force
4a Connect to the Intune service by using Connect-AutopilotIntune
4b Provide the user principle name of a user with enough administrative rights and provide the password in the Sign in to your account window
5

Export the Windows Autopilot deployment profile (Get-AutoPilotProfile), convert the deployment profile to JSON-fornat (ConvertTo-AutoPilotConfigurationJSON) and save the output as AutoPilotConfigurationFile.json (Out-File) by using Get-AutoPilotProfile | ConvertTo-AutoPilotConfigurationJSON | Out-File -FilePath $env:userprofile\desktop\AutoPilotConfigurationFile.json -Encoding ASCII

Note: When there are multiple deployment profiles configured in the tenant, there should be an additional filter being used to only export a specific deployment profile.

OWADP-JSON

Explanation of the attributes in the offline deployment profile

The JSON-file contains a few different attributes and it’s good to understand the usage of those attributes. The following table contains the different attributes and a short explanation.

Attribute Explanation
CloudAssignedTenantId This GUID is a required attribute and specifies the GUID of the Azure AD tenant that should be used.
CloudAssignedDeviceName This string is an optional attribute and specifies the naming pattern for devices that should be used.
CloudAssignedForcedEnrollment

This number is a required attribute and specifies if the device should require AAD Join and MDM enrollment. This can be one of the following values:

  • 0 = not required,
  • 1 = required.
Version This number is an optional attribute and specifies the version that identifies the format of the JSON file. For Windows 10, version 1809, the version must be 2049.
Comment_File This string is an optional attribute and specifies a comment that by default contains the name of the profile.
CloudAssignedAadServerData This encoded JSON string is a required attribute and specifies the branding configuration (this requires Azure AD branding to be enabled) that should be used.
CloudAssignedOobeConfig

This number is a required attribute and specifies a bitmap that shows which Autopilot settings should be configured. This can include the following values:

  • SkipCortanaOptIn = 1,
  • OobeUserNotLocalAdmin = 2,
  • SkipExpressSettings = 4,
  • SkipOemRegistration = 8,
  • SkipEula = 16
CloudAssignedDomainJoinMethod This number is a required attribute and specifies the domain join method that should be used. Both hybrid AAD join and AAD join should be set to 0.
ZtdCorrelationId This GUID is a required attribute and specifies a unique GUID that will be provided to Intune as part of the registration process. This GUID can be used to group the devices in a dynamic Azure AD security group.
CloudAssignedTenantDomain This string is a required attribute and specifies the name of the Azure AD tenant that should be used.

How to use the offline deployment profile

The offline Windows Autopilot deployment profile can be used on Windows 10, version 1809, or later. The only other requirements are that the file is named AutoPilotConfigurationFile.json and that the file is available in C:\Windows\Provisioning\Autopilot\. Below are a few example processes that can be used to prepare a device with an offline Windows Autopilot deployment profile.

1 Manual copy the file to the required location and SYSPREP the device,
2 Use a USB-stick to install Windows and in the same process copy the file to the required location and SYSPREP the device.
3 Use MDT to install Windows and in the same process copy the file to the required location and SYSPREP the device.
4 Use Configuration Manager to install Windows and in the same process copy the file to the required location and SYSPREP the device.
5 Use a third-party product to install Windows and in the same process copy the file to the required location and SYSPREP the device.

How to group devices based on the offline deployment profile

The last thing that is good to mention, is that it’s also possible to group devices based on the fact that it was deployment via an offline Windows Autopilot deployment profile. Devices that are enrolled by using an offline Windows Autopilot deployment profile, will have the Azure AD device attribute enrollmentProfileName set to “OfflineAutopilotprofile-<ZtdCorrelationId>”. The ZtdCorrelationId is available in the offline Windows Autopilot deployment profile as shown and mentioned above. That would make a dynamic query for an Azure AD device group like this: (device.enrollmentProfileName -eq “OfflineAutopilotprofile-7F9E6025-1E13-45F3-BF82-A3E8C5B59EAC”).

More information

For more information regarding offline Windows Autopilot profiles, please refer this article about Windows Autopilot for existing devices.

Block access to a device until specific apps are installed

ESP-BlockApps-TweetThis week a short blog post about a recently introduced feature in the Enrollment Status Page (ESP). The ability block access to a device until specific apps are installed. I also tweeted about that feature recently and I thought it would be good to document the use case, the configurations and the end-user experience.

Introduction

Let’s start with a short introduction. The ESP is strongly recommended with Windows Autopilot. The idea of the ESP, is to block the device until the device is ready for usage by the user. This new feature enables an administrator to only block the device until the most important apps are installed for the user. That enables the user to be earlier productive. The administrator simply chooses which apps are tracked on the ESP and until those apps are installed, the user can’t use the device.

With the recent updates to Microsoft Intune, the ESP can track the following apps:

  • Licensed Microsoft Store for Business apps;
  • Line-of-business apps (APPX, MSIX, single-file MSI)
  • Office 365 ProPlus apps

Note; Keep in mind that there are difference between the user context and the system context. For the exact up-to-date details see the links in section More information.

Configuration

Now let’s continue by looking at the available configuration options. The following three steps walk through adjusting the default ESP. Those steps will show which configurations are required to get to the available configuration options for tracking specific apps. Similar steps are applicable when configuring custom ESPs.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment > Enrollment Status Page (Preview) to open the Enrollment Status Page (Preview) blade;
2 On the Enrollment Status Page (Preview) blade, select Default > Settings to open the All users and all devices – Settings blade;
3a On the All users and all devices – Settings blade, select Yes with Show app and profile installation progress and Yes with Block device use until all apps and profiles are installed to enable the Block device use until these required apps are installed if they are assigned to the user/device setting (see step 3b);
3b When the Block device use until these required apps are installed if they are assigned to the user/device setting is enabled, select Select apps to open the Select apps blade. On the Select apps blade, select the required apps and click Select to return to the All users and all devices – Settings blade and click Save;
ESP-BlockApps-Config

Note: Keep in mind that if the ESP is configured to track Office 365 ProPlus apps, other large apps, or just many apps, it might be required to also increase the timeout as documented in this Support Tip.

End-user experience

Now let’s end this post by looking at the end-user experience. The good thing is that the user will not notice any big differences. The user will still get the same screens and the same experiences. Only users that pay attention to details will notice the small differences. As shown below, the user will see a list of apps that is equal to the number of configured apps by the administrator. That list is most likely shorter then it was before. That’s also the reason why the user might notice that it’s possible to get productive sooner, as the device will be available for use sooner.

ESP-BlockApps-EUE

More information

For more information regarding blocking devices until certain apps are installed, 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:

Hybrid Azure AD join with Windows Autopilot

This week is all about a very often requested feature, which is the ability to hybrid Azure AD join a device when using Windows Autopilot. The combination of the latest updates to Microsoft Intune with Windows 10, version 1809, provides just that! The ability to hybrid Azure AD join a device when using Windows Autopilot! In other words, the device will join the on-premises Active Directory and register in Azure Active Directory. In this blog post I’ll start with a short introduction about the hybrid Azure AD join with Windows Autopilot, followed by the most important configurations. I’ll end this post by looking at the experience.

Introduction

Let’s start with a little introduction about the hybrid Azure AD join through Windows Autopilot. A short summary would be that Intune uses an on-premises connector to create an offline domain join (ODJ) blob for the device that will be provided to the device during enrollment. Now lets go through the high-level Autopilot flow for this scenario and see how that fits.

  • The hardware ID of the device is registered with the Windows Autopilot service;
  • The device is sent to the employee and the employee unboxes the device and turns it on;
  • The device connects to the Windows Autopilot service;
  • The Windows Autopilot service delivers the Autopilot profile to the device;
  • The device performs a MDM-enrollment with Microsoft Intune;
  • Microsoft Intune will use the on-premises connector to generate a machine object in Active Directory, which will generate an ODJ blob;
  • The connector sends the ODJ blob to Microsoft Intune;
  • Microsoft Intune sends the ODJ blob to the device;
  • The MDM-enrollment is completed;
  • The user logs on to the device to complete the domain join;
  • The device receives any targeted group policies;

Configuration

Now let’s continue by looking at the configurations that are required to enable the hybrid Azure AD join scenario via Windows Autopilot. I’ll do that by going through the new Intune-related configurations. That means, I’ll show how to install the Intune connector, I’ll show how to configure the Autopilot deployment profile and I’ll show how to configure the domain join profile.

Requirements

Before looking at the configurations, let’s start with a few important requirements and limitations:

  • The hybrid Azure AD join environment configurations must be in place;
  • The device must run Windows 10, version 1809 or later;
  • The device must have Internet access;
  • The device must have direct access to Active Directory;
  • Automatic enrollment must be configured (Azure AD > Mobility (MDM and MAM));
  • The server hosting the Intune connector must have delegated permissions to create computer accounts in the specified OU;
  • The server hosting the Intune connector must be Windows Server 2016, or later;
  • The server hosting the Intune connector must have Internet connectivity;

Intune connector

The first configuration that should be in place is the installation of the Intune connector. Multiple connectors can be installed to increase scale and availability (or even to support multiple Active Directory domains). The following nine steps walk through the steps to install the Intune connector.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Intune Connector for Active Directory (Preview) to open the Intune Connector for Active Directory (Preview) blade;
3 On the Intune Connector for Active Directory (Preview) blade, select Add connector to open the Add connector blade;
4 On the Add connector blade, click the Download the on-premises Intune Connector for Active Directory to download the connector for Active Directory (ODJConnectorBootstrapper.exe);
5 On the server that should be running the Intune connector for Active Directory, run ODJConnectorBootstrapper.exe;
6 On the Intune Connector for Active Directory Setup dialog box, select I agree to license terms and conditions and click Install;
7 On the Intune Connector for Active Directory Setup dialog box, after the installation completed, select Configure Now ;
8 On the Intune connector for Active Directory dialog box, select Sign In to sign in with a global administrator account to enroll the connector in the tenant and close the dialog box;
9 Back on the Intune Connector for Active Directory (Preview) blade, it should now show an entry for the added connector with the name of the server that is running the connector;
ICforAD

Note: At this moment, make sure that a language pack is installed and configured as described in the Intune Connector (preview) language requirements.

Autopilot deployment profile

The second configuration that should be in place is the Windows Autopilot deployment profile. The following four steps walk through the steps to create the deployment profile. That deployment profile can be assigned to an Azure AD group that contains the required Autopilot devices.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows Autopilot Deployment Program section to open the Windows Autopilot deployment profiles blade;
3 On Windows Autopilot deployment profiles blade, select Create profile to open the Create profile blade;
4a WADP-HAADJOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the Windows Autopilot deployment profile;
  • Description: (Optional) Provide a description for the Windows Autopilot deployment profile;
  • Convert all targeted devices to Autopilot: Select Yes to automatically convert Intune managed devices to Autopilot;
  • Deployment mode: Select User-Driven, as that deployment mode provides the functionality that is needed for this post;
  • Join to Azure AD as: Select Hybrid Azure AD joined (Preview), as that will trigger the on-premises domain join with device registration in Azure AD;
  • Out-of-box experience (OOBE): See 4b

Note: The hybrid Azure AD join is only available for user driven deployments.

4b

On the Out-of-box experience (OOBE) blade, provide the following information and click Save.

  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot hybrid Azure AD join experience;

  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot hybrid Azure AD join experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot hybrid Azure AD join experience;
  • User account type: Select Standard to only make any user on the device a standard user;
  • Apply computer name template (Windows Insider Only): Not applicable, as the computer name standard is defined in the Domain Join profile (see next section);
WADP-HAADJ-OOBE

Domain Join profile

The third configuration that should be in place is the domain join profile. The following four steps walk through the steps to create the domain join profile. That domain join profile can be assigned to an Azure AD group that contains the required Autopilot devices.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, select Create profile to open the Create profile blade;
3a On the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the domain join profile;
  • Description: (Optional) Provide a description for the domain join profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Domain Join (Preview);
  • Settings: See 3b;
3b On the Domain Join (Preview) blade, provide the following information and click OK;

  • Computer name prefix: Provide a computer name prefix. The remaining characters of the 15 characters of a computer name will be random;
  • Domain name: Provide the domain name that the device will join;
  • Organizational unit: (Optional) Provide the OU that the computer account is created in;
WADP-HAADJ-DJP

Note: When no OU is specified, the well known computer object container is used.

End-user experience

Let’s end this post by looking at the end-user experience. The beginning of the out-of-box-experience (OOBE) is similar to any other Windows Autopilot deployment. The difference is happening in the background, as explained during the introduction, and can be noticed during the Network configuration. The configuration will take longer than with a Azure AD join. Another thing that an administrator might notice is that the device will be available within Intune before it’s available within the Active Directory. That makes perfect sense as the domain join profile must come via Microsoft Intune.

WADP-HAADJ-CORP

Note: From an administrator perspective the Event Viewer, on the server running the connector, will show Event ID 30140 in the log ODJ Connector Service from the source ODJ Connector Service Source, with a successful creation of the computer object.

More information

For more information regarding Windows Autopilot and hybrid Azure AD join, please refer to the following articles:

Require an Internet connection during device setup

This week I’m going to look at a well hidden configuration option that is recently introduced and can be really useful in specific scenarios. That configuration option is to require an Internet connection during the device setup. Requiring an Internet connection during device setup can be useful when trying to prevent users from resetting the device (either accidently or on purpose) and configuring it without an Internet connection, as configuring a device without Internet connectivity would enable a user to configure the device with a local user and without enrollment. In this blog post, I’ll start with a short introduction about why this configuration option would be useful and what the options are with this configuration option. Followed by the configuration steps and the end-user experience.

Introduction

Configuring a device without Internet connectivity would enable a user to configure the device with a local user and without an enrollment to Microsoft Intune (and Azure AD). That’s often what organizations want to prevent, as it disconnects a device from the organization. Minor detail, this configuration option must be configured once. Of course it would be great if this configuration option could be a Windows default, or available via the Windows Autopilot configuration. However, to my understanding this is currently not possible due to legal requirements. At this moment it’s simply legally not allowed to require an Internet connection on a device during the initial setup. Having said that, as this setting is configured via the TenantLockdown CSP, I can imagine that, in a Windows Autopilot for existing devices scenario, this can be configured as a Windows default, via PowerShell, by using the WMI Bridge Provider.

Configuration

Before looking at the configuration, let’s start with a few important requirements and limitations:

  • The device must run Windows 10, version 1809 or later;
  • The device must be configured once before the setting is applicable;

Now let’s continue by looking at the required configuration. The following four steps walk through the steps to get create a new device configuration profile and the specific configuration option. That device configuration profile can be assigned to an Azure AD group.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, select Create profile to open the Create profile blade;
3a On the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the device configuration profile;
  • Description: (Optional) Provide a description for the device configuration profile;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Device restrictions;
  • Settings: See 3b;
3b On the Device restrictions blade, select General to open the General blade. On the General blade, select Require with Require users to connect to network during device setup and click OK to return to the Device restrictions blade. On the Device restrictions blade, click OK;
OOBE-Configure-Network

Note: This setting must be configured before it’s applicable. In other words, it’s not applicable during the initial out-of-box experience.

End-user experience

Let’s end this post by looking at the end-user experience. Once the configuration is in place and a reset is performed on the device, there will be an additional check during the device setup. When the device is not connected to the Internet, the end-user will receive a message as shown below. It requires the user to connect to the Internet. The user will not be able to continue without that connection. Once the user is connected to the Internet, the page below will show a Next button that can be used to continue with the device setup.

OOBE-Connect-Network

More information

For more information regarding the device configuration options and the TenantLockdown CSP, please refer to the following articles:

Windows Autopilot self-deploying mode

This week a new blog post about Windows Autopilot. More specifically, Windows Autopilot self-deploying mode. Autopilot self-deploying mode is really useful for devices that are function specific, like for example kiosk devices. The biggest benefit is that a device with a wired network connection (with Internet) can be completely configured without any user interaction. Simply connect the device to the wired network and power it on! Real zero touch provisioning! In this post I’ll provide the configuration steps to create that experience, followed by some known errors and the end-user experience.

Configuration

Let’s start with a few important requirements and limitations:

  • The device must run Windows 10, version 1809 or later;
  • The device can only be Azure AD joined (Active Directory join is not supported);
  • The device must be a physical device with TPM 2.0 (virtual machine is not supported);

Now let’s continue by looking at the available configuration options. In this case I’ll look at the different available configurations options and the related impact of those configuration options. The following four steps walk through the steps to get create a new Windows Autopilot self-deploying profile (including the available settings). That deployment profile can be assigned to an Azure AD group that contains devices.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade;
2 On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows Autopilot Deployment Program section to open the Windows Autopilot deployment profiles blade;
3 On Windows Autopilot deployment profiles blade, select Create profile to open the Create profile blade;
4a

WA-SD-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the Windows Autopilot deployment profile;
  • Description: (Optional) Provide a description for the Windows Autopilot deployment profile;
  • Convert all targeted devices to Autopilot: Select Yes to automatically convert Intune managed devices to Autopilot;
  • Deployment mode: Select Self-Deploying (preview), as that deployment mode provides the functionality that is needed for this post;
  • Join to Azure AD as: Azure AD joined is selected by default and grayed-out, as it’s the only configuration option supported for Windows Autopilot self-deploying devices;
  • Out-of-box experience (OOBE): See 4b.

Note: The Self-Deploying (preview) deployment mode, defines the available Azure AD settings and the available out-of-box experience (OOBE) settings.

4b

On the Out-of-box experience (OOBE) blade, provide the following information and click Save.

  • Language (Region): Select the Language that should be automatically configured during the Windows Autopilot self-deploying experience. This configuration will only be performed when the device is on a wired network connection (with Internet);
  • Automatically configure keyboard: Select Yes to automatically configure the keyboard based on the selected Language. This setting is only available when a Language is configured and this configuration will only be performed when the device is on a wired network connection (with Internet);
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot self-deploying experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot self-deploying experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot self-deploying experience;
  • User account type: Select Standard to only make any user on the device a standard user. With the exception of global administrators and company administrators;
  • Apply computer name template (Windows Insider Only): Create a computer name, according to the configured template, for devices at initial startup;
WA-SD-OOBE

Note: The Autopilot settings can only be downloaded when a network connection is in place. That’s the reason why a wired network connection should be in place. When a wired network connection is not available, it’s required to configure the region, the keyboard and a Wi-Fi.

Known errors

During the testing of Windows Autopilot self-deploying, I ran into multiple errors. More information about an error can always be found in the Event Viewer, at Application and Services Logs > Microsoft > Windows > Provisioning-Diagnostics-Provider > AutoPilot (thank you for the reminder Sandy!). The errors that I’ve seen on screen are documented and explained in the table below. If you’ve seen errors that are not on this list, let me know and I’ll add them.


Error Description
0x800705B4 This error means that the device is either a virtual machine, or does not have TPM 2.0, and is not capable of running Autopilot self-deploying.
0x801c03ea This error means that the device is TPM 2.0 capable, but that the TPM still needs to be upgraded from 1.2 to 2.0.
0xc1036501 This error means that the device cannot do an automatic MDM enrollment, because there are multiple MDM configurations in Azure AD.

End-user experience

As always, let’s end this post by having a look at the end-user experience. The end-user experience will provide a welcome message (see below) after receiving the Autopilot deployment profile and an automatic restart. An easy differentiation between the Autopilot user-driven experience and the Autopilot self-deploying experience, besides the interaction, is the logo that’s used. At this moment the Autopilot user-driven experience uses the square logo of the Azure AD company branding and the Autopilot self-deploying experience uses the banner logo of the Azure AD company branding.

20181104_165048

Note: From and administrator perspective, an Autopilot self-deploying device can be easily recognized by the Management name of the device. It contains a GUID instead of a username.

More information

For more information about enrolling Windows devices by using Windows Autopilot self-deploying mode, please refer to the documentation named Windows Autopilot Self-Deploying mode.

Join us at Experts Live Europe in Prague

b-B6v-rUA bit less than two weeks from now, October 25-26, Experts Live Europe will be in Prague. Together with my finest colleague, Arjan Vroege, I will deliver two sessions! And we hope to see you there!

Experts Live Europe is a Microsoft community conference with a focus on Microsoft cloud, datacenter and workplace management. During this conference, top experts from around the world present discussion panels, ask-the-experts sessions and breakout sessions and cover the latest products, technologies and solutions.

About our sessions

The maybe-not-that-sexy version of modern management – A true story –

In this session, we will take you into the real world of modern management. Modern management is a great buzzword and by now we all know the lovely story of modern management. We all know how it should work, but we often lack the real-world examples of organizations using modern management. During this session, we will show you how we internally deployed Windows 10 with Azure AD join and Intune management for over 10k devices. What choices did we make? Which challenges did we run into? Did we close all the gaps? We’ll try to answer these question. To conclude will also look at the available options right now and how they could have helped us. We will also have a couple of cool demos. To provide a sneak preview, here is a small list with subjects that will be part of our session: Win32 apps, MSIX and Windows AutoPilot.

Thursday Friday 2:40 PM – 3.40 PM

Create your ultimate hybrid workplace, what options do you have?

During this session we will take you into the world of the hybrid workplace. The modern workplace is a great story, for cloud only organizations, but the reality is often that there are a lot of components still on-premises. During this session we will touch the different delegate subjects from identity until apps and from management until connectivity. That means, a lot of ground to cover and a lot of choices to be made. Besides that we will have a couple of cool demos, here is a small list with a sneak preview of subjects that will be part of our session:  Pass-through authentication, Co-management, Win32 apps, MSIX and Azure AD Application Proxy.

Friday 8:00 AM – 9:00 AM

Make sure that you don’t miss these sessions!