Hybrid to Entra ID WiFi Certificate Authentication NPS via WHfB Cloud Trust & Cloud PKI-Replace ADCS
Hello Team, We are working in moving our devices Hybrid Entra ID Joined to Intune autopilot Entra ID Joined Current scenario: Hybrid Entra ID Joined devices (joined to both on-prem AD and Entra ID) Active Directory with Entra ID Connect for object synchronization AD Certificate Services (ADCS) issuing user and device certificates via GPO auto-enrollment Group Policies to push Wi-Fi configuration (EAP-TLS using device certificate) NPS RADIUS server using EAP-TLS ("Smart Card or Other Certificate") for secure 802.1X authentication On-prem SSO enabled through standard Kerberos authentication Now, I am testing Autopilot Win11 Entra ID Joined with WHfB using Cloud trust to SSO to on-prem resources. The autopilot is working, however, the WIFI is not working as the autopilot device doesn't have any certificate from the on-prem ADCS. What is the best practice to try be as much cloud and begin to decommision on-prem services. I have 2 options to push the User and computer certificate to the AUtopilot device: Option 1: Intune Certificate Connector that will bridge on-prem ADCS and Intune, In Intune a PKCS profile to install the certificate to the autopilot device. Option 2: Intune Cloud PKI and configuration profile PKCS profile to install the certificate to the autopilot device. on-prem install the root CA from the Intune cloud PKI. https://learn.microsoft.com/en-us/intune/intune-service/protect/microsoft-cloud-pki-deployment For the on-prem SSO I will contine using Cloud Trust. Component Target Device Identity Autopilot + Entra ID Joined only (no domain join) User Sign-In Windows Hello for Business (WHfB) with Cloud Kerberos Trust Certificate Issuance Replace ADCS/GPO with Microsoft Cloud PKI and Intune PKCS Wi-Fi Authentication Retain existing NPS RADIUS using EAP-TLS, but trust both ADCS and Cloud PKI root CAs On-prem SSO Enabled by AzureADKerberos on domain controllers Hybrid Devices Continue current operation during the transition — no immediate impact The 2 network environment needs to coexist: the on-prem and the cloud. Device Type Certificate Issuer Wi-Fi Auth SSO Hybrid AD-joined ADCS via GPO EAP-TLS (device cert) Native Kerberos Autopilot Entra ID Joined Cloud PKI via Intune EAP-TLS (device cert) WHfB + Cloud Trust (AzureADKerberos) How the New Wi-Fi Auth Works: Autopilot devices receive: A device certificate from Cloud PKI via Intune A Wi-Fi profile using EAP-TLS authentication NPS RADIUS server: Validates the device cert Issues access to Wi-Fi WHfB Cloud Trust provides a Kerberos ticket from AzureADKerberos, enabling seamless access to file shares, print servers, etc. This allows Autopilot Entra ID Joined devices to: Connect to Wi-Fi without GPO Access on-prem resources without passwords High-Level Implementation Steps Deploy Microsoft Cloud PKI in Intune Configure PKCS profiles for user and device certificates Deploy WHfB Cloud Trust via Intune + Entra ID (no AD join needed) Configure AzureADKerberos on domain controllers Install Cloud PKI Root CA in NPS server trust store Update NPS policy to accept certificates from both ADCS and Cloud PKI Deploy Wi-Fi profiles to Autopilot devices via Intune (EAP-TLS using device cert) Based on it, what is the best practice to move the device to the cloud as much possible.
Excluding Windows Hello for Business (WHfB) for Windows 10 using Intune assignment filter
Good morning, I'm experiencing a persistent issue with applying an exclusion policy for Windows Hello for Business (WHfB) on Windows 10 devices (actually a testing VM) managed through Microsoft Intune. Despite configuring the assignment filter and verifying its correct evaluation in Intune, Windows 10 devices continue to allow WHfB PIN creation, and the option to remove the PIN is disabled. Scenario and objective: My goal is to enable Windows Hello for Business for all users except when they log in from a Windows 10 device (already enrolled in Intune). Therefore, the intention is to disable WHfB specifically for Windows 10 devices. Current configuration: WHfB policy: I have a device configuration profile named “WHfB” (Platform: Windows) which enables Windows Hello for Business. Policy assignment: This policy is assigned to a “WHfB Dynamic Group” that contains users with the “manager” attribute. Assignment filter (exclusion): I created and applied an assignment filter named “Windows 10 Device Filter” to the policy mentioned above. Filter mode: Exclude. Filter definition: (device.osVersion -contains "10.0.1") Observed behavior: Filter evaluation in Intune (as shown in the previously provided screenshot): For the problematic Windows 10 device, in the “Filter Evaluation” section of the “WHfB” policy, the “Windows 10 Device Filter” shows “Evaluation Result: Match” and “Mode: Exclude.” The message states “Policy not delivered.” This confirms that the filter is working correctly in Intune and that the WHfB policy is not applied to the Windows 10 device. Behavior on the Windows 10 device: Despite the exclusion, the user (AdeleV) can still modify and use the WHfB PIN. The “Remove” PIN option is disabled (greyed out) in sign-in options. Windows Event Logs (HelloForBusiness/Operational): The log displays several errors (Event IDs 7054, 8203, 7204) and informational events (8210, 8200, 8202, 5060 “PIN required”). Event 7054 specifically indicates error 0x1 (or 0x80000000000000001), which is a generic error. Troubleshooting steps performed: Forced sync and restarts: executed multiple times on the Windows 10 device. Sync status in Intune for the “WHfB” policy sometimes shows “Unavailable,” but filter evaluation is always “Match/Exclude.” OS version verification: The OS version on the device (10.0.19045.3803) confirms that the string “10.0.1” is contained, so the filter syntax is correct. Policy conflict search: I reviewed the device’s configuration profiles and compliance policies applied via Intune, but didn’t identify any obvious conflicts or other policies that explicitly enable WHfB. Question: Given that my WHfB exclusion filter works correctly, but WHfB is still enabled on the Windows 10 device (and the PIN can’t be removed, with a generic error in the log), what could be the root cause?
WHFB non destructive PIN
Hello, I've configured Windows Hello for Business and applied the Non-Destructive PIN Reset policy via Intune. However, after resetting the PIN, when I run dscmdreg /status in the User State, it still shows DestructiveOnly. Additionally, Event Viewer logs Event ID 7060 – PIN Recovery Error 0x83750007. Could you please help me troubleshoot this?
Windows Hello for Business - Multi-Factor Unlock - Wireless Trusted Signal WPA3
I have been experimenting with WiFi trusted signal for Windows Hello for Business due to an issue that appears to have popped up after changing access point security to WPA3. I cannot seem to get the trusted signal configuration XML to properly validate the wireless trusted signal when WPA3 is the security type (With security being a required property). It works fine on WPA2, but no syntax for WPA3 seems to work. The official KB article from Microsoft about multi-factor unlock/trusted signals only lists the following as options: Open The wireless network is an open network that doesn't require any authentication or encryption. WEP The wireless network is protected using Wired Equivalent Privacy. WPA-Personal The wireless network is protected using Wi-Fi Protected Access. WPA-Enterprise The wireless network is protected using Wi-Fi Protected Access-Enterprise. WPA2-Personal The wireless network is protected using Wi-Fi Protected Access 2, which typically uses a pre-shared key. WPA2-Enterprise The wireless network is protected using Wi-Fi Protected Access 2-Enterprise. Just worried this may just be straight up incompatible. Has anyone had luck using WPA3 for WHfB with wireless as a trusted signal?
Azure AD Joined device is not honoring Windows Hello for Business Config Policy from Intune
With the availability of Cloud Kerberos Trust we are now able to deploy WHfB to our Hybrid workforce but we do have a handful of Azure AD Joined devices that we also need to deploy to, all of these devices are enrolled in Intune and our user accounts are all on-prem AD and synced to Azure. When I configured the WHfB policy using the Settings Catalog Configuration Profile and apply it to our test devices, the hybrid one works great - it obtains the settings and I can see the updates to the registry and the Windows UI reflects these settings in the WHfB setup - for example, the PIN Complexity settings were set to minimum 4 and allowed all characters, symbols, etc. However when I applied the same policy to an Azure AD Joined device, the device received the settings, made the registry changes, yet when configuring the PIN, the requirements shown on screen were not what was set in the policy. I tried changing some settings in the policy to see if the updated registry settings would affect the Windows UI but still nothing. Where could this setting be getting overwritten from or, does an AADJ device with an on-prem synced user account need to have the WHfB config set a certain way? We are not making any settings using the other methods of configuring WHfB such as Enrollment, Identity Protection Templace, Account Protection (Endpoint Security) and on-prem Group Policy cannot set WHfB policies on user accounts, only devices so this doesn't apply as it's AADJ. You can see the settings that are applied in the policy and what's reflected in the registry and then what the UI says when setting a PIN.
Allow users to choose how they sign in
Hello, I don't find the option "Allow users to choose how they sign in" to allow users to choose between using Windows Hello for Business or a traditional password to log in. Is it no longer supported? Or how can I just enable the Windows Hello for Business and not by force? Thank you in advance.
Windows Hello for Business implementation
Hi, For a couple of days now we've introduced Windows Hello for Business (WHfB) to a subset of test devices from within Intune. Everything works as expected except for one thing I guess: When someone tries to logon with a non-enterprise account (eg. @live.nl) in Teams, and/or Onedrive, the machine is prompting to authenticate with WHfB. Am I missing something? Why is this happening and how can we prevent this? Any thoughts are welcome.
