Solving On-Premise Access Issues with Azure AD Devices

Last Updated: 10/07/2025 [go to update]

So, todays head scratcher… a user with an EntraID Joined only device iis having connectivity issues. They can connect to M365 Apps for Enterprise (aka Outlook, Excel, Word etc), SharePoint online and other SaaS platforms.

What they cannot access is any of the on-premise resources. Stuff like our support portal, Citrix web portal and as for mapped network drives. Nope, nada, not a chance.

So where do you start looking with something like this? well… lets check the simple things

Cached Passwords?
❌ Nope, none there
VPN connected?
✅ Yes, authenticated and connected
Access to cloud and online resources?
✅ Yup, thats all good
Access network drive?
❌ nope – this errors:

An error occurred reconnecting Microsoft Windows network: Account restrictions are preventing this user from signing in

Ok, something to go and check. Off to Active Directory we go. Checked the following on the user account:

✅Logon Hours – All looking ok
✅Logon to – set correctly, all devices
✅Account enabled- yup all ok
✅Account locked out – nope, account is all ok

So that checks the user account. Checking Intune for the device and:

✅Its compliant
✅Sync recently

OK, so both account in AD and Entra are looking good, and the device is as well. mmmm. Lets do some more checking on the device.

✅VPN still connected
✅Lets try a PING to the Domain Controller and random on premise server
Yeap. That works and the response is ok as well.
✅Lets check the join status – running dsregcmd /status shows us

+———————————————————————-+
| Device State |
+———————————————————————-+
AzureAdJoined : YES
EnterpriseJoined : NO

Thats looking correct.
+———————————————————————-+
| SSO State |
+———————————————————————-+
AzureAdPrt : YES

and so is that all ok. Lets check the rest of the output and see whats good and not so good
✅ What’s Working

Component
Status
Notes
Azure AD Join
✅ AzureAdJoined: YES
Device is properly joined to Azure AD.
Device Certificate
✅ Valid until 2035
Device has a valid certificate and TPM protection.
Azure AD Primary Refresh Token (PRT)
✅ AzureAdPrt: YES
SSO is functioning with Azure AD.
Cloud TGT
✅ CloudTgt: YES
Indicates cloud-based Kerberos ticketing is available.
On-Prem TGT
✅ OnPremTgt: YES
Suggests hybrid access is working.
Ngc Prerequisite Check
✅ PreReqResult: WillProvision
Device is eligible for WHfB provisioning.

⚠️ What’s Missing or Misconfigured
Issue
Details
Impact
WHfB Not Set Up
NgcSet: NO
WHfB (PIN or biometric) is not provisioned. This is often required for Cloud Kerberos Trust.
Workplace Join
WorkplaceJoined: NO
This is expected for Azure AD joined devices, but if you’re troubleshooting hybrid scenarios, it might be relevant.
CertEnrollment
none
No certificate enrollment method is configured. If you’re using certificate-based WHfB, this could be a blocker.
Verify Intune configuration applied to device.
Yup. looking all good

So everything so far is looking good. Can only be something wrong with Kerberos or theres an NTLM issue. Lets carry on digging into this

Lets run a check to verify if the device has a kerberos token:

c:\> klist
Current LogonId is 0:0x1234560

Cached Tickets: (0)

❌Hmm, odd its not managed to obtain a Kerberos token, which means it does have the rights to speak via the Cloud Kerberos Trust. Onto something now.

We know its not a major issue with Cloud Kerberos Trust as we only have one affected user. First and easy thing, is the clock in sync? yup, its matching the Domain controllers and my device. Cool. not a time issue then! Phew!

As our next step, lets run the Cloud Kerberos Trust debug tool

c:\> klist cloud_debug

Current LogonId is 0:0x123abc
Cloud Kerberos Debug info:
Cloud Kerberos enabled by policy: 0
AS_REP callback received: 1
AS_REP callback used: 0
Cloud Referral TGT present in cache: 0
SPN oracle configured: 0
KDC proxy present in cache: 0
Public Key Credential Present: 0
Password-derived Keys Present: 1
Plaintext Password Present: 1
AS_REP Credential Type: 0
Cloud Primary (Hybrid logon) TGT available: 1

