Configuring Azure AD Kerberos authentication on Azure file shares for Windows devices

This week is more Windows. More capabilities for creating a better user experience. This week the focus will be on Azure file shares and the relatively new Azure AD Kerberos authentication option, that can be configured on Windows devices by relying on Microsoft Intune. Azure Files supports the identity-based authentication over SMB, using Kerberos authentication. In preview, that now includes the ability to enable and configure Azure AD for authenticating hybrid identities. That allows users with a hybrid identity, to access Azure file shares using Kerberos authentication. That configuration relies on Azure AD to issue the required Kerberos tickets, to access Azure file shares using the SMB protocol. That basically means that users can access Azure file shares over the Internet, without requiring a line-of-sight to a domain controller. An awesome experience across Windows devices. This post will go into more detail on the required configurations to enable this experience.

Important: Keep in mind that Azure file shares rely on the SMB protocol. That means that devices connect via port 445 over the Internet. That port can be a huge challenge when working from home and relying on an ISP that simply blocks that port by default. Keep that in mind with designing the solution.

Note: The assumption throughout this post is that a Storage account with a file share is already configured.

Enabling Azure AD Kerberos authentication on the Azure file share

When looking at the configuration of enabling the Azure AD Kerberos authentication functionality, it starts with the configuration of Azure Files in the storage account. That includes the configuration of the Active Directory source that contains the user accounts that will access a share in that storage account. Configuring that source will make sure that the preferred method for authentication can be used. That includes the Azure AD Kerberos authentication method. The following five steps walk through enabling Azure AD Kerberos authentication on Azure files.

1. Open the Azure portal and navigate to Storage accounts
2. On the Storage accounts page, select the storage account that should be enabled for Azure AD Kerberos authentication and navigate to File shares
3. On the File shares page, select the configuration state next to Active Directory
4. On the Active Directory page, select Set it up under Azure AD Kerberos
5. On the Azure AD Kerberos blade, as shown below in Figure 1, configure the following settings and click Save
   • Select the Azure AD Kerbers checkbox
   • Domain name: (Optional) Provide the domain name as provide by the script snippet below
   • Domain GUID: (Optional) Provide the domain GUID as provided by the script snippet below

$domInfo = Get-ADDomain $domName = $domInfo.DnsRoot $domGUID = $domInfo.ObjectGUID.ToString()

Figure 1: Overview of the Azure AD Kerberos configuration options

Note: Specify the optional domain name and domain GUID for the on-premises AD, to enable the configuring of file and folder level permissions through Windows File Explorer.

Tip: Make sure to run the provided script snippet with domain administrator permissions to get the right results.

Granting admin consent to the service principal of the Azure file share

Once the Azure AD Kerberos authentication is enabled, the next action is to actually explicitly grant consent to the new Azure AD application, for the Azure file share, that is registered in the Azure AD tenant. The following three steps walk through consenting the required API permissions.

1. Open the Azure portal and navigate to Azure Active Directory > {YourOrganization} > App registrations
2. Select All applications > [Storage Account] {YourStorageAccountName}.file.core.windows.net
3. Select API Permissions, as shown below in Figure 2, and select Grant admin consent for {YourDirectoryName} to grant the required consent

Figure 2: Overview of the app registration and the API permissions

Important: Make sure to disable MFA on the storage account, as users won’t be able to access the file share when MFA is enabled. When not excluded, that will result in system error 1327 when mapping the drive.

Assigning share-level permissions on the Azure file share

When the authentication is configured and the consent is granted, the next action is to configure the users that have access to the particular file share. And the permissions level. Once a user is allowed access to a file share, NTFS permissions can be used on individual files and folders. That enables a more fine-grained control over the permissions on the files and folders. The following five steps walk through configuring a role assignment on the Azure file share.

1. Open the Azure portal and navigate to Storage accounts > select the storage account that is just enabled for Azure AD Kerberos authentication > File shares > select any file share that should be configured
2. On the {YourFileShareName} page, select Access Control (IAM), navigate to Role assignments and click Add > Add role assignment
3. On the Role page, as shown below in Figure 3, select the role of the users – by choosing between Storage File Data SMB Share Contributor, Storage File Data SMB Share Elevated Contributor and Storage File Data SMB Share Reader – and click Next

Figure 3: Overview of the file share role assignment configuration

1. On the Members page, click + Select members, select the required users or groups and click Next
2. On the Review + assign page, verify the configuration and click Review + assign

Note: When no file share is added yet, simply create a file share by using the + File share option and provide a valid name, set the provisioned capacity, and configure the protocol (SMB).

Configuring Windows devices to retrieve Kerberos tickets

When looking at the configuration of Windows devices to actually retrieve a cloud Kerberos ticket during sign-in, a new policy setting is provided via the Policy CSP. That policy settings is CloudKerberosTicketRetrievalEnabled and that setting is currently not yet available in the Settings Catalog. So, at this moment it’s still required to use a custom device configuration profile to configure that policy setting. That policy setting can be configured by using an Integer data type with the simple values of 0 (disable), or 1 (enable). The following nine steps walk through the creation of that custom device configuration profile that will enable the device to retrieve a cloud Kerberos ticket during sign-in, and that is applied to the whole device.

1. Open the Microsoft Endpoint Manager admin center portal and navigate to Devices > Windows > Configuration profiles
2. On the Windows | Configuration profiles blade, click Create profile
3. On the Create a profile blade, provide the following information and click Create

• Platform: Select Windows 10 and later as value
• Profile type: Select Templates as value
• Template name: Select Custom as value

1. On the Basics page, specify a valid Name and optionaly a Description and click Next
2. On the Configuration settings page (see Figure 1), click Add to add a row for the following custom setting and click Next

• OMA-URI setting – This setting is used to enable the device to retrieve a cloud Kerberos ticket during sign-in
  • Name: Provide a name for the OMA-URI setting to distinguish it from other similar settings
  • Description: (Optional) Provide a description for the OMA-URI setting to further differentiate settings
  • OMA-URI: Specify ./Device/Vendor/MSFT/Policy/Config/Kerberos/CloudKerberosTicketRetrievalEnabled as value
  • Data type: Select Integer as value
  • Value: Specify 1 as value

Figure 4: Overview of the custom configuration profile

1. On the Scope tags page, configure the required scope tags click Next
2. On the Assignments page, configure the required assignment and click Next
3. On the Applicability rules page, configure the required applicability rules and click Next
4. On the Review + create page, verify the configuration and click Create

Note: Keep in mind that at some point in time this setting will also become directly available within Microsoft Intune.

Experiencing the Azure file share sign-on on Windows devices

After all the different configurations are inplace, it’s time to experience the Azure file share behavior on Windows devices. That experience requires the use of Windows 11 Enterprise single or multi-session, Windows 10 Enterprise single or multi-session, versions 2004 or later with the latest cumulative updates installed, or Windows Server, version 2022 with the latest cumulative updates installed. The easiest method to experience that behavior, is by simply mapping a network drive to the Azure file share. That should provide a single sign-on experience and make the file share available (as shown below in Figure 5) like any other network mapping.

Figure 5: Overview of the user experience

For a view on the authentication, the IT administrator can use the Azure AD Sign-in logs to verify the authentication and to verify the applied Conditional Access. Even though MFA is not an option, it’s possible to simply require a compliant device for access to the Azure file share. So, a nice smooth integration with a cloud managed and secured device.

More information

For more information about Azure File shares and authentication, refer to the following docs.