Using sensitivity labels to manage access to SharePoint sites on unmanaged devices

This week is a follow-up on my post of a few weeks ago about accessing SharePoint and OneDrive content on unmanaged devices. That post showed how to use the SharePoint admin center to manage the organiztion-wide access control for unmanaged devices and showed how to use PowerShell to manage the site-level access control for unmanaged devices. This post will show something similar to that PowerShell configuration, in a way that this will also provide a method for managing access for unmanaged devices on a site-level. The main difference is that this post will look at a new (currently in public preview) feature that is added to sensitivity labels. That feature enables the administrator to configure Site and group settings for sensitivity labels. Within that configuration the administrator can define the level of access for unmanaged devices when a sensitivity label is applied to a SharePoint site. In this post I’l start with a short introduction about that functionality, followed by the configuration steps. Those configuration steps contain the steps for configuring the sensitivity labels, the steps for applying the sensitivity labels to a SharePoint site and the steps for configuring a basic conditional access policy to provide the device management information to SharePoint Online. I’ll end this post by showing the end-user experience.

Important: This information shown in this blog post relies – at the moment of writing – on preview functionality for sensitivity labels that must be specifically enabled. Without specifically enabling this preview functionality, the mentioned Site and group settings will not be available for sensitivity labels.

Site and group settings for sensitivity labels

Before looking at the configuration options, it’s good to first have a quick look at the new feature of sensitivity labels. By enabling the preview functionality, the administrator receives an additional configuration step when creating (and editing) sensitivity labels, named Site and group settings. The main focus for this post is the configuration section for unmanaged devices in the Site and group settings. That configuration section enables the administrator to provide the user with the option to configure access for unmanaged devices per site by using sensitivity labels. The administrator determines the configuration of the sensitivity labels based on the company policies and the user applies the sensitivity label to SharePoint sites based on the company policies.

When applying a sensitivity label to a SharePoint site, only the settings of the Site and group settings apply to the site. Other settings, such as encryption and content marking, aren’t applied to the content within the SharePoint site. The content within the SharePoint site is also not automatically labeled with the sensitivity label that’s applied to the site. It’s currently still required to use the existing manual and automatic options for applying sensitivity labels to content. The the priority of sensitivity labels is also really important for this

Note: I’m constantly specifically mentioning access of unmanaged devices to SharePoint sites as the focus of this post. However, as the mentioned configuration also enables the user to apply these sensitivity labels to Teams sites, the same behavior for unmanaged devices also applies to the related SharePoint sites.

Configuring the sensitivity labels

The configuration of sensitivity labels, for applying the behavior for unmanaged devices to a SharePoint site, contains an administrator configuration for the sensitivity labels and a user configuration for applying the sensitivity label to new (and existing) SharePoint sites. If needed an administrator can also adjust the applied sensitivity label.

Configuring the site and group settings for sensitivity labels

Let’s start by looking at the steps for an administrator of creating a sensitivity label and configuring the Site and group settings. The eight steps below walk through the creation of a new sensitivity label. Most steps simply describe the usage of the configuration step, as the focus is on the Site and group settings (step 6). After creating the sensitivity label, it can be published like any other sensitivity label by using a Label policy. Keep in mind that after creating and publishing the sensitivity label, it can take up to 24 hours for the sensitivity label to become available for users in the creation and adjustments of SharePoint sites. 

  1. Open the Microsoft 365 compliance center and navigate to Solutions > Information protection (or use the Microsoft 365 security center, or the Security & Compliance center) to open the Information protection page.
  2. On the Information protection page, click Create a label to open the New sensitivity label wizard.
  3. On the Name & description page, configure a name and tooltip for the sensitivity label and click Next.
  4. On the Encryption page, configure the encryption to control who can access the content that have this sensitivity label applied and click Next.
  5. On the Content marking page, configure any custom headers, footers, and watermarks that should be added to content that have this sensitivity label applied and click Next.
  6. On the Site and groups settings page, configure the settings that should take effect when this sensitivity label is applied to SharePoint site (or Office group) and click Next. Specifically looking at the scope of this post, it’s all about the Unmanaged devices section. That section enables the administrator to control the level of access for unmanaged devices when this sensitivity label is applied to a SharePoint site. Similar to the unmanaged devices access control in the SharePoint admin center, the administrator can choose between full access, limited access and block access.
  7. On the Auto-labeling for Office apps page, configure the automatic labeling behavior for Office apps when sensitive content is detected and click Next.
  8. On the Review your settings page, verify the configuration and click Submit.

Note: Keep in mind that the organization-wide configuration for unmanaged devices, in the SharePoint admin center, should be set to the least restrictive configuration to have a configuration that works as expected. If not, and a sensitivity label should apply a less restrictive experience, the organization-wide configuration will overrule the applied configuration of the sensitivity label.

Using the sensitivity labels for SharePoint sites

Once the administrator configured the sensitivity labels, the user can apply the different sensitivity labels to the different SharePoint sites. That can be achieved by the user during the creation of new SharePoint sites or by editing the Site information of existing SharePoint sites. The following three to four steps walk through the process of creating a new SharePoint site and applying a sensitivity label to it.

  1. Open SharePoint and click Create site to open the Create site page.
  2. On the Create site page, choose between a Team site and a Communication site. A sensitivity label can be applied to both type of SharePoint sites.
  3. No matter what the type of SharePoint site, provide a name for the site to enable the remaining settings of a new SharePoint site. Those settings include an Advanced settings section. That section contains the sensitivity labels that the user can choose from. By clicking on the help icon, the user can view the tooltip information of the different sensitivity labels. Now choose the applicable sensitivity label and click Next to continue to the Add group members page (or click Finish for Communication sites).
  4. (Only for Team sites) On the Add group members page, add any additional administrators and click Finish.

