FSlogix not working with Entra ID only identity. All settings are there but it keeps failing

Hello Nikhil,

Greetings! Thanks for raising this question in Q&A forum.

I can see exactly what's going wrong here! Looking at your FSLogix log, the key error is:

"The network path was not found" (Error 53)

This means your session host is able to read the FSLogix configuration correctly (it knows to use AccessNetworkAsComputerObject = 1), but when it actually tries to reach the Azure Files share as the computer object, the connection is failing. This is a very common issue in Entra ID-only (no Active Directory) environments and is usually caused by one of a few things missing Kerberos ticket support, incorrect RBAC assignments on the storage account, or the session host not being able to authenticate to Azure Files using its computer identity.

Here's a step-by-step checklist to get this resolved:

1. Confirm your Storage Account is Entra Kerberos enabled

This is the most common root cause. Go to your Storage Account in the Azure portal, navigate to "Data Storage" > "File shares", then click on "Identity-based access" and make sure "Azure Active Directory Kerberos" is enabled. Without this, the session host cannot authenticate using its computer object.

2. Verify RBAC roles on the Storage Account

Make sure the following RBAC roles are correctly assigned on the Storage Account (not just the file share):

• Users → Storage File Data SMB Share Contributor
• Session Host Computer Objects (or the AVD Session Host's Managed Identity / Entra device) → Storage File Data SMB Share Contributor

Go to your Storage Account > "Access Control (IAM)" and verify both are present.

3. Check the Windows ACLs on the file share

Even if RBAC is correct, the NTFS-level permissions on the share itself must also be set. Connect to the share using a privileged account and ensure:

• Users have Modify permission on their own profile folder
• The root of the share allows List Folder / Read Data for all authenticated users

4. Verify the UNC path and share name

Your log shows the path as \\avdexxxx.file.core.windows.net\profilestore\profiles\. Double-check that:

• The file share named profilestore actually exists in your storage account
• The FSLogix registry key VHDLocations under SOFTWARE\FSLogix\Profiles points to exactly \\avdexxxx.file.core.windows.net\profilestore\ with no typos

5. Confirm the session host can reach the storage endpoint

From the session host, open PowerShell and run:

Test-NetConnection -ComputerName avdexxxx.file.core.windows.net -Port 445

If this fails, your session host cannot reach Azure Files over port 445. You may need to check your NSG rules, firewall settings, or confirm that the storage account's private endpoint or public network access is correctly configured.

6. Check if "Allow storage account key access" is disabled

If you disabled shared key access on the storage account, make sure Entra Kerberos is fully set up as a replacement. If Kerberos isn't working yet, temporarily re-enable key access to test connectivity, then re-secure it once confirmed.

7. Review the FSLogix registry settings on the session host

Make sure these registry keys are correctly set under HKLM:\SOFTWARE\FSLogix\Profiles:

Enabled = 1
VHDLocations = \\avdexxxx.file.core.windows.net\profilestore
AccessNetworkAsComputerObject = 1

Once all of these are verified, sign out of the session and sign back in to test again. The error should clear once the session host can successfully authenticate to Azure Files as its computer object using Entra Kerberos.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.

Hey Nikhil, it looks like FSLogix is trying to mount your VHD from the Azure Files share but can’t even hit the UNC path (“network path not found”). When you run cloud-only (Entra ID-joined) session hosts, you need to make sure Azure Files Kerberos and FSLogix are both configured to use your Entra ID identity (computer or user) to authenticate. Here’s a checklist of things to verify:

1. Verify your Entra ID join and SSO on the session host
   • On the VM, run dsregcmd /status • AzureAdJoined should be YES • SSO State (AzureAdPrt) should be YES and recent
   • In the AVD host pool’s RDP Properties > Advanced, confirm Enable single sign-on is checked
2. Enable cloud Kerberos ticket retrieval FSLogix (and Azure Files) depend on the Kerberos TGT for cifs/<storageaccount>.file.core.windows.net. Make sure you’ve enabled: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\ • CloudKerberosTicketRetrievalEnabled = 1 – Deploy via Intune (Settings Catalog CSP) or a GPO: “Allow retrieving the Microsoft Entra Kerberos Ticket Granting Ticket during logon”
3. Confirm Azure Files is set up for Entra ID–based (Kerberos) auth
   • In the Azure portal, open your Storage account > Data storage > File shares > Identity-based access • Should say “Microsoft Entra Kerberos” enabled
   • Assign the Storage File Data SMB Share Contributor role to either: • Your session host’s computer principal (if using machine identity), or • The user (if you switch FSLogix to use user identity)
4. Check DNS & connectivity
   • From the session host, run Test-NetConnection –ComputerName <storageaccount>.file.core.windows.net –Port 445 and Resolve-DnsName <storageaccount>.file.core.windows.net
   • Both name resolution and TCP/445 must succeed
5. Align your FSLogix network-access setting By default FSLogix tries the machine account: HKLM\SOFTWARE\FSLogix\Profiles\AccessNetworkAsComputerObject = 1 If you don’t have a computer object in AD (cloud-only), switch to user auth: • HKLM\SOFTWARE\FSLogix\Profiles\AccessNetworkAsComputerObject = 0 • HKLM\SOFTWARE\FSLogix\Profiles\AccessNetworkAsUser = 1
6. Validate Kerberos ticket for the share After a fresh logon, run klist and look for an entry like: cifs/<storageaccount>.file.core.windows.net
7. (Optional) Load credential keys from the roaming profile If you’re doing roam-identity and need Credential Manager inside the VHD, also set: HKLM\Software\Policies\Microsoft\AzureADAccount\LoadCredKeyFromProfile = 1

Once you’ve walked through those items, retry and then look at your FSLogix text log (C:\ProgramData\FSLogix\Logs\Profile*.log) for any new errors or Kerberos failures.

Hope this helps!

Reference docs

• Troubleshoot Azure Files SMB authentication (identity-based): https://learn.microsoft.com/troubleshoot/azure/azure-storage/files/security/files-troubleshoot-smb-authentication
• Store FSLogix profiles on Azure Files with Entra ID (cloud-only): https://learn.microsoft.com/fslogix/how-to-configure-profile-container-entra-id-hybrid?tabs=cloud-only-or-external-identities
• FSLogix troubleshooting (long/failed sign-in): https://learn.microsoft.com/fslogix/troubleshooting-long-failed-signin
• Azure Virtual Desktop & Entra ID joined VMs authentication: https://learn.microsoft.com/azure/virtual-desktop/authentication
• FSLogix configuration reference: https://learn.microsoft.com/fslogix/reference-configuration-settings

Hi @Jerald Felix @Himanshu Shekhar , Really appreciate your inputs . So the suggested RBAC was present , was able to connect to storage account on 445. AccessNetworkAsComputerObject = 1 value was also there. Using klist I could see the ticket was being isssued

After going through every step, I redeployed it 4 more times with the exact same error.

Finally 5th iteration of deployment worked - I made couple of changes removed "AccessNetworkAsComputerObject"

added HKLM\Software\Policies\Microsoft\AzureADAccount\LoadCredKeyFromProfile = 1

Also the problem with that setup is that as an AVD non admin user, I can view other users folder and rename their directory. I do have the ACLs setup
GRP-AVD-Admins (your admins group) Full Control This folder, subfolders and files

GRP-AVD-Users (your users group) Modify This folder only

CREATOR OWNER Modify Subfolders and files only

Is it because of HKLM\Software\Policies\Microsoft\AzureADAccount\LoadCredKeyFromProfile = 1 ?

No this is not caused by LoadCredKeyFromProfile. The behaviour you’re seeing is due to incorrect NTFS/SMB share permission design, not FSLogix auth mode.

Fix the root of the share like this: Root folder (\share\profilestore):

1. GRP-AVD-Admins - Full Control (This folder, subfolders and files)
2. GRP-AVD-Users - List Folder / Read Data + Create Folders (This folder only)
3. CREATOR OWNER - Modify (Subfolders and files only)

What fixed mounting: AccessNetworkAsComputerObject = 0 (implicitly)

LoadCredKeyFromProfile = 1

1. This simply switched FSLogix to user-based auth instead of computer-based Kerberos
2. It does not impact authorization/ACL behavior

Issue is due to over-permissive NTFS ACL (Modify at root for users), not related to LoadCredKeyFromProfile; restricting root permissions to List + Create folders only resolves cross-user access.