> 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/administration-guide/lifecycle/configure-managed-system.md). # Configure a managed system Create a managed system — which connector, the fields that matter, the credential, save, activate, then capture the first operation before anything reaches the target. ## What this is, and when you need it A **managed system** is one `MANAGED_SYS` row: one endpoint, one credential, one connector reference, one target instance. It is the object every other lifecycle page hangs off — policy maps, reconciliation configs, synchronization configs and authentication providers all point at it by `MANAGED_SYS_ID`. This page takes you from an empty form to a saved, active system whose connector answers, with the first operation captured before anything reaches the target. Create one per target *instance*, not per target product. Test and production are two managed systems even when they share a connector definition; the credential, endpoint and container differ, and the whole point of a managed system is to hold exactly those. Installing and registering the connector *package* is a different task and is not in this guide — see [Connectors and managed systems](/administration-guide/lifecycle/connectors-and-managed-systems.md). The specific risk: **an absent `ON_DELETE` resource property means "delete the account"**. Both places OpenIAM reads it treat an absent or blank value as `DELETE`, so a newly created managed system deletes target accounts on deprovisioning unless you add the row. Read [Change configuration safely](/administration-guide/start/change-safely.md) once before you activate anything. ## At a glance | | | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | A saved, active managed system reporting a connector reply of `Ok`, its first operation captured in simulation with the values you entered, and nothing yet at the target | | **Where** | **Provisioning → Managed System**, `/webconsole/mngsystemlist`; the form is `/webconsole/mngsystem` | | **You need first** | A connector definition, the endpoint it wants, a least-privilege service account scoped to a test container, and the **Managed Systems** menu resource (`MNGSYS_MENU_ITEM`, under **Provisioning**) with its **Create New Managed System** child (`MNGSYS_NEW`) | | **Takes** | 30–45 minutes, plus one heartbeat sweep (shipped 60 s) before the connector status means anything | | **Reversible** | Partly — untick **Active**, restore the recorded values or delete the system; but a target account a deprovisioning already deleted cannot be brought back, and an exposed credential must be rotated, not restored | ## Before you begin * The connector definition to select. It decides which connector-specific fields the form shows. * The target endpoint in the form the connector wants — for LDAP a URL and port, for JDBC a single connection string, for REST a base URL plus per-operation paths. * A least-privilege service account, and the target container it is scoped to (test OU, test schema, test tenant). * The connector-specific values from that connector's **Connector Configuration Guide**, which is the only thing that defines what each one means for your target. * A `` you can provision repeatedly. ## Create the managed system {% stepper %} {% step %} ### Check the target is not already registered At `/webconsole/mngsystemlist`, search by name. The list is the connectivity dashboard, so it also tells you whether an existing system for this target already has a live connector. Scope this first system to a test OU, test schema or test tenant, and pick one `` you can provision repeatedly. {% endstep %} {% step %} ### Create with Active off Open `/webconsole/mngsystem` and fill these six. Everything else on the form can wait. | Field | What to enter | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Connector** | The connector definition for this target. It also decides which connector-specific fields appear further down the form. Required unless **Manual**. | | **Managed System Name** | Include the environment. This name appears in policy maps, the reconciliation batch task name, the report path and every audit event. | | **Description** | Eighty characters. It truncates silently past that. | | **Host URL**, **Port** | The endpoint, reachable **from the connector host**, not from your workstation. Connectors that take a connection string leave both blank. | | **Login Id**, **Password** | The least-privilege service account, in the format the target wants: `iam\Administrator` for the AD connector, a bind DN for LDAP, a database login for JDBC, a client ID for REST. | | **Communication Protocol** | `SSL` or `CLEAR` — the dropdown offers nothing else, and the value is passed straight through to the connector. | Leave **Active**, **Provision all users with this managed system** and **Supports Date for Affiliations** off. Leave **Simulation Requests** and **Downstream Managed System** empty. Every remaining field, and the column each one writes, is in [Managed system fields](/administration-guide/reference/managed-system-fields.md#the-managed-system-form-field-by-field). **Save**. The route redirects to `mngsystem?id=`; the audit action is `CREATE_MANAGED_SYSTEM`. {% endstep %} {% step %} ### Fill the connector-specific fields Reopen and complete the dynamic fields the connector's template shows. Point the user Base DN at a **test container**. Make the user Search Filter narrow enough that a first search returns a handful of objects, not the directory. For LDAP or Active Directory that is six fields: **Object Primary Key for User** (`uid` on OpenLDAP, `CN` on AD), **Base DN for User** (where objects are created, e.g. `ou=people,dc=openiam,dc=org`), **Search Base DN for User** (where they are looked up, e.g. `dc=openiam,dc=org`), **Search Filter for User** (`(&(objectclass=inetOrgPerson)(uid=?))`, where `?` is the placeholder the connector substitutes the principal into), **Search Scope** (`SUBTREE_SCOPE`) and **Target System Type** (`LDAP`, `ACTIVE_DIRECTORY` or `EDIRECTORY`). Worked sets for LDAP, JDBC and SCIM, with the shipped values of each: [Managed system fields](/administration-guide/reference/managed-system-fields.md#worked-configuration-1-ldap-or-active-directory). A required dynamic field left blank blocks the save, flagging the field itself rather than showing a message — so if **Save** does nothing, look for a highlighted dynamic field before anything else. {% endstep %} {% step %} ### Add the attribute rows In the **Attributes** table add, at minimum, `ON_DELETE` with the value your policy actually wants — `DELETE`, `DISABLE` or `UPDATE`, where absent and blank both mean `DELETE`. Add `INCLUDE_IN_PASSWORD_SYNC = N` if this system must not receive password changes. Add any connector-specific attributes its guide names — these are forwarded to the connector verbatim, and are the intended channel for them. Add `PRE_PROCESS`/`POST_PROCESS` only if you have a script, and only as a Groovy registry ID: a path resolves to nothing and OpenIAM silently substitutes a no-op. The four attribute names OpenIAM itself reads are in [Managed system fields](/administration-guide/reference/managed-system-fields.md#managed-system-attributes-the-four-names-that-mean-something). Save, reopen, and read the rows back. `MODIFY_MANAGED_SYSTEM` carries the full request body. {% endstep %} {% step %} ### Build the policy map Nothing is sent that is not on a policy-map row. If the connector definition has templates, **Create Default Policies** copies them; otherwise build the map by hand. See [Build a policy map](/administration-guide/lifecycle/policy-map.md). {% endstep %} {% step %} ### Activate, and let the heartbeat run {% hint style="warning" %} Risk changes at this tick. While **Active** is off nothing reaches the target; once it is on, an active system with no `ON_DELETE` row deletes target accounts on deprovisioning, and an `ASSIGN_TO_ALL` tick reaches every user. {% endhint %} Tick **Active** and save. OpenIAM tests the connection immediately after a successful save — but that test reads stored heartbeat replies, so on a brand-new system it reports failure until the sweeper has broadcast at least once. A failure here on a system you have just created is expected and is not evidence of a configuration error. Wait one `org.openiam.idm.connector.health.check.sweeptime` interval (shipped 60 s), then check the dashboard. See [Verify connectivity to the target](/administration-guide/lifecycle/verify-connection.md). {% endstep %} {% step %} ### Capture the first operation in simulation Add `Add` (and, if you use it, `Save`) to **Simulation Requests**, provision ``, and read the captured request at `/webconsole/simulation?id=` before you let anything reach the target. See [Simulation mode](/administration-guide/lifecycle/simulation-mode.md). {% endstep %} {% endstepper %} ## Verification * **Values persisted.** Reopen `/webconsole/mngsystem?id=` and read back Name, Connector, Active, Host URL, Port, Communication Protocol, Category, Simulation Requests, Downstream, every dynamic field and every attribute row. * **Audit.** `CREATE_MANAGED_SYSTEM` or `MODIFY_MANAGED_SYSTEM`, with the whole submitted body. `CLONE_MANAGED_SYSTEM` for a clone, `DELETE_MANAGED_SYSTEM` for a delete, `IMPORT_MANAGED_SYSTEM` for a promotion import. All retentions ship `-1` — [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md). * **The row itself**, when you need to be certain what is stored rather than what is rendered: {% code overflow="wrap" expandable="true" %} ```sql SELECT m.MANAGED_SYS_ID, m.NAME, m.IS_ACTIVE, m.IS_MANUAL_SYSTEM, m.CONNECTOR_ID, m.HOST_URL, m.PORT, m.COMM_PROTOCOL, m.USER_ID, m.SEARCH_SCOPE, m.HNDLR_5, m.CONNECTION_STRING, m.DRIVER_URL, m.DOWNSTREAM_SYSTEM_ID, m.ASSIGN_TO_ALL, m.SUPPORTS_DATE_FOR_AFFILIATIONS, m.RESOURCE_ID, o.OBJECT_TYPE, o.KEY_FIELD, o.BASE_DN, o.SEARCH_BASE_DN, o.SEARCH_FILTER FROM MANAGED_SYS m LEFT JOIN MNG_SYS_OBJECT_MATCH o ON o.MANAGED_SYS_ID = m.MANAGED_SYS_ID WHERE m.MANAGED_SYS_ID = ''; SELECT p.NAME, v.ATTR_VALUE FROM RESOURCE_PROP p JOIN MANAGED_SYS m ON m.RESOURCE_ID = p.RESOURCE_ID LEFT JOIN RES_ATTRIBUTE_VALUES v ON v.RESOURCE_PROP_ID = p.RESOURCE_PROP_ID WHERE m.MANAGED_SYS_ID = ''; ``` {% endcode %} * **On the wire.** The generated connector request is persisted to the `provisionconnectorrequest` index and the reply to `connectorreply`. Confirm `LOOKUP_QUERY`, `BASE_DN`, `KEY_FIELD` and your connector-specific attributes are present with the values you expect. See [Search indexes](/administration-guide/reference/search-indexes.md). * **Linked authentication providers.** The form lists them for an existing system. That list is a dependency list: deletion is refused with `LINKED_TO_AUTHENTICATION_PROVIDER` while any provider points here, and changing the credential can break delegated authentication. ## When it goes wrong | Symptom | Cause | Fix | | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Save** does nothing, no message | Either the system is not **Manual** and no connector is selected, or a required dynamic field is empty and the field itself is flagged rather than a message shown | Select a connector; fill the highlighted dynamic field. Do not tick **Manual** to get past it. | | Save rejected, `NO_NAME` | `NAME` blank | Name it. | | Save rejected, `CONNECTOR_REQUIRED` | Non-manual with blank `CONNECTOR_ID` | Select a connector. | | Description truncated | `DESCRIPTION` is `VARCHAR(80)` | Shorten it, or put the detail on the resource. | | Expected connector field absent | The definition's `METADATA_TYPE_ID` has no `MANAGED_SYSTEM_TEMPLATE` page template with a `UI_FIELD_TEMPLATE_XREF` row for it | Repair the template — [Connectors and managed systems](/administration-guide/lifecycle/connectors-and-managed-systems.md#connector-definitions-supply-dynamic-fields). Never put the value into a different field that happens to be visible. | | Dynamic fields entered, none saved | The system is **Manual**, and OpenIAM saves no dynamic fields at all for a manual system — silently | Untick Manual, or accept that a manual system has no connector configuration. | | Connector rejects the search, base DN looks right | `BASE_DN` is where objects are created; the connector searched with `SEARCH_BASE_DN`, or read the filter as `LOOKUP_QUERY` and it was blank | Fill **Search Base DN for User** and **Search Filter for User** separately from Base DN. | | Group provisioning searches the wrong container | `GROUP_BASE_DN` on the wire comes from the group match row's **`SEARCH_BASE_DN`**, not its `BASE_DN` | Fill **Search Base DN for Group**. | | Password never reaches this system | A resource property `INCLUDE_IN_PASSWORD_SYNC = N`. The audit entry for the password change carries a warning naming the property, and the provisioning service log says `Sync not allowed for sys=` at debug level | Change or remove the row. Only the literal `N` excludes the system; any other value includes it. | | Account deleted in the target when you expected a disable | No `ON_DELETE` row; absent and blank both mean `DELETE` | Add `ON_DELETE = DISABLE`. `DELETE` and `DISABLE` are the only two values that behave the same wherever the property is read. | | Pre/post-processor never runs, no error | The attribute value is a path, not a registry ID, and OpenIAM silently falls back to the no-op default processor | Replace with the ID. [Attach a provisioning processor](/administration-guide/lifecycle/provisioning-processors.md). | | Nothing is ever provisioned to this system, no error | **Supports Date for Affiliations** is ticked and the `FUTURE_USER_PROV` batch task is disabled (its shipped state) | Untick it, or enable the task with a suitable `PARAM1` minute window. | | JDBC password or disable fails with a SQL error naming `TBL_NAME` | `PASSWORD_ATTRIBUTE_NAME` / `STATUS_ATTRIBUTE_NAME` still hold the shipped placeholders | Set them to `.` for your schema. | | Users unexpectedly associated with this system | `ASSIGN_TO_ALL = 'Y'`, which adds this system's resource to every user on every add and update | Untick it, then plan the cleanup — [Grant birthright access](/administration-guide/lifecycle/birthright-access.md). | | Downstream system never provisioned | The upstream connector reply was a failure, so the rest of the chain was marked `FAIL_PARENT` and abandoned | Fix the upstream failure and re-save the user. Look for `FAIL_PARENT` in `LOGIN.PROV_STATUS`. | | Cannot delete | `LINKED_TO_AUTHENTICATION_PROVIDER`, `LINKED_TO_USERS` (the message carries the login count) or `LINKED_TO_ACCESS_RIGHTS` | [Decommission a managed system](/administration-guide/lifecycle/decommission-a-managed-system.md). | ## Rollback For a **new test system**: untick **Active** first — that stops the heartbeat and any further provisioning — then remove schedules, policy maps and identities, then **Delete**. Deleting also unlinks (does not delete) any groups and roles bound to it, and deletes its `MNG_SYS_OBJECT_MATCH` rows and its resource's questionnaires. For an **edited production system**: restore the recorded previous values and previous `IS_ACTIVE`, then re-verify at the target, not at the save. If the credential was replaced or exposed, rotate — do not restore. Configuration is reversible; target operations already dispatched are not. ## Advanced behaviour Neither is needed to create a working managed system. ### Downstream managed system, honestly `DOWNSTREAM_SYSTEM_ID` names the system that must be provisioned **after** this one. It is not a soft hint: * On each save, OpenIAM links every entitled managed system to its `DOWNSTREAM_SYSTEM_ID`, producing ordered chains. Only the **first** system in each chain gets a connector request; the audit action for the chain is `PROVISIONING_IN_ORDER`, and the chain is held in the `provisionstream` search index keyed by the child audit-log ID. * Every connector reply is checked against the chain it belongs to. On success the current system is marked done and a request goes out for the next unfinished system. When the chain is exhausted it is discarded. * On **failure** every not-yet-provisioned identity in the chain is marked `FAIL_PARENT`, the chain is discarded, and nothing further is sent. **Already-completed downstream operations are not rolled back** — there is no compensating transaction, so a chain that fails halfway leaves the earlier systems changed and the later ones untouched. Design the order so the least reversible system is last, and read `LOGIN.PROV_STATUS` for `FAIL_PARENT` after a chain failure to see exactly where it stopped. So: the ordering guarantee is real and enforced at the connector reply, not at dispatch. The failure semantics are fail-forward — an upstream failure prevents downstream work but does not undo upstream work. Chains are built from single `DOWNSTREAM_SYSTEM_ID` pointers, so each system has at most one successor, and nothing validates against a cycle. Set it only where the target genuinely cannot accept the account before the upstream one exists (the classic case is a mailbox after a directory account), and test the upstream-failure path deliberately. ### Simulation requests: the real option list **Simulation Requests** is a multi-select over thirteen operations, and this is the whole list: `Add`, `Save`, `Update`, `Enable`, `Disable`, `Lock`, `Delete`, `Login`, `SetPassword`, `ResetPassword`, `SendSingleProvisionOperation`, `DirectDeleteConnectorRequest`, `SyncPasswordFromSrc`. They are stored in the `SIMULATION_ACTIONS` collection table, one `ATTR_VALUE` row per selected operation, and matched by exact operation name — so a row edited by hand to a name not in that list matches nothing and simulates nothing. Two of the thirteen do not behave as the list implies — see [what simulation does not protect against](/administration-guide/lifecycle/simulation-mode.md#what-simulation-does-not-protect-against). ## Related * [Managed system fields and the connector request](/administration-guide/reference/managed-system-fields.md) — every form field, the connector-specific fields, the attribute list on the wire, and worked LDAP, JDBC and SCIM settings. * [Connectors and managed systems](/administration-guide/lifecycle/connectors-and-managed-systems.md) — where the dynamic fields come from. * [Verify connectivity to the target](/administration-guide/lifecycle/verify-connection.md) — what to do after activation. * [Build a policy map](/administration-guide/lifecycle/policy-map.md) — the attribute rows this system will send. * [Attach a provisioning processor](/administration-guide/lifecycle/provisioning-processors.md) — the `PRE_PROCESS`, `POST_PROCESS` and `ON_DELETE` contracts in full. * [Simulation mode](/administration-guide/lifecycle/simulation-mode.md) — what capturing an operation does and does not protect against. *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/administration-guide/lifecycle/configure-managed-system.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.