On-Prem File Server with Azure AD: Access from Azure-joined Devices without Local DC?

This scenario is a common design question and it is important to separate what Azure AD can do from what classic Active Directory Domain Services is required to do.

Short answer: what you are describing is not supported in the way you expect.

Windows Server cannot be Azure AD joined in the same way as Windows 10 or Windows 11. Azure AD Join is a client feature. Windows Server 2022 and Windows Server 2025 do not support Azure AD Join as a replacement for on premises Active Directory Domain Services. Therefore a standalone Windows Server cannot rely purely on Azure AD as its security authority for SMB access control.

From an authentication perspective, SMB on Windows Server is built around Kerberos or NTLM backed by a local Security Account Manager or Active Directory Domain Services. Azure AD is a cloud identity provider and does not expose a domain controller, Kerberos Key Distribution Centre, or LDAP endpoint that an on premises file server can use for traditional Windows integrated authentication.

Because of this, you cannot join an on premises Windows Server directly to Azure AD only and treat Azure AD as if it were a domain.

You cannot assign NTFS or share permissions directly to Azure AD users or Azure AD groups on a standalone file server.

You cannot have Azure AD joined Windows 11 clients access SMB shares on that server using pure Azure AD credentials unless there is an underlying Active Directory Domain Services or equivalent Kerberos infrastructure in place.

If you build the file server as a workgroup server, your only supported identity options are:

Local users and local groups defined on that server Microsoft account based authentication is not supported for SMB in this model Manual credential mapping from clients using stored credentials

This does not meet enterprise security or compliance expectations in most regulated environments.

If the goal is to avoid local domain controllers but still use Azure AD identities, the supported design patterns are different:

Option 1

Use Azure AD Domain Services.

Azure AD Domain Services provides managed domain controllers in Azure that expose Kerberos and LDAP. You can domain join the file server to that managed domain, even over VPN or ExpressRoute. Azure AD users are synchronised into the managed domain and can be used in NTFS and share permissions. This removes the need to deploy your own domain controllers, but it does not eliminate Active Directory Domain Services as a concept.

Option 2

Use Azure Files with Azure AD authentication.

Azure Files supports Azure AD Kerberos and Azure AD Domain Services based authentication. Azure AD joined Windows 11 devices can access Azure Files over SMB using their Azure AD credentials. This is the only Microsoft supported architecture where Azure AD can directly participate in SMB authentication without traditional domain controllers on premises.

Option 3

Deploy a minimal on premises Active Directory Domain Services footprint.

A small domain with one or two domain controllers provides the Kerberos infrastructure required for SMB, while Azure AD Connect synchronises identities to Azure AD. This remains the most common and predictable design for on premises file servers with strict compliance requirements.

To answer your overall design goal clearly:

A traditional on premises Windows file server that uses NTFS permissions cannot rely entirely on Azure AD as its sole identity provider. The Windows Server security model for SMB requires a domain based or local SAM based authority, and Azure AD does not fulfil that role for on premises servers.

If you must keep data on premises and avoid running domain controllers yourself, Azure AD Domain Services is the closest supported architecture. If the primary driver is identity simplification and modern authentication, then Azure Files with Azure AD authentication is the cleaner long term solution.

There is no supported workaround that allows a workgroup Windows Server 2025 file server to apply NTFS permissions directly to Azure AD users or groups and authenticate Azure AD joined clients natively over SMB without some form of Active Directory Domain Services in the background.

If this resolution has been helpful, I kindly request that you take a moment to click on

and select “Yes” to indicate that the response was helpful. Should you have any further questions or require additional assistance, please do not hesitate to let me know.