Azure file share with Azure ad Kerberos cannot authenticate to domain controller on Hybrid-Entra Joined Device

Question

Azure file share with Azure ad Kerberos cannot authenticate to domain controller on Hybrid-Entra Joined Device

Tyler Douglas 20

I've set up and configured an Azure file share with Azure AD Kerberos authentication. When attempting to mount the drive on a hybrid-Entra joined device that is not on our domain network it fails with the below errors.
If I mount using CMD I get: "The password is invalid for \<StorageAccountName>.file.core.windows.net" and am then prompted to enter a username. If I type my username again, I get a message telling me that that username was already tried and a domain controller could not be contacted to verify.

If I mount using Powershell I get: "The system cannot contact a domain controller to service the authentication request. Please try again later"

Note: I have configured the local group policy for the test machine to allow the device to get the Azure AD Kerberos Ticket. The test machine is running Windows 11 Enterprise v23H2

I have also confirmed that the "Storage Account App" is excluded from our MFA policy and I do not see any failed sign-in's related to this issue.

My end goal is to be able to mount this drive on an Entra-Hybrid joined computer that is NOT on our domain network (remote). I believe Entra Kerberos is able to do this based on the description given in this article. I need some assistance understanding where I am going wrong here.

Syed Aaqid Ali 490 Reputation points Microsoft External Staff

2025-03-19T19:21:47.47+00:00
Hi Tyler Douglas,

When attempting to mount an Azure file share with Azure AD Kerberos authentication on a hybrid-Entra joined device that is not connected to your domain network, you may encounter issues related to Kerberos ticket retrieval and domain controller connectivity.

The errors you are experiencing, such as "The password is invalid" and "The system cannot contact a domain controller," suggest that the SMB client is unable to obtain a Kerberos ticket because it cannot reach a domain controller. This issue occurs when the client is outside the network that hosts the domain controllers.

To troubleshoot this issue, following steps might be helpful and consider checking Potential errors when enabling Microsoft Entra Kerberos authentication for hybrid users

Check Network Connectivity: Ensure that the device has internet access and can reach Microsoft Entra services. If there are any firewalls or VPNs in place, they may be blocking necessary traffic.

Verify Azure AD Kerberos Configuration: Make sure that the Azure AD Kerberos authentication is properly configured for the storage account. You can run the Debug-AzStorageAccountAuth cmdlet to perform basic checks on the storage account's authentication setup.

Review Local Group Policy: Since you've configured the local group policy to allow the device to get the Azure AD Kerberos Ticket, double-check that the policy is applied correctly and that there are no conflicting settings.

Service Principal Setup: Ensure that the service principal for the storage account is correctly configured and that the required identifier URIs are set up in the Microsoft Entra application.

MFA Exclusions: Confirm that the storage account application is indeed excluded from MFA policies, as any MFA requirement could prevent successful authentication.

References:

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

Enable Microsoft Entra Kerberos authentication for hybrid identities on Azure Files

Please do not forget to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

If you have any other questions or are still running into more issues, let me know in the "comments" and I would be happy to help you.
Tyler Douglas 20 Reputation points

2025-03-20T12:54:15.6466667+00:00

<Deleted - Posted as answer by mistake>
Tyler Douglas 20 Reputation points

2025-03-20T12:54:46.9333333+00:00

Hi Syed, thank you for your response. When looking into what you had said, I came across two conflicting pieces of information.

This Article: Says "This configuration allows hybrid users to access Azure file shares using Kerberos authentication, using Microsoft Entra ID to issue the necessary Kerberos tickets to access the file share with the SMB protocol. This means your end users can access Azure file shares over the internet without requiring unimpeded network connectivity to domain controllers from Microsoft Entra hybrid joined and Microsoft Entra joined clients."

