Conditional access and ipadOS

Maybe a little overdue, but this week is all about ipadOS in combination with conditional access. At the end of September, Apple released ipadOS. A new platform for iPad. One of the ideas behind ipadOS is to provide “desktop-class browsing with Safari”. That desktop-class browsing is achieved by making sure that the Safari browser on ipadOS will present itself as a Safari browser on macOS. That change introduces a few challenges in combination with conditional access. I know that a lot has been written about this subject already, but looking at the amount of information on my blog about conditional access, and the number of questions I still receive about this subject, I just had to write about this subject. In this post I’ll describe the behavior of ipadOS with conditional access and the challenges that the behavior brings.

The behavior

The first thing is to identify the behavior. The best and easiest place to look for the behavior is the Safari browser itself. Open the Safari browser and browse to a location that is blocked via conditional access. Click on More details and the Device platform will show macOS as the platform (as shown on the top right).

Another method, from an administrator perspective, is by using the Monitoring > Sign-ins section of Azure Active Directory. That section logs the sign-in status. That information also includes device information of the device that is used for the sign-in. On the bottom right is an example of the information that is shown for devices that are running ipadOS and using the Safari browser. It will be recognized as a device running macOS and using the Safari browser.

So far I’ve only mentioned this behavior for the Safari browser on ipadOS. However, there is more. More components that are behaving in a similar way to provide a desktop-class experience. The complete list of affected components on ipadOS is the following:

  • the Safari browser
  • the Native mail app
  • anything that uses Safari View Controllers

Besides that it’s also good to mention that everything else is not affected by this adjustment. So, all Microsoft apps still work as expected, all other browser still work as expected and basically all other apps (with the Intune SDK integrated, or wrapped) still work as expected.

The challenges

Now let’s have a look at the challenges that this behavior brings. Those challenges can be categorized in two main categories, 1) managed apps and 2) differentiating between platforms. This first category contains a flow that actually breaks and the second category contains a flow that needs some more attention. Let’s discuss those challenges in a bit more detail.

Category 1: Managed apps

When looking at the first category, we can simply state that we’re limited in options when we want to require a managed app by either using the Require approved client app or the Require app protection policy control. At this moment these controls only work for Android and iOS. That means that we cannot (easily) force a user to use a managed app on ipadOS. Before we could provide a clear message to a user that a managed app must be used, when trying to connect to a cloud app with the Native mail app or the Safari browser.

This is the point were we have to get creative. It’s possible to look at a technical solution by blocking the Native mail app and the Safari browser when accessing the different cloud apps. However, keep in mind that those technical solutions might also impact macOS (see the second category).

At this moment there is no pretty method to force users away from the Safari browser and into using managed apps on ipadOS. Any solution will also impact macOS. Besides the fact that those solutions will also impact macOS, the end-user experience will also be bad. In this case the only option would be to block access from the Safari browser to the different cloud apps. Not pretty. Also, keep in mind what that would mean for the macOS users, as there are no alternatives for macOS users.

The Native mail app is a different story. There are options when already blocking basic authentication and Exchange Active Sync. In that case you’re relying on modern authentication and when you’re relying on modern authentication, for i(pad)OS devices, you’re relying on the iOS Accounts app in Azure AD. Revoking the user grants will remove the access for the user via the Native mail app (for some detailed steps have a look here). Keep in mind that the behavior will not be as pretty as before.

Category 2: Differentiating between platforms

When looking at the second category, we can (and have) to say that we need to be careful when using the Device platforms condition. There are many scenarios available in which an organization might want to differentiating between ipadOS and macOS. In any of those scenarios don’t forget the potential impact.

Both platforms will impact ipadOS. Anything configured for macOS will impact iOS when using the Native mail app or the Safari browser. Anything configured for iOS will impact all other iOS app.

More information

For more information about the impact of ipadOS with conditional access, please refer to this article Action Required: Evaluate and update Conditional Access policies in preparation for iPadOS launch.

Enable password-less sign-in with security keys

