Entra joined devices in Hybrid environment Auth issues to Azure File Shares with AD identity source

Question

Entra joined devices in Hybrid environment Auth issues to Azure File Shares with AD identity source

mpls 170

Greetings, we are beginning our journey to Entra only but are still in Hybrid mode. We are deploying new devices as Entra only and our user identies are still hybrid. We are using Entra Connect Sync to sync default properties in both directions. We have had Cloud Kerberos working for quite some time. No issues with any of the aforementioned infrastructure. We are noticing on our new Entra deployed Windows devices (Device Preparation Policy) that the users are having issues connecting to the Azure file Shares. Again the File shares are setup with AD DS as the identity source. The computer objects that control the auth to the Azure files shares are set to AES-256.

What we are seeing is that to connect to the Azure file shares the end users must manually enter their credentials as domain\username plus password. Their WHFB pin does not work. Their credentials entered as upn with password does not work.

These Entra joined devices can successfully auth with WHFB or upn to on prem file shares \fqdn\fileshare and \hostname\fileshare.

For these devices we have made sure that Cloud Kerberos Ticket Retrieval Enabled is set on these devices.

Jose Benjamin Solis Nolasco 12,281 Reputation points Volunteer Moderator

2026-07-31T20:33:39.2166667+00:00
Welcome to Microsoft Q&A,

Hello @mpls I hope you are doing well,

Since the Entra joined devices can successfully authenticate to on-premises SMB shares using Windows Hello for Business or UPN, while Azure Files requires manually entering domain\username and password, this appears more specific to the Kerberos authentication path used by Azure Files rather than a general AD DS or device authentication issue.

Because the Azure Files identity source is AD DS and Cloud Kerberos is already enabled, I would first verify whether the Entra joined device is obtaining and using the expected Kerberos ticket for the Azure Files storage account.

I would also verify the Cloud Kerberos configuration and Azure Files AD DS identity configuration rather than changing the user's permissions at this stage.

The most useful next diagnostic information would be the output of klist before and after attempting to access the

Because authentication to the on-premises SMB shares is working, I would avoid making broad changes to Entra Connect, WHfB, or AD DS until the Kerberos ticket path for Azure Files is confirmed.
mpls 170 Reputation points

2026-07-31T22:43:36.2466667+00:00
It seems our setup is not super typical but I think it's not totally unheard of as organizations migrate from hybrid to entra while using existing azure file shares.

Do you know for a situation like this if it is recommended to have these two items configured and enabled:

Cloud Kerberos Ticket Retrieval Enabled

