Recently I’ve been working on creating a new Azure Virtual Desktop environment utilizing the latest features that allow for Azure AD Joined Session Hosts and management with Microsoft Intune.
For this environment, we’re utilizing FSLogix Profile Containers to allow for profile roaming between hosts; traditionally, one would create an Azure Files share, join this to on-premises Active Directory and then configure the appropriate ACL permissions.
Recently Microsoft introduced Azure AD Kerberos, a new way to authenticate without the requirement to authenticate against an on-premises domain. For an in-depth breakdown of how this works, I’d recommend this blog post by Stephen Syfuhs – How Azure AD Kerberos Works (syfuhs.net)
Microsoft provides step-by-step instructions on configuring the file share to utilize this authentication and outlines the configuration required on the clients to obtain a Cloud Kerberos ticket.
However, I was stumbling across either an error message when attempting to connect (or I was being prompted for my credentials), which indicates that Kerberos authentication has failed and is “falling back” to NTLM.
After some back and forth with Microsoft Support, I discovered that when creating the Azure Files share, I’d selected Maximum Security under Protocol settings which restricted clients to using SMB 3.1.1 with AES-256-GCM encryption and forced Kerberos authentication with a ticket encryption type of AES-256.
Now, this seemed fine at first, and the expectation was that this would be the most secure and compatible setting, as Windows 11 supports SMB 3.1.1 and the other protocols mentioned above. In addition, it is explicitly called out in Azure AD Kerberos documentation that “only AES-256” is supported. However, if AES-128-GCM is disabled as a possible SMB channel encryption protocol, the connection would fail and either prompt credentials or fall back to NTLM.
I’ve requested that this be added to the documentation when configuring Azure Files for authentication with Azure AD Kerberos. However, if encountering a similar issue, try enabling AES-128-GCM under File Shares > Security >Protocol Settings