Call4Cloud | MMP-C | Autopilot | Device Preparation

Battle for the Planet of the Web Sign-in Provider

Patch My Pc | install & update thousands of apps

Choosing between Windows Hello or the Microsoft Authenticator App (Web Sign-in) to log in to your Windows Entra Joined device can be a difficult choice, or maybe not! I hope this blog explains why.

1. Introduction

Last Friday, 09-04-2021, I was experimenting with Windows Hello and trying to remove the Password Credential Provider {60b78e88-ead8-445c-9cfd-0b87f74ea6cd} and trying to configure Windows Hello and using a first and second Hello unlock factor.

Let’s start by explaining a bit more about the first and second unlock factors and which providers we can configure.

These are the Credential providers you can choose from.

Of course, this is very important when you want to deliver some more MFA instead of only requiring a simple PIN. In my opinion, only requiring a PIN to unlock your device is not the safest solution out there.

Why, you might ask? In my opinion, many people are using a simple PIN code, or when you allow the possibility to use all characters, they just enter their Microsoft 365 password as a PIN code. A better solution would require two unlock factors.

And not to forget Facial Recognition! I love facial recognition. Luckily, it’s possible and supported to add an external Windows Hello Cam in 21H1. Everyone with a Notebook and a docking station is familiar with this problem. Using a notebook and closing the lid when attaching it to your docking station makes it very hard to use the cam for Facial recognition.

Don’t get me wrong, not using WHfB is way way worse than using a PIN. Of course, WHfB satisfies the requirements for MFA in AAD but there is more to this story!

Back to the unlock factors! I ended up requiring a PIN and facial recognition.

But I was not satisfied yet. It’s way better than only requiring a PIN, but I felt I was missing my favorite sign-in option… Logging in with the Microsoft Authenticator!

2. MFA Authenticator App

When you require MFA, the Microsoft Authenticator App is what you need. Configuring the password-less option and the possibility of signing in with your phone will greatly enhance the user experience.

So why not use the Authenticator App to log on to your Windows device? Luckily, this functionality has been available for some time.

What’s new in Windows 10, version 1809 – What’s new in Windows | Microsoft Docs

By now, everyone has already upgraded their Windows device to a higher release… (I hope so). But when this feature was released, there were definitely some important notes…

It’s very weird that I can not find any up-to-date information about this, except for another warning when you want to configure the corresponding CSP.

That’s great, the same warning. I’m done with all the warnings; let’s see how they work, and if they work. One thing I learned for sure is that it depends on whether you have an existing WHFB-enrolled device or a clean-enrolled device. I will show you my experience with my existing Windows 10/11 device when I wanted to log in with the Microsoft Authenticator app

3. Requiring Web Sign-in

When you want to log in using the Microsoft Authenticator app, you must enable/configure the Web Sign-in provider. Let me briefly sum up what I did to get this working properly and also some other information:

  1. Conditional Access / Require MFA
  2. Enable Microsoft Authenticator Password Less and Phone Sign-in
  3. Enable web sign in with a CSP or Settings Catalog
  4. Force web login to be the first credential provider
  5. Disable Hello with a device configuration policy
  6. Remove OLD Windows Hello credential container
  7. Disable post logon hello provisioning
  8. The results
  9. Don’t display LastloggedonUser
  10. The MFA App Cons (SSO?)
  11. The Password issue

1. Conditional Access

This one is obvious, you will need to require MFA when you want to access Microsoft 365 data from your desktop apps or browser.

2. Enable Password Less / Phone Sign In

To give your end-users a great user experience when signing in by using the Microsoft Authenticator app, you may want to enable passwordless sign-in to increase the user experience and adoption! Some time ago I wrote a blog about this.

Back to the passwordless sign in. – Call4Cloud

3. Enable the Web Sign in

Let’s go forth and start enabling the web sign-in. To do so, I created the two CSPs, as Microsoft was showing in their documentation. One to enable the Web Sign-in Option: ./Device/Vendor/MSFT/Policy/Config/Authentication/EnableWebSignIn

configuring the web-sign in provider with a csp

And one to configure the Preferred AAD Tenant DomainName: ./Device/Vendor/MSFT/Policy/Config/Authentication/PreferredAadTenantDomainName

If you don’t like configuring the custom CSP because it lacks good reporting, just configure it in the Settings Catalog, as this is the preferred way to go nowadays!

4. Force Web Sign in to be the default

Configuring the CSP or Settings Catalog only activates the web sign-in option, but I wanted this option to be the default option, so I started by creating this PowerShell script.

$registryPath =  "HKLM:\Software\Policies\Microsoft\Windows\System"
$Name = "DefaultCredentialProvider"
$value = "{C5D7540A-CD51-453B-B22B-05305BA03F07}"
IF(!(Test-Path $registryPath))
{
New-Item -Path $registryPath -Force | Out-Null
New-ItemProperty -Path $registryPath -Name $name -Value $value `
-Force | Out-Null}
ELSE {

New-ItemProperty -Path $registryPath -Name $name -Value $value `
-Force | Out-Null}

Again… just like with enabling the web sign-in, we can also configure the default credential provider with a nice new addition to the settings catalog: “Assign a default credential provider

configuring the web sign-in provider as default provder by configuring the C5D7540A-CD51-453B-B22B-05305BA03F07 as default credential provider

In the example above, I configured the Web Sign as the default provider but please beware of the fact that the default credential provider ONLY applies when you select “Other User”.

