How to Configure FSLogix with Entra ID Cloud-Only Identities in Azure Virtual Desktop

Managing FSLogix profiles with Entra ID cloud-only identities in Azure Virtual Desktop (short AVD) is crucial for organizations looking to provide a seamless and secure user experience in their cloud-only desktop environment. AVD is a desktop and app virtualization service running in Azure, serving as the successor to Microsoft’s legacy Remote Desktop Services (short RDS). AVD offers simplified management, multi-session client operating systems, optimizations for Microsoft 365 Apps, and robust support for large desktop-as-a-service environments in the cloud. With AVD, organizations can deploy and scale Windows desktops and apps on Azure in minutes while benefiting from built-in security and compliance features like Microsoft Defender or Microsoft Intune.

To manage user profiles for AVD users, the ideal solution is FSLogix, particularly for multi-session AVD hosts. By utilizing FSLogix on Azure File Share, organizations can store FSLogix profiles in Azure. Azure Files (a service in Azure Storage Account) provides fully managed file shares that are accessible via the industry-standard Server Message Block (short SMB) protocol or other protocols too.

However, when managing FSLogix profiles with Entra ID cloud-only identities, organizations often encounter a significant challenge: the inability to set Access Control Lists (short ACLs) on Azure File Shares. Without the ability to define ACLs, managing user access and overall security of FSLogix profile containers becomes problematic.

This blog outlines the supported workarounds, including a practical step-by-step setup guide for enabling FSLogix profiles with cloud-only Entra ID identities.

Authentication Methods for Azure File Shares

Azure File Share supports three types of authentication methods:

• Microsoft Entra ID Domain Services (short Entra ID DS) authentication: This method integrates Azure Files with Entra ID DS. It provides NTFS-like ACLs (Access Control Lists) to your Azure file shares over SMB.

• Microsoft Entra ID (short Entra ID) authentication: This method allows you to use Entra ID credentials to authenticate and authorize for Azure file share access over SMB. With this method it is necessary to have hybrid identities to set the ACLs and access the file shares over SMB (Kerberos).

• Active Directory Domain Service (short AD DS): This method allows you to use your on-premises Active Directory (short AD) credentials for authenticating to Azure file shares. You have to integrate the file share to your on-premise AD with a computer account.

Each authentication method has its own use cases and can be chosen based on the requirements of your specific environment. For more information about authentication methods, visit our blog post: Understanding Authentication Methods for Azure Virtual Desktop

The Challenge with FSLogix and Entra ID Cloud-Only

As mentioned earlier, in a cloud-only environment, using Azure File Shares with Entra ID cloud-only identities presents a significant challenge: you cannot set Access Control Lists (short ACLs) on Azure File Shares due to the lack of Kerberos authentication for the SMB protocol. This limitation directly impacts the ability to securely manage FSLogix profile containers, as proper access control is critical for isolating and protecting user profiles—especially in multi-session scenarios.

Traditionally, overcoming this limitation requires hybrid identities—accounts synchronized from on-premises Active Directory—or the use of Entra ID Domain Services, which provides Kerberos and NTLM support in the cloud. These setups enable the use of traditional Windows authentication methods, including ACLs, on Azure File Shares.

However, Microsoft recognizes the growing demand for fully cloud-native environments and has introduced an official workaround for this scenario. In cloud-only environments where native Kerberos authentication is not available, the supported method for accessing FSLogix profile containers on Azure File Shares is by using the storage account access key in a system context (more to that later in this post). This approach bypasses the need for identity-based authentication and allows AVD session hosts to mount the file share using the access key, enabling FSLogix to function as expected.

While this method does not provide user-level access control via ACLs, it offers a practical solution for deploying FSLogix in cloud-only environments. Organizations should ensure that access keys are stored securely—preferably in Azure Key Vault—and rotated regularly to maintain security best practices.

Workaround for Managing FSLogix Profiles with Entra ID Cloud-Only

There are three primary workarounds for managing FSLogix profiles in a cloud-only AVD environment, each with its own pros and cons:

