Quartz 5

Lab: Azure Files identity-based access

Properties1
tagslab, az-104, storage, azure-files, entraid

3 min read

Lab: Azure Files identity-based access

Outcome

Configure SMB Azure Files access through an identity source, share-level authorization, and file/directory ACLs. Prove that share-level RBAC and file-level permissions are separate gates.

Before you start

Use a disposable storage account and SMB file share. Choose an identity source that your training environment supports: AD DS, Microsoft Entra Domain Services, or Microsoft Entra Kerberos. Check current regional and client prerequisites before selecting cloud-only identities; these vary by identity source and feature availability.

Authoritative setup references: Azure Files identity-based authentication overview, assign share-level permissions, and configure file-level permissions.

Do

  1. Create a storage account and an SMB file share in a disposable resource group.
  2. Enable the chosen Azure Files identity source on the storage account. Record the source, client prerequisites, and any consent or directory configuration it requires.
  3. Create a training Entra security group and add a test user.
  4. At the file-share scope, assign the group an appropriate built-in Storage File Data SMB Share role. Wait for role propagation.
  5. Mount the share from a supported, correctly joined client using the test identity. Create team/readme.txt and record the successful access.
  6. Configure a file or directory ACL that makes a second test identity read-only. Verify that the identity can read but cannot write.

Verify

Capture the identity-source configuration, the group’s share-level RBAC assignment, the mounted-share path, successful file creation, and the read-only ACL. Explain that share-level RBAC grants entry to the share while ACLs constrain directory/file operations.

Break and fix

  1. Remove the share-level role assignment, wait for propagation, and verify that the test identity can no longer access the share. Restore the role and verify access returns.
  2. Keep the share-level role but remove write permission from the ACL. Verify that the identity reaches the share but receives an access-denied result for a write. Restore the ACL.
  3. If the client cannot mount the share, diagnose identity-source choice, client join state, DNS/network path, role propagation, and ACL separately. Do not work around the failure with a storage account key.

Scenario practice

  1. Configure: Choose the identity source, share-level role, and directory ACL for a team that needs write access only to one project folder.
  2. Diagnose: A user can mount the share but cannot create a file. Which evidence separates a share-level RBAC failure from a restrictive directory ACL?
  3. Distinguish: Why is an SMB identity/ACL design safer for this workload than mounting with a storage-account key, and why is it different from NFS access?

Clean up

Unmount the share. Remove test ACLs, role assignments, users/groups created only for the lab, the file share, and the disposable resource group. If you enabled an identity source solely for this lab, follow the current product procedure to disable or remove its configuration only after confirming no other share depends on it.

Sources and re-audit

Re-audit when Azure Files identity-source support, client prerequisites, SMB authorization, or ACL behavior changes.

azure-files · entra-directory-management · groups · rbac · security-group · All labs

Graph View

Backlinks