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.
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).
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 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.
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.
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 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.
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:
The Connector Administrator or Super Administrator role in C1
An Active Directory service account with the appropriate permissions (see above)
Cloud-hosted
Self-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.
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.
Minimum OS disk space for the binary (~60 MB) plus room for logs and the local sync database
The connector runs as a Windows service or Linux daemon — a dedicated host is not required
Network:
Outbound TCP/443 to your C1 tenant
Outbound LDAP (TCP/UDP 389), LDAPS (TCP 636), and Kerberos (TCP/UDP 88) to each domain controller the connector talks to. Global Catalog adds TCP 3268 / 3269. For the full multi-domain port list, see Multi-domain and cross-forest sync.
The service account must have Modify access to %PROGRAMDATA%\ConductorOne so the connector can write to the log file. If the connector can’t write to this directory, the service will fail to start.Linux: there is no default config location — set BATON_CONFIG_PATH (or pass --config-file) to wherever you deploy config.yaml. A common pattern is /etc/baton-active-directory/config.yaml with the log redirected via systemd journal or --file.
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.
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.
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:
Double-click to open properties
Change the Startup type to Automatic
Navigate to the Log On tab and click This account
Click Browse, enter your service account name, and click Check Names
Enter the service account password and confirm it
Click Apply
Navigate back to the General tab and click Start
A minimal config.yaml looks like:
base-dn: DC=example,DC=comdomain: example.commode: winldapldaps: trueclient-id: <C1 client ID>client-secret: <C1 client secret># Include this line to enable provisioningprovisioning: true
If you make changes to the config file, a service restart is required for the changes to take effect.
All fields below can be set in the YAML config file. Unless noted, each field also maps to an equivalent CLI flag (--field-name) and environment variable (BATON_FIELD_NAME).Connection:
Field
Type
Default
Description
domain
string
(required)
Fully-qualified Windows domain. Example: baton.example.com
base-dn
string
(required)
Base DN for LDAP searches. Example: DC=baton,DC=example,DC=com
sitename
string
(any reachable DC)
AD site name. When set, scopes DC discovery to an available DC in that site. Example: US-DC-01
mode
string
winldap (Windows) / ldap (Linux)
Connection mode: ldap (Go library) or winldap (Windows wldap32.dll system calls)
ldaps
bool
false
Enable LDAPS (TLS). Required for account provisioning.
ldaps-port
int
636
LDAPS port. Use 3269 for Global Catalog over LDAPS.
ldaps-skip-verify
bool
true
Skip LDAPS certificate validation (go-ldap mode only; ignored in WinLDAP).
sync-scope
string
Standalone
Standalone or GlobalCatalog. GlobalCatalog is sync-only and omits some profile fields.
Authentication:
Field
Type
Default
Description
bind-type
string
external
external (Kerberos/GSSAPI, uses the service account) or simple (username/password)
bind-user
string
—
Full DN of the bind user (required for simple)
bind-password
string (secret)
—
Password for the bind user (required for simple). On Windows, can be stored as dpapi:… for DPAPI encryption.
Search scope:
Field
Type
Default
Description
user-search-dn
string
base-dn
DN to search for users
user-search-filter
string
(&(objectCategory=person)(objectClass=user))
LDAP filter for users
group-search-dn
string
base-dn
DN to search for groups
group-search-filter
string
(objectCategory=group)
LDAP filter for groups
skip-ous
list of DNs
—
OUs to exclude. Mutually exclusive with only-ous.
only-ous
list of DNs
—
OUs to include. Mutually exclusive with skip-ous.
custom-user-attributes
list of strings
—
Extra LDAP attributes to include in the user profile (for example, githubUserName)
gMSA:
Field
Type
Default
Description
enable-gmsa-sync
bool
false
Enable syncing of Group Managed Service Accounts
gmsa-search-dn
string
base-dn
DN to search for gMSAs. Example: CN=Managed Service Accounts,DC=example,DC=com
gmsa-search-filter
string
(objectClass=msDS-GroupManagedServiceAccount)
LDAP filter for gMSAs
Actions & provisioning:
Field
Type
Default
Description
provisioning
bool
false
Enable Grant/Revoke and account provisioning. Required for any write operation.
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.
Supported trust types
1-way outbound trust (primary trusts remote, or remote trusts primary)
2-way trust
Cross-forest trust
External (non-transitive) trust
Prerequisites
1. Active Directory trust. A trust relationship must exist between the domains. For Kerberos (bind-type: external), the connector’s domain must be trusted by the remote domain. For simple bind, any network connectivity is sufficient.Verify with:
2. DNS resolution. The connector machine must resolve the remote domain’s SRV records, DC hostnames, and A records. The recommended approach is a conditional forwarder on your primary DNS server:
3. Network connectivity. The connector must reach the remote domain’s DCs on the ports you use:
Port
Protocol
Purpose
389
TCP/UDP
LDAP (plaintext with signing)
636
TCP
LDAPS (TLS)
88
TCP/UDP
Kerberos KDC (external/Kerberos auth)
3268
TCP
Global Catalog (optional)
3269
TCP
Global Catalog over SSL (optional)
4. LDAPS certificate trust (if using LDAPS). The remote forest’s root CA certificate must be trusted on the connector machine:
Option A — Automatic cross-forest trust: With a 2-way trust and Enterprise CAs in both forests, the remote root CA is typically published to AD automatically.
Option B — Manual import: Export the remote CA and import it into the connector machine’s Trusted Root CAs (machine store):
Option C — Skip validation (go-ldap mode only, lab/testing): Set ldaps-skip-verify: true. This has no effect in WinLDAP mode, which always validates against the Windows certificate store.
Option D — Plain LDAP with signing: Omit ldaps: true for the additional domain and connect over TCP/389 with LDAP signing.
5. Kerberos configuration (for bind-type: external). On Windows domain-joined hosts, cross-realm Kerberos is typically automatic when a forest or external trust exists. The connector targets the remote DC’s hostname (for example, DC01.remote-forest.example.com) rather than the domain FQDN, because the SPN (ldap/DC01…) is registered under the DC’s machine account.On Linux, add the remote realm to /etc/krb5.conf:
6. Permissions.Authenticated Users has read access to most AD objects by default, which is usually sufficient. For gMSA provisioning in an additional domain, set read-only: false on the domain entry and grant the bind account write access to msDS-GroupMSAMembership.
Additional domain fields
Each entry under additional-domains supports the following fields:
Field
Type
Default
Description
domain
string
(required)
FQDN of the remote domain
base-dn
string
auto-discovered via rootDSE
Base DN for LDAP searches
bind-type
string
external
external (Kerberos) or simple
bind-user
string
—
Bind DN (required for simple)
bind-password
string
—
Bind password (required for simple)
ldaps
bool
inherits primary
Omit to inherit from the primary domain; set true or false to override
ldaps-port
int
636
LDAPS port
read-only
bool
see below
Prevent write operations (Grant/Revoke) to this domain
user-search-dn
string
base-dn
Override user search base
user-search-filter
string
primary filter
Override user search filter
group-search-dn
string
base-dn
Override group search base
group-search-filter
string
primary filter
Override group search filter
skip-ous
list
—
OUs to exclude
only-ous
list
—
OUs to include (mutually exclusive with skip-ous)
gmsa-search-dn
string
base-dn
Override gMSA search base
gmsa-search-filter
string
primary filter
Override gMSA search filter
read-only default: When omitted, read-only defaults to true unless bind-type is explicitly set (in which case it defaults to false). Providing domain-specific bind credentials signals that writes are intended. Set read-only explicitly to override.
How it works
Resource enumeration: the connector paginates across all configured domains — the primary completes first, then each additional domain. All resources land in a single unified sync.
Cross-domain DN lookups (group members, managers, Foreign Security Principals): the DN’s domain suffix is matched against your configured domains to route the lookup.
Cross-domain SID lookups (gMSA ACLs, primary group SIDs): the SID is resolved against each configured domain in order until a match is found.
NetBIOS names (needed for down-level logon display): each forest’s configurationNamingContext is queried for crossRef entries. On Windows, the primary domain also uses the native DsCrackNamesW API; additional domains always fall back to LDAP crossRef.
Diagnosing issues
Run the built-in test harness to check DC resolution, TLS handshake, certificate validation, and LDAP bind for every configured domain:
baton-active-directory.exe test-ldaps
Common failures:
LDAP error 81 (“Server Down”) on the remote domain — TLS handshake failure, almost always a missing CA trust. Import the remote root CA (Option B above) or use plain LDAP with signing.
LDAP result code 32 (“No Such Object”) during the grants phase — the connector hit a DN or SID on a remote domain that isn’t configured. Add the missing domain to additional-domains.
“baseDN auto-discovery failed” — can’t reach the remote rootDSE. Check DNS and network, or set base-dn explicitly.
“SASL bind failed” / “Cannot obtain Kerberos ticket” — cross-realm Kerberos isn’t working. Verify the trust, DNS SRV records, and that you’re targeting the DC hostname rather than the domain FQDN. As a fallback, switch that domain to bind-type: simple.
“netbios domain is empty” warnings — the NetBIOS cache couldn’t load crossRef entries. Confirm read access to the remote configurationNamingContext.
Performance
Each additional domain adds to the sync cycle. The connector completes one domain fully before moving on; LDAP pagination (1000 entries per page) is used throughout; total sync time scales linearly with the number of domains and objects.
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.
You can restrict which Organizational Units the connector syncs by using skip-ous or only-ous (mutually exclusive):
# Exclude specific OUsskip-ous: - "OU=Test,DC=example,DC=com" - "OU=Disabled,DC=example,DC=com"# Or include only specific OUsonly-ous: - "OU=Engineering,DC=example,DC=com" - "OU=Sales,DC=example,DC=com"
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:
Once synced, the specified attributes appear as profile fields on the user in C1 and can be configured as additional usernames for account correlation.
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.
To enable LDAPS, add the following to your config:
ldaps: trueldaps-port: 636 # default; use 3269 for Global Catalog over LDAPSldaps-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.
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:
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.
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.
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.