1. Use Entra ID Domain Services
   This option enables Kerberos authentication in a cloud-only setup, allowing you to set NTFS ACLs on Azure File Shares.
   ⚠️ However, I don’t recommend this at all. Entra ID DS adds significant complexity and overhead to management, especially compared to the alternatives. It’s often considered difficult to maintain and troubleshoot—something to carefully evaluate before adopting.

2. Deploy Active Directory with Entra ID Connect
   Set up a lightweight Active Directory on a small B-Series VM in Azure and sync it to Entra ID using Entra ID Connect. This hybrid approach reintroduces Kerberos and enables traditional ACL-based access control without the complexity of Entra ID DS. It’s a reasonable compromise when full identity integration is needed, and it remains simpler to manage than Entra ID DS.

3. Use the Storage Account Access Key (Cloud-Only)
   This is the simplest and most cost-effective solution. It avoids both hybrid identity and Entra ID DS altogether by authenticating FSLogix profile access using the storage account access key via the session host’s system context.

Step-by-Step: Setting Up FSLogix Profile Containers with Cloud-Only Identities

1. Create the Azure Storage Account
   • Use a Premium File Shares storage account for better performance and scalability.
   • Ensure the storage account is not publicly accessible. Use Private Endpoints to securely connect the storage account to your AVD subnet.
2. Create the File Share
   • In the storage account, create a new file share for FSLogix profile containers (e.g., fslprofiles or profiles).
3. Configure File Share Security Settings
   • Navigate to File Share Settings > Security.
   • By default, the security level is set to Maximum compatibility.
   • Change this to Custom, and configure:
     • Supported SMB protocol versions (only 3.1.1)
     • Authentication mechanisms (NTLM v2)
     • Encryption settings (AES-128-GCM and AES-256-GCM)
   • Use least privilege configurations suitable for FSLogix with cloud-only identities.
4. Assign RBAC Permissions
   
   • Assign AVD users the built-in Storage File Data SMB Share Contributor role on the file share (not on the storage account itself) to allow necessary access.

NOTE: You don’t have to set up the Identity-based access on the Storage account. This setting has to be configured only if you have Entra ID hybrid identities or AD DS or Entra ID DS.

Use Storage Account Access Key

Since users cannot authenticate via Kerberos in a cloud-only setup, FSLogix cannot access the profile container under the user context. Instead, you’ll configure the session host to authenticate using the system account and the storage account access key.

1. Copy the access key
   • Copy the storage account name and access key from the Azure Portal.
     
2. (Optional but Recommended) Temporarily Disable Microsoft Defender on Session Host

   • If you’re managing Microsoft Defender via Intune or Group Policy, temporarily disable real-time protection on the session host(s) you’re about to configure.
     Why? Defender may block or interfere with the execution of PsExec, which you need for configuring credentials in the system context.

3. Connect to your session host via RDP
   • Download the PsExec tool from Sysinternals.
   • Save the PSExec files to a location, where you have access.
   • Open cmd as administrator, navigate to the PSExec file location and run: psexec /s powershell.exe
     • This command starts the PowerShell in a SYSTEM context.
4. Add Storage Credentials Using cmdkey
   • Run the following command in SYSTEM PowerShell, replacing placeholders: cmdkey.exe /add:<your_storage_account>.file.core.windows.net /user:localhost\<alias> /pass:<your_storage_key>
   • Example: cmdkey.exe /add:duostoprodchnorth001.file.core.windows.net /user:localhost\avdaadstorage /pass:xxxxxxxxxxxxxxxx
     

Important Consideration

This workaround must be applied every time a new session host is deployed to the AVD host pool. If you apply it before running Sysprep on a golden image, the configuration will be lost. Always apply it post-deployment or use automation (e.g., via Intune or scripts) to reapply it.

Configure FSLogix

Finally, you have to configure FSLogix itself. You can configure FSLogix either through Microsoft Intune (recommended for centralized management) or directly via the Windows Registry on each session host. Below you’ll find guidance on both methods, including required registry settings and best practices for AVD environments.

1. Configure FSLogix to Use Computer Account
   • By default, FSLogix accesses the profile share using the user context. In cloud-only environments without Kerberos support, this leads to authentication issues. To resolve this, configure FSLogix to use the system (computer) account for authentication:​ New-ItemProperty -Path "HKLM:\SOFTWARE\FSLogix\Profiles" -Name "AccessNetworkAsComputerObject" -Value 1 -Force
