{
"title": "Entra-Only Azure Files SMB GA (May 19, 2026): No AD Needed for Cloud-Only Access",
"content": "Microsoft has officially made Entra-Only identities for Azure Files SMB generally available as of May 19, 2026, marking a pivotal shift for organizations that want to grant identity-based file-share access to purely cloud-native Microsoft Entra ID users without any dependency on Active Directory. The move closes a long-standing gap that forced cloud-only identities to rely on hybrid AD infrastructure, and it paves the way for truly cloud-native file services in Microsoft Azure.

What Is Entra-Only Authentication for Azure Files SMB?

Identity-based access to Azure Files SMB shares previously required either an on-premises Active Directory Domain Services (AD DS) environment or Microsoft Entra Domain Services, a managed domain service. Users and groups had to be synchronized from AD DS to Entra ID via Entra Connect, and the storage account joined the domain. This hybrid requirement was a barrier for organizations born in the cloud or those looking to decommission on-premises AD.

Entra-Only authentication shatters that dependency. It allows Azure Files to authenticate SMB access directly against Microsoft Entra ID, using Kerberos tickets issued by the cloud identity platform. Users and groups that exist solely in Entra ID—whether synchronized from on-premises or cloud-native—can mount SMB shares and be authorized via simple Azure RBAC roles and familiar NTFS access control lists (ACLs). The feature now generally available after a thorough public preview phase, and it supports all standard Entra ID authentication methods, including Windows Hello for Business, FIDO2 security keys, passwordless sign-in, and multi-factor authentication.

How Entra-Only Authentication Works

The magic lies in the Kerberos authentication protocol extended to the cloud. When a user on an Entra ID–joined or Entra ID–registered Windows device attempts to access an Azure Files SMB share, the client receives a Kerberos service ticket from the storage account itself, acting as a Kerberos Key Distribution Center (KDC) proxy. The user first obtains a Primary Refresh Token (PRT) from Entra ID and presents it during the SMB mount request. The storage account validates the token, checks that the user has an Azure RBAC role assignment for the share, and issues a Kerberos ticket that represents the user.

The ticket contains the user’s Entra ID security identifier (SID) mapped from their Entra ID object ID. This mapping is crucial because NTFS ACLs on the file share rely on Windows SIDs. Once the connection is established, file-level permissions are enforced using standard Windows ACLs, which administrators can set by temporarily mounting the share with a storage account key or an existing identity-based path and then assigning permissions using the Entra ID user's or group's SID.

Azure RBAC roles provide the first layer of defense: roles such as \"Storage File Data SMB Share Reader,\" \"Storage File Data SMB Share Contributor,\" and \"Storage File Data SMB Share Elevated Contributor\" govern share-level operations like listing directories, reading files, or changing permissions. Underneath that, NTFS ACLs enable granular control down to individual files and folders, giving IT teams a familiar permission model without the overhead of a domain controller.

Key Benefits Over Traditional AD-Dependent Access

The elimination of on-premises AD DS or Entra Domain Services as a prerequisite delivers several immediate advantages:

  • Cloud-native simplicity: Organizations that never deployed AD or want to retire it can now use Azure Files as a full-featured, identity-aware file service. This is a boon for startups, SaaS vendors, and modern enterprises embracing Zero Trust network models.
  • Seamless modern authentication: Because authentication flows through Entra ID, users can leverage passwordless sign-in, Windows Hello PINs, or FIDO2 keys without any Kerberos delegation complexities. Conditional Access policies, such as blocking logins from unmanaged devices or specific geolocations, apply automatically.
  • Reduced infrastructure footprint: Ditching the need for Entra Connect synchronization, domain controllers in Azure VMs, or the overhead of managing Entra Domain Services saves cost and operational complexity. For hybrid setups that retain on-premises AD, users can still use those identities if synchronized, but the cloud-only option opens the door to a fully modernized stack.
  • Faster provisioning: Creating a new cloud-only user and granting them access to a file share becomes a purely cloud operation—no waiting for synchronization cycles or logon scripts. PowerShell and Azure CLI support enable Infrastructure as Code (IaC) workflows.
  • Secure cross-organization sharing (eventually): While not yet fully realized, this foundation sets the stage for secure, Entra B2B collaboration sharing of Azure Files SMB shares directly between tenants, though today you can achieve similar results with proper cross-tenant access configurations.

Configuration Steps: Getting Started

Enabling Entra-Only authentication on a storage account is straightforward. Using the Azure portal, navigate to your Azure Files storage account, select \"Data storage\" > \"File shares,\" and click \"Identity-based authentication.\" Under \"Active Directory,\" choose \"Microsoft Entra ID for SMB (Kerberos)\" and save. Alternatively, use Azure PowerShell:

powershell Set-AzStorageAccount -ResourceGroupName \"MyResourceGroup\" -Name \"mystorageaccount\" -EnableIdentityBasedAuthentication -ActiveDirectoryProperties $null -DefaultSharePermission \"StorageFileDataSmbShareElevatedContributor\"

Note that the -ActiveDirectoryProperties must be set to $null to indicate Entra-Only.

After enabling, assign one of the SMB share–specific RBAC roles to Entra ID users or groups at the storage account, resource group, or individual share scope. Finally, to configure NTFS permissions, mount the share using the storage account key or an existing identity-based session and use Windows File Explorer or icacls to set ACLs, specifying Entra ID principals by their display name or SID (found via Microsoft Graph or the Entra admin center).

The entire process can be scripted, which is critical for large deployments. Microsoft provides detailed documentation and sample scripts to map Entra ID groups to share-level defaults.

Client and Platform Requirements

Not all Windows configurations are created equal for this feature. At GA, Microsoft supports the following minimum environments:

  • Client OS: Windows 10 version 20H2 or higher, Windows 11 (all editions), Windows Server 2022 and later. The device must be either Entra ID–joined or Entra ID–registered. Hybrid AD–joined devices will also work, but they are not required.
  • Required updates: For Windows 10, the latest cumulative update (LCU) from May 2026 or later ensures the necessary Kerberos Cloud Trust components are present. Windows 11 requires the latest cumulative update that includes the cloud Kerberos trust components. Windows Server 2022 also needs the equivalent servicing update. These updates install the Azure blob key distribution (cloud Kerberos trust) service and the Microsoft Entra ID enhanced authentication provider.
  • Network: The client must be able to reach the storage account’s public or private endpoint (e.g., via Private Link) and also have line-of-sight to typical Entra ID endpoints (login.microsoftonline.com, aadcdn.msauth.net, etc.). Firewall and proxy configurations may need adjustments for seamless ticket acquisition.
  • Storage account region: Entra-Only authentication is supported in all Azure public regions and Azure Government (with an appropriate Entra ID tenant). China 21Vianet and US