Storing FSLogix Profile Containers on Azure Files with Microsoft Entra Kerberos — Cloud-Only / External Identities

If your AVD environment is built entirely on cloud-only or external Entra ID identities — no on-prem AD, no Entra Domain Services — you can still give users FSLogix roaming profiles on Azure Files. Microsoft Entra Kerberos handles the ticket issuance, so the storage account can authenticate users over SMB without any line-of-sight to a domain controller.

This walkthrough covers the full path: storage account setup, Entra Kerberos configuration, session host registry settings, and a validation step at the end.

Before you start: Microsoft is shifting the default Kerberos encryption from RC4 to AES-SHA1 as part of the April 2026 Windows Server update. If your file share isn’t already upgraded to AES-SHA1, plan that upgrade before this rollout — otherwise you risk access issues on shares hosting FSLogix containers once the update lands. Worth checking the FSLogix blog’s Kerberos hardening notice if you haven’t already.

Prerequisites

• An Azure subscription with rights to create storage accounts and app registrations in Entra ID.
• A system with network line-of-sight to a domain controller is not required for the session hosts — but you will need one machine with that line-of-sight if you’re also touching any hybrid pieces during setup.
• Confirm your environment meets Azure Files’ requirements for Entra Kerberos with cloud-only/external identities before you begin (Microsoft maintains a prerequisites checklist — worth a quick pass).

Part 1: Configure the Storage Account and File Share

Step 1 — Create the storage account

Spin up a new Azure Storage account if you don’t already have one dedicated to FSLogix profiles.

⚠️ Important: A storage account can only use one identity-based authentication method. If you later want to move to AD DS or Entra Domain Services, you’ll need a separate account — Entra Kerberos and a second method can’t coexist on the same storage account.

Step 2 — Create the file share

Under that storage account, create the file share that will host your profile VHDX(s). For cloud-only/external identities, this is the share where you’ll later use the Manage access control (see Step 4) instead of classic NTFS ACLs.

Step 3 — Enable Microsoft Entra Kerberos authentication

This is the core step and breaks into three parts:

1. Enable Entra Kerberos on the storage account. This auto-creates an Entra ID app registration for the storage account and lets you assign directory/file-level permissions to Entra-managed groups.
2. Assign share-level permissions. For cloud-only/external identities, once Entra Kerberos is enabled you’ll see a Manage access tab on the file share — that’s the recommended path here (rather than default share-level permissions or Azure RBAC roles, which are more the hybrid-identity pattern). Use it to add Entra users, groups, or specific security IDs.
3. Set NTFS-style permissions for the profile containers. Follow FSLogix’s recommended permission set so users can create/use their own profile while admins retain management rights over the share.

Step 4 — Configure the app registration

A few settings on the auto-created app registration need attention:

1. Grant admin consent to the new service principal — without this, users can’t silently request Entra ID tokens for the storage account during logon.
2. Disable MFA on the storage account. Token/ticket acquisition happens silently at logon; there’s no UI for step-up authentication, so MFA here will just break sign-in.
3. Add the cloud-only groups tag to the app manifest. This is the step that’s easy to miss and is specific to cloud-only/external identities: add kdc_enable_cloud_group_sids to the tags array in the app manifest. Without it, Entra will only include on-prem groups in the Kerberos ticket — cloud-only groups won’t show up, and permission checks against them will silently fail.

Part 2: Configure the Session Hosts

Step 5 — Enable Cloud Kerberos Ticket Retrieval

Session hosts need this turned on before they can pull Entra Kerberos tickets. Pick whichever fits your management stack:

• Intune (recommended for AVD): Deploy the Kerberos/CloudKerberosTicketRetrievalEnabled policy CSP via the Settings Catalog. Multi-session Windows client OS now supports this through Settings Catalog specifically.
• Group Policy: Administrative Templates\System\Kerberos\Allow retrieving the cloud kerberos ticket during logon (naming varies slightly by Windows version).
• Manual/image-baked registry:
• reg add

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

Step 6 — Set the credential-key-from-profile registry value

With a roaming profile solution like FSLogix, Credential Manager’s keys need to travel with the profile itself, not stay pinned to one machine — otherwise users are locked to whichever host they first logged into.

reg add

HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

Bake both Step 5’s registry value (if you’re not using Intune/GPO) and Step 6’s value into your golden image, or push via GPO/Intune so every session host picks them up consistently.

Step 7 — Install and configure FSLogix

1. Confirm FSLogix is installed — if you’re on an AVD-provisioned session host image, it’s typically pre-installed already.
2. Set the standard profile container registry values: Enabled = 1, and VHDLocations pointed at your share:
3. \\<storage-account-name>.file.core.windows.net\<file-share-name>

Part 3: Validate

1. Sign in with a test user who’s assigned to an application group on the host pool and has permission on the file share.
2. Use a fresh account for this test, or enable DeleteLocalProfileWhenVHDShouldApply — otherwise a user with an existing local profile on that host will just reuse it, masking whether FSLogix actually mounted the VHDX from Azure Files.
3. In the Azure portal, go to Storage accounts → your FSLogix storage account → File shares → your share.
4. Confirm a folder shows up in the format <user SID>_<username>. That’s your signal the profile container mounted correctly.

Common gotchas

• Forgetting the kdc_enable_cloud_group_sids manifest tag — this is the one setting unique to cloud-only/external identities that’s easy to skip if you’re following hybrid documentation by habit.
• Leaving MFA enabled on the storage account — silent logon breaks immediately.
• Testing with an account that already has a cached local profile, which hides mounting failures.
• Missing the upcoming RC4 → AES-SHA1 Kerberos encryption default change — worth validating your share’s encryption support now rather than after the April 2026 update ships.

If something doesn’t mount cleanly, FSLogix’s troubleshooting guide for old/temp local profiles is the right next stop.

That’s all for today, will see you in my next blog.