Enforcing Passwordless Logins with AADJ Windows 10 and Endpoint Manager (Intune)

In the last blog post, we enabled FIDO2 security key logins with Windows 10 on our AADJ Windows machines, but users are still able to login with username/password. What if we want to enforce a FIDO2 Security Key or Windows Hello for Business login?

 

Assumptions for this blog post:

 

  • Client is pure Azure AD
  • Client’s Windows 10 machines are Azure AD Joined (AADJ)
  • Client’s Windows 10 machines are managed by Microsoft Endpoint Manager (Intune)
  • You have completed the steps from previous blog post to enable FIDO2 Security Key logins to Azure AD
  • You have enabled Windows Hello for Business device configuration profile (optional for section at end)

 

Enforce Smartcard Login Setting

Let’s start with a simple PowerShell script deployed with MEM to enforce a smartcard login. This will essentially allow Windows Hello Face or PIN, Smart Card, or FIDO2 Security Key logins only.

 

Create a new .ps1 file with the following:

 

# Deploy Registry Settings with Intune

 

$Path = “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System”

$Name = “scforceoption”

$Value = “1”

 

If(!(Test-Path $Path))

{

New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType DWORD -Force | Out-Null}

Else {

New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType DWORD -Force | Out-Null}

 

Open MEM and browse to the PowerShell Scripts pane: https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesMenu/powershell

 

Click Add+, then Windows 10:

 

Give the script a name, then upload the PS1 file with run script in 64-bit PowerShell Host option:

 

Assign the script to your test machines or test user groups. Remember, if you don’t reboot or start/stop the Microsoft Intune Management Extension service, then it could take up to an hour for the script to run on your test machines.

 

Now, let’s look at the results for the user in the UI:

 

The user can still attempt an username/password login that will authenticate against Azure AD or cached credentials, but will be stopped before they reach the desktop with the message:

 

You must use Windows Hello or a smart card to sign in.

 

 

This achieves our original desired result of not allowing username/password logins, but let’s make it cleaner in the next step.

 

**Note: Keep in mind that using this setting will create problems if you need to run a file or application as another user interactively on the desktop. Running as administrator still works fine.**

 

Remove Password Provider

We want to remove the icon for Username and Password login from our machine, so we have to remove the Password Provider authentication method. Again, when using AADJ machines, we don’t have GPOs to easily configure this setting, so this will mean deploying another PowerShell script with MEM.

 

Create a new .ps1 file with the following:

 

# Deploy Registry Settings with Intune

 

$Path = “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{60b78e88-ead8-445c-9cfd-0b87f74ea6cd}”

$Name = “Disabled”

$Value = “1”

 

If(!(Test-Path $Path))

{

New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType DWORD -Force | Out-Null}

Else {

New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType DWORD -Force | Out-Null}

 

Open MEM and browse to the PowerShell Scripts pane: https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesMenu/powershell

 

Click Add+, then Windows 10:

 

Give the script a name, then upload the PS1 file with run script in 64-bit PowerShell Host option:

 

Assign the script to your test machines or test user groups, then look at the UI change:

 

The final result is a more secure login experience to AADJ Windows 10 machines.

 

**Note: Keep in mind that using this setting will create problems if you need to run a file or application as another user interactively on the desktop. Running as administrator still works fine.**

 

Alternative to FIDO2 Security Key Login

If removing the password provider and forcing the user to use the FIDO2 Security Key or Windows Hello for Business PIN/Face is not meeting your client’s needs, you can also suggest multi-factor Windows Hello for Business unlock instead.

 

Unfortunately at the time of this post, the FIDO2 Security Key credential provider is not one of the providers supported by Microsoft for a Windows 10 multi-factor login. The following are still the ones supported and I can verify FIDO2 does not work. When used in Group A or Group B, the security key login will go straight to desktop without a prompt for an additional factor.

 

Supported credential providers:

Credential Provider

GUID

PIN

{D6886603-9D2F-4EB2-B667-1971041FA96B}

Fingerprint

{BEC09223-B018-416D-A0AC-523971B639F5}

Facial Recognition

{8AF662BF-65A0-4D0A-A540-A338A999D36F}

Trusted Signal

(Phone proximity, Network location)

{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}

 

To deploy WHfB multi-factor unlock, we will still be using the MEM portal, but instead of PowerShell, it will be a Custom Device Configuration Profile.

 

https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesMenu/configurationProfiles

 

Click + Create Profile and choose Windows 10, Custom.

Give it a descriptive name, then click Next.

Under OMA-URI Settings, click Add.

Enter the following values:

 

Name:

Windows Hello Multifactor Unlock – First Unlock Factor

OMA-URI:

./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/GroupA

Data Type:

String

Value:

{8AF662BF-65A0-4D0A-A540-A338A999D36F}, {BEC09223-B018-416D-A0AC-523971B639F5}, {D6886603-9D2F-4EB2-B667-1971041FA96B}

 

Click Add again to add a second setting.

 

Name:

Windows Hello Multifactor Unlock – Second Unlock Factor

OMA-URI:

./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/GroupB

Data Type:

String

Value:

{D6886603-9D2F-4EB2-B667-1971041FA96B}

 

Click Next, then Assign this policy to your test group of users or devices.

 

Now, let’s see how this is reflected on our Windows 10 machine for the user. Open Settings, Accounts, Sign-in Options:

Notice the organization requires multiple sign-in options yellow text saying a MEM policy is applying here.

 

Let’s take a look at the sign-in experience now:

In this example, the user signed in with Windows Hello Face, and then has enter the Windows Hello PIN before getting to the desktop.

 

**Note: if you do not remove the password provider or enforce smartcard like the two scenarios prior to this, the user can still login with username and password and bypass this. The same is true for FIDO2 Security Key login, it will bypass this policy.**

 

Final Thoughts

 

While it is nice that Microsoft evangelizes “Passwordless” authentications, all of the scenarios described in this blog series have caveats and removing the password provider often does more harm than good except in certain use-cases. If your client is looking for a more classic MFA Windows 10 login experience (think username/password + Authenticator App), then a third-party app like Duo is still required, which has a software adapter that is installed on the workstation.

 

Blog Post Written By:  Nick Krenek (Principal M365 Security Consultant at CloudServus)

Recent Blog

Blog Categories

Tags