title: Multi-Forest & Multi-Domain Setup category: Connections tags: multi-forest, multi-domain, cross-forest, trusts, connections priority: Normal

Multi-Forest & Multi-Domain Setup

Many enterprises operate multiple Active Directory forests or domains due to mergers, acquisitions, regulatory requirements, or organizational boundaries. IdentityCenter supports these complex topologies by allowing you to create separate connections for each forest and unify identities through its person-centric model.

Key Concepts

Before configuring a multi-forest environment, review these foundational concepts:

Architecture Overview

  ┌─────────────────────────────────────────────────────┐
  │                  IdentityCenter                     │
  │                                                     │
  │  Connection A ──► Forest: corp.local                │
  │  Connection B ──► Forest: partner.com               │
  │  Connection C ──► Forest: acquired.org              │
  │  Connection D ──► Entra ID tenant                   │
  │                                                     │
  │          ┌──────────────────────┐                   │
  │          │   Person Records     │                   │
  │          │  (Unified Identities)│                   │
  │          └──────────────────────┘                   │
  └─────────────────────────────────────────────────────┘

Each forest gets its own connection. Objects from all forests are synchronized into a shared database and matched to unified Person records.

Creating Connections per Forest

One Connection per Forest

Create a separate connection for each AD forest in your environment:

1. Navigate to Administration > Connections
2. Click New Connection for each forest
3. Configure each connection with the forest's domain controller, Base DN, and service account

One Connection per Domain (Alternative)

In a multi-domain forest, you can either:

• Use the Global Catalog (port 3268/3269) to query all domains in the forest through a single connection
• Create separate connections per domain for finer control over scope and credentials

Tip: The Global Catalog only contains a subset of attributes. If you need attributes that are not replicated to the GC (check your AD schema), use per-domain connections instead.

Service Account Considerations

Dedicated Accounts per Forest

Each forest requires its own service account because credentials from one forest are not valid in another (unless trusts are configured for authentication delegation).

Trust-Based Authentication

If a two-way trust exists between forests, you may be able to use a single service account from the trusting forest. However, this approach has limitations:

• The trust must allow authentication delegation
• Selective authentication may block access
• Network latency can increase query times across trust boundaries

Recommendation: Use dedicated service accounts in each forest for reliability and clarity. This avoids dependency on trust configurations and simplifies troubleshooting.

Service Account Permissions

For each service account, delegate the minimum required permissions:

1. Open Active Directory Users and Computers in the target forest
2. Right-click the OUs you want to sync and select Delegate Control
3. Grant the service account Read all user information, Read all group information, and related read permissions
4. If write-back is needed, also delegate Write permissions on the target attributes

Sync Project Configuration

Separate Projects per Forest

Create individual sync projects for each forest connection:

This approach gives you independent control over sync schedules, LDAP filters, and attribute mappings per forest.

Global Catalog Projects

If using Global Catalog connections (port 3268), you can create sync projects that span all domains in a forest with a single query. This is useful for large forests with many child domains.

Note: Objects queried via the Global Catalog will have a reduced set of attributes. The most common attributes (displayName, mail, sAMAccountName, userPrincipalName, member, memberOf) are in the GC by default.

Object Matching Across Forests

IdentityCenter's person-centric model is designed for multi-source environments. When objects from different forests are synced:

1. Each object is stored with its SourceConnectionId, keeping them distinct
2. The Person matching engine runs after each sync
3. Objects from different forests are matched to the same Person using:
   • Email address (most reliable cross-forest identifier)
   • Employee ID (if populated consistently across forests)
   • UPN (if UPN suffixes are shared)
   • Display Name + Department (fuzzy match as a fallback)

Example: Merged Organization

After a merger, "Jane Smith" might have accounts in both forests:

IdentityCenter will match both objects to a single Person record because the email and employee ID match.

Manager Resolution Across Forests

When a user's manager is in a different forest, standard manager resolution cannot follow the DN reference because the DN belongs to a different directory namespace.

How Cross-Forest Manager Resolution Works

1. User jsmith in corp.local has manager DN: CN=Jane Doe,OU=Executives,DC=partner,DC=com
2. This DN does not exist in the corp.local directory -- it references partner.com
3. If objects from partner.com are also synced, IdentityCenter's Lookup step resolves the DN by searching across all synced objects
4. The manager relationship is established through the unified Person record

Requirements for Cross-Forest Manager Resolution

• Both forests must be connected and synced in IdentityCenter
• The manager object must have been synced before the lookup step runs
• The DN reference must exactly match the manager's DN in the other forest

Tip: Run sync projects for all forests before relying on manager resolution. If managers are not resolving, check the order of your sync schedules.

Common Multi-Forest Scenarios

Parent/Child Domains

A single forest with a parent domain and one or more child domains:

corp.local (parent)
  ├── us.corp.local (child)
  ├── eu.corp.local (child)
  └── ap.corp.local (child)

Recommendation: Use a Global Catalog connection at the forest root. All child domain objects are visible through the GC.

Resource Forest

A dedicated forest for Exchange, Skype for Business, or other resources, with linked mailboxes pointing to user accounts in the account forest:

Recommendation: Connect both forests. The resource forest objects will link to account forest users through the Person matching engine.

Merger/Acquisition

Two (or more) completely separate forests with no trust relationship:

Recommendation: Create independent connections for each forest with dedicated service accounts. Use email or employee ID to correlate identities. Over time, as accounts are migrated, the Person records will naturally consolidate.

Monitoring Multi-Forest Health

With multiple forest connections, monitoring is critical:

1. Connection Dashboard -- Check all connections show an Active/Healthy status regularly
2. Sync Run History -- Review sync run logs for each forest to catch failures early
3. Object Counts -- Compare synced object counts against expected totals per forest
4. Unmatched Objects -- Review objects that did not match to a Person -- these may indicate cross-forest correlation issues

Next Steps

• Creating a Connection -- Detailed connection setup guide
• Connecting to Entra ID -- Add cloud directories to your multi-source environment
• Connection Troubleshooting -- Resolve connectivity issues across forests
• Manager Resolution -- Deep dive into manager hierarchy building
• Understanding the Identity Model -- How Person matching works across sources