> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/reference-architectures/single-organization-multi-forest.md). # One organisation, several Active Directory forests One organization whose people and applications are spread across several Active Directory forests, with OpenIAM as the identity provider — the correlation key, per-forest accounts, and how a user in o ## What this is, and when you need it This is the design for a single governance domain — one HR function, one set of policies, one audit boundary — whose directory estate is not single. Several Active Directory forests exist, usually because of past acquisitions or because regions were allowed to run their own, and no one is going to consolidate them inside the horizon of this programme. Usernames differ between forests. A person may have an account in one forest, two, or all five. You need this design when the obvious question — "which directory is the identity?" — has no answer, because none of them is. The decision it centres on is what links a person's accounts across forests, and where authentication happens once it can no longer happen in *the* directory. ## The situation it fits * One organization, one HR system or one clearly primary one, one governance and audit boundary. * Two or more Active Directory forests, with no trust between all of them, or trusts that exist but are not something you want the identity design to depend on. * Usernames that differ across forests for the same person, and no guarantee that any directory attribute is unique across all of them. * Applications bound to the forest they were deployed in, plus a growing set that speak SAML or OpenID Connect and are not bound to any forest. * A population large enough — tens of thousands upward — that per-login round trips to a directory become a capacity question rather than a detail. ## The shape The identity is established from HR, correlated by a workforce identifier, and carries one account per forest. OpenIAM is the authentication authority; the forests hold accounts, not the identity. ```mermaid sequenceDiagram participant U as User, account in Forest A participant APP as Application hosted in Forest B participant IAM as OpenIAM identity provider participant DB as Forest B directory U->>APP: Opens the application URL APP->>IAM: Redirects the browser for authentication IAM->>IAM: Verifies the credential and evaluates entitlement IAM->>APP: Returns an assertion carrying the enterprise identifier APP->>DB: Resolves the local account named in the assertion APP->>U: Establishes the application session ``` The account the application resolves in Forest B exists because OpenIAM provisioned it earlier, as part of the person's joining or of a later access request — not because the sign-in created it. That ordering is the whole design: **lifecycle first, then single sign-on.** Nothing in the diagram works if the Forest B account is not already there. ## The decisions embedded in it | Decision | The choice made here | Explained in | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------- | | What links a person's accounts | A trusted workforce identifier — an employee number, or a synthetic enterprise identifier minted for the purpose. Never a username | Part 2, *Identity correlation: choosing a matching key* | | Where the identity comes from | The HR system, with precedence rules for populations HR does not own | Part 2, *Choosing your authoritative sources* | | How the forests are modelled | Each forest is its own managed system with its own connector and its own account for the person; one OpenIAM identity carries all of them | Part 2, *One person, many accounts* | | Where authentication happens | At OpenIAM. Credential verification is offloaded to ADFS on the domains that have it, and is **not** delegated back to Active Directory on the domains that do not | Part 3, *Where authentication should live* | | What happens to passwords | OpenIAM is the credential authority; the password is propagated to the forest accounts that need a local credential | Part 3, *Password strategy* | | How each application is integrated | A modern protocol where the application supports one; the Access Gateway where it does not | Part 3, *Choosing an SSO approach per application* | | Where the user starts | Portal, bookmark and deep link all work; the design does not require users to abandon their bookmarks | Part 3, *Entry points and the user's experience* | | Where the connectors run | One connector reach per forest, placed so that it can see that forest's domain controllers | Part 6, *Connector placement* | ### The correlation key is the decision that cannot be revised cheaply Everything else on this page can be changed later. The correlation key cannot, because by the time you want to change it there are identities, accounts and entitlements that were linked using it. The key must be a value that is unique per person across the whole estate, stable across a change of name, marital status, department or forest, and present for every population you intend to manage. In an organization with several forests, a username satisfies none of those: it differs by forest, it changes, and it is unique only within its own directory. Email is no better — it changes, and acquired organizations frequently have people with two. Where a workforce identifier already exists and is genuinely enforced, use it. Where it does not — which is common when the forests came from separate companies — the right move is to mint an enterprise-wide identifier and treat OpenIAM as the place it is issued and held. Large organizations do this routinely, precisely so that a person has one identity across a parent and its subsidiaries. It costs a conversation with HR and it removes an entire class of later problem. OpenIAM's synchronization can match an incoming record on the principal, the principal within a specific managed system, the user identifier, an email address, a name, an employee identifier, or a custom attribute. Employee identifier is the one to reach for; managed-system principal is the useful fallback for a feed that genuinely only knows the account name in one forest. ### One identity, several accounts, and why that is not a compromise A person in this design has one OpenIAM identity and one login per forest they hold an account in. Those logins are not duplicates to be cleaned up — they are the model working. The identity carries the person's attributes, entitlements, lifecycle state and history; each login carries a forest-local account name and its state in that forest. This is what makes a leaver event tractable. One termination on the identity disables every forest account the person holds, in the same operation, with one audit trail — instead of five directory clean-ups that someone has to remember to run. It is also what makes the correlation key load-bearing: get it wrong and you get two identities for one person, each holding half the accounts, and no single termination that covers both. ### Where authentication happens, and why not in Active Directory The instinct is to point OpenIAM at Active Directory and let the directory check the password. Resist it where ADFS is not present. Verifying a credential by binding to a domain controller on every sign-in is slow, it does not scale comfortably to six figures of users, and Microsoft's own guidance has moved away from Active Directory as an authentication mechanism. It also makes forest availability a dependency of every sign-in in the organization, which is precisely the coupling this design exists to remove. Where ADFS *is* enabled on a domain, offloading credential verification to it is clean, efficient and worth doing — the federation trust does the work and the directory is not in the interactive path. The first question to ask of every forest in scope is therefore whether ADFS is enabled on it, because the answer changes the authentication design for the users in that forest and nothing else on this page. OpenIAM also supports authenticating a user against a managed system directly, which is the delegated pattern. It exists, it works, and it is the right answer for a small population or a specific edge case. It is not the right answer for an enterprise sign-in path. ### Passwords across forests Once OpenIAM is the credential authority, the forest accounts still need a working local password for anything that authenticates against the directory itself — file shares, legacy Windows integrations, a domain-joined workstation. The design propagates the password to those accounts. Changes made outside OpenIAM are the other half of the problem. A user who changes their password at a Windows workstation changes it in Active Directory, not in OpenIAM, and the two drift. The OpenIAM Password Filter for Active Directory is the component that closes this: it installs on the domain controllers, captures the change as it happens, and sends it to OpenIAM against the managed system that represents that forest — optionally scoped to particular organizational units. It is a per-forest decision, not a global one. Be precise about what this is and is not. **Password synchronization is not single sign-on.** It makes one password work in several places; it does not remove the sign-in prompt, it does not give you a single session, and it does not produce an audit trail of application access. Estates conflate the two constantly, and a programme that delivers password synchronization and calls it SSO will be judged against the wrong expectation. ### Reaching an application in another forest The forest boundary matters much less than it appears to, once the application federates. An application that accepts a SAML or OpenID Connect assertion does not care which forest the user's account lives in — it cares that the assertion is signed by a trusted issuer and names an identity it recognises. That is why the sequence above has no path from Forest A to Forest B at all. The forest boundary matters in exactly two places. First, where the application authenticates against a directory itself — an integrated Windows application, a file share, a legacy system doing an LDAP bind. There the user genuinely needs an account in that forest, and the design's answer is that OpenIAM provisioned one. Second, where the application resolves the assertion against a local directory account, as in the diagram: the account must exist and must be findable from the value the assertion carries, which means the attribute the application matches on has to be one OpenIAM sets when it provisions. For applications behind the Access Gateway the same holds. The gateway establishes the session and injects the identity into the request; whether the application then looks the user up in a local directory or in its own database is the application's business, and either way the account has to be there first. ## What we recommend **Settle the correlation key before anything else, and mint one if the estate does not have one.** It is the cheapest decision to get right now and the most expensive to revisit. **Ask, forest by forest, whether ADFS is enabled**, and let the answer set the authentication design for that population. Do not adopt one authentication pattern across all forests because it is tidier. **Model each forest as its own managed system and each per-forest account as its own login.** Do not try to nominate one forest as the master directory; you will spend the programme reconciling the other four against a choice that was arbitrary. **Sequence the work as lifecycle, then password, then single sign-on.** Delivering SSO before accounts are reliably provisioned produces a demonstration rather than a service. **Where a decision could go either way, prefer the one that removes a runtime dependency on a forest.** The reason to run this design at all is that no single forest should be able to stop the organization signing in. ## What would make this the wrong choice * **The forests are genuinely being consolidated inside the programme's horizon.** If four forests become one within a year, much of this design is scaffolding for a state that will not exist. Model the target, not the transit. * **ADFS is already the enterprise authentication authority and is staying.** Then the design still holds for lifecycle and governance, but OpenIAM is not the identity provider in it, and the pages on where authentication lives should be read with that as the fixed point rather than the variable. * **There is no attribute that can serve as a correlation key and no appetite to create one.** Without a key this design does not degrade gracefully; it produces duplicate identities. If HR will not supply an identifier and the organization will not mint one, resolve that before designing anything else. * **Two of the "forests" are actually two organizations.** If the second estate has its own HR function, its own governance and its own audit boundary, this is not the pattern — see [Coexistence with an incumbent IGA](/solution-architecture/reference-architectures/coexistence-with-incumbent-iga.md) or [Cross-organization federation](/solution-architecture/reference-architectures/cross-organization-federation.md). * **The population is small.** Below a few thousand users the capacity argument against delegated authentication weakens considerably, and a simpler design may be defensible. ## What OpenIAM does not do here * **OpenIAM does not merge forests, and it does not create trusts between them.** It holds one identity that carries accounts in each; the forests remain exactly as separate as they were. * **Correlation is not automatic.** The key is a design decision that you make and configure; there is no identity-resolution heuristic that will work it out from the data. * **A synchronization that matches on a value present on more than one identity does not fail.** It updates the first identity it finds and reports no error. Prove the key is unique before a feed runs in production — see *How a synchronization matches and processes a record* in the Administration Guide. * **The Password Filter is a per-domain-controller deployment.** There is no agentless way to capture a password change made directly in Active Directory. * **Password propagation does not reconcile history.** It carries the current password forward; it does not give the forest accounts a shared password history or a shared lockout state. ## Related * Part 2, *Identity correlation: choosing a matching key* — the decision this design turns on. * Part 3, *Where authentication should live* — the reasoning behind not delegating to Active Directory. * *Manage related accounts* and *Resolve orphan accounts* in the Administration Guide — the mechanisms for linking and for cleaning up what correlation missed. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/reference-architectures/single-organization-multi-forest.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.