Sync Multiple AD domain to single tennat

Somnath Shukla 411 Reputation points

I have two on-premise forest/domain( and in two different country. both domain are independent to each other.
there is no connectivity between these two forest.
I wanted to sync to single Azure AD Tenant which has two separate verified domain in azure AD( and
i know i can use single ad sync to connect multiple forest which are connected.
but here the scenario is different what is best way to achieve this.

also in future if my one on-premsie AD goes corrupt can i resync it from azure AD or i shall go with Azure Backup.

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,708 questions
{count} votes

2 answers

Sort by: Most helpful
  1. Sandeep G-MSFT 16,691 Reputation points Microsoft Employee

    @Somnath Shukla

    Thank you for posting your query on Microsoft Q&A platform.

    In your scenario you cannot sync multiple forests to single Azure AD tenant. You cannot configure AD connect separately in both forests and sync to single Azure AD tenant as it is not supported.


    The only option is to have 2-way trust between both forests and then install AD connect in only one forest.
    This will allow AD connect to talk to both forests to pull objects and sync them all to one single tenant.


    Many organizations have environments with multiple on-premises Active Directory forests. There are various reasons for having more than one on-premises Active Directory forest. Typical examples are designs with account-resource forests and the result of a merger or acquisition.

    When you have multiple forests, all forests must be reachable by a single Azure AD Connect sync server. The server must be joined to a domain. If necessary to reach all forests, you can place the server in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).

    The Azure AD Connect installation wizard offers several options to consolidate users who are represented in multiple forests. The goal is that a user is represented only once in Azure AD. There are some common topologies that you can configure in the custom installation path in the installation wizard. On the Uniquely identifying your users page, select the corresponding option that represents your topology. The consolidation is configured only for users. Duplicated groups are not consolidated with the default configuration.

    Common topologies are discussed in the sections about separate topologies, full mesh, and the account-resource topology.

    The default configuration in Azure AD Connect sync assumes:

    Each user has only one enabled account, and the forest where this account is located is used to authenticate the user. This assumption is for password hash sync, pass-through authentication and federation. UserPrincipalName and sourceAnchor/immutableID come from this forest.
    Each user has only one mailbox.
    The forest that hosts the mailbox for a user has the best data quality for attributes visible in the Exchange Global Address List (GAL). If there's no mailbox for the user, any forest can be used to contribute these attribute values.
    If you have a linked mailbox, there's also an account in a different forest used for sign-in.
    If your environment does not match these assumptions, the following things happen:

    If you have more than one active account or more than one mailbox, the sync engine picks one and ignores the other.
    A linked mailbox with no other active account is not exported to Azure AD. The user account is not represented as a member in any group. A linked mailbox in DirSync is always represented as a normal mailbox. This change is intentionally a different behavior to better support multiple-forest scenarios.

    Once you have this set up in place then you can configure SSPR. While writing the password back to on-premises, AD connect AD connector account will make the password changes in corresponding forest to which user belongs to.

    You can also refer below article to know more about recommended AD connect topologies.

    Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

    1 person found this answer helpful.