Require an Internet connection during device setup

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

Introduction

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

Configuration

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

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

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

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

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

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

End-user experience

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

OOBE-Connect-Network

More information

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

Enable password reset from the login screen

This week is about something similar as last week. This week is all about the password reset option on the login screen. In other words, the Reset password option. Starting with Windows 10, version 1709, it’s possible to enable the Reset password option from the login screen for Azure AD joined devices. I know that a lot has been written already about this subject, but I have the feeling that this subject needs a place on my blog. My style and more details. In this post I’ll provide a short introduction about Azure AD self-service password reset (SSPR), followed by walking through the required configurations for SSPR and the Reset password option. I’ll end this post by looking at the end-user experience.

Introduction

Now let’s start this post with an introduction about Azure AD SSPR. With SSPR users can reset their passwords on their own when and where they need to. At the same time, administrators can control how a user’s password gets reset. That means that the user no longer needs to call a help desk just to reset their password. SSPR includes (the focus of this post is number 2):

  1. Self-service password change: The user knows their password but wants to change it to something new;
  2. Self-service password reset: The user is unable to sign in and wants to reset their password by using one or more of the following validated authentication methods:
    • Send a text message to a validated mobile phone;
    • Make a phone call to a validated mobile or office phone;
    • Send an email to a validated secondary email account;
    • Answer their security questions.
  3. Self-service account unlock: The user is unable to sign in with their password and has been locked out. The user wants to unlock their account without administrator intervention by using their authentication methods.

Configuration

Let’s continue by having a look at the required configuration, to enable the Reset password option from the login screen. As the configuration of the actual settings requires SSPR to be enabled, I divided the configuration into two steps. The first step is to enable SSPR and the second step is to configure the Reset password option.

Step 1a: Enable SSPR

The first step is to enable SSPR, as it’s the starting point for enabling the Reset password option from the login screen. Without SSPR enabled, and still configuring the Reset password option, the user will receive a message that SSPR is not enabled for the user and that the user should contact the administrator. The following seven steps walk through the relatively simple configuration to enable SSPR.

1 Open the Azure portal and navigate to Azure Active Directory > Password reset;
2

AAD_PR_PropertiesOn the Password reset – Properties blade, select All and click Save;

3

AAD_PR_AuthOn the Password reset – Authentication methods blade, select the number of required methods to reset and the available methods to user and click Save;

Note: Make sure that you have at least as many methods available to users as you have required to reset.

4

AAD_PR_RegistrationOn the Password reset – Registration blade, configure whether or not to require users to register when signing in and click Save;

5

AAD_PR_NotificationsOn the Password reset – Notifications blade, configure the notification settings and click Save;

6

AAD_PR_CustomizationsOn the Password reset – Customization blade, configure the customization settings and click Save;

7

AAD_PR_OnPremOn the Password reset – On-premises integration blade, and configure the password write back configuration and click Save;

Note: This is required when using an on-premises directory and also requires the configuration of step 1b.

Step 1b: (Optional) Configure password writeback

Another part of the first step is the optional configuration of password writeback. This should be configured to write the passwords from Azure AD back to the on-premises directory. To achieve this, use the following seven steps to reconfigure Azure AD Connect.

1 On the Azure AD Connect server, start Azure AD Connect to open the Microsoft Azure Active Directory Connect wizard;
2 On the Welcome page, click Configure;
3 On the Additional tasks page, select Customize synchronization options and click Next;
4 On the Connect to Azure AD page, provide the required credentials and click Next;
5 On the Connect Directories page, click Next;
6 On the Domain/OU Filtering page, click Next;
7

MAADC_OptionalFeaturesOn the Optional Features page, select Password writeback and click Next;

Note: I’ve also got Device writeback configured, which causes the next page to appear.

8 (Optional) On the Writeback page, click Next;
9 On the Configure page, click Configure and once completed click Exit;

Step 2: Enable Reset password option