Note: For existing SharePoint sites the user can select the SharePoint site and click Site information to edit the sensitivity label by selecting a different sensitivity label in the Sensitivity selection box.

Configuring conditional access policy

The conditional access policy configuration is required to make sure that Azure AD will pass the device management information on to SharePoint Online. That can be achieved by using the Use app enforced restrictions session control. That in combination with the configuration of the sensitivity labels can provide the organization with the required level of access control on unmanaged devices. For this post the focus is on the Use app enforced restrictions session control. That session control can be configured by following the next seven steps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Security > 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. On the New blade and provide a unique name
  4. Select Users and groups to configure the assigned users of this conditional access policy
  5. Select Cloud apps or user actions and select Office 365 SharePoint Online as the assigned app of this conditional access policy
  6. Select Conditions > Client apps and select Browser as the applicable client app of this conditional access policy
  7. Select Session and select Use app enforced restrictions to make sure that the configured limited experience will be applicable to this session

Note: This configuration can also be used in a conditional access policy that uses a grant controls to make sure that for example MFA is also always required for access to SharePoint Online for unmanaged devices. 

The sensitivity label experience

Let’s end this post by having a look at the end-user experience and little bit of administrator experience. For testing the experience, I’ve created the following four different sensitivity labels (with the mentioned behavior for unmanaged devices) for the users in my environment:

  • Public – This sensitivity label allows full access for unmanaged devices.
  • Internal – This sensitivity label allows limited access for unmanaged devices.
  • Confidential – This sensitivity label also allows limited access for unmanaged devices.
  • Secret – This sensitivity label blocks access for unmanaged devices.

When a user now navigates on an unmanaged device to a SharePoint site with a sensitivity label of Internal (or Confidential), the user will receive a limited experience as shown below in Figure 3. The user will be notified about the limited experience and the user will see the applied sensitivity label. When a user now navigates on an unmanaged device to a SharePoint site with a sensitivity label of Secret, the user will receive a blocked experience as shown below in Figure 4. As the sensitivity label of Public simply provides a full experience, I’m not showing that example.

When quickly looking from an administrator perspective in the SharePoint admin center, the administrator can now see an additional column for the active sites that contains the applied sensitivity label (as shown in Figure 5). By selecting a site and navigating to the policies section, the administrator can also adjust the applied sensitivity label.

More information

For more information about managing access to SharePoint sites with sensitivity labels, refer to the article about using sensitivity labels to protect content in Microsoft Teams, Microsoft 365 groups, and SharePoint sites (public preview).

Configuring the OneDrive sync app basics for Windows devices

This week is all about configuring the OneDrive sync app basics for Windows devices. The main component for accessing OneDrive for Business content on Windows devices, is the OneDrive sync app. By default the OneDrive sync app is available on Windows devices and installed per user. In this post I’ll have a look at the installation of the OneDrive sync app and the basic configuration that I think that should be applied to get the best user experience. All by using Microsoft Intune for managing the Windows devices. I’ll end this post by having a quick look at the configuration on the Windows device.

OneDrive sync app installation

The first thing that should be addressed is the installation of the OneDrive sync app. By default, the OneDrive sync app is available on Windows devices and installs per user. That means that the OneDrive sync app will be installed in the %localappdata% directory, for each user that signs in on the Windows device. That’s not always the most optimal method for addressing the OneDrive sync app installation, as it also often means that during the initial sign in of the user, an update of the OneDrive sync app will be downloaded and installed. To address that, especially on shared and multi-user devices, I like to install the OneDrive sync app with the per-machine installation option. That effectively means that the OneDrive sync app will be installed in the %Program Files% directory (keep in mind that it’s a 32-bit app) and that will make sure that all profiles on the Windows device will use the same OneDrive binaries. Besides the installation location, the behavior of OneDrive is similar.

To make sure that the OneDrive sync app is up-to-date during the initial sign in of to user – to make sure that the different available policies will apply immediately an that conditional access will work – the OneDrive sync app should be up-to-date after provisioning the device. Ideally during the Out-of-the-Box experience (OOBE), with or without using Windows Autopilot. That can be achieved by using a simple PowerShell script, of which an example is shown below.

#Download OneDrive per-machine installer
$downloadLocation = "https://go.microsoft.com/fwlink/?linkid=844652"
$downloadDestination = "$($env:TEMP)\OneDriveSetup.exe"
$webClient = New-Object System.Net.WebClient
$webClient.DownloadFile($downloadLocation, $downloadDestination)

#Run OneDrive per-machine installer
$installProcess = Start-Process $downloadDestination -ArgumentList "/allusers" -WindowStyle Hidden -PassThru
$installProcess.WaitForExit()

That script will download the latest version of OneDriveSetup.exe and will install it with the per-machine installation option. To make sure that it will be installed during the OOBE, wrap it as a Win32 app. As a detection method simply use the installation directory (as the directory will change) of the OneDrive sync app. The reason to go for a Win32 app is simple: a Win32 app will be installed and tracked during the Enrollment Status Page (ESP) and that will make sure that the OneDrive sync app is up-to-date before the user signs in to the Windows device.

Note: For further tuning the initial sign in of the user, have a look at this section of a post by Ben Whitmore.

OneDrive sync app basic configurations

