Field notes · Storage & Identity

Azure Files with Entra ID, no AD

Azure Files with Entra ID and no on-prem AD: keyless SMB, end to end

Q: Why does Azure Files keep prompting for a username and password?

A credential prompt means Entra Kerberos did not work and Windows fell back to a method Azure Files cannot use. When Entra Kerberos is configured correctly, the mount is silent single sign-on using the Kerberos ticket from the user's Windows sign-in. If you see a prompt, check that the PC is Entra joined, the CloudKerberosTicketRetrievalEnabled registry value is set to 1, admin consent was granted, and the user has an SMB share role assigned.

Q: What is the difference between share-level and directory-level permissions on Azure Files?

They are two separate layers, and you need both. Share-level permission is Azure RBAC — the Storage File Data SMB Share Reader, Contributor, or Elevated Contributor role decides who can reach the share at all. Directory and file-level permission is standard Windows NTFS ACLs stored on the files themselves, which decide what each user can do inside the share. Access is the intersection: the RBAC role sets the ceiling, the NTFS ACL sets the specific rights.

Q: Can remote or work-from-home users mount Azure Files over the internet?

Usually not directly. Azure Files SMB uses TCP port 445, which most residential and public ISPs block outbound. For remote users you need a VPN or an ExpressRoute connection into a network that can reach the storage account, or a private endpoint with DNS resolving the storage FQDN to the private IP. The Entra Kerberos authentication is unaffected by this — the blocker is purely network reachability of port 445.

By Captain O9 min read

You have no domain controllers, your users live in Entra ID, and your laptops are Entra joined. You still want people to open a file share in File Explorer as themselves — no storage key, no scripts. That is finally a supported path, and here is the whole thing.

New to cloud? CAMPUX is a free, build-first course. Start here →

Azure Files can authenticate cloud-only Microsoft Entra users over SMB with no on-premises Active Directory, using Entra Kerberos for Entra-only identities. You enable Entra Kerberos on the storage account (leaving the domain fields blank), grant admin consent, assign the SMB share roles to your users or groups, and set one registry value on your Entra-joined PCs. Access is then single sign-on — no storage account keys, no net use, and no credential prompt. That last part is the bit half the internet gets wrong, so we will deal with it head on.

For years the honest answer to "can I use Azure Files with just Entra ID?" was "not really — you need AD DS or at least hybrid identities synced from an on-prem domain." That is no longer true. Microsoft shipped Entra Kerberos support for cloud-only identities, which is exactly the setup most modern, Intune-managed, no-server shops actually have. If that is you, you can stop reading forum threads that tell you to stand up a domain controller.

The one correction that saves you a day: there is no password prompt

People come to this wanting Windows to "pop up and ask for the Entra username and password," like a classic SMB login. Drop that expectation now, because when this is working correctly there is no prompt at all. Your Entra-joined PC already holds a Kerberos ticket from the user's Windows sign-in; the mount uses that ticket silently. It is single sign-on, not a login box.

So if you do get a username/password prompt, that is not success — it is the symptom of failure. It means Entra Kerberos did not engage and Windows fell back to a method Azure Files will not accept (NTLM, or an account/key it does not recognise), which is why no password you type ever works. Chasing the prompt is chasing a dead end. The goal state is a drive that mounts with no interaction whatsoever.

The mental model: three independent layers

Almost every stuck setup is really a confusion between layers that look similar but do different jobs. There are three, and you need all three lined up:

Layer	What it decides	Where you set it
Authentication	Can this identity prove who it is over SMB at all?	Entra Kerberos on the storage account + client ticket
Share-level (RBAC)	Can this identity reach the share?	Azure role assignment (SMB Share roles)
Directory/file (NTFS)	What can this identity do inside the share?	Windows ACLs on the folders and files

Effective access is the intersection of the last two: the RBAC role sets the ceiling, and the NTFS ACL sets the specific rights below it. Grant someone the Contributor share role but no NTFS write on a folder and they still cannot write to it — and that is the design, not a bug.

