Overview of Identity-Based Access for Azure Storage Account File Shares

Steps

 Step 1: Enable Identity-Based Authentication on the Storage Account

This "domain joins" the storage account to your chosen identity source, enabling SMB authentication over identities.

 Option A: Using the Azure Portal (Recommended for Beginners)

1. Sign in to the [Azure Portal]

2. Navigate to your storage account (or create a new one: Search for "Storage accounts" > Create > Basics tab > Select "Standard" performance, "StorageV2" or "FileStorage" account kind > Review + create).

3. In the left menu, under Data storage, select File shares.

4. In the File share settings section, click Identity-based access: Not configured.

5. In the configuration pane:

  - Select your identity source (e.g., Microsoft Entra ID for cloud auth, Active Directory Domain Services (AD DS) for on-premises, or Microsoft Entra Domain Services for managed domains).

   - If using AD DS:

     - Provide the domain name (e.g., `contoso.com`).

     - Generate a Kerberos key for the storage account (via PowerShell/CLI if needed; see below).

     - Create a computer account in AD representing the storage account (e.g., `stgaccountname$`).

     - Set the AD account password to the storage account's Kerberos key (use `Set-ADAccountPassword` in PowerShell).

  - Click Save. This enables authentications for all new and existing file shares.

 Option B: Using Azure CLI

Install Azure CLI if needed, then run:

```

az login

az storage account update --resource-group <resource-group-name> --name <storage-account-name> --enable-files-identity-based-auth true --domain-service <identity-source>

```

- Replace `<identity-source>` with `AADDS` (for Microsoft Entra Domain Services), `AD` (for on-premises AD DS), or omit for Microsoft Entra ID.

- For AD DS, first generate a Kerberos key:

 ```

 az storage account kerb-key generate --resource-group <rg> --name <account> --key-type Primary

 ```

 Use the output key as the password for the AD computer account.

 Option C: Using Azure PowerShell

Install Az PowerShell module (`Install-Module Az.Storage`), then:

```

Connect-AzAccount

Update-AzStorageAccount -ResourceGroupName <rg> -Name <account> -EnableActiveDirectoryDomainServicesForFile $true -ActiveDirectoryDomainName <domain> -ActiveDirectoryNetBiosDomainName <netbios-domain> -ActiveDirectoryForestName <forest>

```

- Adjust parameters based on your identity source.

Verification: After enabling, check the storage account's File shares blade; it should show the configured identity source. Role assignments may take 5-10 minutes to propagate.

 Step 2: Create a File Share and Paths (Directories/Files)

1. In the Azure Portal, go to your storage account > File shares > + File share.

2. Enter a name (e.g., `myshare`), select a tier if needed, and click Create.

3. To create paths (directories/files):

  - Click on the new share > + Directory to add directories.

  - Upload files or create them via the portal, Azure Storage Explorer, or SMB mount (initially using storage account key for setup).

Note: You can't access the share via identities until permissions are set (Step 3). 

Use the storage account key temporarily for initial setup:

- Get the key: Storage account > Access keys.

- Mount via PowerShell: `net use Z: \\<account>.file.core.windows.net\<share> /user:Azure\<account> <key>`.

 Step 3: Configure Share-Level Permissions (Azure RBAC)

This controls access to the entire file share. Use built-in roles like:

- Storage File Data SMB Share Reader: Read access.

- Storage File Data SMB Share Contributor: Read/write access.

- Storage File Data SMB Share Elevated Contributor: Full control.

 Using the Azure Portal

1. In the storage account > File shares > Select your share > Access control (IAM).

2. Click + Add > Add role assignment.

3. Select a role (e.g., Storage File Data SMB Share Contributor).

4. Under Members, choose User, group, or service principal > Select members (e.g., a Microsoft Entra user/group).

5. Click Review + assign. Scope is automatically set to the share.   

 Using Azure CLI

```

az role assignment create --assignee <user-principal-name-or-group-object-id> --role "Storage File Data SMB Share Contributor" --scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>/fileServices/default/shares/<share-name>"

```

Default Option: For broad access, assign the role to "Authenticated Users" (object ID: `THEOBJECTID` for AD DS) at the share scope.

 Step 4: Configure Directory/File-Level Permissions (Windows ACLs)

For finer control on paths within the share:

1. Mount the share using the storage account key (as in Step 2) to a Windows client with network access to your domain controllers (if using AD DS).

2. Use Windows tools to set ACLs:

  - File Explorer: Right-click directory/file > Properties > Security > Edit > Add identities (e.g., domain users/groups) > Set permissions (Full Control, Read, etc.).

  - icacls Command: `icacls Z:\path /grant <domain\user>:(OI)(CI)F` (for full control inheritance).

  - PowerShell: `Set-Acl -Path Z:\path -AclObject (Get-Acl Z:\existing-path-with-desired-permissions)`.

3. Unmount the share after configuration: `net use Z: /delete`.

Inheritance: New directories/files inherit parent ACLs by default. For backups or migrations, use Robocopy (`robocopy source dest /copyall /sec`) to preserve ACLs.

Security Note: If your AD enforces password expiration on the storage account's computer identity, rotate the Kerberos key periodically via Azure CLI/PowerShell and update the AD password.

 Step 5: Mount and Access the File Share Path

From a domain-joined Windows client (or one with connectivity to domain controllers):

1. Ensure the client is signed in with the permitted identity (e.g., Microsoft Entra or AD credentials).

2. Mount via PowerShell (no key needed):

  ```

  $connectTestResult = Test-NetConnection -ComputerName <account>.file.core.windows.net -Port 445

  if ($connectTestResult.TcpTestSucceeded) {

       net use Z: \\<account>.file.core.windows.net\<share>

  } else {

       Write-Error "Cannot connect to SMB port 445"

  }

  ```

3. Access paths: Navigate to `Z:\<directory-path>`; permissions enforce access.

Client-Side Access: Ensure clients have the correct configuration to use these identities: 

Domain-Joined Machines: Clients must be able to reach the domain controllers of the identity source. 

Map Network Drive: Users can map the Azure file share in File Explorer using their domain credentials. 

Kerberos Authentication:  For Microsoft Entra identities, the client machine needs to retrieve a Kerberos ticket, often requiring a custom configuration profile with Microsoft Intune to enable Cloud Kerberos Ticket Retrieval