Azure File share with Entra ID cloud identities for FSLogix

Introduction

Azure Virtual Desktop (AVD) is a desktop and app virtualization service running in Azure. It is the successor of the beloved (or hated…) legacy Remote Desktop Service (Infrastructure) of Microsoft. AVD delivers simplified management, multi-session operating systems, optimizations for Microsoft 365 Apps for enterprise, and support for Remote Desktop Services (RDS) environments in Azure. With AVD, you can deploy and scale your Windows desktops and apps on Azure in minutes, and get built-in security and compliance features.

To securely and efficiently manage the users profiles for AVD users there is only one proper solution: FSLogix. Especially for multi-session AVD hosts. When using FSLogix on Azure File Share, you can store the FSLogix profile containers in Azure. Azure Files offers fully managed file shares in the cloud that are accessible via the industry standard Server Message Block (SMB) protocol.

Azure File Share supports three types of authentication methods:

1. Entra ID Domain Services (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.
2. Microsoft Entra ID (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 nessecarry to have hybrid identities to set the ACLs and access the file shares over SMB (Kerberos).
3. Active Directory Domain Service (AD DS): This method allows you to use your on-premises Active Directory (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 scenario.

“The problem” with Cloud only identities

If you want to use cloud only identitiesyou will face a major problem. You can’t set ACLs on the file share. Due to the missing Kerberos authentication to the Azure File Share. The identities have to be hybrid.

Workaround

In some scenarios you don’t have an on-premise AD or the customer is price sensitive. So you can’t deploy a VM with an AD and Entra Sync.

IMPORTANT: This fix has to be done every time a new session host is deployed to the pool. Keep that in mind! If you try to configure it before syspreping a “golden image” the settings will be lost.

1. Create an Azure Storage account. I would recommend creating a “Premium v2 File shares“ storage account. Also make the storage account not public accessible and use private endpoints, to connect it to the AVD subnet.
2. After creating the storage account, create the file share itself for the profile containers. Give the share a name like fslprofiles or profiles.
3. Under File share settings, select Security. If you haven’t modified the security settings, this value is set to Maximum compatibility.
4. Under the Security settings, select Custom. There you have to select the following protocols, authentication mechanisms or encryption. (Use those least privilege settings only when the file shares are used with FSLogix and cloud only identities)
   
5. Afterwards, the AVD users have to have the RBAC role Storage File Data SMB Share Contributor on the Azure File share where the profiles will be stored.
6. For those scenarios there is a simple but effective workaround:
   Copy your Storage Account name and storage key.
7. Connect to your session host and start the PowerShell with the “System” user account.
   • To do so download the PSEXEC Sysinternal tool and run this command via cmd: psexec /s powershell.exe
8.  To successfully “give” the system account those credentials enter your storage account name, the user with the domain localhost and the storage account as well as the key from the storage account.
   • cmdkey.exe /add:hfastoprodchnorth001.file.core.windows.net /user:localhost\avdaadstorage /pass:xxxxxxxxxxxxxxxx
9. In the end, you can configure the FSLogix settings on the session host. Either via Intune or directly on the host via Registry. For more information about which settings to configure for profile containers on AVD visit: Configure profile containers
10. Normally FSLogix will access the share, which stores the profiles, in the user context. But in this case, the user can’t authenticate with their own identity due to the lack of Kerberos. Thus, you have to “train” FSLogix to use the system account (computer account) to authenticate against the storage account. Set the following registry key (either manually or via Intune):

    • New-ItemProperty -Path “HKLM:\SOFTWARE\FSLogix\Profiles” -Name “AccessNetworkAsComputerObject” -Value 1 -force

11. Afterwards the FSLogix user profile redirection will work.

* For Windows 11 22H2 and newer

Security

• Users cannot access their own or other profiles. They don’t have “permission ” on the storage.
• Users (non-local admin) can’t run programs in the system context.
• Every local administrator of a host can run processes in the system context. Those roles have to be protected.
• The RBAC role Contributor with the permisssion Microsoft.Compute/virtualMachines/runCommand/action can send scripts running in the system context to a host/VM.
• The system has permission to access all shares on the storage account with the credentials.

Sources