Hello @Rajesh-5359 ,
Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.
I understand that you want to enable access to the Azure file shares through AD authentication from both VM and VPN-connected devices and created a private endpoint connection to make it work with the VPN-connected devices, but AD authentication is not working from VPN connected devices and you are getting the following error "The specified password is not correct".
This issue is mentioned in both Azure Files and Azure P2S VPN troubleshooting documents.
- As mentioned in the Azure Files identity-based authentication troubleshooting doc,
Issue: If you're connecting to a storage account via a private endpoint/private link using Azure AD Kerberos authentication, when attempting to mount a file share via net use or other method, the client is prompted for credentials. The user will likely type their credentials in, but the credentials are rejected.
Cause: This is because the SMB client has tried to use Kerberos but failed, so it falls back to using NTLM authentication, and Azure Files doesn't support using NTLM authentication for domain credentials. The client can't get a Kerberos ticket to the storage account because the private link FQDN isn't registered to any existing Azure AD application.
Solution: The solution is to add the Private Link FQDN to the storage account's Azure AD application before you mount the file share.
For step-by-step process, please refer the below document.
- You can also find this in the Point to site VPN troubleshooting doc which says:
Issue: VPN client cannot access network file shares.
Cause: The SMB protocol is used for file share access. When the connection is initiated, the VPN client adds the session credentials, and the failure occurs. After the connection is established, the client is forced to use the cache credentials for Kerberos authentication. This process initiates queries to the Key Distribution Center (a domain controller) to get a token. Because the client connects from the Internet, it might not be able to reach the domain controller. Therefore, the client cannot fail over from Kerberos to NTLM.
The only time that the client is prompted for a credential is when it has a valid certificate (with SAN=UPN) issued by the domain to which it is joined. The client also must be physically connected to the domain network. In this case, the client tries to use the certificate and reaches out to the domain controller. Then the Key Distribution Center returns a "KDC_ERR_C_PRINCIPAL_UNKNOWN" error. The client is forced to fail over to NTLM.
Solution: To work around the problem, disable the caching of domain credentials from the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableDomainCreds - Set the value to 1
Request you to implement the suggested solution to fix the issue.
Kindly let us know if the above helps or you need further assistance on this issue.
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.