Use Azure Files with Multiple Active Directory (AD) Forests
Summary — Use Azure Files with multiple Active Directory forests (SMB)
Applies to: SMB Azure file shares
Purpose
Explains how to allow SMB Azure file shares to be accessed from accounts in multiple on-premises AD DS forests by using forest trusts, domain suffix routing, and hybrid account sync to Microsoft Entra ID. Includes prerequisites, step-by-step configuration, suffix routing options, and validation.
Prerequisites
Two AD DS domain controllers in different forests and different VNETs
Administrative AD permissions (for example, Domain Admin)
If using Azure RBAC for share-level permissions, both forests must be reachable by a single Microsoft Entra Connect sync server
If you want to grant share-level permissions to specific Microsoft Entra users or groups, sync on-prem AD accounts to Microsoft Entra ID with Microsoft Entra Connect first: https://docs.azure.cn/en-us/active-directory/hybrid/whatis-azure-ad-connect
How forest trust relationships work
By default, Azure Files AD DS authentication is supported only against the AD forest where the storage account is registered.
To allow authentication across different forests, configure a transitive forest trust between the forests. A forest trust lets users in any domain of one forest be authenticated in any domain of the other forest.
Multi-forest setup (high-level)
Collect domain and VNET info
Establish and configure a forest trust
Set up identity-based authentication and hybrid user accounts
Collect domain information (example)
Forest 1: onpremad1.com — DomainServicesVNet WUS
Forest 2: onpremad2.com — vnet2/workloads
Establish and configure trust (stepper)
Create the forest trust (on a machine joined to Forest 2)
Open Active Directory Domains and Trusts.
Right-click local domain (e.g., onpremad2.com) → Trusts tab → New Trusts.
Enter the domain to trust (e.g., onpremad1.com) → Next.
Trust Type: Forest trust → Next.
Direction of Trust: Two-way → Next.
Sides of Trust: This domain only → Next.
Outgoing Trust Authentication Level: Forest-wide authentication → Next.
Enter a trust password (same on both sides) → Next.
Confirm and authenticate with an admin account from the other domain when prompted.
On success, the trusted domain appears on the Trusts tab.
Set up identity-based authentication and hybrid user accounts (stepper)
Create storage accounts and shares
In the Azure portal, create storage accounts (example names: onprem1sa and onprem2sa). Deploy them in regions near clients for best performance.
Create SMB file shares and assign share-level permissions: https://docs.azure.cn/en-us/storage/files/storage-files-identity-assign-share-level-permissions Note: Creating a second storage account is optional — example shows two for different forests.
Enable AD DS authentication for the storage account
Enable AD DS authentication on the storage account (e.g., onprem1sa). This creates a computer account in the AD (e.g., onprem1sa) and joins the storage account to that domain: https://docs.azure.cn/en-us/storage/files/storage-files-identity-ad-ds-enable
Create users and sync (hybrid accounts)
Create user accounts in each on-prem domain (e.g., onprem1user, onprem2user).
If using Azure RBAC for share-level permissions, ensure users are synced to Microsoft Entra ID. To force sync: in an elevated PowerShell session run:
Import-Module ADSync (if needed)
Start-ADSyncSyncCycle -PolicyType Delta Verify sync in Azure portal under Microsoft Entra ID → Users (On-premises sync enabled should say Yes).
Grant share-level permissions
Assign share-level permissions either by:
Granting Azure RBAC roles to synced Microsoft Entra users (see: Assign share-level permissions) OR
Using the default share-level permission that applies to all authenticated identities (link in previous steps). Repeat for each forest/storage account as needed.
Directory and file-level permissions (optional)
Use icacls to configure NTFS ACLs across forests: https://docs.azure.cn/en-us/storage/files/storage-files-identity-configure-file-level-permissions#configure-windows-acls-with-icacls
If icacls fails with Access is denied:
Remove existing share mount: net use * /delete /y
Re-mount using the Windows SMB admin method or storage account key (not recommended)
Set icacls permissions from a client in the domain where you're running the command
Note: File Explorer is not recommended to configure ACLs in multi-forest scenarios for cross-forest users.
Configure domain suffixes (reason and methods)
Problem: Azure Files registers an identity whose SPN ends with file.core.chinacloudapi.cn, which doesn’t match on-prem domain suffixes. Clients’ DCs won’t know where to forward requests for that suffix unless routing is configured.
Two options to enable suffix routing:
Modify storage account SPN suffix and add a CNAME record (recommended; works with 2+ forests)
Add custom name suffix and routing rule (works only with two forests)
Modify storage account name suffix and add CNAME record (recommended)
Change SPN for the storage-account computer account to include the AD domain suffix and add a CNAME that maps storage-account.DOMAIN → storage-account.file.core.chinacloudapi.cn.
Example SPN mapping:
onprem1sa.onpremad1.com -> onprem1sa.file.core.chinacloudapi.cn
onprem2sa.onpremad2.com -> onprem2sa.file.core.chinacloudapi.cn
Steps:
Ensure forest trust and identity/hybrid setup are complete.
Set the SPN with setspn: setspn -s cifs/. (Get with: (Get-AdDomain).DnsRoot)
Add a CNAME in AD DNS for each storage account:
Alias (CNAME) name:
FQDN: .
Target host FQDN: .file.core.chinacloudapi.cn
Important: Ensure the hostname portion of the FQDN exactly matches the storage account name to avoid STATUS_OBJECT_NAME_INVALID errors.
Add custom name suffix and routing rule (alternate, two-forest only)
Instead of DNS/CNAME changes, add "file.core.chinacloudapi.cn" as a UPN suffix in the forest that hosts the storage account, then enable name suffix routing on the trusting forest’s outgoing trust for "*.file.core.chinacloudapi.cn".
Steps (high level):
On Forest 2: Active Directory Domains and Trusts → Properties → Add UPN suffix "file.core.chinacloudapi.cn".
On Forest 1: Active Directory Domains and Trusts → Select outgoing trust → Properties → Name Suffix Routing → Enable "*.file.core.chinacloudapi.cn".
Note: This method won't scale beyond two forests.
Validate that the trust and routing are working (stepper)
Verify Kerberos ticket from Forest 1 to a storage account in Forest 2
On a machine in Forest 1, open cmd and run either:
If using CNAME method: klist get cifs/onprem2sa.onpremad2.com
If using suffix routing: klist get cifs/onprem2sa.file.core.chinacloudapi.cn
Expect Kerberos ticket output showing client, server, ticket flags, Kdc Called, etc.
If validation fails (two-forest alternative)
For two-forest setups, you can add a custom UPN suffix (for example onprem1sa.file.core.chinacloudapi.cn) to one forest and then enable name suffix routing on the other forest’s outgoing trust for that custom suffix. Follow the earlier steps under "Add custom name suffix and routing rule".
Notes and recommendations
Preferred method for environments with two or more forests: Modify storage account SPN suffix and add CNAME records (recommended).
The custom-suffix/name-suffix-routing approach is only suitable for up to two forests.
Ensure users that need Azure RBAC share-level assignments are synced to Microsoft Entra ID.
Avoid using File Explorer to set ACLs for cross-forest users; use icacls from appropriate domain-joined clients.
References / Next steps
Overview of Azure Files identity-based authentication support (SMB only): https://docs.azure.cn/en-us/storage/files/storage-files-active-directory-overview
Azure Files FAQ: https://docs.azure.cn/en-us/storage/files/storage-files-faq
Related how-to links used in steps are preserved inline above.
Last updated on 11/11/2025
Expandable: Azure Files FAQ
Was this helpful?