This is the companion to the WHfB Event ID Catalog. That post tells you what the events mean. This walkthrough shows you what to do when you have a problem in front of you — the actual command sequence, the real output, and the decision at each step. A user cannot sign in with Windows Hello. Event 360 is firing. The device is Hybrid Joined. Here is how you find the answer.
As the Event ID Catalog explains, WHfB logs to three separate places. The quickest way to see them together is a single Get-WinEvent query that covers all three:
Read the output and look for Event 360. It will be there at or just before the time the user reported the problem.
This is the single most important thing to understand before you do anything else, and it is the reason the Event ID Catalog calls it out specifically: Event 360 fires as a Warning, not an Error. Default Event Viewer filters hide it. Most SIEM rules miss it. If you are looking for a red event to explain why provisioning was blocked, you will not find one — because it never fires as an error.
The table view truncates the message. Run this to see the full prerequisite checklist:
The body lists every prerequisite with a Yes/No result. Scan each line. The first No is your diagnosis. In this case it was:
Everything else passed. This single condition — "User has logged on with Microsoft Entra credentials: No" — blocked provisioning. The session authenticated via Kerberos or NTLM rather than the Entra PRT path. The cause is almost always a PRT that failed to refresh before the logon.
Before digging into the PRT, confirm exactly what you are dealing with:
| AzureAdJoined | DomainJoined | Join type |
|---|---|---|
| YES | YES | Hybrid Joined — this walkthrough |
| YES | NO | Entra-only (Cloud Join) |
| NO | YES | On-premises only |
On a Hybrid Joined device, "User has logged on with Microsoft Entra credentials: No" means the session authenticated via Kerberos/NTLM rather than the Entra PRT path. The cause is almost always a PRT that could not refresh.
Run dsregcmd /status and look at the PRT section:
| Field | Healthy value | What a problem looks like |
|---|---|---|
AzureAdPrt | YES | NO — no PRT at all |
AzureAdPrtUpdateTime | Today or recent | Days old — stale, refresh failed |
AzureAdPrtExpiryTime | Future date/time | Past date — expired |
EnterprisePrt | YES | NO — on-premises SSO broken |
AzureAdPrtUpdateTime does not flush until the next interactive logon, even when the PRT IS refreshing. Verify by watching AzureAdPrtExpiryTime instead — if the expiry timestamp extends across successive dsregcmd /refreshprt runs, the PRT is refreshing correctly and the stale UpdateTime is just a display artefact.The AAD operational log holds the refresh failure with the exact error code. Run:
Look for error codes in the message body. The ones you are most likely to find on a Hybrid device:
| Error code | Meaning | What it points to |
|---|---|---|
| 0xc000023c | STATUS_NO_LOGON_SERVERS | No domain controller reachable |
| 0x80072ee7 | ERROR_WINHTTP_NAME_NOT_RESOLVED | DNS failure — no network at PRT refresh time |
| 0x8007054B | Cannot get domain name / DC registration data | DC not reachable, even on VPN |
| 0xCAA90022 | ADFS IWA endpoint not discoverable | WS-Trust probe failed — often noise if you use Okta/non-ADFS STS |
| 0xCAA9002B | WS-Trust MEX exchange failed | STS unreachable or Kerberos failed at STS |
If you see 0xc000023c and 0x80072ee7 together at the time of the Event 360, the device had no network when it tried to refresh the PRT. The session that followed had to authenticate via Kerberos/NTLM — triggering the 360.
logon.yourdomain.com/app/office365/.../sso/wsfed/active), you are not on ADFS.Connect to the corporate VPN, then:
Two outcomes:
- EnterprisePrt becomes YES — the VPN routes correctly to the domain controller. The problem was no network at logon time. Ensure devices are fully connected before the login screen appears.
- EnterprisePrt stays NO on VPN — the device still cannot reach a domain controller through the tunnel. Check the event log again for 0x8007054B ("Cannot get domain name"). If it is still firing on VPN, this is a network infrastructure issue: the VPN split-tunnel configuration is likely excluding the DC subnet IPs and DNS for the domain. This cannot be fixed locally — escalate to the network and DC teams.
EnterprisePrt: NO persists on VPN and 0x8007054B is still in the AAD event log, the VPN tunnel does not route traffic to the domain controller. The fix is a VPN routing change, not a device change. Collect the error output and raise it with the network team with three specific asks: (1) confirm DC subnet IPs are in the VPN routing table; (2) confirm internal DNS resolves the domain from within the VPN tunnel; (3) confirm UDP 88 (Kerberos) is not blocked between the VPN pool and DC subnet.Even when Event 360 is firing, WHfB may have successfully enrolled on a previous attempt. Check:
| Result | Meaning |
|---|---|
NgcSet: YES + a KeyId present | WHfB is enrolled — Event 5702 will confirm in the HelloForBusiness log |
NgcSet: NO | WHfB is not enrolled — provisioning never completed |
NgcSet: YES means the device has a WHfB key. The Event 360 is blocking re-provisioning on each logon, but the key from a previous successful enrolment is still valid. Once the PRT issue is fixed (DC reachable at logon time), Event 360 stops firing and the PIN works correctly. If NgcSet: NO, provisioning has never completed — fix the PRT issue first, then the PIN setup flow will appear automatically.
While the infrastructure issue is being investigated, a user who sees "Your credentials could not be verified" at the Windows Hello login screen can do the following:
- Ensure the device is connected to Wi-Fi or Ethernet before the login screen appears — not after.
- On the Windows Hello error screen, click OK and sign in with their password as a fallback.
- Once logged in, open an elevated Command Prompt and run:
dsregcmd /refreshprt - Sign out and sign back in — Windows Hello should authenticate correctly now that the PRT is fresh.
The diagnostic flow at a glance
dsregcmd /status → AzureAdPrt stale?
0xc000023c + 0x80072ee7 = no network at login time
dsregcmd /refreshprt → EnterprisePrt still NO?
0x8007054B still firing on VPN → DC subnet not routed through tunnel
Quick-reference: what to collect before escalating
If you need to raise this with a network team or Microsoft Support, collect the following from the affected device and paste it into the ticket:
Get-WHfBHybridDiagnostics.ps1 and Get-WHfBEventReport.ps1 are free and open source. Both scripts read event logs and device state only — no changes are made to the device. Download from the Imran76Awan/Daily-Tasks repository on GitHub.