This week is all about enabling password-less sign-in with security keys on Windows 10. I know that a lot has been written about that subject already, but it’s that big that it still deserves a spot on my blog. Especially the Microsoft Intune configuration belongs on my blog. In this post I’ll show the required configurations that should be performed, by an administrator and the the user, to enable the user to use a security key as a sign-in method. My user will use a Yubikey 5 NFC security key. I’ll start this post with the authentication method policy that should be configured in Azure AD, followed by the steps for a user to register a security key. I’ll end this post by showing the different methods to configure security keys a sign-in method on Windows 10, by using Microsoft Intune, and the end-user experience.

Keep in mind that the best experience, for password-less sign-in with security keys, is on Windows 10 version 1903 or higher. This is caused by the fact that the PassportForWork CSP setting is introduced in Windows 10 version 1903.

Configure the authentication method

The first step in enabling password-less sign-in with security keys, is configuring the authentication method. Within Azure AD there is the Authentication method policy available, which is currently still in preview, that can be used to enable password-less authentication for users. Either all users, or a specific group of users. Within that policy it’s currently possible to enable FIDO2 security keys and Microsoft Authentication as password-less authentication options. The following three steps walk through the process of enabling FIDO2 security keys as a password-less authentication option for all users.

  1. Open the Azure portal and navigate to Azure Active Directory Authentication methods > Authentication method policy (preview) to open the Authentication methods – Authentication method policy (preview) blade
  2. On the Authentication methods – Authentication method policy (preview) blade, select FIDO2 Security Key to open the FIDO2 Security Key settings blade
  3. On the FIDO2 Security Key settings blade, provide the following information and click Save
  • ENABLE: Select Yes
  • TARGET: Select All users (use Select users to only enable for specific users)
  • Allow self-service set-up: Select Yes
  • Enforce attestation: Select Yes
The key restriction policy settings are not working yet and should be left default for now.

Register security key as sign-in method

The second step is that the user must register a security key that can be used as sign-in method. That does require that the user already registered an Azure MFA method. If not, the user should first register an Azure MFA method. After registering an Azure MFA method, the following nine steps will walk the user through the process of adding an USB security key.

  1. Open the My Profile and navigate to Security info to open the Security info section
  2. On the Security info section, click Add method to open a dialog box
  3. On the Add method page, select Security key and click Add
  4. On the Security key page, select USB device and click Next
  5. A browser session will open to register the security key
  6. Insert the security key, touch it, provide a PIN and click Next
  7. Touch the security key another time and click Allow
  8. Provide a name for the security key and click Next
  9. On the Your all set page, click Done

After registering a security key as a sign-in method, the user can already use the security key as a sign-in method for browser sessions.

Configure security keys as a sign-in option

The third and last step is to configure security keys as a sign-in option on Windows devices. Within Microsoft Intune there are multiple methods for enabling security keys as a sign-in option on Windows 10 devices. It’s also good to keep in mind that, even though password-less sign-in is supported starting with Windows 10, version 1809, the following configuration options are all for Windows 10, version 1903 or later. The reason for that is actually quite simple, as the required setting (UseSecurityKeyForSignin) is introduced in the PassportForWork CSP with Windows 10, version 1903.

Using Windows enrollment (Windows Hello for Business) settings

The first configuration option is by using the Windows Hello for Business settings that are available within the Windows enrollment settings. Those settings actually enable the administrator to configure the use of security keys for sign-in independent of actually configuring Windows Hello for Business. The biggest challenge with this approach is that it can’t be slowly implemented, as it’s all or nothing. The following two steps walk through this configuration.

  1. Open the Azure portal and navigate to Microsoft Intune Device enrollmentWindows enrollment > Windows Hello for Business to open the Windows Hello for Business blade
  2. On the Windows Hello for Business blade, select Enabled with Use security keys for sign-in and click Save

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business.

Using Device configuration (Identity protection) settings

