Merge pull request #312543 from khdownie/kendownie030326-2

Files multiple forest auth integrity check

Author: denrea

articles/storage/files/storage-files-identity-multiple-forests.md

@@ -1,10 +1,10 @@
 ---
-title: Use Azure Files with Multiple Active Directory (AD) Forests
+title: Use Azure Files with Multiple Active Directory Forests
 description: Configure on-premises Active Directory Domain Services (AD DS) authentication for SMB Azure file shares with an AD DS environment using multiple forests.
 author: khdownie
 ms.service: azure-file-storage
 ms.topic: how-to
-ms.date: 02/23/2026
+ms.date: 03/03/2026
 ms.author: kendownie
 ms.custom: sfi-image-nochange
 # Customer intent: As an IT administrator managing multiple Active Directory forests, I want to configure Azure file shares with identity-based authentication, so that users from different forests can access shared resources seamlessly.
@@ -17,11 +17,11 @@ ms.custom: sfi-image-nochange
 Many organizations want to use identity-based authentication for SMB Azure file shares in environments that have multiple on-premises Active Directory Domain Services (AD DS) forests. This is a common IT scenario, especially following mergers and acquisitions, where the acquired company's AD forests are isolated from the parent company's AD forests. This article explains how forest trust relationships work and provides step-by-step instructions for multi-forest setup and validation.
 
 > [!IMPORTANT]
