Azure SMB file share accessible via shared key but not via cloud-only Kerberos authentication

Question

Azure SMB file share accessible via shared key but not via cloud-only Kerberos authentication

IT 0

After a ransomware attack destroyed the network, everything was migrated to cloud-only; all user accounts manually migrated from the destroyed DC/AD to Entra ID, all files restored from backups to SharePoint, all devices to Intune, all MFA, everyone is up and running. BUT... most of the business is run on Access and MySQL databases so SharePoint is not going to work for that. I need mappable SMB cloud shares.

I am trying to follow the cookbook "Enable Microsoft Entra Kerberos authentication for...cloud-only identities on Azure Files". I have tested an SSD-based Azure SMB file share that is accessible by shared key, loaded with files via Azure Store Explorer, and runs one of our local FIleMaker Pro database applications wonderfully, lightning fast. So the proof of concept is a success.

When I try to set it up via Kerberos cloud-only, I can resolve and ping the location but the new ps drive app comes back "access is denied". If I drill down into regedit on my test pc, I don't see the CloudKerberosTicketRetrievalEnabled value anywhere, looking at

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Intune Windows configuration has a policy called Kerberos which has

"Cloud Kerberos Ticket Retrieval Enabled" set to Enabled, but it says above it "6 of 7 settings in this category are not configured".

I ran dsregcmd /status

+----------------------------------------------------------------------+

| Device State |

+----------------------------------------------------------------------+

         AzureAdJoined : YES

      EnterpriseJoined : NO

          DomainJoined : NO

       Virtual Desktop : NOT SET

+----------------------------------------------------------------------+

| Device Details |

+----------------------------------------------------------------------+

           KeyProvider : Microsoft Platform Crypto Provider

          TpmProtected : YES

      DeviceAuthStatus : SUCCESS

then I ran dsregcmd /forcerecovery

re-did my PIN

restarted the pc

same thing - map drive - "access is denied"

help! I need someone who knows more than I do (which will not be hard to find!!!)

IT 0 Reputation points

2026-02-24T04:49:58.9766667+00:00

OK, my message has been restored! Now what is the next step?
Venkatesan S 10,830 Reputation points Microsoft External Staff Moderator

2026-02-24T05:31:21.21+00:00
Hello IT

Thank you for reaching out in Microsoft Q&A forum,

When I try to set it up via Kerberos cloud-only, I can resolve and ping the location but the new ps drive app comes back "access is denied". If I drill down into regedit on my test pc, I don't see the CloudKerberosTicketRetrievalEnabled value anywhere, looking at

When “Access Denied” occurs specifically with Microsoft Entra Kerberos in a cloud-only setup, the issue typically falls into one of three areas:

Client policy not fully applied

Kerberos ticket not being issued

RBAC permissions not correctly assigned.

Below are Troubleshooting steps specifically for cloud-only (Entra ID only, no AD DS, no hybrid) environments.

For cloud-only Azure Files Kerberos authentication, the following registry value must exist on the client device:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters CloudKerberosTicketRetrievalEnabled = 1 (DWORD)
If this value is missing, the device will not automatically retrieve a Kerberos ticket for Azure Files.

Client device: Settings > Accounts > Access work or school > Info > Sync, followed by reboot and registry verification, represent the safest first step for forcing policy application without risking device disenrollment on your Azure AD-joined test PC.

After reboot, verify the registry value using:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters"

If the value is still not present, the Intune configuration profile is not applying successfully.

Verify that the Kerberos ticket is being issued. Run:
klist
You should see an entry referencing:
krbtgt/AZUREADKERBEROS
You can also explicitly request a ticket:
klist get cifs/<storageaccount>.file.core.windows.net
If no ticket is returned, authentication is failing at the client level. This typically indicates:

Policy not applied

Unsupported Windows version

Storage account not correctly configured

Check the RBAC roles were assigned to the users were correct. Assign one of the following roles at the share level:

Storage File Data SMB Share Contributor

Storage File Data SMB Share Elevated Contributor (if required)

After assigning permissions, the user must sign out and sign back in to refresh their token.

Run:
whoami /groups
Confirm that the Entra security group granted access appears in the token. If not, sign out and sign back in.

Use:
net use Z: \\<storageaccount>.file.core.windows.net\<sharename>
The connection must authenticate using the signed-in Entra identity.