The second step is to configure the required setting to enable the Reset password option from the login screen. In other words, the second step is to configure a device configuration profile with at least a custom OMA-URI setting. The required setting is part of the Authentication node of the Policy CSP. It’s the AllowAadPasswordReset policy. That policy allows administrators to enable the self-service password reset feature on the windows logon screen. An integer value of 0 means not enabled and an integer value of 1 means enabled.

The following three steps walk through the creation of a new device configuration profile, including the required OMA-URI setting. After that simply assign the created profile to a user group.

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

On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MSI_AllowPasswordResetOn 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 description;
  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset;
  • Data type: Select Integer;
  • Value: 1.

Note: For testing purposes it’s also possible to configure the Reset password option by using the HKLM\SOFTWARE\Policies\Microsoft\AzureADAccount registry key with the value, type and data of AllowPasswordReset, REG_DWORD and 1.

End-user experience

Now let’s end this post by walking through the end-user experience. On the login screen a new option is available when selecting password as the sign-in option, the Reset password option.

RP_01

When the user selects Reset password, the user will be redirected to the Azure AD self-service password reset service.

RP_02

The User ID is already prepopulated and when the user clicks on Next, the user should choose a verification method. In my case a text to my mobile phone.

RP_03

When the user provides the correct mobile phone number and clicks on Next, the user must provide the actual verification code of the text message.

RP_04

When the user provides the correct verification code and clicks on Next, the user must provide a new password.

RP_05

When the user provides a new password and clicks Next, the user will be provided with the message that the password has been reset. When the user than clicks on Finish, the user will be redirected to the login screen.

RP_06

More information

For more information about SSPR, Windows 10 and the Reset password option, please refer to the following articles:

Enable PIN reset from the login screen

This week I’m going for an end-user experience focused blog post. This week is all about the PIN reset option on the login screen. In other words, the I forgot my PIN option. Starting with Windows 10, version 1709, it’s now possible to enable the I forgot my PIN option from the login screen. When using Windows Hello for Business, which can be configured during the Windows enrollment, by using Microsoft Intune, the PIN is the fallback mechanism when it’s not possible to authenticate with biometrics. In other words, the PIN is really important.

In this post I’ll provide the required configuration to provide the user with the I forgot my PIN option from the login screen. I’ll do that by assuming that the user can use the Windows Hello for Business PIN recovery service to reset their PIN. I’ll end this post by looking at the end-user experience.

Configuration

Now let’s start by having a look at the required configuration to enable the I forgot my PIN option from the login screen. As the configuration of the actual settings requires the tenant ID, I divided the configuration into three steps. The first step is to find and introduce the required setting, the second step is to get the tenant ID and the third step is to use the tenant ID in the actual configuration.

Step 1: Get the required setting

The first step is to get and introduce the required setting. The PIN-related settings are part of the Windows Hello for Business settings, which can be configured by using the PassportForWork CSP. Starting with Windows 10, version 1703, that CSP contains the EnablePinRecovery node. With Windows 10, version 1703, this setting can be used to enable the I forgot my PIN option from the Settings panel and starting with Windows 10, version 1709, this setting can also be used to enable the I forgot my PIN option from the login screen.

This settings has a boolean value that enables a user to change their PIN by using the Windows Hello for Business PIN recovery service. This cloud service encrypts a recovery secret, which is stored locally on the client, and can be decrypted only by the cloud service. The default value of this setting is false. Once the administrator enables this setting, the PIN recovery secret will be stored on the device and the user can change their PIN if needed.

Step 2: Get the tenant ID

The second step is to get the tenant ID. This is super simple these days, but, as I’ve never provided the actual steps, I thought it would be smart to publish them once. To get the tenant ID, simply follow the two steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Properties;
2

tenantIDOn the Properties blade, click Copy next to Directory ID to copy the tenant ID;

Note: Just to be clear, this should be used in the OMA-URI instead of {tenantID}.

Step 3: Configure the required setting

