Another Reason Why The AVD Session Hosts Are Failing To Load FSLogix User Profiles

Azure Files plays a big role in the Azure Virtual Desktop depolyments and for FSLogix to work in the intended way, the storage account needs to be joined to the domain. It can be either extending the on-premises domain to Azure by setting up a domain controller in the respective region or by setting up Azure AD Domain Services feature.

In my case, I setup a Windows Server 2019 domain controller in the same region that I setup the Azure Virtual Desktop environment.

Bit of a background

My steps involved in creating the Storage Account and the Azure Files share where I want to save the profile containers and finally joining the said storage account to the domain.

Domain join was successful and added the user groups from “Access Control (IAM)” to the relevant SMB roles.

---

Soon after joining the domain I was able to map the drive by using the security key and was able to assign the NTFS permissions.

When I logged on with my user account to a domain joined machine and tried to login to the below method.
\\<storageAccountName>.file.core.windows.net\<fileShareName> and it was just trying and trying, but was not loading my file share.

Things I checked

• No funny NSG rules
• VHD Locations are setup in the FSLogix GPO
• 445 SMB port was opened and telnetting to the file share UNC location was successful
• No firewall rules
• Domain joined Storage Account had the corelating computer object created in the Active Directory
• Updated to the latest FSLogix version (2105 – 2.9.7838.44263) as installed which has addressed some profile loading time issues (which I thought will resolve my issue)

AVD Login delay as advertised

When I tried login to the Session Desktop, it was painfully slow and was almost stuck in the “Please wait for the FSLogix Apps Services” stage for quite a while.

When it finally logged me in to the session I noticed there are no User Profile Container VHDs mounted in the session host and no Local_username profile in the C:\Users folder.

Event Viewer to the rescue

Trying to browse the \\<storageAccountName>.file.core.windows.net\<fileShareName> location took a while, and finally threw the below error

Logon failure: Target account name is incorrect.

When digged more, found the below event in the System Log
Source: Security-Kerberos
Event ID: 4

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server server_name$. The target name used was server_name$. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (DNS_prefix.dns_suffix) is different from the client domain (DNS_prefix.dns_suffix), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

---

Reason

This problem occurs because the file share cannot decrypt the ticket that was encrypted in AES256.

However the support article suggests to change the below registry key to be 0x7fffffff in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\parameters

Ideally the Domain Controller set to support only AES128_HMAC_SHA1, AES256_HMAC_SHA1 and Future encryption types.

Changing the key to the above value to 0x7fffffff will potentially allow legacy Kerberos types which opens the Domain Controller network.

This will basically allow DES_CBC_CRC, DES_CBC_MD5 and RC4_HMAC_MD5

Same could be found from the Local Security Policy settings.
Computer Configuration > Windows Settings > Security Settings > Local Policies > Network security: Configure encryption types allowed for Kerberos option

More on supported encryption type info can be found here

---

What I noticed?

I did play around by enabling and disabling the encryption types and noticed DES_CBC_CRC, DES_CBC_MD5 can be omitted from the equation. However RC4_HMAC_MD5 was the game changer as when this was not selected

---

Fun side of the issue

Even though the official documentation says Azure Files supports Kerberos authentication with AD with RC4-HMAC and AES 256 encryption methods, if you haven’t updated the AzFilesHybrid module to the latest and updated the Storage Account to be compatible with AES 256, you will end up having the legacy encryption RC4-HMAC.

Light bulb moment!💡

This was why my Azure Files Share was not connecting! Because RC4-HMAC encryption was disabled as there were no legacy apps supporting this.

What is RC4-HMAC?

Rivest Cipher 4 with Hashed Message Authentication Code using the Message-Digest algorithm 5 checksum function

Supported in Windows 2000 Server, Windows XP, Windows Server 2003,  Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

A casual warning from Microsoft

Systems that can’t support AES encryption are increasing the risk of the systems in your environment and it’s time to either update, upgrade, or replace systems that are not compliant. (read more)

---

The Fix

1. Download the latest AzFilesHybrid module and save it in the domain controller Download Link
   
   
2. Extract the folder and save it in the C:\AzFilesHybrid folder
   
   
3. Open PowerShell as Administrator and browse to C:\AzFilesHybrid folder
   
   
4. Run \CopyToPSPath.ps1
   
   
5. Run import-module AzFilesHybrid and press ‘Yes’ to the prompt
   
   
6. Install an Import the Az module by running install-module Az and import-module Az
   
   
7. Connect to the tenant Connect-AzAccount, provide credentials
   
   
8. Select-AzSubscription -SubscriptionName “Azure Subscription Name”
   At this stage basically you have your Storage Account joined to the domain so no need to join again
   
   
9. Run below commands to update the required storage account to be compatible with AES 256 encryption.

$ResourceGroupName = “StorageAccountName“
$StorageAccountName = “StorageAccountName“

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Once this is done, log off and login back to the Session Desktop or browse the file share location and should work like a charm.

---

Final Words

1. Session Desktop Login experience was so quick and noticed the local_username folder was creating in C:\Users folder as expected
   
   
2. Can browse \\<storageAccountName>.file.core.windows.net\<fileShareName> with the NTFS permissions
   
   
3. FSLogix User profile container attached to the user profile
   
   
4. Keep only the Supported Encryption Types on the recommended way so no unwanted security risks

Chances are your environment is still using RC4_HMAC_MD5 encryption and you must be looking to remove as recommending by Microsoft, however if you have Storage Accounts for the purpose of having Azure Files, chances are they are connecting with the same RC4_HMAC_MD5 encryption. It is best to revisit the config and make sure they are authenticating with AES 256 encryption so you will not run in to any surprises later.

Feature image from : Loading Vectors by Vecteezy