> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-docs-ad-account-provisioning-setup.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Set up an Active Directory connector
> C1 provides identity governance and just-in-time provisioning for Active Directory. Integrate your on-prem Active Directory domains with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access.
## Capabilities
| Resource | Sync | Provision |
| :------------------------------------- | :------------------------------------------------------------ | :------------------------------------------------------------ |
| Accounts | | |
| Groups | | |
| Group Managed Service Accounts (gMSAs) | | |
The Active Directory connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning). When a new account is created by C1, the account's password is sent to a [vault](/product/admin/vaults).
**Notes:**
* The connector syncs each user's primary group membership (for example, Domain Users) via the `primaryGroupID` attribute. AD does not include primary groups in `memberOf`, so the connector resolves these automatically.
* The connector supports syncing across multiple AD domains and forests in a single run via `additional-domains` configuration.
* gMSA sync is opt-in and requires the `enable-gmsa-sync` flag. gMSA provisioning modifies the `msDS-GroupMSAMembership` security descriptor ACL.
* The connector supports two connection modes: **LDAP** (default on Linux) and **WinLDAP** (default on Windows, uses `wldap32.dll` for Kerberos/GSSAPI).
* Account provisioning (create/delete) requires LDAPS (`ldaps: true`).
* When `sync-scope` is set to `GlobalCatalog`, provisioning is not supported and some profile fields may be unavailable.
### Connector actions
Connector actions are custom capabilities that extend C1 automations with app-specific operations. You can use connector actions in the [Perform connector action](/product/admin/automations-steps-reference#perform-connector-action) automation step.
**Global actions** (connector-level):
| Action name | Additional fields | Description |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `enable_user` | `resource_id` (resource ID, required) | Enable a disabled AD account (clears ACCOUNTDISABLE flag) |
| `disable_user` | `resource_id` (resource ID, required) | Disable an active AD account (sets ACCOUNTDISABLE flag) |
| `lock_account` | `resource_id` (resource ID, required) | Lock an AD account — alias for `disable_user`, sets the `ACCOUNTDISABLE` UAC flag. AD has no separate lock state. |
| `unlock_account` | `resource_id` (resource ID, required) | Unlock an AD account — alias for `enable_user`, clears the `ACCOUNTDISABLE` UAC flag. |
| `update_user_attrs` | `resource_type` (string, required), `resource_id` (string, required), `attrs` (map, required), `attrs_update_mask` (string list, required) | Update user attributes. Known names (for example, `first_name`) are mapped to AD attributes; unknown names are passed through as raw AD attribute names. Empty values clear the attribute. Uses `StringField` for `resource_id` (not `ResourceIdField`) because it is invoked by the SDK profile push pipeline. |
| `lookup_user` | At least one of: `upn` (string), `sam_account_name` (string), `employee_id` (string) | Look up a user by UPN, SAM Account Name, or Employee ID and return their DN, SAM Account Name, UPN, display name, employee ID, and objectGUID |
| `set_manager` | `resource_id` (resource ID, required), plus exactly one of: `manager_resource_id` (resource ID) or `clear_manager` (bool) | Set or clear the manager attribute on a user. The handler returns the resulting `manager_dn` as an output for observability; `manager_dn` is not an input. |
**Resource actions** (on user resources):
| Action name | Additional fields | Description |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `update_profile` | `user_id` (resource ID, required), plus optional string fields (see [Profile push attributes](#profile-push-attributes) below), and `custom_attributes` (map of raw AD attribute names to values) | Update a user's profile attributes. Empty values clear the attribute in AD. |
| `move_ou` | `user_id` (resource ID, required), `target_ou` (string, required) | Move a user to a different Organizational Unit. Automatically handles CN collisions by appending a numeric suffix. |
**Resource actions** (on group resources):
| Action name | Additional fields | Description |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| `create` | `name` (string, required), `organizationalUnit` (string, required), plus optional: `sAMAccountName`, `description`, `groupScope` (`global`/`domain_local`/`universal`), `groupType` (`security`/`distribution`), `managedByUser` (resource ID), `managedByGroup` (resource ID), `mailEnabled` (bool), `primaryEmailAddress`, `emailAliases` (string list), `hideFromGAL` (bool), `gidNumber` (int), `userMembers` (resource ID list), `groupMembers` (resource ID list) | Create a new AD group with optional initial members, mail settings, and POSIX attributes |
**Custom PowerShell actions:**
You can define additional actions backed by PowerShell scripts in the config file. See [Custom PowerShell Actions](#custom-powershell-actions) below.
### Resources
* [Official download center](https://dist.conductorone.com/ConductorOne/baton-active-directory): For stable binaries (Windows/Linux) and container images.
* [GitHub repository](https://github.com/ConductorOne/baton-active-directory): Access the source code, report issues, or contribute to the project.
## Gather Active Directory credentials
To configure the Active Directory connector, you need an Active Directory service account with appropriate permissions. The specific permissions depend on your intended use:
* **Sync only**: Read access to AD objects
* **Entitlement provisioning**: Delegated rights to modify group membership
* **Account provisioning**: Delegated rights to create, delete, and manage user accounts, plus LDAPS enabled
* **gMSA provisioning**: Permission to modify `msDS-GroupMSAMembership` on gMSA objects
The service account also needs **Log on as a service** permission and **Modify** access to `C:\ProgramData\ConductorOne`.
### Create a service account
Create a dedicated AD service account for the connector (for example, `svc-baton`). A standard domain user account with read access is sufficient for sync-only operation.
Grant the service account **Log on as a service** permission via local or domain Group Policy, depending on your environment.
### Entitlement provisioning permissions
For entitlement provisioning support, the service account needs delegated rights to manage group membership.
Open Active Directory Users and Computers (ADUC) or run `dsa.msc` from the command line.
Right-click on your forest root (or a specific OU if you only want to provision into groups in that OU) and select **Delegate Control**.
Add the service account running the `baton-active-directory` service.
From the tasks to delegate, check the box for **Modify the membership of a group**.
Click **Next**, then **Finish**.
This delegation grants the service account the ability to provision and deprovision access from Active Directory groups, but it excludes special built-in groups like Administrators, Domain Admins, Enterprise Admins, and Schema Admins.
To manage those protected groups, you must grant explicit **Write Members** permission on each group and update AdminSDHolder to prevent the permission from being removed:
For each protected group: right-click the group, click the **Security** tab, click **Advanced**, click **Add**, select the service account as the principal, and grant **Write Members** permission.
Run the following PowerShell script **from a domain controller with domain admin credentials** to ensure AdminSDHolder does not remove the permission after 60 minutes:
```powershell theme={null}
$domain = "REPLACE_WITH_YOUR_DOMAIN"
$samAccountName = "REPLACE_WITH_YOUR_SERVICE_ACCOUNT"
$adminSDHolderPath = "CN=AdminSDHolder,CN=System," + (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$adminSDHolderPath"
$identity = New-Object System.Security.Principal.NTAccount("$domain\$samAccountName")
$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
$identity,
[System.DirectoryServices.ActiveDirectoryRights]::WriteProperty,
[System.Security.AccessControl.AccessControlType]::Allow,
[Guid]"bf967a9c-0de6-11d0-a285-00aa003049e2", # GUID for 'member' attribute
[System.DirectoryServices.ActiveDirectorySecurityInheritance]::None
)
$acl.AddAccessRule($rule)
Set-Acl -Path "AD:\$adminSDHolderPath" -AclObject $acl
```
### Account provisioning permissions
User account provisioning requires `ldaps: true` in your config.
Open ADUC or run `dsa.msc` from the command line.
Right-click on your forest root (or a specific OU) and select **Delegate Control**.
Add the service account running the `baton-active-directory` service.
From the tasks to delegate, check the box for **Create, delete, and manage user accounts**.
Click **Next**, then **Finish**.
**Done.** Next, move on to the connector configuration instructions.
## Configure the Active Directory connector
To complete this task, you'll need:
* The **Connector Administrator** or **Super Administrator** role in C1
* An Active Directory service account with the appropriate permissions (see above)
The Active Directory connector is self-hosted only. It runs on a Windows or Linux server in your environment with direct network access to your domain controllers.
To get started, follow the **Self-hosted** tab instructions.
**Follow these instructions to use the Active Directory connector, hosted and run in your own environment.**
Once installed and configured, Baton runs as a Windows service (or Linux daemon). The service maintains contact with C1, syncs and uploads data at regular intervals, and passes that data to the C1 UI for access reviews and access requests.
### Requirements
* A Windows or Linux server to host `baton-active-directory` (minimum: 2-4 vCPU, 4-8 GB RAM)
* Outbound network connectivity to port `443` to your C1 tenant
* An Active Directory service account with appropriate permissions (see above)
* The **Connector Administrator** or **Super Administrator** role in C1
### Step 1: Set up a new Active Directory connector in C1
In C1, navigate to **Integrations** > **Connectors** and click **Add connector**.
Search for **Baton** and click **Add**.
Choose how to set up the new Active Directory connector:
* Add the connector to a currently unmanaged app (select from the list of apps that were discovered in your identity, SSO, or federation provider that aren't yet managed with C1)
* Add the connector to a managed app (select from the list of existing managed apps)
* Create a new managed app
Set the owner for this connector. You can manage the connector yourself, or choose someone else from the list of C1 users. Setting multiple owners is allowed.
If you choose someone else, C1 will notify the new connector owner by email that their help is needed to complete the setup process.
Click **Next**.
In the **Settings** area of the page, click **Edit**.
Click **Rotate** to generate a new Client ID and Secret.
Carefully copy and save these credentials. You will need them when configuring the connector.
Next to the **Not Connected** label, click on the word **Baton** to navigate to the application page. Click the pencil icon at the top of the page and rename the application to **Active Directory**. This updates the application name, connector name, and icon.
### Step 2: Install and configure `baton-active-directory`
#### Option 1: Windows installer (recommended)
Download the latest `baton-ad-setup-*.exe` installer from C1.
Run the installer on the host designated to run the connector. The installer prompts for your AD domain, C1 credentials, and connection settings.
The installer writes a YAML config file (with optional DPAPI encryption for secrets), registers a Windows service with auto-restart recovery, and creates Start Menu shortcuts for the GUI Configuration Editor and uninstall.
#### Option 2: Manual setup
On the host designated to run the connector, create a folder: `C:\Program Files\ConductorOne`.
Copy `baton-active-directory.exe` to the `ConductorOne` folder.
Install and set up the connector by running (from an elevated command prompt):
```console theme={null}
baton-active-directory.exe setup
```
The setup process checks for a config file, opens the GUI config editor if none exists, offers to copy the binary to Program Files, optionally configures a service account, and registers the Windows service with auto-start and recovery.
For non-interactive setup, use: `baton-active-directory.exe setup -y`
Grant the service account **Modify** folder permissions to `C:\ProgramData\ConductorOne` so it can write to the log file.
Failing to grant this permission results in a service start error.
Launch the Services console, locate the service named **baton-active-directory**, and configure it:
1. Double-click to open properties
2. Change the **Startup type** to **Automatic**
3. Navigate to the **Log On** tab and click **This account**
4. Click **Browse**, enter your service account name, and click **Check Names**
5. Enter the service account password and confirm it
6. Click **Apply**
7. Navigate back to the **General** tab and click **Start**
The config file is written to `C:\ProgramData\ConductorOne\baton-active-directory\config.yaml`:
```yaml theme={null}
base-dn: DC=example,DC=com
domain: example.com
mode: winldap
ldaps: true
client-id:
client-secret:
# Include this line to enable provisioning
provisioning: true
```
If you make changes to the config file, a service restart is required for the changes to take effect.
The log file is written to `C:\ProgramData\ConductorOne\baton-active-directory\baton.log`.
#### Connector modes
The connector supports two connection modes:
* **LDAP mode** (default on Linux): Uses a Go LDAP library. Supports both External Bind (Kerberos/GSSAPI) and Simple Bind authentication.
* **WinLDAP mode** (default on Windows): Uses Windows `wldap32.dll` system calls with GSSAPI authentication. Simple Bind is not supported in this mode.
If LDAP mode does not connect (usually because your AD server requires more secure authentication methods), try `mode: winldap` in your config.
#### Multi-domain / cross-forest sync
The connector can sync across multiple AD domains and forests in a single run. Add additional trusted domains to your config using native YAML syntax:
```yaml expandable theme={null}
additional-domains:
- domain: remote-forest.example.com
base-dn: DC=remote-forest,DC=example,DC=com
- domain: child.example.com
base-dn: DC=child,DC=example,DC=com
bind-type: simple
bind-user: "CN=svc-baton,OU=ServiceAccounts,DC=child,DC=example,DC=com"
bind-password: "secret"
ldaps: true
```
Each additional domain supports independent connection settings (bind type, credentials, LDAPS, search filters, OU restrictions, read-only mode). Cross-domain group memberships are resolved automatically via Foreign Security Principals.
The `additional-domains` field is YAML-only -- it cannot be set via CLI flags or environment variables.
For detailed setup instructions including trust requirements, DNS, LDAPS certificates, and Kerberos configuration, see the [multi-domain setup guide](https://github.com/ConductorOne/baton-active-directory/blob/main/docs/multi-domain-setup.md).
#### gMSA sync
To sync Group Managed Service Accounts, enable the flag in your config:
```yaml theme={null}
enable-gmsa-sync: true
# Optional: restrict gMSA search scope
gmsa-search-dn: "OU=gMSA,DC=example,DC=com"
```
Each gMSA exposes a `password_retrieval` entitlement representing which principals are authorized to retrieve the managed password. Grant and Revoke operations modify the gMSA's `msDS-GroupMSAMembership` security descriptor ACL.
#### OU filtering
You can restrict which Organizational Units the connector syncs by using `skip-ous` or `only-ous` (mutually exclusive):
```yaml theme={null}
# Exclude specific OUs
skip-ous:
- "OU=Test,DC=example,DC=com"
- "OU=Disabled,DC=example,DC=com"
# Or include only specific OUs
only-ous:
- "OU=Engineering,DC=example,DC=com"
- "OU=Sales,DC=example,DC=com"
```
#### Custom user attributes
By default, the connector syncs a standard set of AD user attributes. Use `custom-user-attributes` to include additional AD attributes in the user profile for account correlation:
```yaml theme={null}
custom-user-attributes:
- githubUserName
- extensionAttribute1
- whenCreated
- pwdLastSet
```
Once synced, the specified attributes appear as profile fields on the user in C1 and can be configured as additional usernames for account correlation.
#### Custom PowerShell actions
You can define additional connector actions backed by PowerShell scripts:
```yaml expandable theme={null}
powershell-actions:
reset-password:
path: "C:\\Scripts\\Reset-Password.ps1"
args:
resource_id:
type: string
is_required: true
new_password:
type: string
is_required: true
```
Each custom action appears alongside the built-in connector actions and can be used in C1 automations. Argument types can be `string`, `int`, or `bool`.
#### Profile push attributes
The `update_profile` resource action declares the following 23 named string fields in its schema. The platform's schema-driven UI shows a dedicated input for each. Attributes outside this list (including `extensionAttribute1` through `extensionAttribute15`) must be set via the `custom_attributes` map field on `update_profile`, or via the `update_user_attrs` global action.
| Field name | AD attribute | Category |
| ------------------------------- | ---------------------------- | ------------ |
| `first_name` | `givenName` | Identity |
| `middle_name` | `middleName` | Identity |
| `last_name` | `sn` | Identity |
| `display_name` | `displayName` | Identity |
| `sam_account_name` | `sAMAccountName` | Identity |
| `user_principal_name` | `userPrincipalName` | Identity |
| `email` | `mail` | Contact |
| `phone_number` | `telephoneNumber` | Contact |
| `mobile_phone` | `mobile` | Contact |
| `job_title` | `title` | Organization |
| `department` | `department` | Organization |
| `division` | `division` | Organization |
| `company` | `company` | Organization |
| `description` | `description` | Organization |
| `employee_id` | `employeeID` | Organization |
| `employee_number` | `employeeNumber` | Organization |
| `employment_type` | `employeeType` | Organization |
| `city` | `l` | Address |
| `state` | `st` | Address |
| `street_address` | `streetAddress` | Address |
| `postal_code` | `postalCode` | Address |
| `country` | `c` | Address |
| `physical_delivery_office_name` | `physicalDeliveryOfficeName` | Address |
AD enforces schema constraints on attribute values. For example, the `c` (country) attribute has a maximum length of 3 characters and expects ISO 3166-1 alpha-2 codes (for example, `US`, not `United States`). Constraint violations are logged with each attribute name and value length to aid debugging.
The `update_user_attrs` global action recognizes the 23 named fields above plus 15 additional aliases (`extension_attribute_1` through `extension_attribute_15` mapping to `extensionAttribute1`–`extensionAttribute15`). Any attribute name not in the combined list is passed through as a raw AD attribute name, allowing direct access to any writable AD attribute.
#### LDAPS configuration
To enable LDAPS, add the following to your config:
```yaml theme={null}
ldaps: true
ldaps-port: 636 # default; use 3269 for Global Catalog over LDAPS
ldaps-skip-verify: true # default; set to false to enforce certificate validation (go-ldap mode only)
```
The `ldaps-skip-verify` flag only affects go-ldap mode. WinLDAP mode uses the Windows certificate store for certificate validation and is not affected by this setting.
To diagnose LDAPS connectivity issues, use the built-in diagnostic command:
```console theme={null}
baton-active-directory.exe test-ldaps
```
This tests DC resolution, TLS handshake, certificate validation, and LDAP bind for all configured domains with detailed error reporting.
#### DPAPI secrets encryption
On Windows, the connector can encrypt sensitive config values (`client-id`, `client-secret`, and `bind-password`) using Windows DPAPI machine-scoped encryption. Encrypted values are prefixed `dpapi:` in the YAML config and are decrypted transparently at startup. The installer encrypts by default; you can also encrypt an existing config manually:
```console theme={null}
baton-active-directory.exe encrypt-config
```
#### GUI Configuration Editor
The connector includes a native Windows GUI for managing configuration without editing YAML files manually:
```console theme={null}
baton-active-directory.exe config-editor
```
If installed via the Windows installer, a **Configuration Editor** shortcut is available in the Start Menu.
#### Authentication
The connector supports two authentication methods, configured via `bind-type`:
* **`external`** (default): Uses Kerberos/GSSAPI. The connector authenticates as the service account running the Windows service. No `bind-user` or `bind-password` needed.
* **`simple`**: Uses username/password bind. Requires `bind-user` (the full DN) and `bind-password`.
```yaml theme={null}
bind-type: simple
bind-user: "CN=svc-baton,OU=ServiceAccounts,DC=example,DC=com"
bind-password: "secret"
```
Run `baton-active-directory --help` to see the full list of configuration flags and environment variables.
### Step 3: Manage the Windows service
Use the following commands to manage the service (all require administrator privileges):
* To start the service: `baton-active-directory.exe start`
* To stop the service: `baton-active-directory.exe stop`
* To check the status: `baton-active-directory.exe status`
* To remove the service: `baton-active-directory.exe remove` (config and binary are preserved)
The connector syncs current data, uploads it to C1, and prints a **Task complete!** message when finished.
Check that the connector data uploaded correctly. In C1, click **Apps**. On the **Managed apps** tab, locate and click the name of the application you added the Active Directory connector to. Active Directory data should be found on the **Entitlements** and **Accounts** tabs.
**Done.** Your Active Directory connector is now pulling access data into C1.
### What's next?
Once your Active Directory connector is synced, you can use C1 to run user access reviews on AD group memberships, enable just-in-time access requests for AD groups and gMSAs, and automate provisioning workflows using connector actions.
## Set up account provisioning
The Active Directory connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning). When C1 creates a new AD user account, the generated password is automatically sent to a [vault](/product/admin/vaults).
Before you begin, confirm:
* The connector config has `ldaps: true` and `provisioning: true`
* A vault is configured in C1 to receive the generated password
* The service account has delegated rights to create, delete, and manage user accounts (see [Account provisioning permissions](#account-provisioning-permissions) above)
### Configure provisioning mappings
In C1, navigate to **Apps** > **Managed apps** and click the name of your Active Directory application.
Under **Accounts management**, click **Edit** next to **Provisioning**.
From the **Connector** dropdown, select your Active Directory connector.
The mapping fields defined by the connector's schema appear below the dropdown.
Enter a CEL expression for each field. See [Provisioning field reference](#provisioning-field-reference) below for guidance.
Click **Test** next to any field to validate the expression against an existing C1 user.
Under **Password storage**, select the vault where generated passwords should be stored.
Click **Save**.
### Provisioning field reference
The fields below are defined by the AD connector's account creation schema. CEL expressions reference profile attributes accumulated from connected directory and HR apps using the pattern `subject.attributes.`. To see which attributes are available for a given user, navigate to that user's profile page in C1.
The DN of the new account is assembled by the connector as: `CN=,,`
#### Required fields
| UI field | Description | Example expression |
| ----------------------- | ------------------------------------------------------------------------------------------------------ | --------------------------------- |
| **Common Name** | The `CN` component of the user's Distinguished Name. Typically the user's full name or display name. | `subject.attributes.display_name` |
| **Organizational Unit** | The OU path where the account will be created, without DC components. The OU must already exist in AD. | `"OU=Users,OU=Corp"` |
| **Domain** | The domain as DC components. Must match an existing domain in your AD forest. | `"DC=example,DC=com"` |
| **Object Class(es)** | One or more LDAP object classes for the new user object. | `["user"]` |
**Organizational Unit** and **Domain** are almost always static strings — they don't vary per user. Enter them as quoted literals unless your organization places users in different OUs based on a profile attribute such as department.
#### Optional fields
| UI field | Description | Example expression |
| ------------------------- | -------------------------------------------------------------------------------------------------- | ---------------------------------------- |
| **Sam Account Name** | The pre-Windows 2000 login name, used for `DOMAIN\username` authentication. Maximum 20 characters. | `subject.attributes.sam_account_name` |
| **User Principal Name** | The UPN login name in `user@domain.com` format, used for modern authentication. | `subject.attributes.user_principal_name` |
| **Enabled** | Whether to enable the account immediately at creation. Defaults to `false`. | `false` |
| **Additional Attributes** | A map of any other LDAP attributes to set at creation time. | See below. |
#### Additional attributes
The **Additional Attributes** field accepts a map of raw LDAP attribute names to CEL expressions. Use this to set user attributes beyond what the named fields cover. Common examples:
| LDAP attribute | Description | Example |
| -------------- | ------------------------- | --------------------------------- |
| `givenName` | First name | `subject.attributes.first_name` |
| `sn` | Last name (surname) | `subject.attributes.last_name` |
| `displayName` | Display name | `subject.attributes.display_name` |
| `mail` | Email address | `subject.attributes.email` |
| `department` | Department | `subject.attributes.department` |
| `title` | Job title | `subject.attributes.job_title` |
| `company` | Company name | `subject.attributes.company` |
| `manager` | Manager (must be full DN) | *(see note below)* |
The `manager` attribute must be the full Distinguished Name of the manager's AD account — for example, `CN=Jane Doe,OU=Users,DC=example,DC=com`. If your source directory exposes the manager's DN directly, you can map it here. Otherwise, omit it at creation time and set it later using the `set_manager` [connector action](#connector-actions).
### Tips and gotchas
* **`sAMAccountName` has a 20-character limit** and cannot contain these characters: `/ \ [ ] : ; | = , + * ? < > @`. If your naming convention could produce values longer than 20 characters, truncate or use an alternative expression.
* **`userPrincipalName` must be unique** across the entire AD forest. A duplicate UPN causes provisioning to fail with an LDAP constraint violation error.
* **Accounts are created disabled by default.** Setting `Enabled` to `false` is intentional — C1 sets the account password in a separate LDAP operation after creation. If you set `Enabled` to `true`, the account will be enabled at creation but will still have a system-generated password sent to your vault.
* **The target OU must already exist.** C1 will not create missing OUs. If the OU specified in **Organizational Unit** doesn't exist when provisioning runs, the request will fail.
* **`objectClass` order matters in LDAP.** For standard AD users, `["user"]` is sufficient. If your schema requires additional classes, list them in structural hierarchy order (for example, `["top", "person", "organizationalPerson", "user"]`).
* **Global Catalog scope disables provisioning.** If the connector's `sync-scope` is set to `GlobalCatalog`, account provisioning is not supported. Use the default scope instead.