The second thing that should be addressed is the configuration of the OneDrive sync app. The idea of configuring the OneDrive sync app on the Windows device, is to make sure that the user can be productive as fast as possible without any user interaction. The following settings are my preferred configurations that should be performed to achieve that goal. The list also contains some settings to limit potential data loss, which might not apply to all organizations. All of these settings are now available as a part of the Administrative Templates that are available in Microsoft Intune. As these settings are configured via Administrative Templates, the configurations are eventually done by using registry key values (device settings at HKLM\SOFTWARE\Policies\Microsoft\OneDrive and user settings at HCU\SOFTWARE\Policies\Microsoft\OneDrive). To configure Administrative Templates, simply open the Microsoft Endpoint Manager admin center portal, navigate to Device > Configuration profiles and create a new profile.

Silently sign in users to the OneDrive sync client with their Windows credentials – This setting is a must for every organization, as it’s used, on (hybrid) Azure AD joined devices, to set up the OneDrive sync app for the user that signs in on the Windows device.

When using the following configuration, the OneDrive sync app will be automatically (and silently) set up for the user that signs in on the Windows device, without the need for the user to provide credentials. That configuration will set the registry key value SilentAccountConfig to 1.

  • Setting type: Device
  • Setting value: Enabled

Silently move Windows known folders to OneDrive – This setting is strongly advised for every organization, as it’s used to set up the redirection of the known folders (Documents, Pictures, and Desktop) of the user to OneDrive.

When using the following configuration, the known folders will automatically (and silently) redirected to OneDrive without user interaction. Besides that, the user receives a notification after the folders have been successfully redirected. That configuration will set the registry key value KFMSilentOptIn to {{yourTenantId}} and KFMSilentOptInWithNotification to 1.

  • Setting type: Device
  • Setting value: Enabled
  • Tenant ID: {{yourTenantId}}
  • Show notification to users after folders have been redirected: Yes

Prevent users from redirecting their Windows known folders to their PC – This setting is strongly advised for every organization (especially in combination with the previous setting), as it’s used to prevent the user from redirecting the known folders (Documents, Pictures, and Desktop) back to the Windows device.

When using the following configuration, the user is prevented from redirecting the known folders back to the Windows device. It forces users to keep their known folders redirected to OneDrive. That configuration will set the registry key value KFMBlockOptOut to 1.

  • Setting type: Device
  • Setting value: Enabled

Use OneDrive Files On-Demand – This setting is strongly advised for every organization, as it’s used to configure OneDrive Files On-Demand. Files On-Demand will help organizations with saving storage space on the Windows device and minimizes the network impact of the OneDrive sync.

When using the following configuration, Files On-Demand is automatically configured for the user. The user will see online-only files in File Explorer, by default, and de file contents don’t download until a file is opened. That configuration will set the registry key value FilesOnDemandEnabled to 1.

  • Setting type: Device
  • Setting value: Enabled

Set the sync client update ring – This setting is strongly advised for every organization, as it’s used to configure the update ring for the OneDrive sync app. It enables the administrator to choose one of the following update rings.

  • Enterprise: In this ring the user gets new features, bug fixes, and performance improvements last.
  • Production: In this ring the user gets the latest features as they become available. This is the default.
  • Insider: In this ring the user receives builds that let them preview new features coming to OneDrive.

When using the following configuration, the update ring will be configured to the production ring and the OneDrive sync app will get the latest features as they come available. That configuration will set the registry key value GPOSetUpdateRing to 5 (Insider=4, Enterprise=0)

  • Setting type: Device
  • Setting value: Enabled
  • Update ring: Production

Allow syncing OneDrive accounts for only specific organizations – This setting is advised for organizations in specific scenarios, as it’s used to prevent the user from uploading files to other organizations by whitelisting allowed organizations.

When using the following configuration, the user will be prevented from adding an account of a different organization. The user receives an error if they attempt to add an account from an organization that is not whitelisted. When a user is already syncing files from another organization, the files stop syncing. That configuration will set the registry key AllowTenantList with a value of {{yourTenantId}} to {{yourTenantId}}.

  • Setting type: Device
  • Setting value: Enabled
  • Tenant ID: {{yourTenantId}}

Prevent users from syncing personal OneDrive accounts – This setting is advised for organizations in specific scenarios, as it’s used to prevent the user from uploading files to their personal OneDrive account.

When using the following configuration, the user will be prevented from adding a personal OneDrive account. When the user is already syncing files from a personal OneDrive, the files stop syncing. That configuration will set the registry key value of DisablePersonalSync to 1.

  • Setting type: User
  • Setting value: Enabled

End-user experience

Now let’s end this post by having a quick look at the end-user experience after applying these configurations. Let’s start by having a look a the last two settings that can be used to prevent easily “losing” data to personal and other organizational accounts. When the user will try to add a personal account, the user will be provided with a message as shown in Figure 8 (below on the left). When the user will try to add another work account, the user will be provided with a message as shown in Figure 9 (below on the right).

The experience of the other more common OneDrive sync app configurations is shown below in Figure 10. OneDrive is automatically configured (see number 1), the known folders are automatically moved to OneDrive (see number 2), the files are on-demand available (see also number 2) and the user is notified about the successful configurations (see number 3).

From an administrator perspective there are also some interesting registry and file locations to look at. To see that the per-machine installation worked as expected, a OneDrive folder should exist in the %ProgramFiles% directory (keep in mind that it’s a 32-bit app). And to see that the device configurations are applied, the corresponding registry keys should be available in HKLM\SOFTWARE\Policies\Microsoft\OneDrive. The user configurations should be available in HCU\SOFTWARE\Policies\Microsoft\OneDrive.

More information

For more information about configuring OneDrive for Business for Windows devices, refer to the following docs:

Accessing SharePoint and OneDrive content on unmanaged devices

