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

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: