question

@MadinaGotova-3743 Firstly, apologies for the delay in responding here! Welcome to Microsoft Q&A Forum, Thank you for posting your query here!

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. 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 an file share with the storage account registered against a domain in forest B, this will not automatically work because the service principal of the storage account does not 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:

Logon to a machine domain joined to forest B
- Open up "Active Directory Domains and Trusts" console
- Right click on "Active Directory Domains and Trusts"
- Click on "Properties"
- Click on "Add"
- Add "file.core.windows.net" as the UPN Suffixes
- Click on "Apply", then "OK" to close the wizard
- Next, add the suffix routing rule on forest A, so that it redirects to forest B.

Logon to a machine domain joined to forest A
- Open up "Active Directory Domains and Trusts" console
- Right-click on the domain that you want to access the file share, then click on the "Trusts" tab and select forest B domain from outgoing trusts. If you haven't configure trust between the two forests, you need to setup the trust first
- Click on "Properties…" then "Name Suffix Routing"
- Check if the ".file.core.windows.net" suffix shows up. If not, click on 'Refresh'
- Select ".file.core.windows.net", then click on "Enable" and "Apply"

**Note:**To use the AD credential for authentication, you need to make sure that the AD credential is synced to Azure AD, and that Azure AD is fully synced to Azure AD DS. If not, AAD DS will not be able to perform authentication against an AD credential. Please check the sync status and let us know if you continue to run into issue.

Refer to this article on Built-in RBAC : https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
assign share-level permissions to an identity

Additional information: 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 which have established trust relationships, or between servers that are not in a domain. We recommend that you avoid using a mix of these configurations.

Multiple forests with AD DS and Azure AD: https://docs.microsoft.com/en-us/azure/architecture/example-scenario/wvd/multi-forest

Please let us know if you have any further queries. I’m happy to assist you further.

---

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.