> 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/access/password-strategy.md). # Password strategy Decide whether passwords are synchronized, federated or both — which direction they travel, what the Active Directory password filter costs you, and which accounts are in scope. ## What this is, and when you need it This page answers the question that follows immediately from [Where authentication should live](/solution-architecture/access/where-authentication-lives.md): *"but then how would OpenIAM know the password of the user?"* It decides whether a credential exists in OpenIAM at all, which direction password changes travel, and — the part most often left undefined until it causes an incident — which accounts are in scope for propagation and which are deliberately not. You need it as soon as any account in the estate still needs a local credential of its own, which in practice means every estate that has not already federated everything. ## Password synchronization is not single sign-on Say this out loud in the first workshop, because the two are conflated constantly and the confusion produces programmes that deliver working software the sponsor considers a failure. | | Password synchronization | Single sign-on | | ---------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------ | | What the user experiences | The same password works in several places. Each of them still asks for it | They authenticate once and are not asked again | | What it solves | Too many *different* passwords to remember, and the help-desk cost of resetting them | Too many *prompts* | | What it needs from the application | Only that its credential can be set by OpenIAM | That it can consume an assertion, a token, or an injected identity | | What it does about the login page | Nothing. The page is still there | Removes it | They are complementary, not alternative. A large estate typically needs both: synchronization for the accounts that still hold their own credential, single sign-on for the applications that can accept an assertion. What it must not do is promise one and build the other. ## The decision | Option | What it costs | What it buys | | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | **Federate, hold no password** | Only works for applications and populations that can federate | Nothing to synchronize, nothing to store, nothing to leak | | **OpenIAM is the credential authority; changes propagate outward** | Users change their password in OpenIAM's self-service rather than at the workstation, which is a change-management task | One policy, one history, one lockout, one place to reset. The cleanest model where OpenIAM authenticates | | **The directory is where passwords are changed; OpenIAM captures them inbound** | A password filter on every domain controller, and the two design consequences below | Users keep the workstation experience they already have, and every other account follows | | **Both directions** | The most moving parts, and a clear rule about which change wins | Realistic for a large estate mid-migration | | **No synchronization** | Every account keeps its own password and its own reset path | Sometimes correct — for privileged and service accounts it is the *only* correct answer | ## Which direction a password change travels **Outward, from OpenIAM.** A password set or reset in OpenIAM is applied to the user's identities and provisioned to the managed systems those identities live on. Two behaviours matter architecturally: the managed system the change originated from is excluded from the fan-out, so a change cannot loop back on itself; and each managed system is included or excluded by its own **Include in password sync** setting, which is present on the shipped managed systems and treats anything other than an explicit exclusion as included. That last point is the one to design around — **the default is to propagate**, so exclusion is an act you must remember to perform. **Inward, from Active Directory.** Users change their password with the ordinary Windows experience and OpenIAM learns about it. This is the path the AD Password Filter exists for, and it is the subject of the next section. **Both.** Workable, and common during a migration, but state the precedence: if a user changes their password in OpenIAM and at their workstation at the same moment, the last write wins and neither system will tell you which it was. ## The Active Directory password filter The filter is a component that runs **on a domain controller, inside the process that handles password changes**. Windows offers two hooks and OpenIAM's filter uses both: one is called *before* the change to say whether the proposed password is acceptable, and one is called *after* the change has been accepted to notify a listener of the new value. So the filter can do two distinct jobs — validate a proposed password against OpenIAM's policy, and capture an accepted one for synchronization — and they can be enabled independently. Four properties of that design belong in an architecture document. **It must be installed on every domain controller that can service a password change**, because any of them can. A filter on three of five domain controllers produces a synchronization that works about sixty per cent of the time, which is worse than one that does not work at all, because nobody notices. **Its configuration is local to each domain controller.** Which OpenIAM instance to call, which managed system the domain corresponds to, whether validation is on, and an optional restriction file naming the containers whose accounts are in scope — all of it is per host. Keeping that configuration identical across every domain controller is an operational requirement the design has to name and someone has to own. **It supports more than one configuration on the same host**, processed in turn, so one domain can feed more than one OpenIAM managed system or more than one OpenIAM environment. That is genuinely useful during a migration — and it means the work done per password change multiplies by the number of configurations, in sequence. **The account must already be known to OpenIAM.** The filter sends the account name and the managed system identifier; OpenIAM finds the person by that pair, and the call fails if the account is not a known login on that managed system. This is the concrete form of the position that identity lifecycle comes first: password synchronization from a directory does not work for accounts OpenIAM has never correlated. ### Two design consequences to state explicitly **Policy validation fails open by default.** When the filter is set to validate a proposed password against OpenIAM's policy and OpenIAM cannot be reached, the outcome is governed by a single setting for unknown validation responses, and the installer sets it to allow. So **a password change proceeds when OpenIAM is unreachable, and the only record is a warning in the domain controller's event log.** That is a deliberate and defensible choice — the alternative is that an unreachable OpenIAM stops password changes across the domain — but it is a choice your risk owner should make knowingly rather than inherit. Setting it to reject makes the filter fail closed, and makes OpenIAM's availability a precondition for changing a password anywhere in the domain. **The validation call is synchronous, and it sits on the password-change path.** The user waits for it, so OpenIAM's reachability and its responsiveness both become part of how changing a password feels at the workstation: a slow platform is a slow password change. Where a host carries several configurations they are processed in turn, so the waits add up. Treat OpenIAM's responsiveness as a domain controller concern once validation is enabled, and monitor it as one. ### What happens when the notification cannot be delivered The capture path is more forgiving than the validation path, and its behaviour matters because it involves credential material at rest on a domain controller. If the notification cannot be delivered, the filter writes an encrypted record of the account and its new password into local storage on the domain controller and starts a background Windows service. That service retries on a timer, clears each record as it succeeds, keeps the ones that still fail, and stops itself once nothing is left to send. The interval is configurable, with a floor of thirty seconds; the installer sets five minutes. An unrecognised response is queued the same way, which is the installer's default. What follows is a design requirement rather than a curiosity. **Credential-adjacent material sits at rest on the domain controller until OpenIAM comes back**, for as long as the outage lasts, on the hosts an organization guards most closely. So the design should minimise that window — make the platform reachable from the domain-controller segment and keep it available — and monitor for undelivered notifications, so that a long OpenIAM outage is treated as an incident rather than an inconvenience. ### The divergence nobody plans for If validation is left off, OpenIAM still evaluates its own password policy when the notification arrives. A password that Active Directory accepted and OpenIAM rejects is not stored, not retried and not escalated: the change stands in the directory, does not stand in OpenIAM, and the only trace is a warning in the domain controller's event log. So **the two policies must agree, or validation must be on.** An estate where OpenIAM's policy is stricter than the domain's will accumulate users whose directory password works and whose OpenIAM password is something older, and it will discover them one help-desk call at a time. ## What "in scope" means, and for which accounts Scope is set in two independent places, and both belong in the design. **Inbound scope** is decided at the domain controller: which hosts carry the filter, whether a configuration is active, and an optional restriction file listing the containers whose accounts are in scope. That file supports both an allow list and a deny list, with deny evaluated first, so a design can say "everything under these organizational units, except these". Because the file lives on each host, it is subject to the same consistency requirement as everything else in the filter's configuration. **Outbound scope** is decided per managed system, by whether it is included in password synchronization. The source system is always excluded from a fan-out originating there. A password reset can additionally be extended to a person's related accounts, which is opt-in and is exactly what you want for a compromise response and exactly what you do not want as a default. Three categories should be out of scope deliberately, and named as such: | Category | Why it is out of scope | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Privileged second accounts** | The entire point of a separate administrative identity is a separate credential. Synchronizing it re-couples what was separated | | **Service and non-human accounts** | They have a rotation lifecycle, not a user lifecycle, and no human should be able to change one by changing their own password | | **Break-glass accounts** | They must work when the platform does not | ## The cross-forest case A person with accounts in five forests and one password is the ordinary reason for synchronization to exist. The model handles it directly: one identity, one credential decision, an account per forest, and propagation to each forest's managed system subject to its own inclusion setting. Where the inbound path is in use, each forest needs its own filter deployment and its own configuration naming that forest's managed system. What the model does not do is make one forest's password *authoritative* for another's: each account holds its own credential and synchronization keeps them equal, so a forest whose own policy rejects a value the others accepted diverges — the same divergence as above, once per forest. ## The connection to form fill One more consumer of a synchronized password is easy to miss. When the Access Gateway signs a user into a legacy application by filling that application's own login form, one of the values it can inject is the user's password on the gateway's managed system. **Form-fill single sign-on therefore depends on password synchronization** — it works precisely because the credential the application expects is one OpenIAM knows and keeps current. Design the two together, or the form fill will work on the day it is built and stop the first time that application's password changes anywhere else. See [Choosing an SSO approach per application](/solution-architecture/access/sso-approach-per-application.md). ## What we recommend **Federate where you can, and hold no password for that population.** The cheapest password is the one that does not exist. **Where OpenIAM authenticates, make OpenIAM the credential authority and propagate outward.** One policy, one history, one reset path. **Use the inbound filter when the workstation must stay the place people change their password** — in a large Windows estate, usually the honest answer. Accept the two design consequences explicitly: decide and record whether validation fails open or closed, and monitor OpenIAM's responsiveness as a domain controller dependency. **Install the filter on every domain controller, and treat its configuration as one artefact deployed identically.** A partial deployment is the worst outcome available. **Make OpenIAM's password policy and the domain's password policy agree**, or turn validation on. Do not leave them different and validation off. **Name the out-of-scope accounts in the design**, not in the configuration afterwards. The circumstance that changes this advice is an estate that has genuinely federated everything and retains no local credentials. There, none of this applies — and there are very few such estates. ## What OpenIAM does not do here * **Validation by the password filter fails open by default.** A password change proceeds while OpenIAM is unreachable, with only a domain controller event log entry — set the behaviour you want knowingly. * **The filter's validation call is synchronous on the password-change path.** OpenIAM's responsiveness is felt by the user changing their password, and several configurations on one host are processed in turn. * **A password OpenIAM's policy rejects on the inbound path is dropped, not retried and not escalated.** The directory and OpenIAM diverge silently. * **The filter's configuration is per domain controller.** There is no central management of it, no console view of which hosts are configured how, and no product-level consistency check. * **The queued-retry store holds credential-adjacent material on the domain controller** for the duration of an outage. Nothing shortens that window but OpenIAM becoming reachable again. * **Password synchronization is not password *****reconciliation*****.** Nothing detects that an account's password was changed out of band on a system that has no filter; the accounts simply diverge. * **This release does not provide an end-user credential vault.** What OpenIAM holds are the credentials for the identities it manages, not arbitrary per-application passwords a user has chosen — where a population needs a personal vault, plan for a separate tool. ## Related * [Where authentication should live](/solution-architecture/access/where-authentication-lives.md) — the decision this one follows from. * [Choosing an SSO approach per application](/solution-architecture/access/sso-approach-per-application.md) — including form fill, which depends on this page's outcome. * *Password policy* and *Configure password recovery and account unlock* in the Administration Guide — the policy objects this design configures. * Part 2, *One person, many accounts* — the accounts that should be out of scope, and why. *Applies to OpenIAM 2026.8.1. Last reviewed 13 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/access/password-strategy.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.