Has anyone experienced Azure Files intermittently rejecting SMB access in an Azure Virtual Desktop environment using FSLogix and Microsoft Entra Kerberos?
The same user, session host, storage account, and profile VHD will randomly alternate between working and failing. The issue affects every user and every host in the pool. The environment worked normally for more than six months, and no configuration changes were made before this started.
Failures consistently report: "The user name or password is incorrect." FSLogix logs show that finding the VHD fails with error 1326, followed by LoadProfile failing with FrxStatus 31.
During a failed session, Entra sign-in logs show a successful storage account sign-in, cloud Kerberos diagnostics look healthy, and `klist get cifs/storageaccount.file.core.windows.net` succeeds with a valid Azure Files CIFS ticket. However, running `dir \storageaccount.file.core.windows.netprofiles` still returns the same username-or-password error. About a minute later, the exact same VHD may attach successfully without any changes.
The storage account uses a private endpoint and private DNS zone. There is no storage firewall involved, and `Debug-AzStorageAccountAuth` passes even when run during a failure. The session hosts have connectivity to a domain controller in Azure, but there is no on-premises Active Directory environment. Has anyone found the cause of intermittent SMB failures like this despite apparently valid Entra authentication and Kerberos tickets?
4 Answers
Conditional Access is worth investigating because MFA enforcement is not supported for the Kerberos authentication used by Azure Files. Check the sign-in and Conditional Access logs, and make sure the storage account is excluded from policies that require MFA. Since the mount eventually succeeds, this may not be the root cause, but intermittent policy or token evaluation should still be ruled out.
I would start by checking the private endpoint path carefully. Verify that the hosts consistently resolve the storage FQDN to the expected private address and that the private DNS zone is linked correctly. Also inspect network and application firewall logs, even if no storage firewall is configured. During the failure, run `Get-SmbConnection` to see whether the client is holding a stale connection or using an unexpected authentication state.
There is a private endpoint and private DNS zone. I also ran `Debug-AzStorageAccountAuth` during an active failure and every check passed, so the behavior still seems inconsistent.
For Entra Kerberos, confirm that cloud Kerberos ticket retrieval is enabled on every session host. The registry setting is `CloudKerberosTicketRetrievalEnabled=1` under `HKLMSYSTEMCurrentControlSetControlLsaKerberosParameters`. In some environments it was useful to configure the registry value as well as the equivalent device-management policy, although the setting alone may not explain a problem that comes and goes.
That registry value is already configured on the hosts.
Because every user and host is affected, and there is no obvious per-user credential problem, I would focus on shared dependencies: private DNS resolution, the private endpoint, SMB session reuse, Kerberos ticket timing, and Conditional Access evaluation. Capture `Get-SmbConnection`, name resolution, and Kerberos output both when the mount fails and when it recovers. Comparing those two states may reveal a stale SMB session or a temporary backend or network-path issue that the authentication diagnostic does not detect.
The storage account is already excluded from the MFA-required policy. I am also checking whether the affected users need to be excluded separately, rather than excluding only the storage account.