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

by

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.

Discover more from All about Microsoft Intune

Subscribe to get the latest posts sent to your email.

38 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
  5. Pingback: Mapping Azure file shares on Windows devices – All about Microsoft Endpoint Manager
  6. Pingback: Excluding Azure file shares from Conditional Access policies requiring MFA – All about Microsoft Endpoint Manager

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

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

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

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

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

  12. Hi Peter, thanks for the article!
    After I setup the Azure fileshare and domainname/guid, CloudKerberosTicketRetrievalEnabled etc it didn’t connect and in wireshark I notices it couldn’t get a kerberos token. I had to run “ksetup /addhosttorealmmap *.windows.net KERBEROS.MICROSOFTONLINE.COM” as admin and restart to make it work. This registers the key:
    “HKLM\SYSTEM\ControlSet001\Control\Lsa\Kerberos\HostToRealm\KERBEROS.MICROSOFTONLINE.COM”
    [reg_multi_sz]SpnMappings:*.windows.net

    Have you seen that before? My system is Windows 10 22H2 and obviously that setting isn’t in there by default.
    Thanks,
    Eric

    Reply

  13. Hi Peter,
    Great article.
    Just a quick one though, in this scenario, I’ve often found that default share permissions lets say Reader, take prescedence over explicit IAM permissions on the share.
    For example, if the default share permission is Reader and I have a IAM of SMB Storage Contributor assigned to a Group. The Users in this group only get assigned Reader permissions, not Contributor. Is there a specific process/niche of being more granular on the permissions to aid security?
    Cheers

    Reply

  14. Hi Peter, this is great. We have deployed this with Entra ID joined machines and Entra Kerberos auth on the Storage Accounts. One additional layer is we have Azure VPN being pushed down by Intune, which also seems to work. However, users are losing access to the drives after an hour, which does appear to be the lifetime of the ticket on issuance. Do you know of a way to extend the ticket lifetime for the storage accounts to say, 10 hours?

    Reply

  15. Hi Peter,

    Thanks your article helped me a lot.
    Got an Azure fileshare working with entra joined windows 11 client.
    one question eventually we want to end in a cloud only solution, without onpremise domain server or managment.
    i have an azure VM Entradomain joined. Using this machine we are unable to set NTFS permissions with Windows Explorer or icacls. is there a solution for this?

    Reply

  16. Great article, anyone looking to push the CloudKerberosTicketRetrievalEnabled via Intune and importing Kerberos.admx, I have tried and failed as that particular entry is one of the forbidden ones. Trying to push that ADMX to the enpoint will end up creating this event under EventViewer\ApplicationsandServices\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Admin in Event Viewer. Event ID is 850 and will tell you that the registery you uploaded is blocked.
    MS article with Intune method:
    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable?tabs=azure-portal%2Cintune#configure-the-clients-to-retrieve-kerberos-tickets

    I have tried your method and it works.

    Reply

Leave a Comment

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