You are on page 1of 4

Single forest, single Azure AD tenant

It is a most common topology is a single on-premises forest, with one or multiple domains, and a single
Azure AD tenant.

In this topology Azure AD authentication and password hash synchronization is used as well as express
installation of Azure AD Connect supports.

Single forest, multiple sync servers to one Azure AD tenant

Multiple Azure AD Connect sync servers is not supported with single forest and single Azure AD tenant.
It's unsupported even if these servers are configured to synchronize with a mutually exclusive set of
objects.

Multiple forests, single Azure AD 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.
The default configuration in Azure AD Connect sync assumes:

1. 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.
2. Each user has only one mailbox.
3. 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.
4. 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:

1. If you have more than one active account or more than one mailbox, the sync engine picks
one and ignores the other.
2. 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.

Multiple forests – separate topologies

Users are represented only once across all directories

1. In this environment, all forests on-premises are treated as separate entities and no user would
be present in any other forest.
2. Each forest has its own Exchange organization and there is no GALSync between the forests.
3. This topology could be the situation after a merger/acquisition or in an organization where each
business unit is operating isolated from each other.
4. These forests are in the same organization in Azure AD and appear with a unified GAL. In this
picture, each object in every forest is represented once in the metaverse and aggregated in the
target Azure AD directory.
Multiple forests – match users

User identities exist across multiple directories

Common for all these scenarios is that distribution and security groups can contain a mix of users,
contacts, and FSPs (Foreign Security Principals)

FSPs are used in ADDS to represent members from other forests in a security group. All FSPs are
resolved to the real object in Azure AD.

Multiple forests – full mesh with optional GALSync

User identities exist across multiple directories. Match using: Mail attribute

A full mesh topology allows users and resources to be located in any forest and commonly there would
be two-way trusts between the forests.

If Exchange is present in more than one forest, there could optionally be an on-premises GALSync
solution. Every user would be represented as a contact in all other forests. GALSync is commonly
implemented using Forefront Identity Manager 2010 or Microsoft Identity Manager 2016. Azure AD
Connect cannot be used for on-premises GALSync.

In this scenario, identity objects are joined using the mail attribute. A user with a mailbox in one forest is
joined with the contacts in the other forests.

Multiple Forests – Account-Resource Forest

User identities exist across multiple directories. Match using: ObjectSID and msExchMasterAccountSID
attributes
In an account-resource forest topology, you have one or more account forests with active user accounts.
You will also have one or more resource forests with disabled accounts.

In this scenario one (or more) resource forest trusts all account forests. The resource forest has typically
an extended AD schema with Exchange and Lync. All Exchange and Lync services as well as other shared
services are located in this forest. Users have a disabled user account in this forest and the mailbox is
linked to the account forest.

Office 365 and topology considerations

Some Office 365 workloads have certain restrictions to supported topologies. If you plan to use any of
these, then read the supported topologies topic for the workload.

Workload

Exchange Online | If there is more than one Exchange organization on-premises (i.e. Exchange has been
deployed to more than one forest) then you must use Exchange 2013 SP1 or later. Details can be found
here: Hybrid deployments with multiple Active Directory forests Skype for Business | When using
multiple forests on-premises then only the account-resource forest topology is supported. Details for
supported topologies can be found here: Environmental requirements for Skype for Business Server
2015

You might also like