Merge pull request #227609 from khdownie/kendownie021623

adding links to multiple forest article

Author: prmerger-automator[bot]

articles/storage/files/storage-files-faq.md

@@ -3,7 +3,7 @@ title: Frequently asked questions (FAQ) for Azure Files
 description: Get answers to Azure Files frequently asked questions. You can mount Azure file shares concurrently on cloud or on-premises Windows, Linux, or macOS deployments.
 author: khdownie
 ms.service: storage
-ms.date: 02/03/2023
+ms.date: 02/16/2023
 ms.author: kendownie
 ms.subservice: files
 ms.topic: conceptual
@@ -16,7 +16,7 @@ ms.topic: conceptual
 
 * <a id="cross-domain-sync"></a>
   **Can I have domain-joined and non-domain-joined servers in the same sync group?**  
-    Yes. A sync group can contain server endpoints that have different Active Directory memberships, even if they are not domain-joined. Although this configuration technically works, we do not recommend this as a typical configuration because access control lists (ACLs) that are defined for files and folders on one server might not be able to be enforced by other servers in the sync group. For best results, we recommend syncing between servers that are in the same Active Directory forest, between servers that are in different Active Directory forests but have established trust relationships, or between servers that aren't in a domain. We recommend that you avoid using a mix of these configurations.
+    Yes. A sync group can contain server endpoints that have different Active Directory memberships, even if they are not domain-joined. Although this configuration technically works, we do not recommend this as a typical configuration because access control lists (ACLs) that are defined for files and folders on one server might not be able to be enforced by other servers in the sync group. For best results, we recommend syncing between servers that are in the same Active Directory forest, between servers that are in different Active Directory forests but have [established trust relationships](storage-files-identity-multiple-forests.md#how-forest-trust-relationships-work), or between servers that aren't in a domain. We recommend that you avoid using a mix of these configurations.
 
 * <a id="afs-change-detection"></a>
   **I created a file directly in my Azure file share by using SMB or in the portal. How long does it take for the file to sync to the servers in the sync group?**  
@@ -113,34 +113,12 @@ ms.topic: conceptual
 * <a id="ad-multiple-forest"></a>
 **Does on-premises AD DS authentication for Azure file shares support integration with an AD DS environment using multiple forests?**
 
-    Azure Files on-premises AD DS authentication only integrates with the forest of the domain service that the storage account is registered to. To support authentication from another forest, your environment must have a forest trust configured correctly.
+    Azure Files on-premises AD DS authentication only integrates with the forest of the domain service that the storage account is registered to. To support authentication from another forest, your environment must have a forest trust configured correctly. For detailed instructions, see [Use Azure Files with multiple Active Directory forests](storage-files-identity-multiple-forests.md).
 
    > [!Note]  
    > In a multi-forest setup, don't use Windows Explorer to configure Windows ACLs/NTFS permissions at the root, directory, or file level. [Use icacls](storage-files-identity-ad-ds-configure-permissions.md#configure-windows-acls-with-icacls) instead.
 
-    The way Azure Files register in AD DS almost the same as a regular file server, where it creates an identity (computer or service logon account) in AD DS for authentication. The only difference is that the registered SPN of the storage account ends with "file.core.windows.net" which does not match with the domain suffix. Consult your domain administrator to see if any update to your suffix routing policy is required to enable multiple forest authentication due to the different domain suffix. We provide an example below to configure suffix routing policy.
-    
-    Example: When users in forest A domain want to reach a file share with the storage account registered against a domain in forest B, this won't automatically work because the service principal of the storage account doesn't have a suffix matching the suffix of any domain in forest A. We can address this issue by manually configuring a suffix routing rule from forest A to forest B for a custom suffix of "file.core.windows.net".
-
-    First, you must add a new custom suffix on forest B. Make sure you have the appropriate administrative permissions to change the configuration, then follow these steps:
-
-    1. Logon to a machine domain joined to forest B.
-    2. Open up the **Active Directory Domains and Trusts** console.
-    3. Right-click on **Active Directory Domains and Trusts**.
-    4. Select **Properties**.
-    5. Select **Add**.
-    6. Add "file.core.windows.net" as the UPN Suffixes.
-    7. Select **Apply**, then **OK** to close the wizard.
-    
-    Next, add the suffix routing rule on forest A, so that it redirects to forest B.
-
-    1. Logon to a machine domain joined to forest A.
-    2. Open up "Active Directory Domains and Trusts" console.
-    3. Right-click on the domain that you want to access the file share, then select the **Trusts** tab and select forest B domain from outgoing trusts. If you haven't configured trust between the two forests, you need to set up the trust first.
-    4. Select **Properties** and then **Name Suffix Routing**
-    5. Check if the "*.file.core.windows.net" suffix shows up. If not, click **Refresh**.
-    6. Select "*.file.core.windows.net", then select **Enable** and **Apply**.
-
+   
 * <a id="ad-aad-smb-files"></a>
 **Is there any difference in creating a computer account or service logon account to represent my storage account in AD?**
 

articles/storage/files/storage-files-identity-ad-ds-enable.md

@@ -16,7 +16,7 @@ recommendations: false
 This article describes the process for enabling Active Directory Domain Services (AD DS) authentication on your storage account in order to use on-premises Active Directory (AD) credentials for authenticating to Azure file shares.
 
 > [!IMPORTANT]
-> Before you enable AD DS authentication, make sure you understand the supported scenarios and requirements in the [overview article](storage-files-identity-auth-active-directory-enable.md) and complete the necessary [prerequisites](storage-files-identity-auth-active-directory-enable.md#prerequisites).
+> Before you enable AD DS authentication, make sure you understand the supported scenarios and requirements in the [overview article](storage-files-identity-auth-active-directory-enable.md) and complete the necessary [prerequisites](storage-files-identity-auth-active-directory-enable.md#prerequisites). If your Active Directory environment spans multiple forests, see [Use Azure Files with multiple Active Directory forests](storage-files-identity-multiple-forests.md).
 
 To enable AD DS authentication over SMB for Azure file shares, you need to register your Azure storage account with your on-premises AD DS and then set the required domain properties on the storage account. To register your storage account with AD DS, you create a computer account (or service logon account) representing it in your AD DS. Think of this process as if it were like creating an account representing an on-premises Windows file server in your AD DS. When the feature is enabled on the storage account, it applies to all new and existing file shares in the account.