Azure Files Kerberos Auth With Hybrid Identities — No More Storage Account Keys for Domain Users

The Problem With Storage Account Keys

If your users are accessing Azure file shares today using a storage account key mounted as a drive letter, you already know the pain: the key is essentially a root password for the entire storage account, it never expires unless you rotate it manually, and there is no concept of per-user permissions at the storage layer. Everyone gets the same access. Windows ACLs on top do not help if the underlying connection is authenticated as the storage account itself.

The alternative — Microsoft Entra Kerberos authentication — lets hybrid domain users access Azure Files the same way they access on-premises file servers: with their Windows credentials, SSO at logon, and proper per-user Windows ACLs at the directory and file level. No key distribution. No shared password. No token management scripts.

This guide covers the full setup for hybrid identities (on-premises AD DS synced to Entra ID), configured via Intune, from storage account configuration through to client-side policy and proof it is working.

Why This Works — The Kerberos Flow

When you enable Microsoft Entra Kerberos on a storage account, Azure registers an Entra ID service principal that represents that storage account. The service principal name follows the pattern [Storage Account] <storageaccountname>.file.core.windows.net.

When a client needs to mount the share, the flow is:

1. The client sends a Ticket Granting Ticket (TGT) request to Microsoft Entra ID during logon — this is the step enabled by the CloudKerberosTicketRetrievalEnabled policy.
2. Entra ID issues a cloud TGT backed by the user's Entra identity.
3. When the client tries to access the Azure Files endpoint (<storageaccount>.file.core.windows.net), it presents the TGT to Entra ID and receives a service ticket for the storage account's service principal.
4. The client presents that service ticket over SMB. Azure Files validates it against Entra ID and checks the user's Azure RBAC share-level permissions.
5. If RBAC passes, Windows ACLs (NTFS permissions) on the share are evaluated to determine read/write/execute access at the file and directory level.

For hybrid identities, the user's Entra account is their synced on-premises AD account. Group memberships synced from AD are honoured in both the RBAC check and the NTFS ACL evaluation. The on-premises domain controller is only needed to configure NTFS ACLs — not for every mount operation.

Prerequisites Checklist

Before you start, confirm every item below. Missing any of these is the most common source of setup failures.

Verify the two required services on a client before you start:

# Check both required services are running before enabling Entra Kerberos auth

$services = @('WinHttpAutoProxySvc', 'iphlpsvc')
foreach ($svc in $services) {
    $s = Get-Service $svc -ErrorAction SilentlyContinue
    if ($s.Status -eq 'Running') {
        Write-Host "[OK]   $svc is Running" -ForegroundColor Green
    } else {
        Write-Host "[FAIL] $svc is $($s.Status) — this WILL block Entra Kerberos auth" -ForegroundColor Red
    }
}

# Check client join state — must be Entra joined or Hybrid Entra joined
$dsreg = (& dsregcmd /status) | Select-String 'AzureAdJoined|DomainJoined'
$dsreg | ForEach-Object { Write-Host $_.Line.Trim() }

# Check port 445 reachability (replace with your storage account name)
$storageAccount = 'mystorageaccount'
$test = Test-NetConnection "$storageAccount.file.core.windows.net" -Port 445
Write-Host "Port 445 reachable: $($test.TcpTestSucceeded)" -ForegroundColor (if ($test.TcpTestSucceeded) { 'Green' } else { 'Red' })

Step 1 — Enable Microsoft Entra Kerberos on the Storage Account

Run the following from Azure PowerShell. For hybrid identities you should also pass the domain name and GUID so that Windows File Explorer can be used to set directory and file-level ACLs (instead of icacls only).

# Get domain info from local AD (run on a domain-joined machine)
$domain     = Get-ADDomain
$domainName = $domain.DnsRoot        # e.g. contoso.com
$domainGuid = $domain.ObjectGUID.ToString()

Write-Host "Domain : $domainName"
Write-Host "GUID   : $domainGuid"

# Enable Entra Kerberos auth on the storage account
Connect-AzAccount
Set-AzStorageAccount `
    -ResourceGroupName 'rg-fileshares-prod' `
    -StorageAccountName 'mystorageaccount' `
    -EnableAzureActiveDirectoryKerberosForFile $true `
    -ActiveDirectoryDomainName $domainName `
    -ActiveDirectoryDomainGuid $domainGuid

# Confirm it is enabled
Get-AzStorageAccount -ResourceGroupName 'rg-fileshares-prod' -StorageAccountName 'mystorageaccount' |
    Select-Object -ExpandProperty AzureFilesIdentityBasedAuth

Expected output after enabling:

Step 2 — Grant Admin Consent to the Auto-Created Entra App

When you enabled Entra Kerberos, Azure automatically registered a service principal in your tenant. You must grant admin consent to its API permissions before any user can authenticate. Without this step, Kerberos ticket requests will fail silently.

Step 3 — Exclude the Storage Account App From MFA Conditional Access

Microsoft Entra Kerberos does not support MFA as part of the Kerberos ticket flow. If your tenant has a Conditional Access policy requiring MFA for all apps (or for all Azure resources), you must add an exclusion for the storage account's Entra app. This is not optional — without the exclusion, every mount attempt fails.

The app to exclude is named: [Storage Account] <your-storage-account-name>.file.core.windows.net

In Entra admin center: Protection › Conditional Access › [your MFA policy] › Users or workload identities › Exclude › Service principals › search for the storage account app name › Save

Step 4 — Assign Share-Level Permissions (Azure RBAC)

Share-level permissions are the first gate before NTFS ACLs are even evaluated. Assign one of the three built-in RBAC roles to users or synced groups at the file share scope.

Assign RBAC at the individual file share scope, not at the storage account scope. Assigning at storage account scope grants access to all shares in that account.

# Assign share-level RBAC — use the synced Entra group, not the on-prem AD group directly

$resourceGroup   = 'rg-fileshares-prod'
$storageAccount  = 'mystorageaccount'
$shareName       = 'profiles'
$groupName       = 'SG-AzFiles-Profiles-Contributor'  # synced from AD

# Get the file share resource ID
$shareId = (Get-AzStorageAccount -ResourceGroupName $resourceGroup -StorageAccountName $storageAccount |
    Get-AzStorageShare -Name $shareName).Id

# Get the Entra group object ID
$groupId = (Get-AzADGroup -DisplayName $groupName).Id

# Assign Contributor role
New-AzRoleAssignment `
    -ObjectId $groupId `
    -RoleDefinitionName 'Storage File Data SMB Share Contributor' `
    -Scope $shareId