This week is all about accessing SharePoint sites and OneDrive accounts on unmanaged devices. More specifically, limiting access to SharePoint and OneDrive content on unmanaged devices. Configuring (limited) access to SharePoint sites and OneDrive accounts starts by using conditional access. For applying conditional access to SharePoint sites and OneDrive accounts, the Office 365 SharePoint Online cloud app, or the recently introduced Office 365 (preview) cloud app can be used. The first cloud app is applicable to all services that depend on SharePoint Online (including OneDrive and Teams). The second cloud app is applicable to all productivity and collaboration services of Office 365. An all-in-one app. However, both of these cloud apps don’t provide really granularity to only apply specific behavior for accessing specific SharePoint sites, or OneDrive accounts. In this post I’ll focus on the Use app enforced restrictions session control and the options that it provides for differentiating between SharePoint sites and OneDrive accounts. About three years ago, I did a post on the basic configurations options of that sessions control.

The Use app enforced restrictions session control can be used to require Azure AD to pass device information to the SharePoint Online. That enables SharePoint Online to know whether the connection was initiated from a managed device. In this case a managed device is an Intune managed and compliant device, or a hybrid Azure AD joined device. SharePoint Online can use that information to provide a limited experience to unmanaged devices. Adjusting the experience can be achieved by using the Unmanaged devices access control in SharePoint Online. In this post I’ll have a look at the standard and advanced configuration options of that access control (including a brief look at the future). I’ll end by having a look at the end-user experience.

SharePoint unmanaged devices standard configuration

The Unmanaged devices access control in SharePoint Online can be used to provide full or limited access on unmanaged devices. It’s even possible to completely block access on unmanaged devices. Limiting the access on unmanaged devices allows the end-user to remain productive while minimizing the risk of accidental data loss. With limited access, users, on unmanaged devices, will have browser-only access with no ability to download, print, or sync files. It won’t be possible to access content through apps, including the Microsoft Office desktop apps. This does require the use of modern authentication. An additional reason to block legacy authentication.

The Unmanaged devices access control standard configuration is available via the SharePoint admin center. This access control can be configured for the complete organization by following the next two steps.

  1. Open the SharePoint admin center and navigate to Policies > Access control > Unmanaged devices
  2. On the Unmanaged devices blade, select the experience for the end-user on unmanaged device by choosing between full access, limited access and block access.

When configuring the Unmanaged devices access control with a limited or blocked experience, by following the mentioned steps, the Apps that don’t use modern authentication access control will automatically change to blocked. The main reason for that is that those apps can’t enforce a limited or blocked experience. Also, these configuration will automatically create corresponding conditional access policies.

SharePoint unmanaged devices advanced configuration

The advanced configuration options of the Unmanaged devices access control in SharePoint Online are only available via PowerShell. The standard configuration via the SharePoint admin center can only configure the access control organization-wide, while PowerShell enables the administrator to configure the access control on site-level. That includes OneDrive accounts. That enables the administrator to configure a limited or blocked experience for specific SharePoint sites and OneDrive accounts. That can be achieved by using the Set-SPOTenant cmdlet for organization-wide configurations, or by using Set-SPOSite cmdlet for site-level configurations. Those cmdlets contain the ConditionalAccessPolicy parameter that can be used to configure the Unmanaged devices access control. That parameter can be used with one of the following values:

  • AllowFullAccess – This value will make sure that the configuration of Allow full access from desktop apps, mobile apps, and the web is applied to the tenant or site. This is the default configuration and allows full access for unmanaged devices.
  • AllowLimitedAccess – This value will make sure that the configuration of Allow limited, web-only access is applied to the tenant or site. This is the limiting configuration that will only allow web access and doesn’t allow the user to print, download or synchronize for unmanaged devices.
  • BlockAccess – This value will make sure that the configuration of Block access is applied to the tenant or site. This will completely block access for unmanaged devices.
  • ProtectionLevel – This value is a preview feature that can be used for configuring authentication tags.

For configuring the Unmanaged devices access control for specific SharePoint sites or OneDrive accounts, the Set-SPOSite cmdlet can be used in combination with the ConditionalAccessPolicy parameter and the Identity parameter. The latter parameter is used for specifying the specific SharePoint site or OneDrive account. An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess

When using the ConditionalAccessPolicy parameter, it enables the administrator to apply even more restrictions. It enables the administrator to combine the limited access with also removing the ability to edit files and the ability to copy and paste from files. That can be achieved by using the AllowEditing parameter with the value $false (default is $true). An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess -AllowEditing $false

Besides limiting the editing abilities for the user, it’s also possible to further limit the preview functionality. That can be achieved by using the LimitedAccessFileType parameter. That parameter can be used with one of the following values:

  • OfficeOnlineFilesOnly – This value will make sure that users can only preview Office files in the browser. This limiting configuration increases security on unmanaged devices, but may decrease user productivity.
  • WebPreviewableFiles – This value value will make sure that users can preview Office files and other file types (such as PDF files and images) in the browser. This is the default configuration and is optimized for user productivity on unmanaged devices, but offers less security for files that aren’t Office files. 
  • OtherFiles – This value will make sure that users can download files that can’t be previewed (such as .zip and .exe) in the browser. This option offers less security on unmanaged devices.

The LimitedAccessFileType parameter enables the administrator to limit the preview functionality, by using one of the three mentioned values. An example is shown below.

Set-SPOSite -Identity <SpecificSiteOrOneDriveAccount> -ConditionalAccessPolicy AllowLimitedAccess -AllowEditing $false -LimitedAccessFileType WebPreviewableFiles

