Intermittent FSLogix Profile Attachment Failures with Azure Files and Entra Kerberos
Asked by
MellowPine47
Has anyone seen Azure Files intermittently reject SMB access in an Azure Virtual Desktop environment using FSLogix and Microsoft Entra Kerberos? The same user, session host, storage account, and profile VHD randomly alternate between working and failing, and the issue affects every user and host in the pool. The environment worked normally for more than six months without any intentional changes.
When it fails, FSLogix reports "The user name or password is incorrect," with error code 1326 and FrxStatus 31 while searching for the profile VHD. During the failure, Entra sign-in logs show successful authentication, cloud Kerberos diagnostics look healthy, obtaining a CIFS ticket for the storage account succeeds, and the ticket is present. However, accessing the Azure Files share from the host still returns the same username-or-password error. About a minute later, the exact same VHD can attach successfully without any configuration changes.
The storage account uses a private endpoint and private DNS zone, with no storage firewall involved. Running the Azure Files authentication diagnostic command during a failure reports that all checks pass. The hosts also have connectivity to an Azure-based domain controller, although there is no on-premises Active Directory environment. Has anyone identified a cause for this kind of intermittent SMB failure despite apparently valid Entra authentication and Kerberos tickets?
Answers
Make sure cloud Kerberos ticket retrieval is enabled on every session host. The registry setting CloudKerberosTicketRetrievalEnabled under HKLMSYSTEMCurrentControlSetControlLsaKerberosParameters can be useful even when the equivalent device-management policy is already configured. A reboot or policy refresh may be needed after changing it.
Reply to this answer
Since the storage account uses a private endpoint, I’d verify the private DNS resolution and check whether the client is consistently reaching the expected private address. During a failure, inspect active SMB sessions with Get-SmbConnection and look for a stale connection or an unexpected server path. Network and application firewall logs are also worth checking, even if no storage firewall is configured. Running the Azure Files authentication diagnostic while the problem is occurring is a good step, but a passing result doesn’t necessarily rule out a transient SMB or connection-state issue.
MellowPine47: The private endpoint and private DNS zone are already configured, and the authentication diagnostic passed even while the attachment was failing. There is no storage firewall in the path, so I’m focusing on connection state and intermittent name-resolution or SMB behavior.
Reply to this answer
Conditional Access is another important check. MFA enforcement on the storage-account Kerberos authentication path is not supported and can cause Azure Files access failures. Review the sign-in and Conditional Access logs, and ensure the storage account is excluded from policies that require MFA. Depending on how the policies are scoped, also verify that the affected users or groups aren’t still being targeted by another overlapping policy.
MellowPine47: The storage account is already excluded from the MFA-required policy. I’m checking whether another policy targeting the users or groups could still be affecting the Kerberos flow, although the fact that access begins working again shortly afterward makes this less certain.
Reply to this answer
Because this affects all users and hosts, it’s unlikely to be a single-user profile or isolated client problem. I’d still confirm the domain-controller connectivity and review Kerberos and SMB events on a host during both a failed and successful attempt. Comparing the tickets, resolved storage address, and existing SMB sessions between those two moments may reveal what changes during the minute before the VHD attaches.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowPine47: That registry value is already present on the hosts, so it doesn’t appear to explain the intermittent failures.