Azure files drive mapping turns red after working and error is the system cannot contact a domain controller to service the authentication request

Question

Hybrid joined

Kerberos

Azure files drive mapped successfully and is being used for days, hours, etc.

Drive decides to disconnect. Shows in explorer as red

Trying to connect

first click on drive - The system cannot contact a domain controller to service the authentication request. Please try again later.

close explorer and click 2nd time on drive - An error occurred while reconnecting X: to \xxxxxxxx.file.core.windows.net\xxxxxxxx Microsoft Windows Network: The local device name is already in use. This connection has not been restored.

disconnected the drive and try to re-map it - Windows Security pop-up - wnats network creds and error in the bottom of the pop-up is The system cannot contact a domain controller to service the authentication request. Please try again later.

Answer 1

Hello MiltThacker-2374,

Greetings! Welcome to Microsoft Q&A Platform.

 

The issue is related to a domain controller for authentication, network connectivity problems between your hybrid-joined system and the domain controller, as you are using Kerberos protocol.

 

Make sure that the following services or conditions are functioning properly:

• The network infrastructure is functioning properly, and all computers and services can communicate.
• The domain controller is accessible. You can run the command nltest /dsgetdc:<Domain Name> /force /kdc (for example, nltest /dsgetdc:contoso.com /force /kdc) on the client or target server.
• Domain Name System (DNS) is configured properly and resolves host names and services appropriately. The clocks are synchronized across the domain. All critical updates and security updates for Windows Server are installed. All software, including non-Microsoft software, is updated. The computer is restarted if you're running a server operating system. The required services and server are available. The Kerberos authentication protocol requires a functioning domain controller, DNS infrastructure, and network to work properly.
• Verify that you can access these resources before you begin troubleshooting the Kerberos protocol. Service principal name missing or duplicated Name resolution failures or incorrect responses (wrong IP addresses given for a server) Large Kerberos tickets (MaxTokenSize) and environment not set up properly Ports being blocked by firewalls or routers Service account not given appropriate privileges (User Rights Assignment) Front-end or back-end services not in the same domain and constrained delegation setup.

 

Troubleshooting steps:

 Ensure that your system has stable network access, especially to the domain controller. Test the connectivity using ping or nslookup commands to see if the domain controller is reachable. Use nslookup to check if the domain controller's DNS name resolves correctly. Run the nslookup command to identify any DNS misconfigurations. Open required ports between the client and the domain controller.

 

Similar post:https://learn.microsoft.com/en-us/answers/questions/1135070/cannot-connect-to-azure-files-share.

 

Here is the doc for your reference: https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-authentication-troubleshooting-guidance, https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable?tabs=azure-portal#configure-the-clients-to-retrieve-kerberos-tickets,

  

Hope this answer helps! please let us know if you have any further queries. I’m happy to assist you further.

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

Answer 2

I get this issue as well.

When using Microsoft Entra Kerberos identity-based access for an Azure File share, you do not need line-of-site to a domain controller to access the share, unless you are using fine-grain ACL permissions on items within the share.

I am thinking it's something on the Windows client. Some sort of DNS cache or whatever that stops it from continuing to work with the Azure File share.