Note: Keep in mind that the site-level configuration will only work as expected when it’s more restrictive than the organization-wide configuration.

Conditional access configuration

The conditional access configuration is required to make sure that Azure AD will pass the device information to the SharePoint Online. That can be achieved by using the Use app enforced restrictions session control. This configuration can be used next to other conditional access policy that use grant controls to make sure that for example MFA is also always required for access to SharePoint Online or OneDrive for Business on unmanaged devices. That in combination with the limited configuration can provide the organization with the required level of access control on unmanaged devices. For this post the focus is on the Use app enforced restrictions session control. That session control can be configured by following the next seven steps.

  1. Open the Microsoft Endpoint Manager admin center portal and navigate to Security > 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. On the New blade and provide a unique name
  4. Select Users and groups to configure the assigned users of this conditional access policy
  5. Select Cloud apps or user actions and select Office 365 SharePoint Online as the assigned app of this conditional access policy
  6. Select Conditions > Client apps and select Browser as the applicable client app of this conditional access policy
  7. Select Session and select Use app enforced restrictions to make sure that the configured limited experience will be applicable to this session

What the future brings

Before having a look at the end-user experience, it might be good to briefly mention that the near future will bring some more possibilities. While writing this post new MFA and other granular policies for SharePoint sites and OneDrive are introduced by using a new user action in conditional access. The Accessing secured app data user action. That user action is already configurable in conditional access by using this url for configuring the conditional access policy. It enables the administrator to configure a few protection levels for data. Those protection levels can be added to SharePoint sites and OneDrive accounts and can be assigned with different conditional access policies. That eventually might provide the administrator with a more granular control over the access to the data in the different locations. Jan Bakker already wrote some more details about that functionality at his blog. More about that subject in the future.

End-user experience

The mentioned configurations enable the administrator to provide different limited experiences to different SharePoint sites and OneDrive accounts. Let’s bring these configurations together to provide a limited experience for accessing OneDrive on unmanaged devices and by blocking access to specific SharePoint sites on unmanaged devices. Below in Figure 3 is an example of the end-user experience when opening a Word document in OneDrive on an unmanaged device, when limited access is configured with web previewable files and no editing options. That will enable the user to only preview the document in the browser. Below in Figure 4 is an example of the end-user experience when opening a TXT-file in OneDrive on an unmanaged device and when the same limited configurations apply. That will block the user from accessing the file.

Below in Figure 5 is an example of the end-user experience when accessing a SharePoint site when that specific site is blocked on unmanaged devices. That will provide the user with the message that the access is denied for untrusted devices, due to organizational policies.

More information

For more information about conditional access, SharePoint Online and OneDrive for Business, refer to the following docs:

Configure FIDO2 security key restrictions

This week is all about FIDO2 security keys. More specifically about configuring FIDO2 security key restrictions to make sure that users can only use specific FIDO2 security keys, or to prevent users from using specific FIDO2 security keys. That makes this blog post a follow up on this post about enabling password-less sign-in with security keys. In this post I’ll provide a short introduction about the FIDO2 security key AAGUID (and how to find it), followed by the steps to configure the FIDO2 security key restrictions. I’ll end this post by looking at the end-user experience.

FIDO2 security key AAGUID

According to the FIDO2 specification each authenticator should provide an Authenticator Attestation GUID (AAGUID) during attestation. An AAGUID is a 128-bit identifier that indicates the type (for example make and model) of the authenticator. The AAGUID should be identical across identical authenticators that are created by the same manufacturer, and should be different from the AAGUID of authenticators of different types and different manufacturers. To ensure this, the AAGUID is randomly generated.

The AAGUID of a FIDO2 security can be used to configure restrictions for the end-users, by either only allowing specific FIDO2 security keys based on their AAGUID or by only blocking specific FIDO2 security keys based on their AAGUID. To help with that some manufactures (like Yubico) provide a complete list of the AAGUIDs of their FIDO2 security keys.

When this information is not easily available, it’s possible to find the AAGUID by using the get_info.py script that’s available in the Python-FIDO2 library provided by Yubico. That script can make the device WINK, which will provide the information about the FIDO2 security that includes the AAGUID. Below (in Figure 1) is an example of FIDO2 security key that is sending a WINK. The information provided when sending the WINK includes the AAGUID and on some devices also the FIDO2 security key name and model.

Another method to retrieve the AAGUID of a FIDO2 security key is to register the security key as a sign-in method. That can be achieved via the Security method section of My account. After registering the security key, the AAGUID can be found with the security key as shown below in Figure 2.

Below is an overview of the FIDO2 security keys that I’ve had available during testing, including their AAGUID.

FIDO2 security keyFIDO2 AAGUID
Yubikey 5 NFC (Firmware version: 5.1.x)fa2b99dc9e3942578f924a30d23c4118
Yubikey 5C (Firmware version: 5.1.x)cb69481e8ff7403993ec0a2729a154a8
Feitian ePass FIDO-NFC Security Key K9ee041bce25e54cdb8f86897fd6418464
Feitian BioPass FIDO2 Security Key K2677010bd7212a4fc9b236d2ca5e9d4084
Feitian BioPass FIDO2 Security Key K2777010bd7212a4fc9b236d2ca5e9d4084
Feitian BioPass FIDO2 Security Key K3312ded7454bed47d4abaae713f51d6393
eWBM Goldengate Security Key G31095442b2ef15e4defb270efb106facb4e
eWBM Goldengate Security Key G32087dbc5a14c944dc88a4797d800fd1f3c

Configuring FIDO2 security key restriction