Lets analyse this output:

Field	Value	Meaning
Cloud Kerberos enabled by policy	`0`	❌ Cloud Kerberos Trust is not enabled via policy. *This is a key issue.*
AS_REP callback received	`1`	✅ The system received a response from the KDC.
AS_REP callback used	`0`	❌ The response was not used, possibly due to a mismatch or policy issue.
Cloud Referral TGT present in cache	`0`	❌ No referral TGT from Azure AD is cached. This suggests the cloud trust path is not functioning.
SPN oracle configured	`0`	⚠️ Not configured. This is optional but may affect service ticket resolution.
KDC proxy present in cache	`0`	⚠️ No KDC proxy is being used. This is expected unless you’re using hybrid scenarios with KDC proxy.
Public Key Credential Present	`0`	⚠️ No WHfB key is present. This is fine if you’re using password-based auth.
Password-derived Keys Present	`1`	✅ Password-based authentication is available.
Plaintext Password Present	`1`	✅ The plaintext password is available (e.g., from a recent login).
AS_REP Credential Type	`0`	ℹ️ Indicates the type of credential used; `0` typically means password.
Cloud Primary (Hybrid logon) TGT available	`1`	✅ A hybrid logon TGT is available, so the user is logged in with a hybrid identity.

So, from the debugging, it would appear that the device has not had Cloud Kerberos trust enabled by our Intune policy. Odd, Intune said it had!

Things we’ll need to check on the device in the morning:

Event Viewer > Applications and Services Logs > Microsoft > Windows > HelloForBusiness > Operational
- Event ID 300 – WHfB provisioning started
- Event ID 301 – WHfB provisioning succeeded
- Event ID 304 – WHfB provisioning failed
- Event ID 400 – Key registration with Azure AD failed
- Event ID 401 – Key registration with Azure AD succeeded
Event Viewer > Applications and Services Logs > Microsoft > Windows > Kerberos-Key-Distribution-Center > Operational
- Event ID 4768 – A Kerberos authentication ticket (TGT) was requested
- Event ID 4769 – A Kerberos service ticket was requested
- Event ID 4771 – Kerberos pre-authentication failed
- Event ID 4776 – Credential validation failed (NTLM fallback or password issues)

I also just verified DNS, because some things are DNS related. Running

ipconfig /all

the output showed that IPv6 was running. Now we have had issues in the past with IPv6, so that got disabled to rule that out.

User will shutdown tonight and we’ll carry on the debugging tomorrow. And just for fun, we’ve also logged a call with Microsoft Premier Support. Lets see how we get on.

What else will we look at along with the event logs. Well:

dsregcmd /refreshprt to see if we can refresh the Azure AD Primary Refresh Token (PRT) on a Windows device.
Attempt to re-setup WHfB

I’ll update this post with more information and troubleshooting, and how it was eventually fixed as the case goes along.

Update 10/07/2025

So, reviewing things the next morning and discussing with Microsoft, we kind of got to the point where the account authorisation was being blocked from somewhere, as when we deployed a new machine the issue followed to it. That ruled out the machine.

Decided to take a step back and lets look at our users history in our IT Support portal system and see what tickets they have logged previously.

And its here in the history we find something. It looks like this user had lost a device which then triggered the teams lost process to kick in, which includes isolating the account by ring fencing it, and getting the account disabled. This is our security processes to secure the identity whilst the hardware was investigated.

It appears that the hardware was found again which allowed the account to be re-enabled. However, speaking to our SOC, the account was still ringfenced. This mean the account was operating at a lower level but preventing access to everything and anything. A few minutes later, and a quick chat with our SOC to confirm the account is ok and the hardware is known, the account was removed from the ring fence and within 5 minutes we had full access back to the user account.

The lesson here? Take a look at the history of people and hardware before launching deep into the technical details. Sometimes, just sometimes, it is the more obvious and often overlooked root cause that is causing the issue.