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. When a new account is created by C1, the account’s password is sent to a vault.

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 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 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 below.

Resources

• Official download center: For stable binaries (Windows/Linux) and container images.

• GitHub repository: 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

1. 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.

2. 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.

1. Open Active Directory Users and Computers (ADUC) or run dsa.msc from the command line.

2. 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.

3. Add the service account running the baton-active-directory service.

4. From the tasks to delegate, check the box for Modify the membership of a group.

5. 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:

1. 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.

2. Run the following PowerShell script from a domain controller with domain admin credentials to ensure AdminSDHolder does not remove the permission after 60 minutes:

   $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.

1. Open ADUC or run dsa.msc from the command line.

2. Right-click on your forest root (or a specific OU) and select Delegate Control.

3. Add the service account running the baton-active-directory service.

4. From the tasks to delegate, check the box for Create, delete, and manage user accounts.

5. 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)

Cloud-hosted

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.

Self-hosted

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

1. In C1, navigate to Integrations > Connectors and click Add connector.

2. Search for Baton and click Add.

3. 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
4. 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.

5. Click Next.

6. In the Settings area of the page, click Edit.

7. Click Rotate to generate a new Client ID and Secret.

   Carefully copy and save these credentials. You will need them when configuring the connector.

8. 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)

1. Download the latest baton-ad-setup-*.exe installer from C1.

2. Run the installer on the host designated to run the connector. The installer prompts for your AD domain, C1 credentials, and connection settings.

3. 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

1. On the host designated to run the connector, create a folder: C:\Program Files\ConductorOne.

2. Copy baton-active-directory.exe to the ConductorOne folder.

3. Install and set up the connector by running (from an elevated command prompt):

   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

4. 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.

5. 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:

base-dn: DC=example,DC=com
domain: example.com
mode: winldap
ldaps: true
client-id: <C1 client ID>
client-secret: <C1 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:

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.

gMSA sync

To sync Group Managed Service Accounts, enable the flag in your config:

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):

# 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:

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:

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:

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:

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:

baton-active-directory.exe encrypt-config

GUI Configuration Editor

The connector includes a native Windows GUI for managing configuration without editing YAML files manually:

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.

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

1. 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)
2. The connector syncs current data, uploads it to C1, and prints a Task complete! message when finished.

3. 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. When C1 creates a new AD user account, the generated password is automatically sent to a vault.

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 above)

Configure provisioning mappings

1. In C1, navigate to Apps > Managed apps and click the name of your Active Directory application.

2. Under Accounts management, click Edit next to Provisioning.

3. From the Connector dropdown, select your Active Directory connector.

   The mapping fields defined by the connector’s schema appear below the dropdown.

4. Enter a CEL expression for each field. See Provisioning field reference below for guidance.

   Click Test next to any field to validate the expression against an existing C1 user.

5. Under Password storage, select the vault where generated passwords should be stored.

6. 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.<attribute_name>. 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=<commonName>,<organizationalUnit>,<domain>

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 [e-mail] 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.

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.