The configuration steps are pretty straightforward and can be achieved by adjusting the FIDO2 Security Keys authentication method. That can be achieved by performing the 3 steps mentioned below. Those steps are fully focussed on configuring the KEY RESTRICTION POLICY. When the FIDO2 Security Keys authentication method is not yet enabled, make sure to also perform the required actions for that. In other words, make sure to enable the authentication method and configure the target of the authentication method.

  1. Open the Azure portal and navigate to Azure Active Directory Security > 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 section
  3. On the FIDO2 Security Key settings section, provide at least the following information (see also Figure 3 for an overview of the available options) and click Save
  • Enforce key restrictions: Select Yes
  • Restrict specific keys: Select Block to create a key restriction policy that will blacklist the specified AAGUIDs and select Allow to create a key restriction policy that will whitelist the specified AAGUIDs
  • Click Add AAGUID and specify the specific AAGUIDs that should be blocked (blacklisted) or allowed (whitelisted)

End-user experience

Let’s end this post by having a look at the end-user experience. When the end-user wants to register a security key (either not on whitelist, or on the blacklist), via the Security info section in My Profile, the end-user can walk through the complete process of adding another sign-in method. At the end of the process, the end-user will receive an error with the message that the particular key type has been blocked by the organization. The message doesn’t provide a list of supported security keys.

More information

For more information about password-less authentication deployment and password-less FIDO2 security keys, refer to the following articles:

Windows 10 enrollment methods

This week is all about Windows 10 enrollment methods. The different methods to enroll Windows 10 devices into Microsoft Intune. There are many different methods to enroll Windows 10 devices, which makes it easy to get lost. In this post I’ll provide an overview of these different enrollment methods, including the use case of the enrollment method and how to perform the enrollment. This post is definitely not a complete guide through the different enrollment methods. Its main purpose is to create awareness for the different enrollment methods and to describe the main characteristics of the enrollment methods.

The different enrollment methods

Now let’s discuss the different enrollment methods and their use cases. Before starting, it’s good to mention that I’m aware of the existence of the MDM only enrollment method. However, I don’t consider that as a valid option to enroll a device into Microsoft Intune, as that method doesn’t register the device in Azure AD. And that provides many challenges, for example with conditional access. When discussing the different enrollment methods, I’ll try to group those methods were possible and I’ll try to mention the differences.

Bring Your Own Device (BYOD)

Description: The Bring Your Own Device (BYOD) method enables the user to enroll a personal device into Microsoft Intune by using the Settings panel and adding a Work and School account. That action will trigger the flow to register the device in Azure AD and that will also automatically enroll the device into Microsoft Intune.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Keep in mind that within the auto-enrollment configuration, the administrator can also configure MAM enrollment. When the MDM and MAM enrollment is configured for a user, the MAM enrollment takes precedence for personal devices.

Example scenario: This can be useful for Bring Your Own Device (BYOD) scenarios. The device will be enrolled as a personal device.

Azure AD join (with auto enrollment)

Description: The Azure AD join method enables the user to enroll a corporate-owned device into Microsoft Intune, similar to enrolling a personal device – by using the Settings panel and adding a Work and School account – the user can also choose to join the device to Azure AD. That option will become available during the same configuration flow. The user has to specifically choose to join Azure AD during that flow (as shown in Figure 2). This same behavior can also be triggered during the Out-Of-the-Box-Experience (OOBE). That can be achieved by setting the device up for an organization. That will trigger the flow to Azure AD join the device.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1).

Example scenario: This can be useful for Choose Your Own Device (CYOD) scenarios. The device will be enrolled as a corporate-owned device.

Windows Autopilot

Description: The Windows Autopilot method enables users to easily enroll corporate-owned devices. Windows Autopilot can be used to automate the Azure AD Join and directly enroll corporate-owned devices into Microsoft Intune. This method simplifies the OOBE – as mentioned with the Azure AD join method – as it will automatically add the device to AD or Azure AD and directly enroll the device into Microsoft Intune.

Important requirements: This requires that the device should be added in Microsoft Intune as Windows Autopilot devices (as shown in Figure 5) and specific Windows Autopilot profiles should be created to control the behavior and the OOBE.

Example scenario: This is useful in scenarios when handing out devices to users without the need to build, maintain, and apply custom operating system images to the devices. The device will be enrolled as a corporate-owned device.

Device Enrollment Manager (DEM)

Description: The Device Enrollment Manager (DEM) method enables the administrator to enroll multiple corporate-owned devices. The DEM account is a special account with permissions to enroll and manage multiple (up to 1000) corporate-owned devices. That enables a bulk enrollment method for non-personal corporate-owned devices. The enrollment can be achieved by following any of the flows to configure an Azure AD join.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Besides that the Device Enrollment Manager (DEM) should be configured (as shown in Figure 3) and make sure to keep the maximum number of devices that the user account can add to Azure AD matches.

Example scenario: This can be useful in scenarios where the device is enrolled and prepared before handing it out to the user of the device. The device will be enrolled as a corporate-owned device.

Provisioning package

Description: The provisioning package method enables the administrator to bulk enroll corporate-owned devices. A provision package can be used to add devices in bulk to Azure AD and automatically enroll those devices into Microsoft Intune. That provisioning package can be created by using the Windows Configuration Designer (as shown in Figure 4) and can be applied to corporate-owned devices. Once the package is applied, it’s ready for Azure AD users to sign in.

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1). Besides that make sure to keep the maximum number of devices that a user can add to Azure AD matches with the usage of the package.

Example scenario: This can be useful in scenarios where an authorized user joins large numbers of corporate-owned devices. The device will be enrolled as a corporate-owned device.

Co-management

