StorageAccount - SMB File Share - Map Drive - Errors

Question

Hi,

We are encountering a problem setting up file sharing with ACL implementation for our users. The pcs are joined to Azure AD, our users are registered in Azure AD.

CF: https://support.microsoft.com/en-us/account-billing/join-your-work-device-to-your-work-or-school-network-ef4d6adb-5095-4e51-829e-5457430f3973

We have implemented Azure AD DS.

CF: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-domain-services-enable?tabs=azure-portal

Users are not administrators of their PC. An Azure P2S VPN based on AzureAD authentication is set up.

The storage account is accessible by the VPN via private link.

When we try to mount a "Z:" drive on \[STORAGENAME].file.core.windows.net\share1 the command provided in New-PSDrive returns a message "the network resource type is incorrect".

The using net us returns error 53. net use Z: \<YourStorageAccountName>.file.core.windows.net<FileShareName> /user:<DOMAINNAME\username>

Or net use Z: \<YourStorageAccountName>.file.core.windows.net<FileShareName> /user:username@domainFQDN Same error 53

--> Verification of the LSA/LmCompatibilityLevel key is 3

--> Test-netConnection \[STORAGENAME].file.core.windows.net\share1 returns the IP address of the private link with TCPTestSucceeded to True

--> AzureFileDiagnostic does not return a problem

NOTE: Execution with admin rights and userlocal\key type authentication. It does not seem that this tool can do a test with a non-administrator AZAD account.

We have initialized a server VM in our tenant and do not have this connection problem.

we don't know where the problem is, do you have any idea?

thanks a lot

Answer 1

Hei unknown error,

Thank you for contacting Microsoft community.

I gather that you have a storage account file share that is accessible on a VM setup in the tenant (meaning on an Azure VM) but isn't accessible through any other network outside Azure even though you are connected via a VPN.

It seems like either the Storage account has a network restriction or there is a policy restriction.

Most connectivity restrictions can be diagnosed via Connectivity tool on Storage account menu, "Context menu for Storage account (left menu) > Help > Connectivity check"

It helps if you run this on the target computer you are trying to troubleshoot, open the Azure portal on the target computer, navigate to the storage account and run the tool.

Please mark this as "Answer" if it helps

Answer 2

@unknown error Welcome to Microsoft Q&A Forum, Thank you for posting your query here.

• Please share the screenshot of the error message?
• Please cross verify the the SMB version (SMB version compatibility) and verify DNS resolution(nslookup yourfileshare.file.core.windows.net) ?
• Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445 Instructions here - https://learn.microsoft.com/en-us/azure/storage/files/storage-how-to-use-files-windows
• Error 53: This error typically indicates that the network path to the Azure file share is not found. Here are some steps to troubleshoot this error:
  1. Ensure that the workstation has network connectivity to the Azure file share. You can try pinging the file share endpoint from the workstation to verify connectivity.
     1. Verify that the DNS resolution is working correctly. Ensure that the file share endpoint is resolving to the correct IP address.

Based on the error message: Refer to the suggestion mentioned in this troubleshooting article

FQDN of the storage account from the non domain joined pc helped to resolve the issue

The on-premises DNS server resolves IP addresses. However, Azure DNS resolves the Azure file share Fully Qualified Domain Name (FQDN). All DNS queries to Azure DNS originate from the virtual network. There's a DNS proxy inside the virtual network to route these queries to Azure DNS. For more information, see On-premises workloads using a DNS forwarder.

• System error 53 or system error 87 can occur if NTLMv1 communication is enabled on the client. Azure Files supports only NTLMv2 authentication. Having NTLMv1 enabled creates a less-secure client. Therefore, communication is blocked for Azure Files.

To determine whether this is the cause of the error, verify that the following registry subkey isn't set to a value less than 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

For more information, see the LmCompatibilityLevel topic on TechNet.

• Solution for cause 2

Revert the LmCompatibilityLevel value to the default value of 3 in the following registry subkey:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

To learn how to enable AD DS authentication, first read Overview - on-premises Active Directory Domain Services authentication over SMB for Azure file shares and then see Enable AD DS authentication for Azure file shares.

How it works: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-active-directory-overview#azure-ad-ds

This article lists common problems that might occur when you try to connect to and access SMB Azure file shares from Windows or Linux clients. It also provides possible causes and resolutions for these problems.

If the troubleshooting steps mentioned above do not resolve your issue, it would be helpful to provide the specific error messages you are encountering, any relevant event log entries, and the output of the "DSRegCmd /status" command on the workstation. This information can help in further diagnosing the problem.

If the issue still persist, I wish to engage with you offline for a closer look and provide a quick and specialized assistance, please send an email with subject line “Attn:subm” to AzCommunity[at]Microsoft[dot]com referencing this thread and the Azure subscription ID, I will follow-up with you.  Once again, apologies for any inconvenience with this issue.

Thanks for your patience and co-operation.

---

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.