-> To set share-level permissions for specific Microsoft Entra ID users or groups by using Azure role-based access control (RBAC), first sync the on-premises AD accounts to Entra ID by using [Microsoft Entra Connect](../../active-directory/hybrid/whatis-azure-ad-connect.md). Otherwise, use a [default share-level permission](storage-files-identity-assign-share-level-permissions.md#share-level-permissions-for-all-authenticated-identities).
+> To set share-level permissions for specific Microsoft Entra ID users or groups by using Azure role-based access control (RBAC), first sync the on-premises AD accounts to Entra ID by using [Microsoft Entra Connect Sync](/entra/identity/hybrid/connect/how-to-connect-sync-whatis). Otherwise, use a [default share-level permission](storage-files-identity-assign-share-level-permissions.md#share-level-permissions-for-all-authenticated-identities).
 
 ## Prerequisites
 
-- Two AD DS domain controllers with different forests and on different virtual networks (VNETs)
+- Two AD DS domain controllers with different forests and on different virtual networks
 - Sufficient AD permissions to perform administrative tasks (for example, Domain Admin)
 - If using Azure RBAC, both forests must be reachable by a single Microsoft Entra Connect Sync server
 
@@ -35,15 +35,15 @@ A forest trust is a transitive trust between two AD forests that allows users in
 
 To configure a multi-forest setup, perform the following steps:
 
-- Collect domain information and VNET connections between domains
+- Collect domain information and virtual network connections between domains
 - Establish and configure a forest trust
 - Set up identity-based authentication and hybrid user accounts
 
 ### Collect domain information
 
 For this exercise, we have two on-premises AD DS domain controllers with two different forests and in different virtual networks.
 
-| **Forest** | **Domain** | **VNET** |
+| **Forest** | **Domain** | **Virtual network** |
 |--------|--------|------|
 | Forest 1 | onpremad1.com | DomainServicesVNet WUS |
 | Forest 2 | onpremad2.com | vnet2/workloads |
@@ -61,16 +61,16 @@ To enable clients from **Forest 1** to access Azure Files domain resources in **
 1. Right-click on the local domain **onpremad2.com**, and then select the **Trusts** tab.
 1. Select **New Trusts** to launch the **New Trust Wizard**.
 1. Specify the domain name you want to build trust with (in this example, **onpremad1.com**), and then select **Next**.
-1. For **Trust Type**, select **Forest trust**, and then select **Next**.   
+1. For **Trust Type**, select **Forest trust**, and then select **Next**.
 1. For **Direction of Trust**, select **Two-way**, and then select **Next**.
 
-    :::image type="content" source="media/storage-files-identity-multiple-forests/direction-of-trust.png" alt-text="Screenshot of Active Directory Domains and Trusts console showing how to select a two-way direction for the trust." border="true":::
+   :::image type="content" source="media/storage-files-identity-multiple-forests/direction-of-trust.png" alt-text="Screenshot of Active Directory Domains and Trusts console showing how to select a two-way direction for the trust." border="true":::
 
 1. For **Sides of Trust**, select **This domain only**, and then select **Next**.
 1. Users in the specified forest can be authenticated to use all of the resources in the local forest (forest-wide authentication) or only those resources that you select (selective authentication). For **Outgoing Trust Authentication Level**, select **Forest-wide authentication**, which is the preferred option when both forests belong to the same organization. Select **Next**.
 1. Enter a password for the trust, and then select **Next**. You must use the same password when creating this trust relationship in the specified domain.
 
-    :::image type="content" source="media/storage-files-identity-multiple-forests/trust-password.png" alt-text="Screenshot of Active Directory Domains and Trusts console showing how to enter a password for the trust." border="true":::
+   :::image type="content" source="media/storage-files-identity-multiple-forests/trust-password.png" alt-text="Screenshot of Active Directory Domains and Trusts console showing how to enter a password for the trust." border="true":::
 
 1. You should see a message that the trust relationship was successfully created. To configure the trust, select **Next**.
 1. Confirm the outgoing trust, and select **Next**.
@@ -97,7 +97,7 @@ After you establish the trust, follow these steps to create a storage account an
    - If the user is synced to Entra ID, grant a share-level permission (Azure RBAC role) to the user **onprem1user** on storage account **onprem1sa** so the user can mount the file share. To do this, go to the file share you created in **onprem1sa** and follow the instructions in [Assign share-level permissions for specific Microsoft Entra users or groups](storage-files-identity-assign-share-level-permissions.md#share-level-permissions-for-specific-azure-ad-users-or-groups).
    - Otherwise, use a [default share-level permission](storage-files-identity-assign-share-level-permissions.md#share-level-permissions-for-all-authenticated-identities) that applies to all authenticated identities.
 
-Repeat steps 4-8 for **Forest2** domain **onpremad2.com** (storage account **onprem2sa**/user **onprem2user**). If you have more than two forests, repeat the steps for each forest.
+Repeat steps 4-8 for **Forest 2** domain **onpremad2.com** (storage account **onprem2sa**/user **onprem2user**). If you have more than two forests, repeat the steps for each forest.
 
 ## Configure directory and file-level permissions (optional)
 
@@ -109,7 +109,7 @@ If icacls fails with an *Access is denied* error, follow these steps to configur
 
 1. Re-mount the share by using either the [Windows permission model for SMB admin](storage-files-identity-configure-file-level-permissions.md#use-the-windows-permission-model-for-smb-admin) or the storage account key (not recommended). See [Mount SMB Azure file share on Windows](storage-how-to-use-files-windows.md).
 
-1. Set icacls permissions for user in **Forest2** on storage account joined to **Forest1** from client in **Forest1**.
+1. Set icacls permissions for user in **Forest 2** on storage account joined to **Forest 1** from client in **Forest 1**.
 
 > [!NOTE]
 > Don't use File Explorer to configure ACLs in a multi-forest environment. Although users who belong to the forest that's domain-joined to the storage account can have file and directory-level permissions set via File Explorer, it doesn't work for users that don't belong to the same forest that's domain-joined to the storage account.
@@ -124,12 +124,12 @@ For example, when users in a domain in **Forest 1** want to reach a file share w
 
 You can configure domain suffixes by using one of the following methods:
 
-- [Modify storage account suffix and add a CNAME record](#modify-storage-account-name-suffix-and-add-cname-record) (recommended - works with two or more forests)
+- [Modify storage account SPN suffix and add a CNAME record](#modify-storage-account-spn-suffix-and-add-cname-record) (recommended - works with two or more forests)
 - [Add custom name suffix and routing rule](#add-custom-name-suffix-and-routing-rule) (doesn't work with more than two forests)
 
-### Modify storage account name suffix and add CNAME record
+### Modify storage account SPN suffix and add CNAME record
 
-You can solve the domain routing issue by modifying the suffix of the storage account name associated with the Azure file share, and then adding a CNAME record to route the new suffix to the endpoint of the storage account. With this configuration, domain-joined clients can access storage accounts joined to any forest. This solution works for environments that have two or more forests.
+You can solve the domain routing issue by modifying the SPN suffix of the storage account associated with the Azure file share, and then adding a CNAME record to route the new suffix to the endpoint of the storage account. With this configuration, domain-joined clients can access storage accounts joined to any forest. This solution works for environments that have two or more forests.
 
 In this example, the domains **onpremad1.com** and **onpremad2.com** have **onprem1sa** and **onprem2sa** as storage accounts associated with SMB Azure file shares in the respective domains. These domains are in different forests that trust each other to access resources in each other's forests. You want to allow access to both storage accounts from clients who belong to each forest. To do this, you need to modify the SPN suffixes of the storage account:
 
@@ -180,7 +180,7 @@ First, add a new custom suffix on **Forest 2**. Make sure you have the appropria
 1. Open the **Active Directory Domains and Trusts** console.
 1. Right-click on **Active Directory Domains and Trusts**.
 1. Select **Properties**, and then select **Add**.
-1. Add "file.core.windows.net" as the UPN Suffix.
+1. Add "file.core.windows.net" as the UPN suffix.
 1. Select **Apply**, then **OK** to close the wizard.
 
 Next, add the suffix routing rule on **Forest 1**, so that it redirects to **Forest 2**.
@@ -197,58 +197,62 @@ Next, add the suffix routing rule on **Forest 1**, so that it redirects to **For
 Validate that the trust is working by running the **klist** command to display the contents of the Kerberos credentials cache and key table.
 
 1. Sign in to a machine or VM that's joined to a domain in **Forest 1** and open a Windows command prompt.
+
 1. To display the credentials cache for the domain-joined storage account in **Forest 2**, run one of the following commands: 
-   - If you used the [Modify storage account name suffix and add CNAME record](#modify-storage-account-name-suffix-and-add-cname-record) method, run: `klist get cifs/onprem2sa.onpremad2.com`
+   - If you used the [Modify storage account SPN suffix and add CNAME record](#modify-storage-account-spn-suffix-and-add-cname-record) method, run: `klist get cifs/onprem2sa.onpremad2.com`
    - If you used the [Add custom name suffix and routing rule](#add-custom-name-suffix-and-routing-rule) method, run: `klist get cifs/onprem2sa.file.core.windows.net`
+
 1. You should see output similar to the following. The klist output differs slightly based on which method you used to configure domain suffixes.
 
-```
-Client: onprem1user @ ONPREMAD1.COM
-Server: cifs/onprem2sa.file.core.windows.net @ ONPREMAD2.COM
-KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
-Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
-Start Time: 11/22/2022 18:45:02 (local)
-End Time: 11/23/2022 4:45:02 (local)
-Renew Time: 11/29/2022 18:45:02 (local)
-Session Key Type: AES-256-CTS-HMAC-SHA1-96
-Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
-Kdc Called: onprem2.onpremad2.com
-```
+   ```
+   Client: onprem1user @ ONPREMAD1.COM
+   Server: cifs/onprem2sa.file.core.windows.net @ ONPREMAD2.COM
+   KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
+   Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
+   Start Time: 11/22/2022 18:45:02 (local)
+   End Time: 11/23/2022 4:45:02 (local)
+   Renew Time: 11/29/2022 18:45:02 (local)
+   Session Key Type: AES-256-CTS-HMAC-SHA1-96
+   Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
+   Kdc Called: onprem2.onpremad2.com
+   ```
 
 1. Sign in to a machine or VM that's joined to a domain in **Forest 2** and open a Windows command prompt.
+
 1. To display the credentials cache for the domain-joined storage account in **Forest 1**, run one of the following commands:
-   - If you used the [Modify storage account name suffix and add CNAME record](#modify-storage-account-name-suffix-and-add-cname-record) method, run: `klist get cifs/onprem1sa.onpremad1.com`
+   - If you used the [Modify storage account SPN suffix and add CNAME record](#modify-storage-account-spn-suffix-and-add-cname-record) method, run: `klist get cifs/onprem1sa.onpremad1.com`
    - If you used the [Add custom name suffix and routing rule](#add-custom-name-suffix-and-routing-rule) method, run: `klist get cifs/onprem1sa.file.core.windows.net`
+
 1. You should see output similar to the following. The klist output differs slightly based on which method you used to configure domain suffixes.
 
-```
-Client: onprem2user @ ONPREMAD2.COM
-Server: krbtgt/ONPREMAD2.COM @ ONPREMAD2.COM
-KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
-Ticket Flags 0x40e10000 -> forwardable renewable pre_authent name_canonicalize
-Start Time: 11/22/2022 18:46:35 (local)
-End Time: 11/23/2022 4:46:35 (local)
-Renew Time: 11/29/2022 18:46:35 (local)
-Session Key Type: AES-256-CTS-HMAC-SHA1-96
-Cache Flags: 0x1 -> PRIMARY
-Kdc Called: onprem2
-
-Client: onprem2user @ ONPREMAD2.COM    
-Server: cifs/onprem1sa.file.core.windows.net @ ONPREMAD1.COM
-KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
-Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
-Start Time: 11/22/2022 18:46:35 (local)
-End Time: 11/23/2022 4:46:35 (local)
-Renew Time: 11/29/2022 18:46:35 (local)
-Session Key Type: AES-256-CTS-HMAC-SHA1-96
-Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
-Kdc Called: onpremad1.onpremad1.com
-```
+   ```
+   Client: onprem2user @ ONPREMAD2.COM
+   Server: krbtgt/ONPREMAD2.COM @ ONPREMAD2.COM
+   KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
+   Ticket Flags 0x40e10000 -> forwardable renewable pre_authent name_canonicalize
+   Start Time: 11/22/2022 18:46:35 (local)
+   End Time: 11/23/2022 4:46:35 (local)
+   Renew Time: 11/29/2022 18:46:35 (local)
+   Session Key Type: AES-256-CTS-HMAC-SHA1-96
+   Cache Flags: 0x1 -> PRIMARY
+   Kdc Called: onprem2
+   
+   Client: onprem2user @ ONPREMAD2.COM    
+   Server: cifs/onprem1sa.file.core.windows.net @ ONPREMAD1.COM
+   KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
+   Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
+   Start Time: 11/22/2022 18:46:35 (local)
+   End Time: 11/23/2022 4:46:35 (local)
+   Renew Time: 11/29/2022 18:46:35 (local)
+   Session Key Type: AES-256-CTS-HMAC-SHA1-96
+   Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
+   Kdc Called: onpremad1.onpremad1.com
+   ```
 
 If you see the preceding output, you're done. If you don't, follow these steps to provide alternative UPN suffixes to make multi-forest authentication work.
 
 > [!IMPORTANT]
-> This method works only in environments with two forests. If you have more than two forests, use one of the other methods to configure domain suffixes.
+> Adding a custom name suffix and routing rule works only in environments with two forests. If you have more than two forests, [modify the storage account SPN suffix and add a CNAME record](#modify-storage-account-spn-suffix-and-add-cname-record) instead.
 
 First, add a new custom suffix on **Forest 1**.
 
@@ -268,9 +272,8 @@ Next, add the suffix routing rule on **Forest 2**.
 1. Check if the "onprem1sa.file.core.windows.net" suffix shows up. If not, select **Refresh**.
 1. Select "onprem1sa.file.core.windows.net", then select **Enable** and **Apply**.
 
-## Next steps
+## Next step
 
-For more information, see the following resources:
+For more information, see:
 
-- [Overview of Azure Files identity-based authentication support (SMB only)](storage-files-active-directory-overview.md)
-- [Azure Files FAQ](storage-files-faq.md)
+- [Overview of Azure Files identity-based authentication (SMB only)](storage-files-active-directory-overview.md)