Description: The co-management method enables administrators to automatically enroll corporate-owned devices. Co-management enables organizations to automatically enroll devices into Microsoft Intune. This requires the device to be managed with Configuration Manager and the enablement of co-management. Within the co-management configuration, the automatic enrollment in Microsoft Intune can be configured (as shown in Figure 6).

Important requirements: This requires that auto-enrollment is configured (as shown in Figure 1) and that the device is registered or joined to Azure AD (can be achieved via Client Settings).

Example scenario: This is useful in scenarios when the flexibility is still required to use the technology solution that works best for the organization. The device will be enrolled as a corporate-owned device.

Group Policy

Description: The Group Policy method enables administrators to automatically enroll corporate-owned devices. Group Policy enables organizations to automatically enroll devices into Microsoft Intune. The automatic enrollment is triggered by the Group Policy (as shown in Figure 7). That means that the device is always hybrid Azure AD joined.

Important requirements: This requires the device to registered in Azure AD.

Example scenario: This is useful in scenarios when mass-enrolling domain-joined devices.The device will be enrolled as a corporate-owned device.

An overview of the enrollment methods

Let’s end this post by providing short overview of the different enrollment methods and their most important characteristics that are mentioned in throughout this post. Those characteristics are the ownership registration of the device, the user affinity with the device and the user interaction with the device during the enrollment.

Enrollment methodOwnershipUser affinityUser interaction
Bring Your Own DevicePersonalYesYes
Azure AD joinCorporateYesYes
Windows AutopilotCorporateYesYes
Device Enrollment ManagerCorporateNoNo
Provisioning packageCorporateNoNo
Co-managementCorporateYesNo
Group PolicyCorporateYesNo

A couple of remarks with this table are that 1) Windows Autopilot contains multiple scenarios, including scenarios without user interaction and that 2) methods without user affinity provide challenges with conditional access.

More information

For more information about configuring Windows 10 enrollment methods, refer to the following docs:

Report-only mode for conditional access

This week is, like last week, about a awareness for new feature that is introduced with conditional access. Last week was all about the recently introduced Conditional Access Insights workbook. In that post I already mentioned the Report-only mode for conditional access policies. In this post I want to focus on that Report-only mode. Report-only mode is a new state of a conditional access policy state that allows IT administrators to evaluate the impact of conditional access policies before enabling them in their environment. That enables the IT administrators to anticipate on the number and names of users impacted by common deployment initiatives such as blocking legacy authentication, requiring multi-factor authentication, or implementing sign-in risk policies. A great step forward.

In this post I’ll walk through the steps of configuring Report-only mode for conditional access policies, followed by looking at the end-user experience. I’ll end this post by looking at the administrator experience.

Configure report-only mode

Let’s start by having a look at the steps to configure the Report-only mode for a conditional access policy. These steps will walk through the creation of a new conditional access policy, with a focus on configuring the Report-only mode. The exact configuration of the conditional access policy assignments and conditions are not part of that focus. The following three steps walk through that configuration.

  1. Open the Azure portal and navigate to Azure Active Directory  > Security > Conditional access (or open the Microsoft 365 Device Management portal and navigate to Endpoint security Conditional access) to open the Conditional access – Policies blade
  2. On the Conditional access – Policies blade, click New policy to open the New blade
  3. On the New blade, configure the assignment and conditions to filter the users and cloud apps that should be targeted by the conditional access policy. After configuring the conditions it’s time to look at the access controls. The access controls are the configuration that eventually might impact the end-user. In the access controls, the grant control determines that behavior. In the grant control the IT administrator can configure the requirements that should be met for accessing the cloud app for the end-user. Depending on the configured requirements, there might be a minimal impact for the end-user (see Figure 1 and and Figure 2 about the messages that are shown about the impact of the conditional access policy based on the configured requirements). After configuring the grant control, select Report-only with Enable policy (also shown in Figure 1) and click Create.

End-user experience

Depending on the configuration that is used in the grant control, of the conditional access policy, the end-user might have a slight impact when using the Report-only mode. The table below is a summary of the available requirements in combination with the potential impact. This table is based on the information as shown during the configuration of the conditional access (see Figure 2), as I haven’t been able to get the mentioned experience on my test devices. I’ve tested with a Samsung Galaxy 10, iPad 2018 and iPhone X.

RequirementPotential user impact
Require multi-factor authentication No impact
Require device to be marked as compliantMay prompt users on macOS, iOS and Android devices to select a device certificate
Require Hybrid Azure AD joined device No impact
Require approved client appMay prompt users on macOS, iOS and Android devices to select a device certificate
Require app protection policyMay prompt users on macOS, iOS and Android devices to select a device certificate

Administrator experience

An interesting part to look at is the experience of the IT administrator. That can be achieved by looking at the Conditional Access Insights workbook (as shown last week). The Conditional Access Insights workbook can be used to get the insights of the different Report-only mode conditional access policies. The data in the workbook can be filtered to only show information about Report-only mode conditional access policies, or even only data of a specific conditional access policy.

Besides that workbook, the Sign-ins monitoring of Azure AD also provides a new tab in the details of a sign-in. That tab is the Report-only (Preview) tab. As shown below that tab provides information about the different Report-only mode conditional access policies that were applicable to the sign-in. Per conditional access policy, the result is shown of the sign-in. That result will show what the effect would be of that conditional access policy and that information will help with determining the impact of enabling that conditional access policy.

Below is an overview of the different result states of a Report-only conditional access policy. Almost all of these results are shown in Figure 3 above (with the exception of the user action required result).

