Goodbye Domain Controllers: Access Azure File Shares with Microsoft Entra Kerberos (Step-by-Step Guide)

Moving files to the cloud is no longer a “future plan” , it’s now a survival strategy for organizations modernizing their identity infrastructure. With companies aggressively removing on-premises dependencies, decommissioning old AD servers, and shifting toward passwordless authentication, one practical challenge still remained:

How do we securely access large, traditional SMB file shares from Entra ID-joined devices without any domain controller connection?

Until recently, this required Domain Controllers, hybrid trusts, or NTLM/Kerberos issued by on-prem AD.

Not anymore.
Microsoft has introduced Microsoft Entra Kerberos authentication for Azure Files for Hybrid & Cloud Only identities (Preview) , enabling seamless, passwordless SMB access from:

• Entra ID Joined devices
• Hybrid Joined devices
• Cloud-only users
• Hybrid users
• Passwordless users (Passkeys, Windows Hello for Business)
• Zero DC / Zero line-of-sight environments

This blog explains why this matters, how it works, and provides a full step-by-step configuration guide with testing from an Entra Joined Windows 11 device.

Why Azure Files + Entra Kerberos Matters Now

Most companies have TBs of unstructured files living inside on-premises file servers. SharePoint Online or OneDrive may not be suitable because of:

• Large datasets (multi-TB)
• Application dependencies requiring SMB
• Legacy folder structures and ACLs
• Need for lift-and-shift without redesigning information architecture

Azure Files is perfect for this scenario because it provides:

• True SMB file shares (NTFS ACLs, inheritance, apps compatibility)
• Cloud-scale performance (Premium + Standard tiers)
• Global redundancy options
• Azure AD / Entra ID based RBAC (no more domain controllers!)

With Entra Kerberos, access becomes even more powerful:

• No NTLM
• No on-prem domain controllers
• No line-of-sight
• Passwordless authentication works
• Supports roaming profiles, FSLogix, and VDI scenarios

This is a key step in the journey of “Retire On-Prem AD gracefully”.

Understanding Identity Types

Hybrid Identities

These are on-premises AD DS accounts synced to Microsoft Entra ID using:

• Microsoft Entra Connect, or
• Microsoft Entra Connect Cloud Sync.

Cloud-Only Identities

These are accounts that exist only in Microsoft Entra ID, with no on-prem AD presence.

The new Entra Kerberos preview unlocks seamless file share authentication for both identity types.

What Microsoft Entra Kerberos Authentication Enables

When this feature is enabled, Azure Files relies on Microsoft Entra ID to issue Kerberos tickets for SMB access. This means:

• Users authenticate to Azure file shares using their Entra ID credentials.
• Azure Files receives a Kerberos service ticket, not user credentials.
• Cloud-only users no longer need a domain controller for file share access.
• Hybrid users still require on-prem DC access only when ACL changes are made (to resolve SID → name lookups).

This is a major shift toward a DC-less file access experience for modern organizations.

Azure Files Identity-Based Authentication (SMB)

Azure Files supports identity-based SMB authentication similar to a traditional Windows file server:

• Assign permissions at share, folder, or file level.
• Works with Windows, Linux, and macOS SMB clients.
• No additional charges, this is included with Azure Files.
• Not supported for NFS shares.

Security Tip : For Azure Files Access Always use identity-based authentication. Never share\Use storage account keys.

Important Limitation

You can enable only ONE identity source per storage account:

• On-premises AD DS ( Or It can be DC running on an Azure VM)
• Microsoft Entra Domain Services
• Microsoft Entra Kerberos (preview)

Choose wisely based on your environment.

How the Kerberos Flow Works

1. A user or application requests access to an Azure SMB file share.
2. Azure Files redirects the request to the configured identity source.
3. The identity source (Entra ID, AD DS, or Entra ID DS) authenticates the identity.
4. Upon successful authentication, it issues a Kerberos ticket.
5. The client presents the Kerberos ticket to Azure Files.
6. Azure Files validates the ticket and authorizes the user.

Azure Files never receives passwords, only Kerberos tickets.

Common Use Cases

Replacing On-Prem Fileservers

Organizations modernizing infrastructure can migrate file data to Azure Files while keeping the same identity and access model.

Lift-and-Shift Applications

Applications lifted to Azure VMs can continue using SMB file shares with Kerberos authentication, no directory redesign required.

Backup & Disaster Recovery (DR)

Azure Files can serve as a DR target for on-prem file servers:

• Preserves NTFS DACLs
• Supports proper access control during failover

Choosing the Right Identity Source

Before enabling identity-based access, understand which identity system best fits your environment.

On-Premises AD DS

Use this when:

• You already have a strong on-prem AD environment.
• Clients/servers have uninterrupted network connectivity to domain controllers.
• You're not ready to move identities fully to the cloud.

Microsoft Entra Kerberos

Choose this if:

• You want to authenticate cloud-only identities (no DC required).
• You have hybrid identities but clients cannot consistently reach on-prem DCs.
• You're using Entra Joined VMs with FSLogix profiles on Azure Files.
• You’re preparing long-term identity modernization toward Entra ID.

This is the recommended option for most modern cloud-first organizations.

Microsoft Entra Domain Services

Use this when:

• You need a managed domain (Entra ID DS) for VMs running legacy applications.
• You already have Entra ID DS enabled and operational.

Entra ID DS behaves like a cloud-hosted AD domain that is a child of your Entra tenant.

Which Identity Source Should You Choose? Practical Guidance

Requirement / Scenario	Best Option
On-prem AD with reliable DC connectivity	AD DS
Clients without DC access (remote-first)	Entra Kerberos
Cloud-only identities	Entra Kerberos
FSLogix profiles on Entra-joined VMs	Entra Kerberos
Existing Entra ID Domain Services setup	Entra Domain Services

Microsoft Entra Kerberos authentication Prerequisites

Before enabling Microsoft Entra Kerberos authentication for Azure SMB file shares, make sure the following requirements are in place.

Core Requirements

• A storage account can use only one identity source. If it's already configured with AD DS or Microsoft Entra Domain Services, disable that first.
• For hybrid identities, you must have:
• An Active Directory domain (AD DS)
• Microsoft Entra Connect or Cloud Sync
• Users and groups created in AD and synced to Entra ID (for RBAC permissions)
• For cloud-only identities, no on-prem AD is required.
• The following Windows services must be running:
• WinHTTP Web Proxy Auto-Discovery Service
• IP Helper
• MFA must be disabled on the Microsoft Entra app representing the storage account.
• Cross-tenant/B2B access isn’t supported. Only users from the same Entra tenant can authenticate.
• Kerberos tickets always use AES-256 encryption.
• External identity support is limited to FSLogix on Azure Virtual Desktop. Non-AVD B2B access isn't supported.
• Cloud-only identity support (preview) currently works only with default share-level permissions.

OS & Domain Requirements

For Cloud-Only Identities (Preview)

Supported OS:

• Windows 11 Enterprise/Pro (single or multi-session)
• Windows Server 2025 (with latest cumulative updates)

For Hybrid Identities

Supported OS:

• Windows 11 Enterprise/Pro (single or multi-session)
• Windows 10 Enterprise/Pro (version 2004 or later + latest updates, including KB5007253)
• Windows Server 2025 (latest updates)
• Windows Server 2022 (latest updates, including KB5007254)

Device Join Requirements

• Clients must be Entra joined or hybrid joined.
• Devices joined only to AD or Entra ID DS aren't supported.
• Cloud-only identity support is available only in Azure Public Cloud.

Step-by-Step Configuration Guide

Step 1 – Create or Select Your Storage Account

Navigate to: Azure Portal → Storage Accounts → Create

When creating your Azure storage account, select the subscription, resource group, storage account name, region, and preferred storage type based on your business needs. Choose the performance tier and redundancy model that aligns with your workload.

For Azure Files, pricing depends on the storage type you select. Azure Files offers two main billing approaches for Standard storage: Pay-as-you-go and Provisioned (v1/v2). The overall cost of Azure Files is influenced by four key factors, especially the billing model.

Billing Models Explained

1. Provisioned v2 (Recommended)
A modern provisioning model where you independently allocate storage, IOPS, and throughput.
You pay for the capacity and performance you provision,even if you don’t use it fully.
Best option for new deployments.

2. Provisioned v1
An older provisioning model where you only provision storage, and IOPS/throughput scale automatically based on the storage size.
Recommended only if you have a specific need for this legacy model.

3. Pay-as-you-go
A consumption-based model where costs are based on actual usage, including storage consumed, transactions, and data transfer.
Use this only if your workload fits a true consumption model, otherwise, Provisioned v2 is preferred.

Click Next, then configure the Advanced settings for the storage account based on your requirements. You can refer to the screenshot below to see the options I selected.

Click Next to configure the Networking settings. Since I want to access the file share over the internet, I’m keeping the default options. You can modify these settings based on your own requirements.