Step 1 — Enable Entra Kerberos on the storage account

In the portal: your storage account → Data storage → File shares → Identity-based access → Configure → enable Microsoft Entra Kerberos. Because you have no on-prem AD, leave the domain name and domain GUID fields blank — those exist only for hybrid setups syncing from a real domain. Save. From the CLI it is one flag:

# turn on Entra Kerberos for a cloud-only (Entra-only) account
az storage account update \
  --name "mystorageacct" --resource-group "rg-files" \
  --enable-files-aadkerb true

This registers a small application in your tenant that represents the storage account for Kerberos. You will grant it consent next.

Step 2 — Grant admin consent (the step everyone skips)

Enabling Kerberos created an app registration, and it requests a couple of delegated Graph permissions (openid, profile, User.Read) so it can issue tickets for signed-in users. Until an admin consents, nothing works — and the error you get downstream looks nothing like "missing consent," which is why this eats so much time.

In the portal: Microsoft Entra ID → App registrations → All applications, find the app named after your storage account (something like [Storage Account] mystorageacct.file.core.windows.net) → API permissions → Grant admin consent for <tenant>. Some portal blades also surface a "Grant admin consent" button right on the storage account's identity configuration — either works. You need to be a Global Administrator or Privileged Role Administrator to click it.

Step 3 — Assign the SMB share roles (share-level access)

Authentication only says "you are who you say you are." A role assignment is what actually lets an identity reach the share. There are three built-in roles, and you assign them to your Entra users or, better, groups:

Storage File Data SMB Share Reader — read-only.
Storage File Data SMB Share Contributor — read, write, delete.
Storage File Data SMB Share Elevated Contributor — Contributor plus the right to modify NTFS ACLs. Give this to admins, not everyone.

Scope the assignment to the file share (or the storage account, if you want it to cover every share):

az role assignment create \
  --role "Storage File Data SMB Share Contributor" \
  --assignee "<user-or-group-object-id>" \
  --scope "/subscriptions/<sub>/resourceGroups/rg-files/providers/Microsoft.Storage/storageAccounts/mystorageacct/fileServices/default/fileshares/myshare"

Watch the default

Azure Files lets you set a default share-level role that applies to every authenticated identity in the tenant. It is convenient and a footgun — leave it unset and grant explicit groups instead, so a random user in your tenant is not silently a Contributor on the share.

Step 4 — Configure the client (the registry value + Entra join)

The PC has to be Microsoft Entra joined (or Entra hybrid joined). On top of that, Windows needs one setting flipped so it will fetch a cloud Kerberos ticket for the storage account instead of only looking for an on-prem KDC:

# HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
# DWORD, value 1
CloudKerberosTicketRetrievalEnabled = 1

Push it to your fleet with an Intune configuration profile (Settings Catalog → Kerberos → "Cloud Kerberos Ticket Retrieval"), not by hand on each machine. The user needs to sign out and back in (or reboot) after it applies, so the session picks up a cloud ticket.

Entra-only gotcha — realm mapping

For strictly cloud-only identities, some environments also need a Kerberos realm mapping so Windows knows to use cloud Kerberos for *.file.core.windows.net rather than treating it as an unknown realm. If mounts still fail after the registry key, add the host-to-realm mapping (Intune Kerberos settings, or the HostToRealm configuration) pointing the storage FQDN at the KERBEROS.MICROSOFTONLINE.COM realm. Microsoft's enablement doc, linked below, has the exact current values — check it, because this detail changes.

Step 5 — Set directory permissions without a storage key

You said no storage account keys, and you can keep that promise. Historically the only way to set NTFS ACLs was to mount the share as the all-powerful storage key and run icacls. Instead, give an admin identity the Elevated Contributor role from Step 3, mount the share as that admin, and edit permissions the normal Windows way — right-click a folder → Properties → Security, or icacls — adding your Entra groups with the rights you want. A common pattern: on the top folder, remove broad inheritance, then grant specific Entra groups Modify or Read as appropriate.

