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()

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

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
  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
  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.

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.

28 thoughts on “Configuring Azure AD Kerberos authentication on Azure file shares for Windows devices”

  1. Great article! I hope that my comments won’t be out of scope: if I want to do the same action but I have not ad, only aad. What can I do? Because at now, the only solution that I found is ZeeDrive. Could you support me?
    Thank you

    Reply
    • Hi Emanuaele,
      This solution indeed requires a hybrid identity. There are however more options for authentication, including Azure AD DS. If that’s not an option, you indeed need to rely on third-party solutions, or SharePoint/OneDrive.
      Regards, Peter

      Reply
  2. has anyone figured out how to implement friendly cnames for azure file shares? it would help greatly when migrating from a legacy fileserver (when users rely on unc paths)

    Reply
  3. Hello Peter,

    A customer have different file shares on Azure Files, one of them is an archive share. They want to setup that share as read only (except for one user). I thought this would be the solution, but unfortunately they still need an AD, while the customer just want to get rid of all the servers.
    The reason they want it on read only is that there are a lot of write actions (costs) which are not necessary. Of course a solution would be to setup Azure AD DS, but that comes also with a cost.
    What would be your advice in this case?

    Regards,
    Willem

    Reply
  4. Excellent tutorial thanks.
    Having one glitch – adding a group into a role for the share access does not seem to work.
    Tried groups sync’d from local AD, and also tried creating directly in cloud. User in these groups do not get permission, adding the user directly and access is fine.
    Anyone had similar and figure out what was going wrong?

    Reply
  5. This worked before, but recently Config profile ./Device/Vendor/MSFT/Policy/Config/Kerberos/CloudKerberosTicketRetrievalEnabled shows success on my client, but reg key is under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters is not set anymore.

    Reply
    • Having this issue as well although only recently configured. The OMA-URI above sets the registry key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters which is not working for us. But during testing, manually adding the reg key to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters allowed it to work as expected.

      Was the kerberos.admx previously pointing to the Lsa location I wonder?

      Reply
  6. I am missing one thing.. What if your client isn’t windows.. Then CloudKerberosTicketRetrievalEnabled doesn’t work and you are dependent of DNS records.

    But what to use as servername in this SRV records for use with EntraID / AzureAD?

    _kerberos._udp.dc._msdcs 0 100 88 servername.domain
    _kerberos._tcp.dc._msdcs 0 100 88 servername.domain
    _kerberos._udp 0 100 88 servername.domain
    _kerberos._tcp 0 100 88 servername.domain
    _kerberos-master._udp.dc._msdcs 0 100 88 servername.domain
    _kerberos-master._tcp.dc._msdcs 0 100 88 servername.domain
    _kerberos-master._udp 0 100 88 servername.domain
    _kerberos-master._tcp 0 100 88 servername.domain

    Reply
      • ChromeOS and Windows with Google Credential Provider for Windows (GCPW).
        The last one changes the Gina of Windows so you can login to windows with your Google account.
        Single Sign-On with the webbrowser is working fine. But it would be nice if we could let it work for some fileshares too. The Windows pc’s/laptops are not domain joined with a windows domain controller. They are part of the Google MDM that manage these machines.

        One note.. Our primary enviroment is Google Workspace for Education Plus. But we also have an Microsoft 365 A3 enviroment that uses single sign-on with the google account but we rarely use.

        Reply

Leave a Reply to Peter van der Woude Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.