A file server is a trust decision wearing a disk. The question that matters is not where the bytes live but who vouches for the person asking for them, and Azure Files makes you answer that question once, per storage account, in a way that is expensive to change later. This article is about choosing correctly.
One source of authority per account
Every storage account picks exactly one identity source for SMB, and the choices are mutually exclusive: your on-premises Active Directory, Entra Domain Services, or Entra Kerberos. This is not a setting you toggle experimentally. The source decides which users can authenticate at all, which devices can reach the share with a ticket, what your migration path looks like, and who holds the keys to permission changes. When I design a deployment, this decision comes before sizing, before networking, before cost. Get it wrong and you rebuild the account; there is no in-place conversion worth trusting.
The classic path is domain-joining the storage account to your on-premises AD. The account becomes a computer object, your domain controllers issue the tickets, and only hybrid identities, users synced from AD into Entra ID, can pass. It works, it is mature, and it drags your domain controllers into the availability story of a cloud service: a client that cannot reach a DC cannot authenticate to the share. I still deploy it, but only for estates that are structurally committed to AD for years to come, and I treat it as the path you inherit rather than the path you choose.
Entra Domain Services exists for a narrow case: Azure VMs joined to a managed domain, usually lifted applications that insist on classic domain semantics. It is not a fleet answer and I will not spend more of this series on it.
Entra Kerberos is the modern path, and until recently it carried an asterisk large enough to disqualify it for the very organizations it seemed built for. Entra ID itself acts as the ticket authority: your device requests a service ticket for the share from the cloud realm, KERBEROS.MICROSOFTONLINE.COM, and no domain controller participates. The asterisk was that it only worked for hybrid identities. A cloud-native company, the kind with no AD at all, was locked out of the modern path to its own file shares. That ended May 19, 2026, when Entra-only identity support went GA. Cloud-only users, cloud-only groups, tickets from the cloud, ACLs edited in the portal. For a cloud-native estate this is now the only defensible choice, and for a hybrid estate it is usually the better choice too, because it removes the domain controller from the mount path while your synced identities keep working.
The device matrix, stated plainly
Identity sources authenticate users, but the device in their hands decides whether the handshake can happen at all, and this is where deployments quietly fail. Entra Kerberos requires the device to be Entra joined or hybrid joined. A machine that is joined only to on-premises AD, with no Entra registration, cannot use it, and neither can a device joined to an Entra DS managed domain. In the other direction, the classic AD DS path does not care about Entra join but demands unimpeded connectivity to a domain controller at mount time.
For cloud-only identities specifically, the client floor is higher than most fleets expect: Windows 11 24H2 or later with current updates, or Windows Server 2025. Windows 10 does not work with cloud-only identities, full stop, though it remains supported on the hybrid-identity path. If your fleet still carries Windows 10 and you have no AD, your file share project has just become a Windows 11 project first, and it is better to know that in the design meeting than in the pilot.
The storage account key is not an identity. It is a skeleton key with no name attached, no MFA in front, and full control behind. Retiring it from daily use is the first real security decision you make on this platform.
Two layers of permission, and who may edit them
Authorization on Azure Files runs through two gates, and the stricter one always wins. The first gate is Azure RBAC at the share level: a small set of roles, reader, contributor, and elevated contributor, that decide whether an authenticated identity may enter the share at all. The second gate is the NTFS ACL on every directory and file, the same DACL model your file server has enforced for twenty years, migrated intact if you copy it correctly. I treat the RBAC layer as a coarse bulkhead, one or two groups per share, and let ACLs do the real modeling, because that is the arrangement your existing permission structure already assumes.
The operational question is who can edit the ACLs and with what tool, and here the platform shows its age lines. On the AD DS path you manage permissions with the tools you already know, File Explorer and icacls, against a live DC. With cloud-only identities those tools do not work at all; the portal’s Manage access view and the REST-based RestSetAcls PowerShell module are the supported editors. This sounds like a footnote and is not: your help desk’s muscle memory for right-click, Properties, Security does not transfer to a cloud-only share, and the build sheet that follows this article exists partly to rebuild that muscle memory on the new tools.
Cloud-only groups carry one piece of ceremony worth knowing before it burns you: the storage account’s Entra application needs a manifest tag before group SIDs are included in tickets, and a user carrying more than 1,010 group SIDs cannot get a ticket at all. Deeply nested group estates hit this in production; flat, purposeful share groups do not, which is one more argument for naming discipline over group sprawl.
The limitation that shapes the architecture
Now the sentence that should be in every Azure Files article and almost never is: the SMB flow does not support multifactor authentication. Kerberos ticket issuance for the share cannot satisfy an MFA grant, and if a Conditional Access policy demands MFA of the storage account’s application, mounts fail with system error 1327. Microsoft’s own guidance is to exclude the storage app from MFA policies. That exclusion is not a workaround; it is the documented design, still true after the Entra-only GA.
Sit with what that means. The identity layer can tell you who someone is, with phishing-resistant credentials on the device sign-in if you have done Windows Hello properly, but the file share itself will never challenge them again. If your security model requires a second factor between a compromised session and the finance share, that control cannot live on the SMB flow. It has to live on the path the traffic takes: a VPN that demanded MFA at connect time, or Global Secure Access applying Conditional Access to the network segment that carries port 445. That is why the next article in this series is about networking, and why I refuse to discuss Azure Files identity and networking as separate decisions. The identity source authenticates; the access path is where enforcement lives.
The remaining honest limitations: no cross-tenant access, guest identities only in narrow AVD profile scenarios, and the storage account key sitting underneath everything as a break-glass superuser that bypasses every ACL. Guard the key like the domain admin password it effectively is, plan its rotation, and design your daily operations so nobody needs it. The build sheet that follows puts all of this into practice: named groups, real ACLs, the manifest tag, the CA exclusion, and a validation pass that proves a cloud-only user sees exactly what the ACL says and nothing more.
Azure Files
‹ Previous: [AF 1.1] Build Sheet: Your First Azure File Share
Next: [AF 2.1] Build Sheet: Cloud-Native Identity for Azure Files ›