The second configuration option is by using the Identity protection device configuration profile. The Identity protection device configuration profile, provides the same configuration options as the Windows Hello for Business settings. The biggest difference is that the Identity protection device configuration profile can be implemented by using groups, which allows a phased implementation (and differentiation). The following four steps walk through this configuration.

  1. Open the Azure portal and navigate to Microsoft Intune Device configuration Profiles to open the Devices configuration – Profiles blade
  2. On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade
  3. On the Create profile blade, provide the following information and click Create
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Identity protection
  • Settings: See step 4
  1. On the Windows Hello for Business blade, select Enable with Use security keys for sign-in and click OK;

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business

Use Device configuration (Custom) settings

The third and last option is by using a Custom device configuration profile. That Custom device configuration profile, is actually identical to the Identity protection device configuration profile. The only difference is that it’s a OMA-URI configuration, so no simple UI switch. Even though it’s good to mention this option, to remember what the actual configuration is that’s done on the background. The following four steps walk through this configuration.

  1. Open the Azure portal and navigate to Microsoft Intune Device configuration Profiles to open the Devices configuration – Profiles blade
  2. On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;
  3. On the Create profile blade, provide the following information and click Create;
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Windows 10 and later
  • Profile type: Identity protection
  • Settings: See step 4
  1. On the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/SecurityKey/UseSecurityKeyForSignin
  • Data type: Select Integer;
  • Value: 1

This setting requires Windows 10, version 1903, or later, and is not dependent on configuring Windows Hello for Business

End-user experience

Let’s end this post by having a look at the end-user experience. Below on the first row it starts with a static example of the sign-in experience on Windows 10 and in a browser. The second row is an example of the password-less sign-in experience of an user on Windows 10, version 1903, using a Yubikey 5 NFC security key. I’m specifically showing the experience when using the Other user sign-in option, as it will show that the user doesn’t need to provide a username nor a password. The user only needs to have the security key and the related PIN.

More information

For more information about password-less sign-in on Windows 10, see this doc named Enable passwordless security key sign in for Azure AD (preview).

Another new discovery method: Meet the Azure Active Directory Group Discovery!

This week is back to the world of Configuration Manager. With the release of Configuration Manager, version 1906, a lot of new features are introduced. Even a few very nice pre-release features. One of these pre-release features is the subject of this post, the Azure Active Directory Group Discovery. The Azure Active Directory Group Discovery can be used to discover user groups and members of those groups from Azure AD. In case there are users found in Azure AD user groups that haven’t been previously discovered, those users will be added as user resources in Configuration Manager. A user group resource record is created when the group is a security group. In this post I’ll briefly show the prerequisites, followed by the configuration steps. I’ll end this post by showing the administrator experience.

Prerequisites

Let’s start with the prerequisites that should be in place to configure the Azure Active Directory Group Discovery. The following 2 prerequisites should be configured.

1 Enable pre-release feature: The pre-release feature must be enabled. That can be achieved by simply doing the following: Open the Configuration Manager administration console and navigate to Administration > Overview > Updates and Servicing > Features. Select Azure Active Directory user group discovery and click Turn on in the Home tab;
CM-AADUGD-Prerelease
2 Enable cloud management: The cloud management Azure service must be added. That can be achieved by doing the following: Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services. Click Configure Azure Services in the Home tab and follow the documented instructions here;

Configuration

When the prerequisites are in place it’s time to look at the actual configuration steps. The following 7 steps walk through the required configuration steps for enabling Azure Active Directory Group Discovery.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services;
2 Select the Cloud Management Azure service and click Properties in the Home tab, to open the Cloud Management Properties dialog box;
CM-AADUGD-Properties
3

CM-AADUGD-CMPropertiesOn the Cloud Management Properties dialog box, select the Discovery tab, select Enable Azure Active Directory Group Discovery and click Settings to open the Azure AD Group Discovery Settings dialog box.

Note: The Settings button will be disabled when Enable Azure Active Directory Group Discovery is not selected.

4

CM-AADUGD-AADGDSOn the Azure AD Group Discovery Settings dialog box, select the Discovery Scopes tab and click Add to open the Select Azure Active Directory Objects dialog box.

