4.4 Identity-Based Access for Azure Files

Azure Files identity is layered

Azure Files provides fully managed file shares that can be mounted by Windows, Linux, and macOS clients over SMB, and by supported clients over NFS for specific configurations. Identity-based access is most often discussed for SMB. The key idea is that share access is not controlled by only one setting. Network access must allow the request, the user or computer must authenticate through a supported identity source, Azure RBAC must permit share-level access, and file or directory ACLs must permit the operation.

There are several identity source options. Traditional Active Directory Domain Services integration lets domain-joined machines use AD DS identities for SMB access. Microsoft Entra Domain Services can support managed domain scenarios. Microsoft Entra Kerberos for Azure Files supports cloud Kerberos authentication for hybrid identities in supported Windows scenarios and can reduce dependency on line-of-sight to domain controllers for some designs. The exam usually gives clues such as domain-joined Windows clients, hybrid users, existing AD DS, or cloud-only management goals.

Azure RBAC roles for Azure Files include share-level roles such as Storage File Data SMB Share Reader, Storage File Data SMB Share Contributor, and Storage File Data SMB Share Elevated Contributor. These roles do not replace NTFS permissions inside the share. Think of RBAC as opening the share door and NTFS permissions as controlling rooms and files inside. A user with share Contributor can still be denied by NTFS ACLs on a folder. A user with NTFS Modify but no share-level role can also fail.

Portal path example: Storage account > Data storage > File shares > select share. Use Access Control (IAM) to assign a Storage File Data SMB Share role to a user or group at the storage account or share scope. Use Configuration or File shares identity-based access settings on the storage account to configure the chosen directory service integration. Then manage directory and file ACLs from a mounted Windows client or supported administrative tooling.

CLI examples for role assignment:

STORAGE_ID=$(az storage account show \
  --name staz104files01 \
  --resource-group rg-storage-prod \
  --query id -o tsv)

az role assignment create \
  --assignee user1@contoso.com \
  --role 'Storage File Data SMB Share Contributor' \
  --scope $STORAGE_ID/fileServices/default/fileshares/projects

Mount examples show the difference between key-based and identity-based thinking. A key-based Windows mount uses the storage account name as the user and the account key as the password. It is easy, but it is broad and difficult to audit by user. Identity-based access allows the user identity to be evaluated and logged more meaningfully, but it requires correct domain or Entra configuration.

net use Z: \\staz104files01.file.core.windows.net\projects /persistent:yes

Before assuming permissions are wrong, check connectivity. SMB uses TCP port 445. Some internet providers and corporate networks block outbound 445, which causes mount failures even when identity settings are correct. Private endpoints, VPN, or ExpressRoute can provide a private path, but DNS must resolve the file endpoint to the private IP when public access is disabled. A private endpoint for blob does not help Azure Files; use the file subresource.

Troubleshooting cases:

Administrators must also decide how to handle elevated tasks. Storage File Data SMB Share Elevated Contributor can be used for administrative operations that need elevated file permission management. It should not be assigned broadly. For normal user access, assign group-based roles and manage NTFS ACLs through groups. This aligns with the least privilege model and keeps operations maintainable.

Case scenario: a company wants a shared departmental drive in Azure Files for domain users. Users should map the drive with their normal Windows identity, help desk staff should manage folder permissions, and storage keys should not be distributed. The correct design is identity-based SMB access integrated with the appropriate directory service, Azure RBAC file share roles assigned to groups, NTFS ACLs set on directories, storage firewall or private endpoint access for client networks, and a process to restrict or monitor account key usage.

If the problem states that users receive access denied only on one folder, focus on NTFS ACLs. If they cannot mount the share at all, start with port 445, DNS, and network rules.