Let me tell you why and how to make sure it also applies to the default login

5. Disable WHfB

When using WHfB, the Cloud Experience Credential Provider {C5D7540A-CD51-453B-B22B-05305BA03F07} will not be the default sign-in option. WHfB will still be in command!

To test it further, I disabled WHfB with an Identity protection device configuration profile and made sure WHfB wasn’t enabled by default.

Of course, you also need to ensure Windows Hello isn’t enabled in the tenant-wide Windows Hello for Business Windows Enrollment settings. You will need to set it to DISABLED!! Configuring it to not be configured is not sufficient to disable it!

6. Remove the old Hello creds

Unfortunately, this was not sufficient, when you want to configure the web sign as the default credential provider on existing devices with Windows Hello already configured you also need to remove the existing Windows Hello credential container. To do so you will need to run this command in the user session itself:

certutil /deletehellocontainer  

If you want to deploy this to all devices, you could create a simple PowerShell script that targets the login user and removes the hello container.

7. Disable Post Logon Provision

To be sure WHfB does not have the urge to say “hello” again after the user login, I also created this script to disable post-logon hello provisioning.

$registryPath =  "HKLM:\Software\Policies\Microsoft\PassportForWork"
$Name = "DisablePostLogonProvisioning"
$value = "1"
IF(!(Test-Path $registryPath))
{
New-Item -Path $registryPath -Force | Out-Null
New-ItemProperty -Path $registryPath -Name $name -type "dword" -Value $value `
-Force | Out-Null}
ELSE {
New-ItemProperty -Path $registryPath -Name $name -type "dword"  -Value $value `
-Force | Out-Null}

You could also use a CSP if you don’t want to use PowerShell. A small side note: Windows Insider Preview only!

disablepostlogonprovisioning csp

8. The Result

After some hard work and configuring a bit more policies than anticipated, here are the results:

The sign-in screen shows us only the option to click on sign-in (or sign-in options..)

It immediately asks to “send a notification”

After pressing the correct number on my phone, Windows logged in without any problems. If you ask me… this is 100% MFA.

9. Don’t display the last logged-on user

When you think you are done and could get yourself a nice beer, I noticed that sometimes, when logging in, the password becomes the default provider again. I resolved it by configuring the: dontdisplaylastusername to 1 instead of 0

10. The MFA App Cons

But what about the cons? There must be some. Let’s start with an easy one. You will need to have internet access. Without Internet access, nothing will happen. However, working without Internet Access with the Microsoft 365 apps can be difficult. When you try to sign in without Internet Access, you will be prompted with a warning.

Also, requiring only this web sign-in option may not be the best practice, like the Break Glass account. You will need to have an additional sign-in option. And here comes the pain: You still can log in the old-school way, with your password, right?

11. Password Credential Provider

From the Hello deep dive to Web Sign in to the Password problem. To dig a little bit deeper into the password credential provider. When you want to remove this option, be my guest but I am not recommending it (for now…). Because when you disable or remove the credential provider from the login screen you are also disabling the possibility to enter a password when you want to: Run As / Run as admin / UAC prompts

Not having the possibility to use the run as an option, could give you a lot of problems when you want to run something as admin when a user has problems on his Windows device. If you want to disable it, you can do this by creating a new registry key: Disabled

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{60b78e88-ead8-445c-9cfd-0b87f74ea6cd}

Luckily, Microsoft came up with a way better option because disabling the password credential provider is maybe a bit too much! We now can configure the PasswordLess experience.

Enable Password Less Experience

It’s good to know that it doesn’t prevent a user from signing in with a password when selecting the “Other user” option in the lock screen. Besides still having the option to log in with a password in case of emergency, it doesn’t impact the “Run As,” as I showed you first! I love it!!

Conclusions:

One thing is for sure, you need MFA when logging into your Windows device. Requiring WHfB is a perfect start but only requiring a PIN is maybe to best solution. In my opinion, going passwordless and using the Authenticator App to log in is the best thing you can do!

3 thoughts on “Battle for the Planet of the Web Sign-in Provider

  1. Nice article, thanks.

    You maybe interested into the “note” regarding the upcoming “cloud trust” feature of WhfB within this article:
    https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-overview

    “Windows Hello for Business is introducing a new trust model called cloud trust in early 2022. This trust model will enable deployment of Windows Hello for Business using the infrastructure introduced for supporting security key sign-in on Hybrid Azure AD joined devices and on-premises resource access on Azure AD Joined devices. More information will be available on Windows Hello for Business cloud trust once it is generally available.”

    I guess, once available this will finally solve your problem.

  2. I think this is a very nice functionality. Thanks for your explanation! I have configured it in my lab environment. However, I find a downside: it does not seem possible to make MFA mandatory with this web sign-in. When a user has set up Passwordless authentication in the authenticator app, they receive a notification on their phone. But if this is not the case, users can log into Windows with just a username and password. Once in Windows, they are then faced with MFA notifications for OneDrive, Teams, Outlook, and Edge. This is not the desired result in my situation.

    After some research, I see that the normal MFA policy with “All cloud apps” does not affect this web sign-in. With a conditional access policy scoped on the user action of device registration, the login acknowledges the CA policy but it is not applied. Am I doing something wrong, or is this an inherent downside to web sign-in?

Leave a Reply

Your email address will not be published. Required fields are marked *

5  +  5  =  

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.