Note: Once an Azure AD group is added, it will be shown in the overview of this dialog box.

5

CM-AADUGD-SAADOOn the Select Azure Active Directory Objects dialog box, (optionally add a name in the Name starts with text box) click Search to find the specific Azure AD group(s), select the Azure AD group and click OK.

Important: The search results will show cloud only Azure AD groups for both users and devices. Also, credentials will be requested when searching for Azure AD groups for the first time.

Note: Repeat this step for all applicable Azure AD groups.

6

CM-AADUGD-CMPropertiesPSBack on the Azure AD Group Discovery Settings dialog box, select the Poling Schedule tab. Use this tab to make adjustments to the discovery schedule.

Note: At this moment delta discovery is disabled.

7 Back on the Cloud Management Properties dialog box, click OK.

Note: Keep in mind that this is currently still a preview features.

Administrator experience

Now let’s end this post with the most interesting part, the administrator experience. From an administrative perspective, this configuration introduces at least the following new items.

1 Discovery method: One of the most interesting items is the new Azure Active Directory Group Discovery itself. After the configuration is finished the discovery method can be found by navigating to Administration > Overview > Cloud Services > Azure Services. Selecting the cloud management Azure service, and selecting the Azure Active Directory Group Discovery Agent Type, provides the option Run Full Discovery Now.
CM-AADUGD-Overview
2 Log file: One of the most important items is the log file SMS_AZUREAD_DISCOVERY_AGENT.log. This log files provides the information about the full and delta discoveries of the Azure Active Directory User Discovery and about the full discoveries of the Azure Active Directory Group Discovery (as shown below). The nice part is that the log file also provides information about the Microsoft Graph requests that it uses for the different discoveries.
CM-AADUGD-Log
3 CM-AADUGD-GroupPropCloud-only user groups: The most useful item is the availability of the cloud-only user groups in the on-premises environment. These user groups can be recognized by only having the Agent Name of SMS_AZUREAD_USER_GROUP_DISCOVERY_AGENT (as shown on the right). The availability of the cloud-only user groups in the Configuration Manager environment, and the availability of the new attributes for existing user groups, enables a whole lot of new scenarios. Most of these scenarios are related to co-managing Windows 10 devices with Configuration Manager and Microsoft Intune.
4 Group properties: The overall most interesting, most important and most useful item is the information in the database. The main user group tables and views now contain additional fields for cloud-related information. Some nice information can be found below, were I used a simple query to get some basic information about user groups. That information shows a few important differences with normal user groups. The group contains Azure AD information.
CM-AADUGD-SQL

More information

For more information about the Azure Active Directory Group Discovery, please refer to the Configure Azure Active Directory user group discovery section in the documentation about configuring discovery methods for Configuration Manager

Windows Autopilot white glove service

This week is about Windows Autopilot. More specifically, the Windows Autopilot white glove service. The Windows Autopilot white glove service will enable organizations to pre-provision Windows 10 devices to make sure that end-users get their device faster to a fully provisioned state. In this post I’ll start with a short introduction about the Windows Autopilot white glove service, followed by the steps to enable the white glove service in Windows Autopilot. I’ll end this post by showing the end-user experience.

Introduction

Now let’s start with a short introduction about the Windows Autopilot white glove service (also known as Windows Autopilot for white glove deployment). This process is designed to get the user faster up-and-running. That is achieved by splitting the provisioning process (as shown below). The starting point of the Windows Autopilot for white glove deployment is the same as any other Windows Autopilot deployment, it starts with a device that is provided by the OEM (imaged and accommodated with drivers). The second step is what makes this the Windows Autopilot for white glove deployment, it enables an organization to pre-provision device apps, device settings, device policies and user apps (of the assigned user) on the device. This can be achieved by an OEM, partner or the IT organization itself. That also enables the faster user experience, as, once the user logs on, only user settings and user policies are still required.

WhiteGlove-Process

