Introduction

One of the new features in Windows 10 1803 is the ability for "local Active Directory" Domain joined workstations to allow users to reset their password from the login screen. This was introduced for Azure Active Directory joined systems in Windows 10 1709.

In this post I’m quickly going to run through what you need to do in order to configure this for your domain. I’m making the following assumptions:

You have Azure AD configured, and have sync working for local AD users to AAD.
You have the correct Office 365/Azure Azure Active Directory Premium, Intune / Enterprise Management Suite licences already enabled and assigned to users.
You have configured Self Service Password Reset for your Azure AD Domain, including password writeback (e.g. your test users can use https://aka.ms/sspr to reset their password from a web page). If not, see here. SSPR from the login screen will not work if SSPR isn't already properly configured.
You have some Windows 10 1803 devices joined to your domain for testing.

Getting Started

In order to configure SSPR on the Windows 10 login screen you will need to do the following:

Configure Hybrid Azure AD join for your target computers.
Configure your devices to be managed by Intune, Microsoft's MDM component in Office 365/Azure Active Directory.
Configure a couple of Intune Profiles with settings for your target computers, and apply these to the test computers.
Assign your Intune SSPR profiles to your target computers.
Test... and you're (hopefully) done.
Troubleshooting

Configuring Hybrid Azure AD Join

As you probably know if you're the kind of person who reads IT techie posts past the first few paragraphs, in order to manage computers in a traditional enterprise network, you would join them to a directory service such as Active Directory (AD), which would give you a central place to create and configure users to log on to those computers, along with settings for your users and devices. As you probably know if you're looking at an article on configuring Microsoft Intune, you can also have users and devices connected to Azure Active Directory (AAD), which allows you to create and manage computers and users in AAD.

It’s been possible with a variety of tools over the years to synchronise user accounts between your on-premise AD and AAD. This has typically been used to move user mailboxes to the Exchange Online component of Office 365 without having to maintain two different accounts for the same user, as this would be a huge pain for both the users and the IT department. The current tool that Microsoft provide for synchronising account details between AD and AAD is known as AD Connect. At the time of writing, the current version is 1.1.888.0, which was released to fix a really annoying bug with high CPU use in AD Connect 1.1.819.0.

From the release of AD Connect 1.1.819.0, Microsoft have greatly simplified the configuration of Hybrid AAD join, enabling you to complete all of the configuration steps from the AD Connect wizard in most cases. I’ve used this to configure our Hybrid AAD join and it did everything for me, including re-configuring our AD FS farm correctly which I know scares more than a few people away from configuring Hybrid AAD join.

There are lots of good reasons to keep your AD Connect setup up-to-date and this is one more very important reason among other good reasons such as enabling automatic updates, general bug and performance fixes, etc. You can review the AD Connect release notes and version history and grab the latest copy from here, and if you use AD Connect at all I strongly suggest that you do so every few months.

Once you’ve configured Hybrid AAD join and allowed time/triggered an update in whatever method you’re using, you can verify that computers from Active Directory are being imported into AAD by opening your Azure Active Directory Portal, going to all devices and searching for a computer you know should be synchronised.

Hopefully you will find your device is now visible in AAD. Check the join type and it should say “Hybrid Azure AD joined”. This means that this has been syncronised from your local AD. If you’re doing this via AD Connect you should also be able to open the AD Connect Synchronization Service Manager and see the devices you’ve chosen to sync included as “Adds” in what will probably a fairly hefty Delta import job.

Configure your devices to be managed by Intune.

The next step after getting the devices in to AAD is to have them managed by Intune. If you're following this along with me, you'll need to configure Intune to act as your MDM Authority for the target devices and then use Intune to manage settings related to SSPR on those devices.

Enabling Intune

To enable Intune, if you've not done so already, go to your Azure Portal, open Azure Active Directory and select "Mobility (MDM and MAM)". From here, select "Microsoft Intune". The Configuration options for Intune will appear.

Note the two options for MDM (Mobile Device Management) and MAM (Mobile Application Management). If that confuses you then you’re not alone but broadly speaking, the difference is that MDM is targeted to managing devices that your org controls and MAM is targeted to managing Applications and data, whether or not you control the device.

The main thing to consider for what we’re talking about here is that your MAM and MDM scopes cannot overlap. Users and devices need to be managed by one or the other and there cannot be a clash. You can choose to work with just MDM as in the example above where the scope for MDM is set to “All” and the MAM scope is set to “None”, or you can choose to just target some users and devices for MDM and target some others for MAM by selecting “Some” and targeting groups for MDM and MAM respectively.

To add the Intune to your Azure portal shortcuts the way I’ve done here, go to “All Services”, search for “Intune” and “star” it as a favourite. Then drag to where you want it in your list.

Enrolling a device in Intune

In Azure Active Directory, create some test groups for users and devices you wish to target for Intune, and populate them with your test subjects. Being able to see computer accounts in AAD and assign them to groups is another test of the Hybrid Azure AD Join, by the way.

In this example we have two groups for test devices, one that we’re using to apply general Windows 10 device profiles, and one that we’re using specifically to test SSPR.

Next, go to Intune to enroll your devices. From the main Intune home screen, select “Device Enrollment” and verify that your Tenant name looks right, that your MDM authority is set to Intune and your account status is Active.

With that all in order, return to Intune Home, then go to Device Compliance, then Policies, then click “Create Policy”. Create a policy by giving it a name, setting the platform to target Windows 10 and later, and working through Device Health, Device Properties, System Security and Windows Defender ATP settings.Still in your policy, choose Assignments and under “Include”, assign your target users (either “All Users” or a previously created and populated group of test users).

Doing this will ensure you will get a view of the “device health” of devices that enroll into Intune.

Now we’ve done the following:

Enabled Azure AD Hybrid Join for our on-prem Windows 10 devices, and verified that's worked.
Enabled Intune and configured it to enroll our Windows 10 devices.

We are now ready for the next step, configuring Auto-MDM enrollment group policy settings in our local AD.

Move your test devices to their own OU in Active Directory.
Create and link a new GPO to this OU.
In the GPO, open Computer Configuration, Policies, Administrative Templates, Windows Components, MDM.
Set "Auto MDM Enrollment with AAD Token" to Enabled.
(If you've got it set to Enabled elsewhere) also set "Disable MDM Enrollment" to "Disabled".

For more information about this process, see this Microsoft article.

This will now create a set of scheduled tasks on each computer in that OU that will attempt to enroll that device into Intune.

You can view these tasks in Task Scheduler, Microsoft, Windows, EnterpriseMgmt,{guid}. You can view how these tasks are behaving in the event viewer, under Applications and Services Logs, Microsoft, Windows, DeviceManagement-Enterprise-Diagnostics-Provider.

It’s normal to see a few errors here during the first attempts to connect to Intune, which are typically Event ID 76 messages in the Admin log here. All being well they should settle down and you should see successful enrollment messages (Event ID 72 and 75).

If not, check your network firewall isn’t preventing your devices from reaching the URLs/IPs mentioned in this article. If you’re still having trouble, I’ve found the foxdeploy article on Intune enrollment troubleshooting to be very useful.

Once you have this working you can verify that the Intune console can see the device by going to Intune home, Devices, All Devices and searching for the device name.

In the example above, devices 10370, 10745 and 10868 are all working correctly. They’re imported into Azure AD correctly and they’ve successfully run the MDM auto-enrollment task, changed their management authority to Intune and applied the compliance policy.

10758 is an example of a problem you might have in a mixed SCCM/Intune environment where a machine has failed to change its MDM authority to Intune because it has the SCCM agent on it. I’ll be discussing how to fix that in another article.

Testing Intune Profile Management.

Before we proceed with deploying SSPR settings, it's wise to apply a test Intune profile and make sure that behaves as expected. Device or User profiles are how you apply settings to target

You don’t have to do this but if you’re new to Intune then it’s a good idea to make sure you’re comfortable with applying a harmless setting before pushing out something that might cause issues.

We’re going to push out a profile to change the desktop wallpaper on managed computers. To do this, go to Intune Home, Device Configuration and Profiles. Select Create Profile. Give your profile a name and select “Windows 10 and later” under Platform. Under Profile type, select “Device Restrictions”.

Under Device Restrictions, Select Locked Screen Experience and put in a URL that links directly to a suitable graphics file.

Click OK to close the Personalization window, Click OK to close Device Restrictions then on your profile’s property page, click “Save” to save the profile.

Now we need to assign the policy. Click Assignments, choose an appropriate target device group under “Include” and click Save again. You may want to choose a more modest scope for your test deployment than I’m using below, though “All Users & All Devices” here does only refer to objects that are already enrolled in Intune.

Note that the setting we’ve changed, the login screen wallpaper basically, applies to devices. We need to test our ability to target devices rather than users, as SSPR is also a change to the device.

Now we play the waiting game while we wait for the test devices to receive and apply the updated profile.

Assign your Intune SSPR profiles to your target computers.

Now we've proven that we can control Windows 10 devices via Intune and push profiles down and see them apply, we can create a couple of profiles to enable SSPR.

There are two items to push down to your test devices, and each will require its own profile. Note that we are pushing these profiles down to groups of devices, not people. We are changing the way the devices work, not configuring user options.

Creating your Windows 10 SSPR Device Configuration profile.

Go in to Device Configuration and create a new Intune profile as before, selecting Windows 10 and later for the Platform, and Custom for the Profile Type.

We will now create a custom OMA-URI setting under the Settings tab.

Give the setting a meaningful name. Or not, it's not me who has to document it later.
For OMA-URI, put ./Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset
For Data type select Integer
For Value, type 1.
OK out of this setting and save the profile.
Under Assignments, assign this profile to your target devices.
Save this profile and now you're ready for the next part.

The next setting we need to deliver is a registry change. There's a number of ways to do this but I'm going to walk through making the change via Intune, because I feel it makes sense to keep as much of the deployment settings in one place as possible, but if you have a preferred method for delivering registry changes to devices then go for it.

Create a powershell .ps1 file with the code below in it and give it a sensible name:

# # Rob 22/8/2018 Adds SSPR registry entry to Windows 10 computers (see [docs.microsoft.com/en-us/azu...](https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-sspr-windows)) # This script will create the registry path, key and value if they're not present. If it's present, it will update the value to ensure it's correct. # $registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\AzureADAccount" $Name = "AllowPasswordReset" $value = "1" IF(!(Test-Path $registryPath)) { New-Item -Path $registryPath -Force | Out-Null New-ItemProperty -Path $registryPath -Name $name -Value $value ` -PropertyType DWORD -Force | Out-Null}
ELSE { New-ItemProperty -Path $registryPath -Name $name -Value $value ` -PropertyType DWORD -Force | Out-Null}

From Device Configuration, open PowerShell Scripts and choose "Add". Give the PowerShell script profile a sensible name like "SSPR Registry Setting" and upload the .ps1 file we created previously.

Under Settings, ensure that both “Run this script using logged on credentials” and “Enforce script signature check” are set to No. Once you’ve created the profile, assign it to your test machine group the same as we did for the OMA-URI profile.

If you want to create the registry key by other means, the path you want is: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount (you may need to create the “AzureADAccount” key. You need to create a dword entry named “AllowPasswordReset” here and assign the value “1” to it.

That’s it. Once the profiles we’ve just created have applied to your test machines, that in theory is all you need to do.

Test... and you're (hopefully) done.

If all is well, you should see "Reset Password" under the normal Windows Login dialogue. login

Select this and you should hopefully be taken through a SSPR interface that is similar to the web page SSPR process. Assuming this happens and it completes without errors, congratulations, you’ve read a fairly long blog post and configured SSPR for your AD devices. I’d call that a decent job!

Troubleshooting

We're making the assumption at this point that you've got devices enrolled successfully in to Intune.

No Reset Password link appears.

If the Reset Password link does not appear, this suggests the settings we created in the profiles above are either incorrect or are not being applied correctly. This is why assigning a test profile for something harmless like wallpaper is a good idea before trying to roll out more complex settings, so if you haven't done that already, try creating that test profile now, assign it to the same machine groups as your SSPR profiles and check that it applies as expected.

To further troubleshoot, we can look at the profile we’ve created for SSPR, by going to Intune Home, Device Configuration, then Profiles. Now select the SSPR profile and you should be taken to the overview screen for this profile. In an ideal world this would be a nice big green circle like our example, showing that the target devices have all applied the profile correctly.

If there’s an issue here, you should see a colour coded entry to tell you what went wrong.

You can troubleshoot the powershell script profile in a similar way. You can also run regedit on a target machine and look for the registry entry (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount). If it’s not there and you don’t want to delay testing of SSPR you can then also cheat a little by manually creating the entry using the notes in the previous section.

Reset Password link is there but does not work.

I've had some fun with this. It appears that SSPR on the desktop is rather sensitive to GPOs that change the login experience in any way. A symptom of this is that the Reset Password button appears, but clicking it doesn't result in the expected login to the SSPR recover page and instead you just get dropped back to the login screen.

After a very long twitter conversation with Nick Wiley (@npwiley), in which we’ve discovered that we’ve both got things working by setting directly opposite settings at one point, I’m just thinking that the best approach is to not attempt to manage the login experience with GPOs at all and just use modern management. (See below for twitter thread.)

So, this is something of an uncertain ground. From Nick’s tests (he’s done more of the heavy lifting here than I have, and deserves the credit), the main policy/setting to worry about at the login screen is the policy that blocks app notifications.

twitter.com/npwiley/s…

twitter.com/RobertoMo…