Click Next and configure the Data Protection settings. Since this storage account will host file shares, I’m enabling soft delete and retaining deleted shares for 7 days. You can adjust the retention period based on your organization’s requirements.

Click Next. I’m keeping the Encryption settings at their default values, but if your environment requires customer-managed keys, ensure the prerequisites are met and then enable that option.

Click Next. If you need to apply Tags to your storage account, add them here; otherwise, proceed to the Review + Create page. Review all your configurations, and then click Create to provision the storage account.

Now go to the Storage Accounts section, you’ll see that the storage account has been successfully created.

Step 2 – Enable Microsoft Entra Kerberos Authentication

Now that the storage account is ready, let’s configure Entra Kerberos for our file share.
Open the storage account, go to File shares, and click on Identity-based access (Not configured) to begin the setup.

On the Identity-based access page, you’ll see all the identity sources supported for Azure file shares. Since we’re enabling and testing Microsoft Entra Kerberos, select it and click Set up.

In the next menu, select the Microsoft Entra Kerberos checkbox. In the Domain Services section, enter your on-premises AD Domain Name and Domain GUID (required only for hybrid environments ,cloud-only setups don’t need this).Click Save to apply the settings.

If you want to manage directory and file permissions through Windows File Explorer, the domain name and GUID must be provided. You can retrieve this information from your domain admin or by running Get-ADDomain on any on-prem AD-joined machine. The DNSRoot in the output is your domain name, and the ObjectGUID is your domain GUID.

If you prefer configuring permissions using icacls, this step is optional. but remember, the client must have full network connectivity to the on-prem AD.

Note: Configuring permissions through Windows File Explorer isn’t currently supported for cloud-only identities (preview).

For this demo testing, I’ll showcase both hybrid user and cloud-only user scenarios, so I’ll include these details in the configuration.

Step 3 – Configuring Share-Level Permissions for Azure File Shares

After enabling your identity source (Microsoft Entra Kerberos, AD DS, or Entra Domain Services), the next step is to assign share-level permissions for your Azure file share. Without this, users won’t be able to access the share ,regardless of their NTFS/ACL permissions.

Azure Files supports two ways of assigning share-level permissions:

1. Assign permissions to specific Microsoft Entra users or groups
2. Assign a default share-level permission to all authenticated identities

Both methods serve different scenarios depending on your identity setup.

1. Assigning Share-Level Permissions to Specific Entra Users or Groups (Recommended)

For most environments, you should assign access to specific Entra ID users or groups, and then apply detailed folder/file permissions using Windows ACLs.
This approach gives the strongest and most granular access control.

Important Notes

• The Entra identity must be synced from on-prem AD DS if you’re using hybrid identities. Example: user1@onprem.local synced to Entra as user1@contoso.com.
• Assign permissions to the Entra version of the identity.
• Use built-in Azure RBAC roles for Azure Files, such as:
• Storage File Data SMB Reader
• Storage File Data SMB Contributor
• Storage File Data SMB Elevated Contributor
• Avoid wildcard (*) permissions in custom roles—this may unintentionally grant broader access as new data actions are added.

Once assigned, share-level permissions may take up to 3 hours to fully propagate.

2. Assigning a Default Share-Level Permission (All Authenticated Identities)

In some scenarios, instead of assigning permissions per user or group, you can configure a default share-level permission. This applies the same access level to all authenticated identities.

This method is useful when:

• You’re using Microsoft Entra Kerberos for cloud-only identities (preview).
• On-prem AD identities aren’t synced to Entra ID.
• You have identities such as:
• sMSA/gMSA accounts
• Computer accounts
• You’re working in multi-tenant environments where AD DS syncs to a different Entra tenant.
• You prefer to control access only through Windows ACLs.

Key Notes

• With default share-level permissions, you don’t need to sync on-prem identities to Entra ID.
• All authenticated users get the same permission level (Reader, Contributor, Elevated Contributor, etc.).
• Default permission starts as None, meaning no access until you assign a level.

Now let’s configure the share-level permission. Since we’re testing access for both cloud-only and hybrid identities, I’ll assign the Storage File Data SMB Share Contributor role for this demo.

Step 4 - Finalize Entra Kerberos Configuration: Admin Consent, Cloud-Only Group Support & MFA Exclusions

Once Microsoft Entra Kerberos authentication is enabled on your storage account, a few additional configurations are required to ensure both hybrid and cloud-only identities can authenticate successfully. This step covers three important actions: 

