Windows Hello for Business Issues

Question

I have an in-production WH configuration in Intune that works very well, my unlock factors work as expected and no problems.

We have some shared devices that do not access PII that we are not able to utilize WH MFA on since they're shared, so I'm trying to set up Trusted Signal for the IP address. This worked fine when the machines were domain joined, but since moving this over to Intune it has not worked.

First here is my configuration:

Digits: ``Allows the use of digits in PIN.
Group A: {D6886603-9D2F-4EB2-B667-1971041FA96B}
Group B: {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}
Device Unlock Plugins: 10.80.80.0/24

After setting this up (tried doing this both through the settings catalog, and a custom OMA-URI), I verified the registry entries on the machine after forcing a sync using gci HKLM:\SOFTWARE\Microsoft\Policies\PassportForWork\ | select -index 1 and that returned:

Name Property
---- --------
DeviceUnlock GroupA : {D6886603-9D2F-4EB2-B667-1971041FA96B}

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

Plugins :

10.80.80.0/24

When signing in utilizing the pin, we are receiving "Your organization requires one more step" and shortly after receive "Couldn't verify additional factor. Please use a different sign-in option.". Just because it might be asked, yes we have verified the device is inside the 10.80.80.0/24 subnet and does not have any other connected interfaces.

Going through event viewer in Applications and Services > Microsoft > Windows > HelloForBusiness, we are seeing 4 different entries happening within the same second:

---Entry 1---
Event ID: 5002
Level: Information
A user is signing into the device with the following gesture information:
Type: Invalid
Subtype: No Bio

---Entry 2---
Event ID: 3520
Level: Information
Attempting multi-factor unlock using provider {D6886603-9D2F-4EB2-B667-1971041FA96B}. The list of acceptable providers are:
Group A: {D6886603-9D2F-4EB2-B667-1971041FA96B}
Group B: {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}

---Event 3---
Event ID: 8520
Level: Success
Successfully authenticated the user's credential.
Processing time: 71 milliseconds.

---Event 4---
Event ID: 5001
Level: Information
A user signed into the device with the following information:
Username: SYSTEM
User SID: SYSTEM
Credential Type: Software Key
Deployment Type: Certificate Trust

Also in Event Viewer under Windows Logs > Security, we are seeing at that same second 4 entries:

---Event 1---
Event ID: 5059
Level: Audit Success
Key migration operation.
Subject:
Security ID: LOCAL SERVICE
Account Name: LOCAL SERVICE
Account Domain: NT AUTHORITY
Logon ID: 0x3E5
Process Information:
Process ID: 2952
Process Creation Time: ‎2025‎-‎01‎-‎17T15:41:41.824962600Z
Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: RSA
Key Name: {REDACTED}
Key Type: User key.
Additional Information:
Operation: Export of persistent cryptographic key.
Return Code: 0x0

---Event 2---
Event ID: 5059
Level: Audit Success
Key migration operation.
Subject:
Security ID: LOCAL SERVICE
Account Name: LOCAL SERVICE
Account Domain: NT AUTHORITY
Logon ID: 0x3E5
Process Information:
Process ID: 2952
Process Creation Time: ‎2025‎-‎01‎-‎17T15:41:41.824962600Z
Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: RSA
Key Name: {REDACTED}
Key Type: User key.
Additional Information:
Operation: Export of persistent cryptographic key.
Return Code: 0x0

---Event 3---
Event ID: 4648
Level: Audit Success
A logon was attempted using explicit credentials.
Subject:
Security ID: SYSTEM
Account Name: REDACTED-REDACTED$
Account Domain: WORKGROUP
Logon ID: 0x3E7
Logon GUID: {00000000-0000-0000-0000-000000000000}
Account Whose Credentials Were Used:
Account Name: redacted@redacted.com
Account Domain: AzureAD
Logon GUID: {00000000-0000-0000-0000-000000000000}
Target Server:
Target Server Name: localhost
Additional Information: localhost
Process Information:
Process ID: 0xae0
Process Name: C:\Windows\System32\LogonUI.exe
Network Information:
Network Address: -
Port: -
This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.

---Event 4---
Event ID: 4624
Level: Audit Success
An account was successfully logged on.
Subject:
Security ID: SYSTEM
Account Name: REDACTED-REDACTED$
Account Domain: WORKGROUP
Logon ID: 0x3E7
Logon Information:
Logon Type: 11
Restricted Admin Mode: -
Remote Credential Guard: -
Virtual Account: No
Elevated Token: No
Impersonation Level: Impersonation
New Logon:
Security ID: AzureAD\REDACTED
Account Name: redacted@redacted.com
Account Domain: AzureAD
Logon ID: 0x30B1400
Linked Logon ID: 0x0
Network Account Name: -
Network Account Domain: -
Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID: 0xae0
Process Name: C:\Windows\System32\LogonUI.exe
Network Information:
Workstation Name: REDACTED-REDACTED
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: 2FA
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

Not sure how else to troubleshoot this issue, since the provider it's using is there, and the trusted signal is in Group B, but it looks like it is not attempting trusted signal to me. Also a bit confused on the "audit success" unless that's just the pin and not the trusted signal, I see "Network Information" is blank in that event, but we verified the device is connected during the login process. We've also tried this both on fresh reboot, and on computer lock, get the same results either way we try it.

Any recommendations or help?

TIA!

Answer

@Nate Breeden, Thanks for posting in Q&A.

Form the information you provided, it seems that the policy has successfully applied, but it failed for some reasons, I have done some research about the issue, but there is not much information I can find, it is suggested that you open an online case to get more help.

https://learn.microsoft.com/en-us/mem/get-support

Thanks for your understanding.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer

UPDATE: the issue was my signal rule, the subnet I had in there was too large.

During our migration we are having to deal with a lot of subnets, while moving them to a more organized subnet range, so our rule was temporarily set to 10.1.0.0/10. After talking with support we changed the signal to the actual subnet the device was on which worked.

Doing some more testing afterwards, trusted signal will not recognize a subnet range lower that /16 (so for example, 10.80.0.0/16 will work, but 10.80.0.0/15 will not).

Hope this helps someone down the road.

Answer

UPDATE: the issue was my signal rule, the subnet I had in there was too large.

During our migration we are having to deal with a lot of subnets, while moving them to a more organized subnet range, so our rule was temporarily set to 10.1.0.0/10. After talking with support we changed the signal to the actual subnet the device was on which worked.

Doing some more testing afterwards, trusted signal will not recognize a subnet range lower that /16 (so for example, 10.80.0.0/16 will work, but 10.80.0.0/15 will not).

Hope this helps someone down the road.

Share via

Windows Hello for Business Issues

3 answers

Your answer