Azure Files Entra-Only GA — Active Directory Finally Optional for Cloud SMB
Azure Files has reached general availability for Entra ID-only authentication over SMB, eliminating the historical requirement for Active Directory Domain Services when providing shared file storage to Azure workloads. This is a significant milestone for cloud-native organisations and for enterprises modernising away from on-premises identity infrastructure.
The Historical Dependency on Active Directory
Azure Files SMB authentication has historically required either an on-premises AD DS environment joined to the storage account, or Azure Active Directory Domain Services — a managed AD-compatible domain service. Both options carry operational overhead. On-premises AD DS requires maintaining hybrid identity infrastructure, synchronising identities via Entra Connect, and managing domain join for Azure workloads. Azure AD DS provisions a managed domain but introduces additional cost, requires a virtual network with specific DNS configuration, and is architecturally closer to a compatibility shim than a cloud-native identity pattern.
For organisations that never deployed Active Directory — pure cloud-native startups, containerised platform teams, greenfield enterprise subsidiaries — neither option was appropriate. They were effectively locked out of using Azure Files for SMB workloads, or forced to deploy identity infrastructure they had no other use for solely to satisfy the Azure Files authentication requirement.
What Entra-Only Authentication Changes
With Entra ID-only authentication at GA, Azure Files can now use Entra ID as the sole identity provider for SMB access control. Users and service principals authenticate directly against Entra ID using OAuth 2.0 token flows, and share-level and directory or file-level permissions are enforced using Entra identities without any AD intermediary. A containerised workload running in Azure Kubernetes Service can authenticate to Azure Files using a workload identity — a Kubernetes service account federated with an Entra managed identity — without any AD involvement.
Use Cases Now Fully Enabled
Several enterprise use cases that were previously architectural workarounds are now first-class supported patterns:
- Containerised workloads needing persistent shared storage can mount Azure Files using Kubernetes workload identity without requiring the node pool to be AD-joined
- Cloud-born applications in organisations that never deployed on-premises AD can now use Azure Files for shared configuration, media, and data exchange without provisioning Azure AD DS
- Dev and test environments can be fully isolated from production identity infrastructure while still using Azure Files for shared build artefacts and test data
- ISV and SaaS platforms hosting multi-tenant applications can use per-tenant managed identities to isolate Azure Files access without per-tenant AD configurations
Security Model Implications
The security model implications are broadly positive. Entra ID token-based authentication benefits from Conditional Access policies, Privileged Identity Management for elevated share access, and the full Entra sign-in risk detection surface. This is a stronger security posture than Kerberos-based AD authentication for most cloud workloads, particularly where just-in-time access and continuous access evaluation are organisational requirements. For enterprise security architects, Entra-only Azure Files is the recommended target state for new deployments.
Key Takeaways
- Azure Files Entra-only GA removes the last major blocker for cloud-native SMB without Active Directory
- Containerised workloads can now use Kubernetes workload identity to authenticate to Azure Files — a fully cloud-native pattern
- Entra-based authentication provides a stronger security posture than AD Kerberos for most cloud workloads
- Entra-only is the recommended target state for new Azure Files deployments — no Active Directory required