Note: Port 445 must be open

Reference:

Microsoft Entra Kerberos Authentication for Azure Files | Microsoft Learn

Troubleshoot Azure Files identity-based authentication and authorization issues (SMB) - Azure | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-02-24T09:25:07.06+00:00

Hello IT

Please let us know if you have any further queries on this. Feel free to reach out!
IT 0 Reputation points

2026-02-25T01:05:28.09+00:00
I found a way to add **Enable CloudKerberosTicketRetrieval**via regedit:reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

and rebooted. Now I get

PS C:\Users\IT> klist

Current LogonId is 0:0x1e1de3

Cached Tickets: (1)

#0> Client: @xxx @ AzureAD

Server: krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM KerbTicket Encryption Type: Unknown (-1) Ticket Flags 0x40810000 -> forwardable renewable name_canonicalize Start Time: 2/24/2026 15:52:35 (local) End Time: 2/25/2026 1:52:35 (local) Renew Time: 3/3/2026 15:52:35 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x400 -> 0x400 Kdc Called: TicketSuppliedAtLogon

PS C:\Users\IT> klist tgt

Current LogonId is 0:0x1e1de3

Error calling API LsaCallAuthenticationPackage (Ticket Granting Ticket substatus): 1312

klist failed with 0x8009030e/-2146893042: No credentials are available in the security package

PS C:\Users\IT> klist get cifs/$hostname

Current LogonId is 0:0x1e1de3

Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x35

klist failed with 0x80090303/-2146893053: The specified target is unknown or unreachable

PS C:\Users\IT> whoami /groups

GROUP INFORMATION

Group Name Type SID

========================================= ================

Mandatory Label\High Mandatory Level Label S-1-16-12288

Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group

BUILTIN\Administrators Alias S-1-5-32-544 Mandatory group, Enabled by default, Enabled group, Group owner

BUILTIN\Users Alias S-1-5-32-545

Mandatory group, Enabled by default, Enabled group

NT AUTHORITY\INTERACTIVE Well-known group S-1-5-4 Mandatory group, Enabled by default, Enabled group

CONSOLE LOGON Well-known group S-1-2-1 Mandatory group, Enabled by default, Enabled group

NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group

NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group

LOCAL Well-known group S-1-2-0 Mandatory group, Enabled by default, Enabled group

Unknown SID type S-1-12-1-2301018183-1277023848-2124304043-3656760532 Mandatory group, Enabled by default, Enabled group

NT AUTHORITY\Cloud Account Authentication Well-known group S-1-5-64-36 Mandatory group, Enabled by default, Enabled group

PS C:\Users\IT> NET USE R: \$hostName$sharName

Enter the user name for 'x.file.core.windows.net':

Enter the password for x.file.core.windows.net:

System error 86 has occurred.

The specified network password is not correct.

OS Version: 26200.7840

SO: it looks like an Intune problem. What are the next steps?
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-02-25T04:57:16.83+00:00
Hello IT,

Thank you for sharing the latest results.

The key point is this error:

klist get cifs/<storageaccount>.file.core.windows.net klist failed with 0x80090303: The specified target is unknown or unreachable

This means the client is unable to obtain a Kerberos service ticket for the Azure Files endpoint. Since the device is Azure AD joined and already receiving a Kerberos ticket from Entra ID, this suggests the Microsoft Entra Kerberos configuration on the storage account needs to be verified.

Could you please run the following Azure PowerShell command and share the output:

Get-AzStorageAccount ` -ResourceGroupName <ResourceGroupName> ` -Name <StorageAccountName> | Select-Object -ExpandProperty AzureFilesIdentityBasedAuth

Please confirm that the output shows:

DirectoryServiceOptions set to AzureActiveDirectoryKerberos

ActiveDirectoryProperties present in the output

This will help confirm whether Microsoft Entra Kerberos is fully configured on the storage account.

Once you share the result, we can guide you on the next step.
IT 0 Reputation points

2026-02-25T21:57:29.89+00:00

PS /home/it> Get-AzStorageAccount `

-ResourceGroupName RGName `

-Name SAName |

Select-Object -ExpandProperty AzureFilesIdentityBasedAuth | fl

DirectoryServiceOptions : AADKERB

ActiveDirectoryProperties :

DefaultSharePermission : StorageFileDataSmbShareContributor