1. Granting admin consent to the auto-created service principal
2. Enabling cloud-only group SID support (mandatory for cloud-only identities) 
3. Excluding the storage account from MFA policies

 Let’s walk through each one.

Grant Admin Consent to the Auto-Generated Service Principal

When you enable Microsoft Entra Kerberos, Azure automatically creates a service principal for your storage account (named:
[Storage Account] <your-storage-account-name>.file.core.windows.net).

This service principal is required for the Kerberos flow but is not used for file access authorization so avoid making any unnecessary modifications.

How to Grant Admin Consent

Go to Microsoft Entra ID → App registrations Select All applications Locate the app named: [Storage Account] <your-storage-account-name>.file.core.windows.net 

Open the app → go to API permissions Click Grant admin consent Confirm with Yes This grants the required permissions: openid ,profile, User.Read

Enable Cloud-Only Groups Support (Mandatory for Cloud-Only Identities)

Kerberos tickets have a limit of 1,010 SIDs. With cloud-only identity support now in preview, Entra Kerberos may need to include both: 

• On-premises group SIDs
• Entra ID cloud group SIDs

If the total exceeds the limit, authentication fails, and users won’t receive a Kerberos ticket. To avoid this issue, Microsoft requires enabling a special manifest tag.

How to Enable Cloud Group SID Support

Go to Entra ID → App registrations Open the app for your storage account Go to Manifest Find the tags section Add the following entry:

"kdc_enable_cloud_group_sids"

Click Save
This ensures cloud-only identities can receive Kerberos tickets without hitting the SID limit.

Disable MFA for the Storage Account Application

Microsoft Entra Kerberos does not support MFA for SMB access. If MFA applies to all apps in your Conditional Access policies, the storage account’s app must be excluded ,otherwise SMB access will fail. 

How to Exclude the Storage Account App

Open Conditional Access Edit the policy enforcing MFA Go to Cloud apps → Exclude Search for the app named:[Storage Account] <your-storage-account-name>.file.core.windows.net 

Add it to the exclusion list Save the policy 

If you skip this step…

Users will receive:
System error 1327: Account restrictions are preventing this user from signing in.

Mapping the share with net use or accessing via Explorer will fail.

Step 5 - Configure Clients to Retrieve Entra Kerberos Tickets

To allow your devices to authenticate to Azure File shares using Microsoft Entra Kerberos, you must enable Entra Kerberos support on every client that will access the file share. This configuration is mandatory, without it, the client will not be able to obtain Kerberos tickets from Entra ID. 

You can enable this setting using any one of the following methods: 

• Microsoft Intune
• Group Policy 
• Registry Key 

Choose the method that best fits your management approach. Once configured, the device will retrieve Kerberos tickets from Entra ID and use them for seamless SMB authentication to Azure Files.

In my setup, I enabled this using an Intune Windows Configuration Profile with the Settings Catalog option and assigned it to the device.

A reboot or policy refresh is required before the change takes effect.

Optionally if you wanted To enable it using GPO Configure the following Group Policy setting on the client and set it to Enabled: Administrative Templates → System → Kerberos → Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

This policy allows the device to retrieve a cloud-based Kerberos Ticket Granting Ticket (TGT) when the user signs in.

Warning: Once this setting is applied, clients won’t be able to access storage accounts that use on-premises AD DS authentication unless Kerberos realm mappings are configured. If your environment needs to support both ADDS–based storage accounts and Microsoft Entra Kerberos–based storage accounts, follow the guidance in “Configure coexistence with storage accounts using on-premises AD DS.”

Test and Validate the Entra Kerberos File Share 

To connect to the file share, we first need to create one.
Go to your storage account, open File shares, and click + File share to create a new share.

In the file share creation menu, enter a file share name and select an access tier, you can choose from Transaction Optimized, Hot, or Cool. For this demo, I’ll select the Hot tier.
Click Next to configure the file share backup options.

For this test file share, I’m not enabling native backup, so I’ll simply click Next, then Review + Create to finalize the file share creation.

Now the file share has been created, and you can see all available options—such as Connect, Upload, Add directory, Deleted shares, Change tier, Edit quota, and more. You’ll also notice that Identity-based access now shows as Configured.

Access Azure File Share using Cloud Only Account

Now let’s connect the file share from an Entra Joined PC using a cloud-only account.
At this stage, we’re relying solely on the default share-level permission, which grants access to all authenticated users based on the selected permission role. We haven’t configured any additional RBAC roles or Windows ACLs, as the default permission already covers this scenario.