The third step is to configure the required setting to enable the I forgot my PIN option from the login screen. In other words, the third step is to configure a device configuration profile with at least a custom OMA-URI setting. The following three steps walk through the creation of a new device configuration profile, including the required OMA-URI setting. After that simply assign the created profile to a user group.

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

On the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b.
3b

MIS_PINResetOn 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 description;
  • OMA-URI: ./Device/Vendor/MSFT/PassportForWork/{tenantID}/Policies/EnablePinRecovery;
  • Data type: Select Boolean;
  • Value: Select True.

End-user experience

Now let’s walk through the end-user experience. On the login screen a new option is available when selecting PIN as the sign-in option, the I forgot my PIN option.

IfmP_01

When the user selects I forgot my PIN, the user will be redirected to the login experience of the identity provider. In my case ADFS.

IfmP_02

When the user provides a password and clicks on Sign-in, the user needs to provide an additional verification option, on an Azure AD branded page. In my case a text message.

IfmP_03

When the user provides the additional verification and clicks on Next, the user will be provided with an additional notification to make sure that the user is aware of the impact.

IfmP_04

When the user accept the impact of resetting the PIN and clicks Continue, the user will be provided with a dialog box to create a new PIN. Also, the user can click on PIN requirements to view the requirements for the new PIN. In my case it will show the Windows Hello for Business settings as configured in the Windows enrollment section of Microsoft Intune.

IfmP_05

When the user provided a new PIN and clicks OK, the user will be provided with the message that it’s all set. When the user than clicks on OK, the user will be redirected to the login screen.

IfmP_06

More information

For more information about Windows 10 and the (remote) PIN reset functionality, please refer to the following articles:

Deep dive ingesting third-party ADMX-files

A bit more than a week ago I got the suggestion to do a blog post about the ingestion of custom and/or third-party ADMX-files. Not without a reason. The suggestion was triggered by the latest Spectre and Meltdown vulnerabilities and the ability to manage site isolation via policies for Google Chrome. That was enough motivation for me to look into it. In this post I’ll provide an introduction to ingesting ADMX-files, followed by a step-by-step overview of how to ingest custom and/or third-party ADMX-files and how to configure the related settings. As a configuration example I’ll use the manage site isolation setting for Google Chrome. I’ll end this post with showing the configuration result.

Introduction

Starting with Windows 10, version 1703, it’s possible to ingest ADMX-files and to set those ADMX-backed policies for Win32 apps and Desktop Bridge apps, by using Windows 10 MDM. The ADMX-files that define policy information, can be ingested to the device by using OMA-URI. The ingested ADMX-files are then processed into MDM policies. When the ADMX policy settings are ingested, the registry keys, to which each policy is written, are checked so that known system registry keys, or registry keys that are used by existing inbox policies or system components, are not overwritten. This precaution helps to avoid security concerns over opening the entire registry. Currently, the ingested policies are not allowed to write to locations within the System, Software\Microsoft, and Software\Policies\Microsoft keys, except for the locations documented here.

Configuration

Now let’s have a look at the configuration. The configuration contains two important steps. The first step is to ingest the ADMX-file and the second step is to configure the required setting. I will configure both settings on the device level.

Step 1: Ingest the ADMX-file

The first step is to ingest the ADMX-file. As this post is using Google Chrome as an example, make sure to download the Chrome policies here. Before starting with ingesting this ADMX-file, it’s important to first construct the OMA-URI setting and value.

Setting

The OMA-URI should look like this ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/{SettingType}/{FileUid or AdmxFileName}. In this URI the following variables should be provided:

AppName: This should be the name of the app that will be configured, but can theoretically be anything. In this example I’ll use Chrome;
SettingType: This should always be policy with ingesting ADMX-files. So, in this example I’ll use Policy;
FileUid or AdmxFileName: This should be the name of the ADMX-file, but can theoretically be anything. In this example I’ll use ChromeADMX.

Value

The value is a lot easier. That’s simply the content of the downloaded chrome.admx, which is available in the folder policy_templates\windows\admx. So, to make this really simple, open chrome.admx in an editor and press Ctrl+A, followed by Ctrl+C.

