> 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/identity/one-person-many-accounts.md). # One person, many accounts Decide how a person's several accounts are represented — one identity with an account per managed system, separate records linked as related accounts for privileged access, and where service and non-h ## What this is, and when you need it A person in a large estate does not have an account. They have eight: one in each forest they work across, a second administrative account in one of them, a mailbox identity, an application account that predates the directory, and a shared credential nobody will admit to. This page decides how those are represented — which of them are *the same identity*, which are *separate records linked to a person*, and which are not people at all. You need it when designing for more than one directory, when administrators do privileged work from a second account, and when the estate contains service accounts that somebody has to own. Getting this wrong does not fail immediately; it fails at the first leaver, when the accounts that were never attached to a person are the ones nobody revokes. ## The decision | The account | Represent it as | Why | | ------------------------------------------------------------------ | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | A person's normal account in each directory, forest or application | **One identity, one login per managed system** | This is the model. One person, one set of entitlements, one leaver event that reaches every system | | A second, higher-privilege account for the same human | **A separate user record, linked as a related account** | It needs its own entitlements, its own certification, its own credential policy and its own lifecycle — while staying traceable to its owner | | A non-production or development account for the same human | **A separate user record, linked as a related account** | Same reasoning; usually a different approval path and a shorter life | | A service account owned by an application team | **A user record of a non-human type, with a named human owner** | It needs an owner, a review and a credential rotation. It does not need a person | | A shared credential used by several humans | **Nothing — remove it** | It cannot be attributed, certified or revoked meaningfully. Model the people, not the credential | ## What the model actually is Underneath, the shape is simple and worth stating precisely because two of its properties surprise people. One OpenIAM identity holds a set of **logins**, each bound to a managed system: an account in Forest A, an account in Forest B, an account in an application, and the OpenIAM account itself on the default managed system. Entitlements attach to the identity; provisioning fans out to the logins. ```mermaid flowchart LR P[One person - one OpenIAM identity] P --> L0[Login on the default managed system] P --> L1[Login on Forest A] P --> L2[Login on Forest B] P --> L3[Login on an application] P -. related account .-> A[Second identity - privileged] A --> L4[Admin login on Forest A] ``` Read the dotted line as the important one: a privileged account is a *second identity*, not a second login on the first. **An account name is unique within a managed system.** OpenIAM will not hold the same account name twice on one managed system, which means it cannot represent two people sharing one account. That constraint is useful — it is the product refusing to model something that cannot be governed. **One login per managed system per person is the assumption everything else makes.** Where an identity does hold two logins on the same managed system, OpenIAM takes the first one it finds when it authenticates, when it propagates a password, and when it provisions — with no flag marking one as primary and no defined order. That is the technical reason the second row of the decision table is a separate identity rather than a second login: the model has no way to distinguish "my normal account" from "my admin account" on the same system, so anything that resolves an account for a person will sometimes resolve the wrong one. ## Related accounts: the pattern for privileged and secondary identities A **related account** is a typed link between two OpenIAM user records: the person, and the second account that belongs to them. A person has at most one primary account and any number of related ones. Three relationship types ship. Two of them are named for a specific Active Directory development and staging pattern rather than as general categories; the third, a privileged-account type, is the one to reach for when tracking administrative second accounts. The list is metadata, so most deployments add their own — one per kind of second account they actually have. Decide those categories at design time, because they become the vocabulary of every later report and every certification campaign. What the link buys you, and what it does not: **It buys traceability and reach.** The second account has an owner. Reports and reviews can follow the link from a person to everything they hold. A password reset can be extended to a person's related accounts, so a compromise response reaches all of them rather than one. **It does not merge entitlements.** The second record holds its own access, is certified on its own, and is provisioned on its own. That separation is the point — an admin account's entitlements should not be attested alongside a normal user's — but it means the leaver process must explicitly follow the link. **A leaver process that terminates the primary identity and does nothing about its related accounts leaves those accounts live**, and they are the most privileged accounts in the estate. **It does not make the second account authenticate as the person.** It is a separate identity with a separate credential. Whether the two share a password is a Part 3 decision, and the usual answer for a privileged account is emphatically no. ## Service accounts and non-human identities Non-human identities are the population most often left out of a design and most often found by an auditor. Three things settle the treatment. **They are identities, and they belong in the model.** A service account with no OpenIAM representation is an account no campaign can review, no leaver process can touch and no report can count. Give it a user record with a non-human user type. OpenIAM ships user types including a system-account type, and the type list is metadata you extend. **Every one has a named human owner, and ownership is reviewed.** The owner is not the person who requested it three years ago; it is whoever answers for it now. When that person leaves, the account does not — which is precisely why owner reassignment has to be part of the leaver process. Model ownership as a related-account link or as an explicit attribute, but model it. **Their credentials are not people's credentials.** Password policy, rotation and storage for a service account are a different design from a workforce password, and interactive sign-in should not be possible with one at all. *Rotate service credentials* in the Administration Guide covers the operational half. Where a non-human identity is a workload rather than an account — a certificate, a token, a cloud workload identity — be honest in the design about what OpenIAM manages: it governs accounts and their entitlements on managed systems it has a connector for. A workload identity issued and rotated by a cloud platform is not an OpenIAM object, and pretending otherwise produces an inventory that is wrong. ## The multi-forest case The question this page exists to answer, in an estate with several forests, is: *my identity is in Forest A, the application sits in Forest B — what links them?* The answer is the identity, not the accounts. Each forest is its own managed system with its own connector and its own account for the person. One OpenIAM identity carries all of those accounts, correlated on the workforce identifier from Part 2 — **not** on the account names, which differ by forest by construction. Entitlements in Forest B are granted to the person, and provisioning creates or updates the Forest B account because that person holds an entitlement, regardless of which forest their "home" account is in. Two consequences to design for: **A person may need an account in a forest they do not work in.** That is not an anomaly; it is what entitlement-driven provisioning does. Decide whether the joiner process creates accounts everywhere or only on demand — on demand is almost always right, and it keeps the estate smaller. **Each forest needs a connector that can reach its own domain controllers.** That is a Part 6 placement question, but it is decided by this model: one connector reach per forest, not one connector for "Active Directory". ## What we recommend **One identity per person, one login per managed system.** Resist every proposal to model a second account as a second login on the same system; the model cannot tell them apart. **Every privileged or secondary human account is a separate identity, linked as a related account, with its own certification and its own credential policy.** Define your own relationship types rather than reusing the shipped development and staging names for whatever you happen to have. **Make related accounts a first-class part of the leaver design, in writing.** Terminating a person must enumerate and act on their related accounts. This is the failure that audits find. **Give every service account a user record, a non-human type and a named owner, and review ownership on a schedule** — not only when the owner leaves. **Do not model shared credentials.** Where one exists, the design output is a plan to remove it, not a representation of it. The circumstance that changes this advice is a small estate with one directory and no administrative second accounts, where related accounts add structure with nothing to hold. Even there, model the service accounts. ## What OpenIAM does not do here * **There is no primary flag among a person's logins on one managed system.** Where two exist, OpenIAM uses the first it finds for authentication, password propagation and provisioning, with no defined order. * **OpenIAM cannot represent two people sharing one account.** An account name is unique within a managed system, by constraint. * **A related-account link does not cascade lifecycle.** Terminating the primary identity does not terminate the linked records; that has to be designed into the leaver process. * **A related-account link does not merge or inherit entitlements.** The two records are governed separately, which is the intent, but it means nothing is shared unless you grant it twice. * **The shipped relationship types are two Active Directory-specific ones and a privileged-account type.** There is no general taxonomy of second accounts in the box; you define it. * **OpenIAM does not manage credentials it has no connector for.** A cloud workload identity or a platform-issued certificate is outside what the platform can govern, however much it belongs in your inventory. ## Related * [Identity correlation: choosing a matching key](/solution-architecture/identity/correlation-key.md) — the value that attaches all of these accounts to one person. * [Designing for every population](/solution-architecture/identity/populations.md) — where non-human identities sit alongside the human ones. * *Manage related accounts* in the Administration Guide — the link, its types and its audit trail. * *Resolve orphan accounts* and *Rotate service credentials* in the Administration Guide — the two operational consequences of this page. *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/identity/one-person-many-accounts.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.