Azure NetApp Files Entra Kerberos Preview: Windows SMB Setup, Limits and ACL Rules

It is a preview, so it isn't for production yet. Azure defines "In preview" as available to all Azure customers for non-production use and testing. Microsoft's configuration guide on Microsoft Learn, updated September 24, 2026, also labels the feature as preview.

What's actually changing​

Microsoft's "What's new" page for Azure NetApp Files states the goal plainly: Azure NetApp Files now supports Microsoft Entra Kerberos authentication for SMB volumes. The capability enables users with hybrid or cloud-only identities to authenticate through Microsoft Entra ID using cloud-issued Kerberos tickets.

According to the same page, the main benefit is that the feature removes the requirement for SMB clients to have network line-of-sight to Active Directory Domain Services domain controllers in the authentication path.

That's a real shift. Microsoft's own explainer on Kerberos in Azure NetApp Files described native Microsoft Active Directory as the only KDC type that Azure NetApp Files currently supports. The KDC (Key Distribution Center) is the server that issues Kerberos tickets. With this preview, Entra ID can play that role for SMB access.

The two identity types work like this:

• Hybrid identities: Accounts that start in on-premises AD DS and sync to Entra ID. One identity covers both on-premises and cloud resources.
• Cloud-only identities: Accounts created and managed only in the Entra tenant, with no on-premises directory behind them.

Azure NetApp Files doesn't handle passwords here. Microsoft's guide says the service doesn't prompt for credentials or issue Kerberos tickets. The Windows client gets the ticket when the user signs in interactively and then presents it when mounting the share.

Section summary: SMB volumes on Azure NetApp Files can now use Kerberos tickets issued by Entra ID for hybrid and cloud-only users, so clients no longer need a line of sight to a domain controller during authentication. The feature is in preview and meant for testing.

Planning boundaries to check first​

Microsoft lists several limits you should check before you create any resources:

• Same-region NetApp account: The NetApp account must be in the region where you deploy the volumes.
• One connection per account: A subscription can have multiple Entra ID connections, but each NetApp account can have only one.
• Either-or identity model: A NetApp account can use Entra ID-based authentication or AD DS-based authentication, but not both at once. This is the most important limit for existing customers. Don't expect to add Entra Kerberos to an account that already serves AD DS-joined SMB volumes. Plan for a separate account or a deliberate migration.
• Managed identity: The Entra ID connection uses a system-assigned or user-assigned managed identity on the NetApp account.

Features not supported in the preview​

If your design depends on file access logs for auditing, think hard about that gap before you pilot. Auditors don't like surprises.

Section summary: Identity is set per NetApp account, and you can't mix AD DS and Entra ID in one account. Three features are unavailable in the preview.

Step-by-step: setting up the preview​

This follows Microsoft's published procedure. Menu labels and commands are as Microsoft documents them.

1. Register the preview feature​

In Azure PowerShell:

Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFEntraID
Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFEntraID

Azure CLI users can run az feature register and az feature show instead. The state can sit at Registering for up to 60 minutes. Wait for Registered before you continue.

2. Sync hybrid users (hybrid deployments only)​

If you'll use hybrid identities, configure Microsoft Entra Connect Sync first and sync the on-premises AD users who need access.

3. Register an Entra application​

• Create an app registration with Single tenant only as the supported account type.
• Write down the Application (client) ID from the Overview page.
• Under API permissions, add these Microsoft Graph application permissions: Application.ReadWrite.OwnedBy, DelegatedPermissionGrant.ReadWrite.All and User.Read.
• Select Grant admin consent for the tenant.
• Under Certificates & secrets > Certificates > Upload certificate, upload a public certificate in .cer, .pem or .crt format. Self-signed certificates work, but Microsoft doesn't recommend them for production.

4. Set up Azure Key Vault​

• Create a key vault and note its name and URI. The URI format is https://vault_name.vault.azure.net.
• Give the NetApp account's managed identity the Key Vault Secrets User role on the vault.
• Store the certificate in Key Vault. The public certificate you uploaded to the app registration must match the certificate in the PFX stored in Key Vault. A mismatch here is the most likely cause of a failed setup, so check it first.

5. Allow outbound access to Microsoft Graph​

Azure NetApp Files must be able to reach graph.microsoft.com. Microsoft's procedure uses an Azure NAT gateway (Standard SKU, one or more public IPs). Attach it to the virtual network that contains the delegated Azure NetApp Files subnet, and associate it with both the delegated subnet and the client subnet. Microsoft notes that the NAT gateway handles outbound traffic only. No inbound access or extra firewall rules are needed.

6. Enable the NetApp account's managed identity​

In the portal, go to Azure NetApp Files > NetApp account > Settings > Identity. Choose system-assigned or user-assigned. For system-assigned, turn the status on under the System assigned tab and select Save.

7. Create the Entra ID connection​

From the NetApp account, go to Entra ID connection > Create and fill in:

• Application ID: from step 3.
• Domain Name: the AD domain synced to Entra ID (for hybrid) or any custom domain.
• Azure Key Vault URI: from step 4.
• Certificate name: the Key Vault certificate linked to the app registration.
• SMB server prefix: this sets the FQDN you'll use to mount the SMB volume, so choose it carefully.