2. Prevent Windows 11 22H2 from Removing Configuration (Credential Guard)
   • Windows 11 22H2 and newer versions may enable Credential Guard by default, which can interfere with FSLogix accessing network resources via the system account. To ensure FSLogix continues working after a host is reallocated or rebooted, disable Credential Guard with the following registry key:​ New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "LsaCfgFlags" -Value 0 -Force
   • NOTE: This setting can be included in your golden image or deployed via Intune if the hosts are Intunemanaged.Disabling Credential Guard may have security implications. Ensure that no other policy or security baseline is re-enabling Credential Guard, as it will override this registry setting.
3. Configure Additional FSLogix Settings
   • Set the following recommended registry settings to optimize FSLogix performance:​

$VHDLocations = "\\<STORAGE-ACCOUNT-NAME>.file.core.windows.net\<SHARE-NAME>"
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name Enabled -PropertyType DWORD -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name DeleteLocalProfileWhenVHDShouldApply -PropertyType DWORD -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name FlipFlopProfileDirectoryName -PropertyType DWORD -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name LockedRetryCount -PropertyType DWORD -Value 3 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name LockedRetryInterval -PropertyType DWORD -Value 15 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name ProfileType -PropertyType DWORD -Value 0 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name ReAttachIntervalSeconds -PropertyType DWORD -Value 15 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name ReAttachRetryCount -PropertyType DWORD -Value 3 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name SizeInMBs -PropertyType DWORD -Value 30000 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VHDLocations -PropertyType String -Value $VHDLocations -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VolumeType -PropertyType String -Value "vhdx" -Force


Implement Redirections.xml for Profile Optimization

To manage the size of FSLogix profile containers and enhance application performance, implement a redirections.xml file to exclude unnecessary folders (e.g., Teams cache, browser caches) from being redirected.

• Create a redirections.xml file with the desired exclusions.
• Place the file in a central location accessible by users (e.g., seperate file share or same file share as profile container).
• Ensure users have read permissions to the XML file.
• Configure FSLogix to reference the redirections.xml file by setting the RedirXMLSourceFolder registry key.

Note: The redirections.xml file is processed during user sign-in and sign-out. Changes to the file take effect upon the next sign-in. ​For more details on creating and implementing redirections.xml, refer to the Microsoft documentation: Custom profile redirections.xml – FSLogix

Configure FSLogix via Intune

You can automate the FSLogix configuration using Intune and a configuration profile. This is especially useful in environments managing AVD hosts at scale. Find the configuration profile and supporting resources in this GitHub repository: FSLogix Intune Configuration Profile – GitHub Repository

This repository includes:

• FSLogix settings for profile containers.
• Redirections.xml file for optimized folder redirection and exclusions.
• Intune deployment-ready templates.

Verify FSLogix Profile Container Configuration

After configuring FSLogix, verify the setup:​

1. Sign in as a standard user.

2. Open Command Prompt and navigate to the FSLogix Apps directory:​ cd "C:\Program Files\FSLogix\Apps"

3. Run the following command to list active redirections:​ frx list-redirects

4. Open Azure Portal and navigate to the path specified in VHDLocations.

5. Locate the folder corresponding to the standard user and verify the presence of the newly created VHDX container.

Security Considerations regarding the Workaround

But how secure is this workaround you may ask yourself now?

• Users can’t access other profiles since they don’t have permissions on the file share
• Only the system context has access, not standard users
• Local admins can run code in system context, so protect those roles
• Avoid using Contributor RBAC where not needed, as it allows VM command injection

If a local admin account is compromised, profile access becomes the least of your concerns—so secure admin roles.

Conclusion

Managing FSLogix profiles with cloud-only Entra ID is completely feasible—without hybrid identity or Entra ID DS—using the Storage Account Access Key method. While it trades per-user ACL control for simplicity and cost-effectiveness, it’s secure, scalable, and ideal for modern, cloud-native environments.

---

Sources:

• Overview of Azure Files identity-based authentication options for SMB access
• Using FSLogix file shares with Azure AD cloud identities in Azure Virtual Desktop – cloud-only, AVD