Mounting it

Once all three layers are in place, there is nothing clever to do. In File Explorer → Map network drive → point it at the UNC path, leave "Connect using different credentials" unchecked, and let it mount as the signed-in user:

\\mystorageacct.file.core.windows.net\myshare

No prompt, no key, no script. If you want to script the mapping for consistency you still can, but the authentication is happening off the user's existing Entra session either way.

The gotcha that has nothing to do with identity: port 445

This one bites remote and work-from-home users constantly, and it is not an auth problem, so no amount of Kerberos fiddling fixes it. Azure Files SMB rides TCP port 445, and most residential and public ISPs block outbound 445. From the office you are probably fine; from a home network the mount just times out.

The fix is network reachability, not credentials: a VPN or ExpressRoute into a network that can reach the storage account, or a private endpoint on the storage account with DNS resolving mystorageacct.file.core.windows.net to the private IP. If you go private-endpoint, remember the DNS half — a private endpoint with public DNS still resolves to the public name and fails. This is the same public-versus-private decision you make for other PaaS services; if that trade-off is fuzzy, our service endpoints vs private endpoints note lays it out.

When it still will not mount — quick triage

It prompts for a username and password

Entra Kerberos is not engaging. Confirm the PC is Entra joined, CloudKerberosTicketRetrievalEnabled is 1 and the user has re-logged in, admin consent was granted in Step 2, and the user has an SMB share role. Any one of those missing produces the prompt.

"Access is denied" after it connects

Authentication and share-level worked, but the NTFS ACL does not grant the user rights on that folder. Fix the directory permissions in Step 5, not the role.

The connection just times out

That is port 445 or DNS, not identity. Check reachability from the client (Test-NetConnection mystorageacct.file.core.windows.net -Port 445) and your VPN/private-endpoint DNS.

Role assigned but still cannot reach the share

Role assignments can take a few minutes to propagate, and a stale Kerberos ticket can hang on. Have the user sign out and back in, or run klist purge, then retry.

The whole trick is separating the three layers in your head: identity proves who you are, the RBAC role gets you to the share, the NTFS ACL decides what you do inside it.

Questions people also ask

Can I use Azure Files with Entra ID and no on-premises Active Directory?

Yes. Microsoft Entra Kerberos for Azure Files now supports cloud-only (Entra-only) identities, so you no longer need AD DS or hybrid identity sync. Enable Entra Kerberos on the storage account, grant admin consent, assign the SMB share roles to your Entra users or groups, and set the client registry key on your Entra-joined PCs. Access is single sign-on using the user's existing Windows session.

Why does Azure Files keep prompting for a username and password?

A prompt means Entra Kerberos did not work and Windows fell back to a method Azure Files cannot use, so no password succeeds. When it is configured correctly the mount is silent SSO. Check that the PC is Entra joined, CloudKerberosTicketRetrievalEnabled is set to 1, admin consent was granted, and the user has an SMB share role assigned.

Do I need storage account keys to set NTFS permissions on Azure Files?

No. Assign the Storage File Data SMB Share Elevated Contributor role to an admin identity, mount the share as that identity, and set the directory and file ACLs with the Windows Security tab or icacls. That role grants the rights needed to edit NTFS permissions, so you never mount with the storage key.

What is the difference between share-level and directory-level permissions?

They are two layers and you need both. Share-level is Azure RBAC — the SMB Share Reader/Contributor/Elevated Contributor role decides who can reach the share at all. Directory and file-level is standard Windows NTFS ACLs on the files themselves, deciding what each user can do inside. Effective access is the intersection of the two.

Can remote or work-from-home users mount Azure Files over the internet?

Usually not directly, because SMB uses port 445 which most home and public ISPs block outbound. Use a VPN or ExpressRoute into a network that can reach the account, or a private endpoint with DNS resolving the storage FQDN to the private IP. The Entra Kerberos authentication is unaffected — the blocker is purely network reachability.