I’ll start this post by saying I do not endorse disabling Windows Hello for Business. There are big benefits to using WHfB, and I recommend using it. But, different organizations have different desires. So, this post will describe how to remove Windows Hello as an authentication method on workstations. To clarify – how to remove it from devices where users have already configured a WHfB PIN to sign into their workstations. We’re looking at an existing functioning EIDJ/Intune environment where some users have WHfB PIN sign-in configured, and others are signing in with their password.
I’m sure if you’re reading this you already have at least a basic understanding of Windows Hello for Business, but if not, read this – Windows Hello for Business Overview – Windows Security | Microsoft Learn. By default, Windows Hello for business is “Not Configured” in Intune. Newly enrolled devices will prompt you to set up Windows Hello when you first sign in, but you can skip the setup if you’d like. Let’s take a quick look at ways to configure Windows Hello for Business in Intune before we start, and why these policies aren’t enough to remove WHfB as a sign-in option on devices where it’s already configured.
There are two primary ways to accomplish this with Intune. The first is under Devices > Enrollment > Windows Hello for Business.
This is a tenant-wide configuration that applies to all users/devices. I’ll probably make a future blog post on this specific configuration, but if you’re operating in an existing environment with Intune-enrolled devices, and this is set to the default of “Not Configured”, proceed with caution. Even if you change this to “Disabled”, then users who have already configured Windows Hello will have the requirements enforced – even though the policy is disabled. For example, if users voluntarily configured a 6-digit numeric PIN, and you change this to “Disabled”, you’ll see there are still options for pin length, letters, special characters, etc….. And those will apply to the users who already have WHfB configured PINs. It will result in user confusion and possibly chaos since they now have to change their PIN to something else. However, for anyone who did NOT have WHfB configured, changing this to disabled disallows them from setting it up. Confusing, right? So, be careful with this if there are existing devices in your environment.
The second option we have is to create an Endpoint Security Account Protection Policy. Here we can enforce the policy against a subset of users. You end up with the same options as the tenant-wide policy. The issue with this policy is, again, if users already have WHfB PINs configured on their devices, it does not remove it as a sign-in option. It simply blocks users from setting up WHfB if they don’t already have it configured.
How do we remove WHfB PIN sign-in for existing devices?
Step one, if we want to turn off Windows Hello and force everyone to sign in with their passwords, is to get one of the two previously mentioned policies in place. My personal preference in existing environments is the Endpoint Security policy to start, and then once we have a handle on everything, we can enforce the global enrollment policy. This at least prevents new users from setting up WHfB, but we still need to deal with the users who already have it configured.
When we enforce the Account Protection Profile to disable Windows Hello for Business, we can see it properly applying to the user in the registry. A value of 0 for UsePassportForWork means the user can’t configure WHfB as a sign-in method.
And it’s greyed out, and won’t allow us to change the PIN or remove the sign-in method:
BUT, we can still sign in with our PIN since we set this up before the account protection profile was applied. So we need to focus on how to do this at the device level, and then see if we can push it out with Intune.
After messing with the registry for a while and getting nowhere, I started searching elsewhere. I even tried editing the below registry value to 0, which disables all sign-in methods, but it still allowed me to sign in with both the existing PIN, and the account password.
It did totally grey out all other sign-in options. Neat, but didn’t solve the problem.
Some further searching online lead me to the directory “C:\windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc”. I found plenty of issues on the Microsoft forums where users weren’t able to reset their PIN, or had other issues with their PIN, such as it not being available. This directory stores the PIN and its dependent configuration files. Deleting this directory should result in the PIN being removed as a sign-in method. Remember that Windows Hello sign-in methods are tied specifically to that device. So, this will have no impact on any authentication methods outside of that device for the user.
However, even administrators don’t have access to this directory.
Once we take ownership and grant permissions, if you show hidden files and unhide protected operating system files, you’ll see a bunch of directories that make up the details for users who have set up Windows Hello for Business PIN:
Deleting the entire Ngc folder and then signing out would only allow me to sign back in with my password, and since we have the policy to block users from enrolling in WHfB, mission accomplished. I should note that an empty NGC directory is recreated after a reboot.
Pushing this with Intune
Now that we know how to remove PIN sign-in from existing devices, we can look at how to push this to all devices with Intune. For that, we have two scripts – One to detect if WHfB PIN data is configured on a device, and the other to take ownership of the NGC directory, change permissions, and then delete it. I like to use SetACL for this since I have used it in the past. For more information on using SetACL, see this reference guide (SetACL Command Line-Version (SetACL.exe) – Syntax and Description (helgeklein.com)). It was a huge help in my old role when we’d need to manually clean up inherited workstation AV software where we didn’t have removal passwords or access to the dashboard. Both scripts are below and available on my github.
Detection:
$ngc = get-childitem C:\windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc -ErrorAction SilentlyContinue
if ($ngc -ne $null) {
Write-output "WHfB PIN configured"
exit 1
}
else {
write-output "WHfB PIN not configured"
exit 0
}Remediation:
$path = "c:\temp"
$TempDir = Test-Path $path
If ($TempDir -eq $False) {
New-Item -ItemType Directory -Path C:\Temp -Force
}
else {
write-output "Temp Directory Already Exists"
}
Invoke-WebRequest -Uri "https://github.com/gnon17/MS-Cloud-Scripts/raw/main/SetACL.exe" -OutFile C:\Temp\SetACL.exe
C:\Temp\SetACL.exe -on "C:\windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc" -ot file -actn setowner -ownr "n:administrators"
C:\Temp\SetACL.exe -on "C:\windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc" -ot file -actn ace -ace "n:administrators;p:full" -actn rstchldrn -rst DACL
Remove-Item "C:\windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc" -recurse -force
Remove-Item $path\SetACL.exe -ForceI have the scripts named as if it’s a remediation, and I suggest that’s how you use it if you’re licensed for remediations. If you’re stuck with Business Premium or EM+S E3 licenses for Intune, we can’t use remediations. In that case, we use the poor man’s remediation, a Win32 app, which is what I had to do. Simply wrap the remediation file as your install file, and use the detection script as the custom detection rule, then deploy it to your devices:
Check the status in the Intune dashboard to verify the app is “installed” after removing the NGC folder. Or, open company portal on a device and verify the status:
So, if you really want to only have users sign in with their password. Create a profile that disabled Windows Hello for Business, and then for those existing devices out there already using WHfB, run the remediation script as a Win32 app or a remediation.