Define host name-to-Kerberos realm mapping (for the Entra devices accessing AD DS identity based storage accounts do we need to realm map to OURDOMAIN.COM?

Klist on an Entra joined machine shows this for the AD DS identity based storage accounts. The server doesn't show the storage account

Server: krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: Unknown (-1) Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize Start Time: 7/31/2026 22:27:37 (local) End Time: 8/1/2026 8:27:37 (local) Renew Time: 8/7/2026 22:27:37 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x400 -> 0x400 Kdc Called: TicketSuppliedAtLogon

2 answers

Your answer

Jose Benjamin Solis Nolasco 12,281 Reputation points Volunteer Moderator

2026-07-31T20:33:39.2166667+00:00

Welcome to Microsoft Q&A,

Hello @mpls I hope you are doing well,

Since the Entra joined devices can successfully authenticate to on-premises SMB shares using Windows Hello for Business or UPN, while Azure Files requires manually entering domain\username and password, this appears more specific to the Kerberos authentication path used by Azure Files rather than a general AD DS or device authentication issue.

Because the Azure Files identity source is AD DS and Cloud Kerberos is already enabled, I would first verify whether the Entra joined device is obtaining and using the expected Kerberos ticket for the Azure Files storage account.

I would also verify the Cloud Kerberos configuration and Azure Files AD DS identity configuration rather than changing the user's permissions at this stage.

The most useful next diagnostic information would be the output of klist before and after attempting to access the

Because authentication to the on-premises SMB shares is working, I would avoid making broad changes to Entra Connect, WHfB, or AD DS until the Kerberos ticket path for Azure Files is confirmed.
mpls 170 Reputation points

2026-07-31T22:43:36.2466667+00:00

It seems our setup is not super typical but I think it's not totally unheard of as organizations migrate from hybrid to entra while using existing azure file shares.

Do you know for a situation like this if it is recommended to have these two items configured and enabled:

Cloud Kerberos Ticket Retrieval Enabled

Define host name-to-Kerberos realm mapping (for the Entra devices accessing AD DS identity based storage accounts do we need to realm map to OURDOMAIN.COM?

Klist on an Entra joined machine shows this for the AD DS identity based storage accounts. The server doesn't show the storage account

Server: krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: Unknown (-1) Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize Start Time: 7/31/2026 22:27:37 (local) End Time: 8/1/2026 8:27:37 (local) Renew Time: 8/7/2026 22:27:37 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x400 -> 0x400 Kdc Called: TicketSuppliedAtLogon

Answer 1

Okay on an Entra joined avd machine I am logged in with my hybrid identity that can definitely map these shares. When I try to map it prompts me to enter my security pin.

Here is one of the errors I am seeing. It is trying to use NTLMV2 instead of Kerberos

This machine attempted to authenticate to a remote resource via NTLM.

Process Information:

Process Name: SYSTEM

Process PID: 0x4

Client Information:

Username: username

Domain: UPPERCASEDOMAIN

Hostname: entrajoinedhost 

Sign-On Type: Single Sign-On

Target Information:

Target Machine: Untrusted

Target Domain: Untrusted

Target Resource: cifs/storageacct.file.core.windows.net

Target IP: 192.x.x.x

Target Network Name: storageacct.file.core.windows.net

NTLM Usage:

Reason ID: 6

Reason: The target name could not be resolved by Kerberos or other protocols.

NTLM Security:

Negotiated Flags: 0xE2888015

NTLM Version: NTLMv2

Session Key Status: Present

Channel Binding: Supported

Service Binding: cifs/storageacct.file.core.windows.net

MIC Status: Protected

AvFlags: 0x2

AvFlags String: MIC Provided

Answer 2

Marcin Policht 107.9K MVP Volunteer Moderator

The fact that users can access on-premises SMB shares using WHFB and Cloud Kerberos Trust implies that Cloud Kerberos itself is functioning correctly. The issue appears to be specific to Azure Files authentication rather than Kerberos in general.

Check which Kerberos ticket is being obtained. On an affected Entra-joined device, after the user signs in with WHFB, run klist and klist cloud_debug. You should see a Cloud TGT as well as a service ticket for the Azure Files SPN (typically cifs/<storageaccount>.file.core.windows.net) when the share is accessed. If the service ticket is not issued, the problem is occurring before Azure Files authentication.

Verify that the storage account's AD DS configuration is healthy. Confirm that the storage account has the correct domain information (Get-AzStorageAccount -ResourceGroupName <RG> -Name <StorageAccount> | Select AzureFilesIdentityBasedAuthentication), that the AD computer object representing the storage account still has a valid password and SPNs, and that the Kerberos encryption types match your domain policy. AES-256-only is supported, but if domain controllers or the storage account object have inconsistent encryption settings, Kerberos can silently fall back to prompting for NTLM credentials.

The fact that domain\username works but UPN does not indicates Windows Credential Manager is falling back to legacy SMB authentication rather than using the user's existing Kerberos session. If Kerberos were being used, users should not be prompted at all. It might worth checking whether the SMB client is attempting Kerberos by capturing Microsoft-Windows-SMBClient/Connectivity and Microsoft-Windows-Kerberos-Key-Distribution-Center event logs while reproducing the issue.

Another potential cause might be DNS or SPN resolution. Ensure clients are connecting using the storage account FQDN (\\storageaccount.file.core.windows.net\share) and not via an alias or DFS namespace unless SPNs have been configured appropriately. Kerberos requires the service principal name to match exactly.

You might want to also check whether this is an issue with Device Preparation Policy deployments. Compare an affected device against a working Entra-joined device by looking at:

dsregcmd /status
klist cloud_debug
klist tickets
gpresult /r (to confirm no legacy credential or Kerberos policies differ)
Get-SmbConnection after attempting access
Event Viewer under Applications and Services Logs → Microsoft → Windows → SMBClient and Kerberos.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

mpls 170 Reputation points

2026-07-31T23:19:37.0766667+00:00

Thank you. Will work through your suggestions.