> 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/getting-started-guide/lifecycle/connect-to-ad.md). # Connect OpenIAM to Active Directory Create the managed system that connects OpenIAM to your Active Directory test organizational unit. **Goal:** a managed system pointing at your test AD, scoped to the POC OU, with `ON_DELETE = DISABLE` set **before anything can write**.\ **Time:** 20–30 minutes.\ **Prerequisites:** connector service running ([Install the AD connector](/getting-started-guide/lifecycle/install-ad-connector.md)); service account and OU DNs from your worksheet. {% stepper %} {% step %} **Open the managed system** OpenIAM ships a demo managed system wired to the AD PowerShell connector: **Provisioning → Managed System → "AD Win02 \[Remote Connector]"**. Edit it (or create a new managed system choosing connector *AD Powershell CONNECTOR*) and set: | Field | Value | | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | `AD POC` (or keep the existing name) | | Connector | AD Powershell CONNECTOR | | Active | Yes | | Manual | **No** — "manual" managed systems have no connector and generate human tasks instead of operations; everything on this page assumes an automatic (connector-driven) managed system, and the `ON_DELETE` behavior below is only honored for automatic ones | | Login ID | `yourdomain\svc-openiam` — **include the domain**, single backslash | | Password | the service account password | | Object primary key for user | `sAMAccountName` | | Base DN for User | `OU=Provisioned,OU=OpenIAM-POC,DC=yourdomain,DC=local` (where provisioned accounts will be created) | | Search Base DN for User | `OU=OpenIAM-POC,DC=yourdomain,DC=local` (where syncs look — see the scope note below) | | Base DN / Search Base DN for Group | `OU=Groups,OU=OpenIAM-POC,…` | | Search scope | Subtree | | PermittedDN | `OU=OpenIAM-POC,DC=yourdomain,DC=local` | **Why `PermittedDN` matters:** it's a connector-side guard, independent of anything OpenIAM sends. Create operations outside this DN (or its sub-OUs) are skipped and modify operations on objects outside it are refused — a second fence around your POC OU. **Why the Search Base DN matters for scope:** when a sync query uses `-Filter` without an explicit `-SearchBase`, the connector fills in this managed system's SearchBaseDN. Setting it correctly here is your primary import scope; the sync pages add an explicit `-SearchBase` anyway for clarity. {% endstep %} {% step %} **Set ON\_DELETE = DISABLE (do this now)** Still on the managed system's configuration page, find the **Attribute** section — it lets you attach out-of-the-box attributes to the managed system's resource, and its picker lists the supported names (`ON_DELETE`, `PRE_PROCESS`, `POST_PROCESS`, …). Add: | Attribute | Value | | ----------- | --------- | | `ON_DELETE` | `DISABLE` | Save, then re-open the page and confirm the attribute persisted — this one line is the safety contract for [Deprovision by disabling](/getting-started-guide/lifecycle/deprovision-disable.md). What this does: when a user is deleted in OpenIAM, the provisioning engine looks up `ON_DELETE` on each target's resource. Unset means **DELETE** — the AD account is deleted. `DISABLE` converts the delete into a disable operation, which is what this POC demonstrates and what most organizations run in production (`UPDATE` is the third option, for attribute-only handling). Setting it now, before any sync or provisioning has run, means there is no window in which a stray delete could reach AD. {% endstep %} {% step %} **Test the connection** Use the managed system's **Test connection**. Green means the round trip worked: OpenIAM → RabbitMQ → connector → domain controller with your service account, and back. On the **Managed System Dashboard**, the **Running connector status** column then shows a connector instance and the time it last replied. An empty or red status means the connector never answered — check the queue name against [Install the AD connector](/getting-started-guide/lifecycle/install-ad-connector.md) before touching anything else. {% endstep %} {% endstepper %} ## If it failed | Symptom | Likely cause | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Test hangs then fails | Queue name mismatch ([Install the AD connector](/getting-started-guide/lifecycle/install-ad-connector.md), step 1) — the request never reached the connector | | Immediate authentication failure | Login ID missing the `DOMAIN\` prefix, or wrong password | | Connector log shows AD errors | Service account lacks rights on the OU, or the DC is unreachable from the Windows host | Connector-side detail is in the logs in `C:\Connectors\\` on the Windows host. ## You know this worked when… {% hint style="success" %} Test connection is green, and the managed system shows `ON_DELETE = DISABLE` in its attribute configuration. Capture a screenshot of both — they're POC evidence. {% endhint %} Next: [Import AD groups](/getting-started-guide/lifecycle/import-groups.md). --- # 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/getting-started-guide/lifecycle/connect-to-ad.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.