SmbOAuthSettings : Microsoft.Azure.Commands.Management.Storage.Models.PSSmbOAuthSettings
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-02-26T04:46:05.5566667+00:00
Hello IT,

Thank you for sharing the output.

The value:

DirectoryServiceOptions : AADKERB

confirms that Microsoft Entra Kerberos is enabled correctly on the storage account.

The setting:

DefaultSharePermission : StorageFileDataSmbShareContributor

defines the default permission level, but users still need an Azure RBAC role assignment on the storage account or the file share in order to access it.

Please confirm that the user has one of the following roles assigned:

Storage File Data SMB Share Contributor

Storage File Data SMB Share Elevated Contributor

and that the assignment scope is the storage account or the specific file share.

If the role was assigned recently, sign out of Windows and sign back in, then run:

klist purge klist get cifs/<storageaccount>.file.core.windows.net

This will request a new Kerberos ticket with the updated permissions.

If possible, please also confirm whether the role is assigned directly to the user or via a group, and at which scope.
Rukmini 44,000 Reputation points Microsoft External Staff Moderator

2026-02-27T02:26:09.6866667+00:00

Hello IT, Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Rukmini 44,000 Reputation points Microsoft External Staff Moderator

2026-02-27T02:32:41.2+00:00

Hello IT,

Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Raja Pothuraju 47,840 Reputation points Microsoft Employee Moderator

2026-03-03T17:05:37.6833333+00:00

@IT, Just checking in to see if below information was helpful. If you have any further updates on this issue, please feel free to post back.
IT 0 Reputation points

2026-03-05T15:06:20.4033333+00:00

I have the following issues that are currently keeping me from implementing Azure SMB shares:

First, Intune is not sending the CloudKerberosTicketRetrievalEnabled key down to the clients.

I can map a client SMB drive if I manually add the reg key to a client:

reg add "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1 /f

I have an Intune policy (actually two) and apparently neither is working - all 0's.

The top policy is All devices included with these custom OMA-URI Settings:

Second, I am trying to troubleshoot by inspecting the client registry from Intune, but need Windows license verification? And an E-series client license? How do I troubleshoot the above Intune configuration?

Third, when I do successfully map an Azure SMB drive it's a mess. It shows up in Powershell and CMD but not in File Explorer. It doesn't matter if I create the drive using New-PSDrive, new-SMBMapping, NET USE, if I add -Persist or /persistent:yes or not; the only way the drive shows up in File Explorer is to map a network drive in File Explorer. If I map the drive in File Explorer, it shows up in File Explorer, Powershell and CMD. And -persist doesn't survive a logout.

Fourth, I have a live network user who successfully connected to an SMB drive two weeks ago by using an access key, and was able to run a database remotely with great performance on my SSD configured share. When we just tested SMB connectivity without the key it still worked! Everything I have read tells me the access key is not retained anywhere on the client, the client has been booted several times since, the Kerberos ticket enabled value is not in the client registry, and yet I can still map and access a drive from the client to an SMB share.

I set CloudKerberosTicketRetrievalEnabled to 0 and after a client reboot was still able to map a drive. I then rotated the storage account keys and rebooted the client again, and when I mapped a drive from File Explorer I was prompted for my PIN, and could not connect:

I then turned the Kerberos key back to 1 and rebooted, and when I tried to map a drive with new access keys after verifying the Kerberos ticketing is turned on, it did not work.

I tried it again with credentials, the same credentials I am using for the current login connection, and this user has elevated privs for the resource:

So, it now looks like Kerberos was never working at all, only the access key, and I cannot map a drive at all unless I use an access key.

I need this fixed asap, I have 60 users waiting for this resource, I have burned up multiple weeks on this and just need to get working the ability for my users to map to a cloud SMB drive with no on-prem controller, which leads me to my last question:

How can I get a Microsoft tech support person to remote to my session and help me fix it? Why I am forced into exchanging messages back and forth? This is incredibly ineffective and inefficient and time-consuming and frustrating. I need a SME to figure out what's wrong, which probably won't take long.

Rob
Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-03-06T12:00:21.6766667+00:00

Hello IT

We have initiated a private message. Please check it and provide the necessary information so we can discuss further on your concern.
Ganesh Patapati 12,175 Reputation points Microsoft External Staff Moderator

2026-03-10T22:24:42.4433333+00:00