Section summary: Setup involves feature registration, an app registration with Graph permissions and admin consent, certificate storage in Key Vault, managed-identity access, outbound Graph connectivity and the connection itself.

Client configuration: Windows is where it lives or dies​

The client that actually mounts the volume must be an Entra ID-joined Windows VM. Microsoft also describes an optional Entra ID-registered VM that acts as a jump box when you can't RDP straight into the joined machine. The jump box never mounts the volume.

Microsoft also says production environments can use Entra ID-joined VMs to access the shares. The Entra app, certificates, Key Vault and NAT gateway configuration all keep working after you remove the test VMs.

On the joined VM, set these Group Policy options:

1. Computer Configuration > Administrative Templates > System > Kerberos: enable Allow retrieving the cloud kerberos ticket during the logon.
2. In the same location, configure Define host name-to-kerberos realm mappings with the volume's FQDN. Do this after you create the Entra ID volume. Microsoft's example uses the value name KERBEROS.MICROSOFTONLINE.COM with the value smbserver.contoso.com.
3. Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options: enable Network security: Allow PKU2U authentication requests to this computer to use online identities.

To let a hybrid user RDP in, add them to the local group:

net localgroup "Remote Desktop Users" /add AzureAD\UPN

Users sign in with the format AzureAD\user@EntraIDdomain, for example AzureAD\[email][email protected][/email]. If sign-in fails, Microsoft suggests selecting More Choices and entering the credentials there.

Before you set ACLs, add an entry to the Windows hosts file that maps the volume's IP address to the SMB server FQDN. Microsoft's example is 102.54.94.97 smbserver.contoso.com.

Section summary: Most of the work happens on the client. You need an Entra-joined Windows VM, three policy settings, a realm mapping and a hosts-file entry.

Permissions: icacls only, and watch the group limit​

By default, any user can access the share. You restrict access with Windows ACLs (NTFS permissions) at the root, directory or file level. Where permissions conflict, the most restrictive one wins.

There are two firm rules in the preview:

• icacls is the only supported tool. Setting ACLs through Windows File Explorer isn't supported for hybrid or Entra-only identities.
• No group ACLs for cloud-only identities. Using icacls to apply ACLs to groups isn't supported for Entra ID-only identities, so plan on assigning permissions per user for those accounts. At scale, that could become a real admin burden.

Microsoft's examples grant a hybrid user access from the Entra-joined VM, either through a mapped drive or the UNC path. The UNC form follows this pattern: icacls \\<smbserver>.contoso.com\entravol /grant "AzureAD\user@<EntraIDdomain>":(R,W). The mapped-drive example in the documentation appears to contain stray spacing and a duplicated AzureAD\ prefix. Test the syntax in a lab before you script it.

Day-two operations​

• Editing: For volumes that depend on the Entra connection, you can change only the Key Vault URI, certificate name and managed identity resource ID. That flexibility matters for certificate rotation.
• Deleting: You can delete the connection only after all Entra-dependent volumes are gone.

How it compares with Azure Files​

If this sounds familiar, Azure Files went through the same change earlier. There are differences worth noting, though.

On Azure Files, Microsoft documents that cloud-only identities support (preview) is only available using a default share-level permission, and share-level authorization uses Azure RBAC roles. Azure NetApp Files uses a different model: the NetApp account's Entra connection plus per-file and per-directory NTFS ACLs set with icacls.

Client requirements are similar in spirit. For Azure Files, clients must be Microsoft Entra joined or Microsoft Entra hybrid joined. They can't be joined to Microsoft Entra Domain Services or joined to AD only. Azure NetApp Files' guide is narrower and documents only an Entra ID-joined VM. Don't assume hybrid-joined clients will work with Azure NetApp Files until Microsoft says so.

The Azure Files documentation also notes that for sovereign clouds, cloud-only identities are supported in all regions of the Azure Public cloud, but aren't supported in Azure US Gov or Azure China 21Vianet clouds. That limit applies to Azure Files. Microsoft hasn't published a matching cloud-availability matrix for the Azure NetApp Files preview, so government-cloud customers should confirm availability before planning around it.

The WindowsForum take​

For organizations moving toward cloud-first identity, keeping domain controllers alive just so SMB storage can authenticate has been a real frustration. This preview goes after that directly. It fits the broader push to retire on-premises AD that has already reached Azure Files, Windows Hello for Business cloud trust and Intune-managed endpoints.

It doesn't make things simpler overnight, though. You still manage an app registration with fairly broad Graph permissions, a certificate that needs rotating, Key Vault role assignments, a NAT gateway (which costs money) and client Group Policy. The NTFS ACLs have to be managed from the command line, and cloud-only users can't be assigned permissions through groups. Is that less work than running a pair of domain controllers? For a small cloud-native team, probably yes. For a large enterprise with thousands of per-user ACLs, it depends on the details.

Our recommendation: set up a separate NetApp account in a test subscription, pilot with a few cloud-only and hybrid users, and check the three unsupported features against your production needs. Hold off on production until general availability.

Related WindowsForum topics: Microsoft Entra Connect Sync deployment, Windows Hello for Business cloud Kerberos trust, Azure Files identity-based authentication and Intune Group Policy migration.