Write-Host "RBAC assigned: $groupName → Contributor on $shareName" -ForegroundColor Green

Step 5 — Set NTFS Permissions on the Share

RBAC grants access to the share. NTFS ACLs control access within the share — which directories and files each user or group can read, write, or execute. For hybrid identities, you need a device with network connectivity to the on-premises domain controller to set NTFS ACLs, because the ACL editor needs to resolve AD group SIDs.

Mount the share using the storage account key first (to get elevated access to set ACLs), then use icacls to set the permissions:

# Mount with storage account key to get rights to set ACLs
$accountKey = '<storage-account-key>'
$sharePath  = '\\mystorageaccount.file.core.windows.net\profiles'

net use Z: $sharePath $accountKey /user:AZURE\mystorageaccount

# Set root permissions: Domain admins get Full Control; Users get Modify
$rootPath = 'Z:\'
icacls $rootPath /grant "CONTOSO\Domain Admins:(OI)(CI)(F)"
icacls $rootPath /grant "CONTOSO\SG-AzFiles-Profiles-Contributor:(OI)(CI)(M)"
icacls $rootPath /remove "Everyone"  # remove the Everyone default

# Verify ACLs
icacls $rootPath

# Disconnect the admin mount when done
net use Z: /delete

The icacls flags: (OI) = object inherit (files), (CI) = container inherit (subdirectories), (F) = Full Control, (M) = Modify.

Step 6 — Configure Clients via Intune to Retrieve Kerberos Tickets

This is the client-side step that enables the Kerberos TGT retrieval from Entra ID at logon. Without it, the client has no cloud TGT and cannot get a service ticket for the storage account, so the mount fails.

Deploy this via Intune Settings Catalog — not OMA-URI. The OMA-URI method does not work on Azure Virtual Desktop multisession devices, which is a common deployment scenario for Azure Files with Entra Kerberos.

Alternatively, for devices managed by registry or Group Policy:

Step 7 — Coexistence With AD DS Storage Accounts

If your environment has some storage accounts using on-premises AD DS authentication and others using Entra Kerberos, you need Kerberos realm mappings on the clients. Without them, enabling CloudKerberosTicketRetrievalEnabled on clients will break access to AD DS-authenticated storage accounts.

For each AD DS-authenticated storage account, add a host-to-realm mapping via Intune Settings Catalog (Kerberos › HostToRealm), Group Policy (Admin Templates\System\Kerberos\Define host name-to-Kerberos realm mappings), or via command:

:: Map the AD DS storage account hostname to the on-prem realm
:: Realm names are CASE SENSITIVE and must be UPPERCASE
ksetup /addhosttorealmmap adsstorageaccount.file.core.windows.net CONTOSO.LOCAL

:: Verify the mapping was added
ksetup

:: Or view the raw registry key
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm"

Step 8 — Proof It Is Working

After a reboot (or gpupdate /force + sign-out/sign-in), verify the Kerberos ticket is issued and the share mounts cleanly.

# 1. Check Kerberos tickets — look for a ticket issued by Entra ID for the storage account
klist

# Look for a line like:
# Server: cifs/mystorageaccount.file.core.windows.net @ KERBEROS.MICROSOFTONLINE.COM
# KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

# 2. Mount the share without a password — should use Kerberos silently
net use Z: \\mystorageaccount.file.core.windows.net\profiles

# Expected output (no password prompt):
# The command completed successfully.

# 3. Confirm who you are connecting as
net use  # check the listed username for Z: — should show your domain account

# 4. Verify NTFS permission is honoured
icacls Z:\  # shows the ACLs on the root — your account/group should appear

# 5. Run the Debug cmdlet if something is wrong (requires AzFilesHybrid module v0.3.0+)
Debug-AzStorageAccountAuth -StorageAccountName 'mystorageaccount' -ResourceGroupName 'rg-fileshares-prod' -Verbose

The klist output should include a ticket for cifs/<storageaccount>.file.core.windows.net with the Kerberos realm shown as KERBEROS.MICROSOFTONLINE.COM — that is the Entra ID Kerberos realm, confirming the cloud ticket flow is working rather than the on-premises AD DS flow.

Common Errors and Fixes

References

• Microsoft Learn — Enable Microsoft Entra Kerberos authentication for Azure Files (hybrid identities)
• Microsoft Learn — Assign share-level permissions to an identity
• Microsoft Learn — Configure directory and file-level permissions over SMB
• Microsoft Learn — Policy CSP — Kerberos/CloudKerberosTicketRetrievalEnabled
• Microsoft Learn — Troubleshoot Azure Files SMB authentication issues