Before looking at the configuration, let’s go through a few important requirements and limitations of the Windows Autopilot for white glove deployment:

  • The device must run Windows 10, version 1903 or later;
  • Only user-driven scenarios, supporting both, Azure AD join and hybrid Azure AD join;
  • Must be a physical devices that support TPM 2.0 and device attestation (virtual machines are not supported);
  • The device must have a ethernet connectivity (Wi-Fi connectivity is not supported).

Configuration

Let’s continue by looking at the actual configuration. As the configuration of a Windows Autopilot deployment profile now contains a new look-and-feel, I thought it would be good to show screenshots of that new experience. The following 4 steps walk through the creation of a Windows Autopilot deployment profile that allows white glove.

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

On the Create profile blade, on the Basics section, provide the following information and click Next;

  • 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;

WA-WG-CreateProfile-Basics

4b

On the Create profile blade, on the Out-of-box experience (OOBE) section, provide the following information and click Next.

  • Deployment mode: Select User-Driven, as that deployment mode provides the functionality that is
    needed for this post;

  • Join to Azure AD as: Select Azure AD joined to join the device to Azure AD during the Windows Autopilot user-driven experience;
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot user-driven experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot user-driven experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot user-driven experience;
  • User account type: Select Administrator to only make any user on the device an administrative user;
  • Allow White Glove OOBE: Select Yes, as that enables the functionality that is needed for this post;
  • Apply computer name template: Create a computer name, according to the configured template, for devices at initial startup;
WA-WG-CreateProfile-OOBE
4c On the Create profile blade, on the Scope tags section, click Next;
WA-WG-CreateProfile-Scope
4d On the Create profile blade, on the Assignments section, add an assignment and click Next;
WA-WG-CreateProfile-Assignment
4e On the Create profile blade, on the Review + create section, click Create;
WA-WG-CreateProfile-Review

Administrator experience

Now let’s end this post by having a look at the administrator experience. More specifically the experience of the IT person performing the Windows Autopilot white glove deployment. Below on the first row is are the screens that the administrator has to go through, after pressing the Windows key 5 times on the initial OOBE screen. First the administrator has to select the Windows Autopilot provisioning option and click Continue, followed by confirming the device information and clicking Provision. The QR-code contains the identifier of the device and can be used to make some configuration changes.

After starting the process, it will either fail or succeed. Like with everything else. The reason I specifically mention it, is because the result is clearly shown by the background color. Below on the second row, are screenshots of a failed and succeeded Windows Autopilot white glove deployment. To make creating screenshots easy, I simulated both scenarios on a VM (see the error on the red screenshot and the no found messages in the green screenshot). Simulated, because a VM is not supported and will not work. On a physical device those screenshots will also provide a QR-code. As shown below, after a failure the administrator can choose to Retry, Reset and View diagnostics and after a success the administrator can Reseal the device. Resealing the device will make sure that the end-user will receive the expected OOBE.

WA-WG-01 WA-WG-02
WA-WG-Error WA-WG-Success

More information

For more information about enrolling Windows devices by using the Windows Autopilot white glove service, please refer to the documentation named Windows Autopilot for white glove deployment.

Join us at Experts Live Netherlands in Den Bosch

EXPERTSLIVE.6015_email-signature_spreker_ENG_200x200A bit less than a week from now, June 6, Experts Live Netherlands will be in Den Bosch. Experts Live Netherlands is one of the biggest Microsoft community events, with over 1200 visitors. I’m proud to be part of the speaker lineup again. Together with my finest colleague, Arjan Vroege, I will deliver a session about moving to a modern managed workplace at your own pace! And we hope to see you there!

About our session

During our session we will discus (and show) how to migrate to a modern managed workplace at your own pace. As many organizations want to make the switch to a modern managed workplace, but are currently unable to make the complete switch. Often this is related to missing specific management features, like limited control over updates and missing rich app deployment features. The good news is that it’s not required to directly make the complete switch. This can be achieved in steps, by using Configuration Manager and Microsoft Intune. In this session we will present and show you how to use these tools in combination with Windows 10 to make a smooth transition.

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:

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