Configuration

Now let’s put the OMA-URI setting and value together, in Microsoft Intune, in a Device configuration profile. To do this, simply follow the three steps below and keep in mind that the OMA-URI setting (step 3b) is nothing more than just putting together the variables as mentioned in the Setting section.

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

MSI_DC_CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Windows 10 – Chrome configuration;
  • Description: (Optional);
  • Platform: Select Windows 10 and later;
  • Profile type: Select Custom;
  • Settings: See step 3b;
3b

MSI_DC_AddRowOn 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: Chrome ADMX Ingestion;
  • Description: (Optional);
  • OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx;
  • Data type: Select String;
  • Value: [Complete content of the chrome.admx];

Step 2: Configure the required setting

The second step is to configure the required setting. Finding the correct values for configuring the required setting, is similar to finding the correct values for any other ADMX-backed policy. So, make sure to be familiar with my post about Deep dive configuring Windows 10 ADMX-backed policies. Before starting with the configuration, it’s important to first construct the OMA-URI setting and value.

Setting

The OMA-URI should look like this ./Device/Vendor/MSFT/Policy/Config/{AppName}~{SettingType}~{CategoryPathFromADMX}/{SettingFromADMX}. Make sure to pay attention to the use of tildes in this URI. In this URI the following variables should be provided:

AppName: This should be the name of the app, as configured with the ingestion of the ADMX-file. In this example I used Chrome;
SettingType: This should be the same as configured with the ingestion of the ADMX-file. In this example I used Policy;
Chrome_CatCategoryPathFromADMX: This should be the complete category path, which actually starts with number 3 in the picture below. That shows googlechrome as the parent category. That category should be followed until the category definition of the ADMX-file, as shown with number 1 in the picture on the right. Number 2 in that same picture, shows that there is no additional parent category;
Chrome_SettingSettingFromADMX: This should be the name of the setting, which is shown with number 2 in the picture on the right. That shows SitePerProcess as the actual name of the setting. Number 2 in that same picture shows the actual registry that will be configured and which we can use to verify the result.

Value

The value is again a lot easier. In this example I simply want to enable the policy, which can be done by using <enabled/>. For more complicated settings, refer to my earlier mentioned post.

Configuration

Now let’s put the OMA-URI setting and value together, in Microsoft Intune, in the previously created Device configuration profile. To do this, simply follow the four steps below and assign the profile to an user group. Just like with ingesting the ADMX-file, keep in mind that the OMA-URI setting (step 4) is nothing more than just putting together the variables as mentioned in the Setting section.

1 Open the Azure portal and navigate to Intune > Device configuration > Profiles;;
2 On the Devices configuration – Profiles blade, select the earlier created Windows 10 – Chrome configuration profile to open the Windows 10 – Chrome configuration blade;
3 On the Windows 10 – Chrome configuration blade, select Properties > Settings to open the Custom OMA-URI Settings blade;
4

MSI_DC_AddRow1On 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 on the Custom OMA-URI blade and Save on the Windows 10 – Chrome configuration blade);

  • Name: Chrome – ADMX – SitePerProcess;
  • Description: (Optional);
  • OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/SitePerProcess;
  • Data type: Select String;
  • Value: <enabled/>;

Result

Let’s end this post with the result of the device configuration. The easiest location to look for a success would be Google Chrome itself, but instead I would like to show that the configuration actually arrived on the device. Below on the left is a screenshot of the Settings panel (Accounts > Access work or school > {tenant} > Info). That screenshot clearly shows the custom policy of Chrome~Policy~googlechrome. The applied custom policy doesn’t get any clearer than that. Below on the right is a screenshot of the Registry Editor. That screenshot clearly show the applied configuration, which can be matched with the registry setting in the ADMX-file (see number 2 in the picture with SettingFromADMX).

Chrome_Settings Chrome_Registry

More information

For more information about ingesting ADMX-files, refer to this article Win32 and Desktop Bridge app policy configuration.