Share via

Azure VPN Gateway P2S Issues Acces Storage SMB Share

rr-4098 2,211 Reputation points
2026-03-11T16:27:16.4233333+00:00

We have a storage account setup without a public endpoint but is restricted by IP's. We had a request to setup a P2S VPN for 5 users who will need to be able to access the smb share over the VPN. I have tried allow the Gateway subnet and made sure the Storge Service Endpoint is enabled, allowed the public IP for the gateway.. No matter what I do, I cannot connect to the VPN with out issue but as soon as I try to browse the share in the portal or mount it I get access denied. Please note, test-netconnect does pass.

Thoughts???

Azure Storage
Azure Storage

Globally unique resources that provide access to data management services and serve as the parent namespace for the services.


Answer accepted by question author
  1. Ganesh Patapati 11,835 Reputation points Microsoft External Staff Moderator
    2026-03-11T21:15:53.4+00:00

    Hello rr-4098

    Thanks for the reply!

    In your scenario Azure Files does not authenticate SMB access using Entra ID tokens or OAuth. All identity‑based SMB access requires Kerberos authentication.

    To issue Kerberos tickets, Azure Files must be able to authenticate users against one of the following supported identity sources:

    • On‑premises Active Directory Domain Services (AD DS)
    • Microsoft Entra Domain Services (AAD DS)
    • Microsoft Entra Kerberos (preview)

    In your current setup, the on-premises domain controllers are not accessible from Azure, AAD DS has not been deployed, and Entra Kerberos is not enabled.

    Because of this, there is no Kerberos Key Distribution Center (KDC) available to issue a ticket for:

    cifs/<storageaccount>. file.core.windows.net

    Microsoft docs:

    Enable Microsoft Entra Kerberos authentication for hybrid and cloud-only identities (preview) on Azure Files

    Enable Microsoft Entra Kerberos authentication for hybrid identities on Azure Files

    NOTE: There is no supported Kerberos authentication source configured for Azure Files SMB access**.**

    Until a valid Kerberos identity source is provided, Azure Files cannot authenticate user credentials, and access will continue to fail.

    The Recommended scenarios is to Enable Microsoft Entra Kerberos for Azure Files


    Can you please update us if the action plan provided was helpful?

    Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

    If these answer your question, click "Upvote" and "Accept Answer" which may be beneficial to other community members reading this thread.


1 additional answer

Sort by: Most helpful
  1. Q&A Assist
    2026-03-11T16:27:29.3233333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    For SMB over P2S VPN, the VPN connectivity test succeeding but SMB access being denied typically indicates an authentication/identity issue rather than pure network reachability.

    From the provided context, a common cause is how SMB/Kerberos/NTLM behave when the client is connected over VPN and cannot properly reach a domain controller or use cached domain credentials. In this situation, the client may fail to fall back from Kerberos to NTLM and ends up with access denied when trying to reach file shares.

    The documented workaround is to disable caching of domain credentials on the client so that SMB authentication can proceed correctly over the VPN:

    1. On the Windows client, open Registry Editor.
    2. Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    3. Create or edit the DisableDomainCreds DWORD value.
    4. Set DisableDomainCreds to 1.
    5. Reboot the client and test SMB access to the Azure file share again over the P2S VPN.

    This change forces the client not to rely on cached domain credentials, which helps SMB authentication succeed when the client is connected via VPN and cannot use normal Kerberos flows.

    If SMB access is still denied after this change, verify separately (outside the VPN issue) that the storage account permissions and firewall/IP rules allow the client IPs or private endpoints used by the P2S clients, and that the correct credentials (storage key/SAS/identity) are used when mounting the share.


    References:


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.