Using FSLogix with Azure AD Join Storage Accounts

Hello and welcome to the very first post on the Virtual Desktops Community site!! We are hoping to post something at least every week with the latest and greatest news and features!!

In this weeks topic we will be discussing the newely released into public preview Azure AD Join for Azure Files and how it helps with FSLogix. A few months ago Microsoft released the capabilty for us to join our AVD Session hosts to Azure Active Directory. However, the limitation which we hit was that we could not use FSLogix with these session hosts as Azure Files at the time could only support a join to Active Directory Domain Services. For many people this meant that they could not use Azure AD Join as FSLogix is used in a majority of AVD environments, especialy for multi-session desktops.

Last week this barrier got lifted when Microsoft announced that we can now allow Kerberos Authentication against Azure Files storage account to Azure AD.

So in thie blog post we are going to deploy it, try it out and highlight some things you need think about. The deployment steps are all taken from here – Create an Azure file share with Azure Active Directory (preview) | Microsoft Docs

The pre-reqs

Before we get started we need to make sure that we meet all the pre-reqs. These are:

• Windows 11 Enterprise single or multi-session. (which we will be using)
• Windows 10 Enterprise single or multi-session, versions 2004 or later with the latest cumulative updates installed, especially the KB5007253 – 2021-11 Cumulative Update Preview for Windows 10.
• Windows Server, version 2022 with the latest cumulative updates installed, especially the KB5007254 – 2021-11 Cumulative Update Preview for Microsoft server operating system version 21H2.

You also need to ensure that your user accounts in Azure AD are “hybrid user identities”. This means that they need to have been created in Active Directory Domain Services and then synced to Azure AD using Azure AD Connect. If you are unsure then just go into Azure AD and check to make sure that the account is “Directory Synced”

The next thing we need is a storage account, so head over into the Azure Portal and create one if you don’t have one already.

OK once the storage account is created we can now begin the configuration process.

Step 1 – Run the PowerShell scripts

The first thing we need to do is to run the PowerShell scripts listed here – Create an Azure file share with Azure Active Directory (preview) | Microsoft Docs. Before you run those you need to install the Az.Storage and AzureAD Modules. Note, do not use Powershell 7.x for this, use the latest version PowerShell 5.1.

The only variables you need to put in the script are:

• $resourcegroupname = The name of the resource group containing your Azure Files storage account
• $storageaccountname = The name of the storage account

Once you have ran the scripts we should have an Azure Storage Account capable of authenticating against Kerberos!

The scripts perform the following:

• Set the password (service principal secret) based on the Kerberos key of the storage account. The Kerberos key is a password shared between Azure AD and Azure Storage. Kerberos derives the password’s value from the first 32 bytes of the storage account’s kerb1 key

• Connect’s to Azure AD and retrieves the tenant information
• Generates the service principal names for the Azure AD service principal
• Create’s an application for the storage account
• Create’s a service principal for the storage account
• Set the password for the storage account’s service principal

Step 2 – Set the API Permissions

Now that we have enabled the storage account we need to set the API Permissions for the app to read the Azure AD User details. To do this perform the following:

1. Open Azure Active Directory.
2. Select App registrations on the left pane.
3. Select All Applications.
4. Select the application with the name matching your storage account.
5. Select API permissions in the left pane.
6. Select + Add a permission.
7. Select Microsoft Graph at the top of the page.
8. Select Delegated permissions.
9. Select openid and profile under the OpenID permissions group.
10. Select User.Read under the User permission group.
11. Select Add permissions at the bottom of the page.
12. Select Grant admin consent for “DirectoryName”.

You should then have something similar to this –

Step 3 – Configure the Share Permissions

We have 2 options here, we can configure Share-Level permissions at the share level, or we can configure share-level permissions for all authenticated identities. Normally for production environment sit’s best to configure permissions at the share level and restrict it by AD users or groups. As this my test environment I configured Share-level permissions for all authenticated identities. This assigns the share-level permissions to be set the same for anybody who authenticates. To configure this we run:

• ResourceGroupName is the name of the resource group containing the storage account
• AccountName is the storage account

Note, for production environments we strongly recommend using the method of assigning permissions to AD Groups. You can read more here – https://docs.microsoft.com/en-gb/azure/storage/files/storage-files-identity-ad-ds-assign-permissions?tabs=azure-powershell

Step 4 – Configure the NTFS Permissions

Now that we have configured the share permissions we need to set the default NTFS Permissions. We can do this by logging onto a VM which is joined to the Azure AD so we get authenticated to access the share, and then use icacls to assign the default permissions. Before we can dot hat though we need to set some registry settings to allow us to authenticate using Kerberos. I did thia via Nerdio scripted actions and ran then against the host I was logging onto. The registry settings to set are:

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

Once you have set those you need to open up a command prompt and run:

• dsregcmd /RefreshPrt

Lock your Screen and then unlock

run the following 2 commands:

• klist purge
• klist get krbtgt

If it has worked you should see a Kerberos TGT by looking for an item similar to the one highlighted below:

You can now use net use comand to map to the drive and set the permissions via iCACLS. You can view information on how to do that here – https://docs.microsoft.com/en-gb/azure/storage/files/storage-files-identity-ad-ds-configure-permissions

Net use M: \\fslogixstoragead..file.core.windows.net\profile

Step 5: Configure the Session Hosts

OK so now we need to configure the session hosts to enable AD Kerberos functionality. There are 2 registry settings that are required:

• reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1
• reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

You can set these manually, not via Group Policy. Again, I used Nerdio scripted actions.

Step 6 – Configure the FSLogix File path

Again, I did this via Nerdio but the full instructions are here – https://docs.microsoft.com/en-us/fslogix/configure-profile-container-tutorial#configure-profile-container-registry-settings

Step 7 – Test!

OK now everything should be set. We can now log onto a Azure AD Joined AVD Host, and use FSLogix on a storage account which is AD Joined. Pretty cool right!!

Conclusion

Many peope have been waiting a while for this and it’s great to see the advancements that are being made. Azure AD is a huge and complex beast and Microsoft are doing a great job of enabling this functionality.

At this moment in time you still need Active Directory in place to create the hybrid users and groups, but at least now now this gives us the option to use AVD Hosts and FSLogix profiles without having to have line of sight of the domain controllers which means not having to deploy DC’s or VPN links to keep them nearby.