Hello IT

Can you please share the requested details in the Private Messages for further troubleshoot the issue.

1 answer

Your answer

IT 0 Reputation points

2026-02-24T04:49:58.9766667+00:00

OK, my message has been restored! Now what is the next step?
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-02-24T09:25:07.06+00:00

Hello IT

Please let us know if you have any further queries on this. Feel free to reach out!
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-02-25T04:57:16.83+00:00

Hello IT,

Thank you for sharing the latest results.

The key point is this error:

klist get cifs/<storageaccount>.file.core.windows.net klist failed with 0x80090303: The specified target is unknown or unreachable

This means the client is unable to obtain a Kerberos service ticket for the Azure Files endpoint. Since the device is Azure AD joined and already receiving a Kerberos ticket from Entra ID, this suggests the Microsoft Entra Kerberos configuration on the storage account needs to be verified.

Could you please run the following Azure PowerShell command and share the output:

Get-AzStorageAccount ` -ResourceGroupName <ResourceGroupName> ` -Name <StorageAccountName> | Select-Object -ExpandProperty AzureFilesIdentityBasedAuth

Please confirm that the output shows:

DirectoryServiceOptions set to AzureActiveDirectoryKerberos

ActiveDirectoryProperties present in the output

This will help confirm whether Microsoft Entra Kerberos is fully configured on the storage account.

Once you share the result, we can guide you on the next step.
IT 0 Reputation points

2026-02-25T21:57:29.89+00:00

PS /home/it> Get-AzStorageAccount `

-ResourceGroupName RGName `

-Name SAName |

Select-Object -ExpandProperty AzureFilesIdentityBasedAuth | fl

DirectoryServiceOptions : AADKERB

ActiveDirectoryProperties :

DefaultSharePermission : StorageFileDataSmbShareContributor

SmbOAuthSettings : Microsoft.Azure.Commands.Management.Storage.Models.PSSmbOAuthSettings
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-02-26T04:46:05.5566667+00:00

Hello IT,

Thank you for sharing the output.

The value:

DirectoryServiceOptions : AADKERB

confirms that Microsoft Entra Kerberos is enabled correctly on the storage account.

The setting:

DefaultSharePermission : StorageFileDataSmbShareContributor

defines the default permission level, but users still need an Azure RBAC role assignment on the storage account or the file share in order to access it.

Please confirm that the user has one of the following roles assigned:

Storage File Data SMB Share Contributor

Storage File Data SMB Share Elevated Contributor

and that the assignment scope is the storage account or the specific file share.

If the role was assigned recently, sign out of Windows and sign back in, then run:

klist purge klist get cifs/<storageaccount>.file.core.windows.net

This will request a new Kerberos ticket with the updated permissions.

If possible, please also confirm whether the role is assigned directly to the user or via a group, and at which scope.
Rukmini 44,000 Reputation points Microsoft External Staff Moderator

2026-02-27T02:26:09.6866667+00:00

Hello IT, Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Rukmini 44,000 Reputation points Microsoft External Staff Moderator

2026-02-27T02:32:41.2+00:00

Hello IT,

Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Raja Pothuraju 47,840 Reputation points Microsoft Employee Moderator

2026-03-03T17:05:37.6833333+00:00

@IT, Just checking in to see if below information was helpful. If you have any further updates on this issue, please feel free to post back.
Praveen Bandaru 11,800 Reputation points Microsoft External Staff Moderator

2026-03-06T12:00:21.6766667+00:00

Hello IT

We have initiated a private message. Please check it and provide the necessary information so we can discuss further on your concern.
Ganesh Patapati 12,175 Reputation points Microsoft External Staff Moderator

2026-03-10T22:24:42.4433333+00:00

Hello IT

Can you please share the requested details in the Private Messages for further troubleshoot the issue.

Answer 1

Hello @IT,

As discussed over the call, the issue you are experiencing is due to a misconfiguration during the storage account creation. To resolve this, we created a new storage account, added a file share to it, and followed the steps outlined in the below document step by step:

Enable Azure Files identity-based authentication (hybrid identities)

Since your use case involves accessing the file share using Microsoft Entra ID cloud-only identities, we tested this scenario from a Microsoft Entra–joined device. We successfully obtained the Entra Kerberos ticket from Entra ID and were able to access the file share from the client device without any issues.