> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-jorge-mcp-resources-documentation.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Set up an LDAP connector
> C1 provides identity governance and just-in-time provisioning for LDAP. Integrate your LDAP server 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 | | |
| Roles (`organizationalRole` in LDAP) | | |
| Groups (`groupOfUniqueNames` in LDAP) | | |
The LDAP connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning).
### POSIX account provisioning
The LDAP connector supports provisioning `posixAccount` entries with automatic UID number assignment. When creating a new POSIX account, the connector can look up the highest `uidNumber` currently in use across all existing `posixAccount` entries in your directory and automatically assign the next available value.
To use this feature, configure the following account provisioning mappings:
| Mapping field | Destination value | Description | Example CEL expression |
| :-------------------------------------- | :------------------------ | :----------------------------------------------- | :------------------------------------------------------------------------------------ |
| **RDN Key** | `rdnKey` | The RDN attribute for the new entry | `"uid"` |
| **RDN Value** | `rdnValue` | The value for the RDN attribute | `subject.profile.login` |
| **Path** | `path` | The DN path where the account will be created | `"ou=users,o=Example Org"` |
| **Suffix** | `suffix` | The top-level entry DN (naming context) | `"dc=example,dc=com"` |
| **Object Class(es)** | `objectClass` | Must include `posixAccount` | `["top", "person", "organizationalPerson", "posixAccount"]` |
| **Calculate the next valid UID Number** | `calculatePosixUIDNumber` | Set to `true` to enable automatic UID assignment | `true` |
| **Additional Attributes** | `additionalAttributes` | Other required POSIX attributes | `{"cn": "Jane Doe", "sn": "Doe", "homeDirectory": "/home/jdoe", "gidNumber": "5000"}` |
Automatic UID number calculation assigns `uidNumber` only. You must provide `gidNumber` manually in the **Additional Attributes** mapping. If you set **Calculate the next valid UID Number** to `true`, any `uidNumber` value provided in **Additional Attributes** is ignored.
### 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 |
| ----------- | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `create_ou` | `name` (string, required), `parent_dn` (string), `description` (string) | Create an LDAP organizational unit (`organizationalUnit`) under a parent container. `parent_dn` defaults to the configured base DN; a parent outside the base DN is rejected. Idempotent — creating an OU that already exists succeeds. |
To use `create_ou`, the connector's bind account must have permission to add child entries under the target parent DN (by default, the configured base DN). For OpenLDAP and similar servers, this is write/add access on the parent container; for Active Directory, delegate the **Create Organizational Unit objects** right on the parent OU.
**Resource-scoped actions (user):**
| Action name | Additional fields | Description |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `update_profile` | `user_id` (resource ID, required), `first_name` (string), `last_name` (string), `display_name` (string), `email` (string), `custom_attributes` (string map) | Set core profile fields (first name, last name, display name, email) and/or arbitrary custom LDAP attributes on an existing user. This action is scoped to the `user` resource type, which is what makes it discoverable and usable from C1's attribute-push-rule feature. It also backs C1's [push profile](/product/admin/account-provisioning) flow for LDAP users. |
The `update_profile` action returns `success` (bool), `updated_user` (the user resource after the update, best-effort re-fetched; absent if the read-back failed, though the write itself still succeeded), `applied` (the number of attributes changed), and `skipped` (named fields or `custom_attributes` entries that were not written).
`update_profile` is intended for generic LDAP directories (Active Directory and FreeIPA have their own connectors). It applies the following rules:
* **Named fields:** `first_name` → `givenName`, `last_name` → `sn`, `display_name` → `displayName`, `email` → `mail`. A named field is applied only when present and non-empty; a present-but-empty named field cannot clear the attribute and is instead reported in `skipped`.
* **`inetOrgPerson` requirement:** only `last_name` (`sn`) is universal — it's a MUST attribute of the base `person` object class. `first_name` (`givenName`), `display_name` (`displayName`), and `email` (`mail`) are only defined by RFC 2798's `inetOrgPerson` object class, so writing one of them to an entry that doesn't carry `inetOrgPerson` fails loudly with LDAP result code 65 ("Object Class Violation") — an atomic, clearly-signaled failure with no partial write, not a silent no-op.
* **Custom attributes:** `custom_attributes` maps arbitrary raw LDAP attribute names to values; an empty value clears the attribute (unlike the named fields above, where empty just means "not supplied"). Keys are used **verbatim** as attribute names — the named-field mapping above applies only to the named arguments, never to `custom_attributes`. `{"user_id": "x"}` therefore writes an attribute literally named `user_id` (failing with LDAP result code 17, "Undefined Attribute Type", if the directory has no such attribute); it does not write `uid`. The same goes for baton profile field names such as `login` and `path`: they are attempted as literal attribute names rather than skipped.
* **Collisions:** a `custom_attributes` key is dropped (never merged with, or overwriting, a named field's slot) and reported once in `skipped` when it case-insensitively matches either one of the four named field names, or the LDAP attribute a supplied named field is writing (`givenName`, `sn`, `displayName`, `mail`). The latter only applies when that named field was actually supplied and non-empty; otherwise `{"givenName": "Jane"}` is an ordinary raw write.
* **Not modifiable:** password attributes (`userPassword`, or any name containing `password` — use credential rotation instead) and `objectClass` are rejected; the user's RDN attribute (for example `cn` when the DN is `cn=jdoe,...`) is skipped, since renaming requires a different operation.
* **Multi-valued attributes:** setting (not clearing) a value on an attribute that currently holds more than one value returns an error instead of silently discarding the extra values; clearing (an empty value) still removes all values.
* **Scope:** only entries within the configured user search scope (`user-search-dn`, falling back to `base-dn`) can be modified; out-of-scope or non-user DNs are rejected.
The connector's bind account must have permission to modify the target entry.
## Gather LDAP credentials
Configuring the connector requires you to pass in credentials for LDAP. Gather these credentials before you move on.
Here's the set of credentials you'll need when setting up the connector:
* The username and password of an LDAP account
* URL of the LDAP server, which can use either `ldap:` or `ldaps:` schemes, and optionally includes a port number
**Done.** Next, move on to the connector configuration instructions.
## Configure the LDAP connector
To complete this task, you'll need:
* The **Connector Administrator** or **Super Administrator** role in C1
* Access to the set of LDAP credentials generated by following the instructions above
**Follow these instructions to use a built-in, no-code connector hosted by C1.**
*Cloud-hosted connector not currently available.*
**Follow these instructions to use the LDAP connector, hosted and run in your own environment.**
When running in service mode on Kubernetes, a self-hosted connector maintains an ongoing connection with C1, automatically syncing and uploading data at regular intervals. This data is immediately available in the C1 UI for access reviews and access requests.
### Resources
* [Official download center](https://dist.conductorone.com/ConductorOne/baton-ldap): For stable binaries (Windows/Linux/macOS) and container images.
* [GitHub repository](https://github.com/conductorone/baton-ldap): Access the source code, report issues, or contribute to the project.
### Step 1: Set up a new LDAP connector
In C1, navigate to **Integrations** > **Connectors** > **Add connector**.
Search for **Baton** and click **Add**.
Choose how to set up the new LDAP 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. We'll use them in Step 2.
### Step 2: Create Kubernetes configuration files
Create two Kubernetes manifest files for your LDAP connector deployment:
#### Secrets configuration
```yaml expandable theme={null}
# baton-ldap-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
name: baton-ldap-secrets
type: Opaque
stringData:
# C1 credentials
BATON_CLIENT_ID:
BATON_CLIENT_SECRET:
# LDAP credentials
BATON_BIND_DN:
BATON_PASSWORD:
BATON_URL:
# Optional: include if you want C1 to provision access using this connector
BATON_PROVISIONING: true
```
See the connector's README or run `--help` to see all available configuration flags and environment variables.
#### Deployment configuration
```yaml expandable theme={null}
# baton-ldap.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: baton-ldap
labels:
app: baton-ldap
spec:
selector:
matchLabels:
app: baton-ldap
template:
metadata:
labels:
app: baton-ldap
baton: true
baton-app: ldap
spec:
containers:
- name: baton-ldap
image: public.ecr.aws/conductorone/baton-ldap:latest
imagePullPolicy: IfNotPresent
env:
- name: BATON_HOST_ID
value: baton-ldap
envFrom:
- secretRef:
name: baton-ldap-secrets
```
### Step 3: Deploy the connector
Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
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 LDAP connector to. LDAP data should be found on the **Entitlements** and **Accounts** tabs.
**Done.** Your LDAP connector is now pulling access data into C1.