To connect, open your file share and click Connect. 

In the connection menu, select your desired platform. Since I’m using Windows, I’ll choose a drive letter and select the AD or Entra authentication option, then click Show script.

You can either run the generated script on the device or mount the share directly through Windows File Explorer.

We have a Entra joined PC which is signed using a Cloud only Account.

The Azure File Share is now successfully mounted and accessible on the Entra Joined PC using a cloud-only identity.

Since this is a cloud-only account, ACL permissions cannot be added through File Explorer

Access Azure File Share using Hybrid Account

Now that we’re signed in with a hybrid user account, accessing the Azure File Share from an Entra Joined device that has line-of-sight to the on-premises domain controller allows us to configure folder ACLs directly through Windows Explorer.

This works because we previously configured the on-prem AD Domain Name and Domain GUID during the Entra Kerberos setup. As a result, Entra Kerberos seamlessly supports both hybrid identities and cloud-only identities, depending on your deployment scenario.

How Mixed Permissions Work in Azure File Shares

Azure Files uses two layers of access control:

1. Share-level permissions (Azure RBAC)
2. Directory/File-level permissions (Windows ACLs / NTFS)

Understanding how these work together is crucial for proper access configuration.

Share-Level + User-Level Permissions

If you configure both a default share-level permission and specific RBAC permissions for a user or group, Azure Files always gives the user the higher of the two permission levels.

Example:

• Default share-level: Elevated Contributor
• User-specific RBAC: Reader
• The user receives Elevated Contributor

How RBAC and NTFS Permissions Work Together

Share-level permissions act as the first gate ,it determine whether a user can access the file share at all.

NTFS permissions (ACLs) then provide granular control on what a user can do inside the share, such as read, write, delete, or modify.

Important Rule

The most restrictive permission always wins.

Example scenarios:

Share-Level Permission	NTFS Permission	Resulting Access
Read	Read/Write	Read only (share-level is more restrictive)
Contributor	Read	Read only (NTFS is more restrictive)

Even if a user has Contributor at the share-level, if NTFS only grants Read, the user can only read.

Supported NTFS Permissions

Azure Files supports the standard set of Windows ACLs, allowing full compatibility with:

• Folder owners
• Authenticated users
• Built-in groups
• File server–style ACL inheritance

This ensures a familiar Windows Fileserver experience.

Configuring Windows ACLs

The method depends on the identity type:

1. Cloud-Only Identities (Preview)

• Must configure ACLs using Azure Portal or PowerShell
• File Explorer and icacls are not supported yet (Which you have seen from the previous Testing)

Configure Windows ACLs Using the Azure Portal

When Microsoft Entra Kerberos is your identity source, you can configure Windows ACLs directly from the Azure portal for both hybrid and cloud-only identities.

Steps: Sign in to the Azure portal using this URL: https://aka.ms/portal/fileperms (By default Manage access won't be visible)

Navigate to the file share where you want to manage permissions.
Select Browse from the menu. To set ACLs at the root folder, click Manage access from the top menu.

This provides a simple way to apply NTFS-style permissions without requiring Windows Explorer or command-line tools.

As shown in the screenshot below, the default NTFS permissions grant access to Authenticated Users. Before assigning permissions to end users, you can modify these default ACLs either through Windows Explorer (for hybrid users with line-of-sight to the domain controller) or through the Manage access page in the Azure portal.

2. Hybrid Identities

• Can configure ACLs using:
• Windows File Explorer
• icacls
• PowerShell (Set-Acl)
• You can migrate existing NTFS permissions using:
• Robocopy
• AzCopy (latest version)
• Azure File Sync (ACLs preserved automatically)

Important Hybrid Identity Note

If you're using Microsoft Entra Kerberos for hybrid access:

• Hybrid identities must be synced to Entra ID for their ACLs to be enforced.
• You can set ACLs for identities that are not synced, but they will not be enforced because the Kerberos ticket won’t contain those SIDs.
• If your identity source is on-prem AD DS, non-synced identities can be enforced because AD DS includes those SIDs in the Kerberos ticket.

Conclusion

Microsoft Entra Kerberos authentication for Azure Files represents a major step forward in enabling secure, modern, passwordless access to cloud file shares especially in hybrid and cloud-only environments.

For organizations moving away from on-prem infrastructure, this feature eliminates the dependency on domain controllers and simplifies your identity strategy. Combined with device modernization and Window Hello for Business, it ensures a seamless and secure access experience for users.