ResultExplanation
Report only: FailureThe configured conditional access policy conditions were satisfied, but not all the required (non-interactive) controls were satisfied.
Report only: SuccessThe configured conditional access policy conditions and required (non-interactive) controls were satisfied. 
Report only: Not appliedNot all configured conditional access policy conditions were satisfied.
Report only: User action requiredThe configured conditional policy conditions were satisfied, but a user action would be required to satisfy the required controls.

More information

For more information regarding report-only, please refer to the following documents:

Conditional Access Insights

This week is all about creating awareness for the Conditional Access Insights workbook. This workbook is currently still in preview and is using Azure Monitor workbook functionality. The Conditional Access Insights workbook contains sign-in log queries that can help IT administrators with getting insights on the impact of conditional access policies. That is useful for troubleshooting, for following trends and for testing the latest introduction to conditional access of Report-only policies. Especially the latest category can be easily verified by using the Conditional Access Insights workbook. In this post I’ll walk trough the steps of creating a Log Analytics workspace (to store Azure Monitor log data), followed by the steps to send Azure AD sign-in information to Azure Monitor logs.I’ll end this post by actually looking at the Conditional Access Insights workbook.

Create a Log Analytics workspace

The first step to prepare for using the Conditional Access Insights workbook, is to create a Log Analytics workspace. A Log Analytics workspace is a unique environment for Azure Monitor log data. Each Log Analytics workspace has its own data repository and configuration, and data sources and solutions are configured to store their data in a particular workspace. To create a Log Analytics workspace simply follow the 2 steps below.

  1. Open the Azure portal and navigate to  All services  > Log Analytics workspaces to open the Log Analytics workspaces blade
  2. On the Log Analytics workspaces blade, provide the following information and click OK
  • Select Create New
  • Log Analytics Workspace: Provide a unique name for the Log Analytics workspace
  • Subscription: Select a valid subscription for the Log Analytics workspace
  • Resources group: Select an existing resource group for the Log Analytics workspace, or click Create new to create a new resource group for the Log Analytics workspace
  • Location: Select a location for the Log Analytics workspace
  • Pricing tier: Select a pricing tier for the Log Analytics workspace

Note: Alternatively the Log Analytics workspace can be created during the process of configuring the diagnostic settings of Azure AD.

Send logs to Azure Monitor logs

The second step to prepare for using the Conditional Access Insights workbook, is to send the Azure AD sign-in logs to Azure Monitor logs (previously known as Log Analytics). Azure Monitor logs allows the administrator to query data to find particular events, analyze trends, and perform correlation across various data sources. To send the Azure AD sign-in logs to Azure Monitor logs simply follow the 3 steps below.  

  1. Open the Azure portal and navigate to  Azure Active Directory  > Diagnostic settings to open the [Azure AD] > Diagnostic settings blade
  2. On the [Azure AD] > Diagnostic settings blade, click Add diagnostic settings to open the Diagnostic settings blade
  3. On the Diagnostic settings blade, provide the following information and click Save
  • Name: Provide a unique name for the diagnostic settings configuration
  • Select Send to Log Analytics
  • Subscription: Select a valid subscription for the Azure Monitor logs
  • Log Analytics Workspace: Select the previously created Log Analytics workspace as a location to store the Azure Monitor logs
  • Log: Select SignInLog

Conditional Access Insights workbook

After making sure that the Azure AD sign-in information is send to Azure Monitor logs, the Conditional Access Insights workbook can be used to get insights in the log data. This workbook contains sign-in log queries that can help IT administrators monitor the impact of conditional access policies. This provides the IT administrators with the ability to report on how many users would have been granted or denied access. This workbook contains details per condition so that the impact of a policy can be contextualized per condition. The following steps walk through navigating to and through the Conditional Access Insights workbook.

  1. Open the Azure portal and navigate to  Azure Active Directory  > Workbooks to open the [Azure AD] > Workbooks blade

Tip: Also make sure to take a look at the other available workbooks, as those workbooks provide a lot of insights about the different sign-ins. Really useful for insights.

  1. On the [Azure AD] > Workbooks blade, click Conditional Access Insights (Preview) to open the Conditional Access Insights (Preview) workbook

The Conditional Access Insights workbook provides the IT administrator with a lot of insights based on the Azure AD sign-in information. The figures above show the following information:

  • Figure 4 shows the parameter selection and the Impact summary section of the workbook. The parameter selection section provides five parameters to filter the insights of the workbook: Conditional Access Policy, Time Range, User, Apps and Data View. The first filter can also be used to easily verify the impact of the recently Report-only conditional access policies, as the insights can be filtered to a specific conditional access policy. The Impact summary section, shows a quick overview of the results for the selected conditional access policy in the specified time range. Clicking on the different tiles will further filter the breakdown sections.
  • Figure 5 and 6 show the Breakdown per condition and sign-in status section of the workbook. The Breakdown per condition and sign-in status section shows the impact of the selected conditional access policies broken down by each of six conditions: Device state, Device platform, Client apps, Sign-in risk, Location and Applications. Clicking on the logs sign with a breakdown, will open the used query in the logs viewer. That will provide the kql-query that is used to filter the right information.
  • Figure 7 shows the Sign-in details section of the workbook. The Sign-in details section enables the IT administrator to investigate individual sign-ins, filtered by the parameters selected in the workbook. Search for individual users, sorted by sign-in frequency, and view their corresponding sign-in events.

More information

For more information regarding conditional access insights, refer to the following documents:

Conditional access and ipadOS

Update: Azure AD has taken a change in how they recognize the browsers so conditional access will now work as expected when creating an iPad conditional access policy and browsing to the modern desktop-class browsing experience on iPadOS. For more information see this article.

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