While this other article says (Under the ""Mounting prerequisites" section): "If your AD source is AD DS or Microsoft Entra Kerberos, your client must have unimpeded network connectivity to your AD DS. If your machine or VM is outside of the network managed by your AD DS, you'll need to enable VPN to reach AD DS for authentication."

Could you please confirm if what I am trying to do is possible? To clarify my end goal is to be able to mount this drive on an Entra-Hybrid joined computer that is NOT on our domain network (remote) without having to use a VPN. If that is not possible, then what is the first article I linked above referring to?

As for the steps you have mentioned, please see below.

Check Network Connectivity: I have confirmed that the device can reach the file share via port 445 by running- "Test-NetConnection -ComputerName <StorageAccount>.file.core.windows.net -Port 445"

Verify Azure AD Kerberos Configuration: When running debug, it did confirm that Kerberos was the configured authentication method for the server.

Review Local Group Policy: The device does appear to be getting an azure Kerberos ticket.

Service Principal Setup: I would appreciate some clarification on this step as I have not seen this mentioned in the Kerberos Authentication setup documentation.

MFA Exclusions: The app "[Storage Account] <AccountName>.file.core.windows.net" is excluded from my MFA policy. I am also not seeing any failed sign-in's in Entra ID that would indicate an issue with the MFA policy.
Venkatesan S 1,625 Reputation points Microsoft External Staff

2025-03-21T14:26:37.29+00:00
Hi Tyler Douglas

In my above response to Syed, I link to two articles that seem to have conflicting information on what is possible with Entra AD Kerberos, I would appreciate some clarification on which article is correct.

The first article appears to be correct only when the authentication and authorization fully rely on Azure AD Kerberos and Microsoft Entra ID. However, in hybrid scenarios where NTFS permissions are still based on on-prem AD SIDs, some operations still require connectivity to AD DS.

For authentication: If configured properly, Azure AD Kerberos should allow users to authenticate and mount Azure Files remotely without requiring a VPN.

For authorization: If file share permissions rely on NTFS ACLs with on-prem AD SIDs, then the system may still need to contact on-prem AD to verify permissions.

Since you mentioned:

You have added NTFS ACLs using your on-prem AD identity,

You can mount the share only when on-prem AD is reachable,

It strongly suggests that authorization is failing due to lack of on-prem AD access.

If this resolves your issue, please click “up-vote" for it, which could help other community members who read this thread. And, if you have any more questions, please let us know.

Accepted answer

2 additional answers

Your answer

Tyler Douglas 20 Reputation points

2025-03-20T12:54:15.6466667+00:00

<Deleted - Posted as answer by mistake>
Venkatesan S 1,625 Reputation points Microsoft External Staff

2025-03-21T14:26:37.29+00:00

Hi Tyler Douglas

In my above response to Syed, I link to two articles that seem to have conflicting information on what is possible with Entra AD Kerberos, I would appreciate some clarification on which article is correct.

The first article appears to be correct only when the authentication and authorization fully rely on Azure AD Kerberos and Microsoft Entra ID. However, in hybrid scenarios where NTFS permissions are still based on on-prem AD SIDs, some operations still require connectivity to AD DS.

For authentication: If configured properly, Azure AD Kerberos should allow users to authenticate and mount Azure Files remotely without requiring a VPN.

For authorization: If file share permissions rely on NTFS ACLs with on-prem AD SIDs, then the system may still need to contact on-prem AD to verify permissions.

Since you mentioned:

You have added NTFS ACLs using your on-prem AD identity,

You can mount the share only when on-prem AD is reachable,

It strongly suggests that authorization is failing due to lack of on-prem AD access.

If this resolves your issue, please click “up-vote" for it, which could help other community members who read this thread. And, if you have any more questions, please let us know.

Answer 1

Hi Tyler Douglas

I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this! Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others", I'll repost your solution in case you'd like to "Accept" the answer.

Issue:

When configuring Azure AD Kerberos for Azure Files authentication, users should be able to mount Azure Files remotely without requiring a VPN. However, if file share permissions rely on NTFS ACLs with on-prem AD SIDs, the system may still need to contact the on-prem AD to verify permissions.

Solution:

The root cause was that the computer no longer had a local AD Kerberos ticket, which prevented it from verifying NTFS permissions to access the drive.

Once the computer was able to contact the domain controller and receive a local Kerberos ticket, access to the drive was restored, even without an active connection to the domain controller.
After testing, I found that the ticket remained valid for several days, allowing continued access to the drive without requiring reauthentication to the local DC.

If you have any other questions, please let me know. Thank you again for your time and patience throughout this issue.

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Venkatesan S 1,625 Reputation points Microsoft External Staff

2025-03-26T08:28:08.3866667+00:00

Hi Tyler Douglas

Please Accept the answer and up-vote wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

chrischin 915 Microsoft Employee

Hi Tyler,Sounds like we are dealing with 2 separate AD domains here.

You mention the session hosts are hybrid joined. Let's say the session hosts are hybrid joined to AD domain A and joined to Entra tenant X. Are the devices hybrid joined via Entra ID Connect?

Let's also say that your user identities are hybrid identities from AD domain B and Entra tenant X? Is this done via a separate Entra ID Connect (than for devices)?

When you enabled Entra Kerberos on the Azure File share, did you pick the guid and domain name for AD domain A or B?

What did you prime the Azure File share with as far as ACLs? It should be SIDs from AD Domain B.

Your ACLs needs to look like those in the screenshot in this link (https://learn.microsoft.com/en-us/fslogix/how-to-configure-storage-permissions) where the SIDs are from AD domain B (hybrid identity domain).

Tyler Douglas 20 Reputation points

2025-03-21T13:07:05.89+00:00

Hello, we do not have two separate AD domains. We have one AD domain that is synced to Entra via Entra ID connect. The device I am attempting to mount the drive on is Hybrid-Entra joined, so it is joined both to our on prem AD and our Entra tenant. Running dsregcmd /status on the device does confirm this. I did use the correct GUID and domain name in the Entra Kerberos setup. For the access control for the share, I have both the default (cloud) "users" and "Administrators" groups that are created for the share which my user is a member of the SMB Elevated Contributor role. I also have my domain user account added through NTFS. I believe the share itself is likely configured correctly as I have no issues mounting it on a device that has a connection to our on-prem AD. Where I am running into issues is attempting to mount the drive on a hybrid-joined device without line of sight to the on prem AD. In my above response to Syed, I link to two articles that seem to have conflicting information on what is possible with Entra AD Kerberos, I would appreciate some clarification on which article is correct.
chrischin 915 Reputation points Microsoft Employee

2025-03-21T13:55:47.3433333+00:00

Thanks Tyler, I mis-interpreted what you meant by "not on our domain network." Is the plan to run these session hosts with FSLogix without line of sight to the AD domain controller permanently? If that is the case, I would suggest not having them hybrid-joined and instead, have them Entra-joined only since the on-prem joined side would continue to run in a degraded state. You will have to have line of sight to the AD domain controller when you prime the file share because it needs to know what the SIDs are for the NTFS permissions. For my customers that are using hybrid-identities on Entra-joined (only) session hosts where they can't establish temporary connectivity to AD to prime the Azure File share, I have them using a computer that does have line of sight to AD, mount the Azure File share there (e.g. net use Z: \<YourStorageAccountName>.file.core.windows.net<FileShareName>) using the storage key, run the iacls commands then unmount. Once the NTFS permissions are there (follow the link in my previous post for exact NTFS permissions required), your session hosts should be able to use it for your hybrid-users without session hosts having connectivity back to AD.

https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-mount-file-share
Venkatesan S 1,625 Reputation points Microsoft External Staff

2025-03-24T07:45:58.67+00:00

Following up to see if the above answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 3

For authentication: If configured properly, Azure AD Kerberos should allow users to authenticate and mount Azure Files remotely without requiring a VPN.

For authorization: If file share permissions rely on NTFS ACLs with on-prem AD SIDs, then the system may still need to contact on-prem AD to verify permissions.

This comment by Venkatesan S ended up leading me to the issue. The problem was that this computer no longer had a local AD Kerberos ticket, so was not able to verify it had the correct NTFS permissions to access the drive. Once the computer was able to contact the domain controller and receive a local Kerberos ticket, this started working regardless of if it has an active line of site to the domain controller. I am now testing this again after leaving the computer sit for a few days and it has still retained its ticket and access to the drive without needing to reauthenticate to the local DC. Thank you all for your assistance with this issue.

Share via

Azure file share with Azure ad Kerberos cannot authenticate to domain controller on Hybrid-Entra Joined Device

2 additional answers

Your answer