> ## Documentation Index > Fetch the complete documentation index at: https://www.c1.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Set up a Cisco ISE connector > C1 provides identity governance and just-in-time provisioning for Cisco ISE. Integrate your Cisco ISE instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access. ## Capabilities The Cisco Ise connector syncs the following resources: | Resource | Sync | Provision | | :- | :- | :- | | Accounts | | | | Admin Groups | | | | Admin Users | | | | Identity Groups | | | **Additional functionality:** The Cisco ISE connector supports [automatic account provisioning and deprovisioning](/docs/product/admin/account-provisioning.md). ### Account creation fields When provisioning a new Cisco ISE internal user, C1 prompts for the following fields: | Field | Required | Description | | :- | :- | :- | | `username` | Yes | Login name for the new internal user (for example, `jdoe`). | | `email` | No | Email address for the new internal user. | | `first_name` | No | First name of the new internal user. | | `last_name` | No | Last name of the new internal user. | New accounts are created in the enabled state with a randomly generated password, which C1 shows you once at creation. When C1 also carries a login for the account being provisioned, the **Username** entered here is the name sent to Cisco ISE. ### Provisioned entitlements | Resource | Entitlement | Operation | | :- | :- | :- | | Identity Group | Member | Add an internal user to the identity group, or remove them from it | Identity group membership is the only access C1 can change in Cisco ISE. Admin users are read for inventory and access reviews: their admin-group membership is synced as a grant, and C1 does not create, delete, modify, grant, or revoke it. **Notes:** * Two membership changes running at the same time against the same user can overwrite each other. Cisco ISE has no endpoint that adds or removes a single group membership, so each grant and revoke rewrites the user's whole group list. If a grant and a revoke overlap, one of them can be lost; re-run the access change to reapply it. * Other settings on an internal user are left alone by a membership change, including the account's enable password. > [!WARNING] > > **Network requirement: TCP port 9060.** The Cisco ISE connector reaches ISE through the ERS API on TCP port 9060, so your ISE Policy Administration Node (PAN) must accept connections on that port from wherever the connector runs — C1's infrastructure for a cloud-hosted connector, or your own environment for a self-hosted one. > > Cisco ISE keeps port 9060 closed until the ERS API is turned on, and opens it as soon as you enable ERS. If the connector cannot reach ISE, check that ERS is enabled on the PAN before you go looking for a firewall rule. > [!WARNING] > > **The ERS CSRF check must be turned off for C1 to provision access.** In the Cisco ISE admin console, **Administration** > **System** > **Settings** > **API Settings** > **API Service Settings** offers **CSRF Check (only for ERS Settings)**. Select **Disable CSRF For ERS Request**, the compatibility option other ERS clients also rely on. > > If **Enable CSRF Check for Enhanced Security** is selected instead, the connector still syncs users, groups, and admin users normally, but every write is rejected by ISE: creating an account, deleting an account, and granting or revoking identity group membership all fail with a permission error and change nothing in ISE. > [!WARNING] > > **ISE's TLS certificate must be one the connector trusts.** Cisco ISE ships with a self-signed certificate, and many deployments keep an internally-issued one. The connector verifies it like any HTTPS client, so an untrusted certificate stops the sync before ISE ever sees the credentials, with an error naming `x509: certificate signed by unknown authority`. Connecting by IP address fails the same way for a second reason — ISE's default certificate carries no IP SAN, so the error instead reads `cannot validate certificate for
because it doesn't contain any IP SANs`. > > A **cloud-hosted** connector has no setting to skip verification or add a CA, so ISE needs a publicly trusted certificate. Replace it under **Administration** > **System** > **Certificates** > **System Certificates**, and make sure the name you configure in C1 matches a name on the certificate. For a private CA, run the connector self-hosted, where that host can trust it. > > A **self-hosted** connector can be told to skip verification with `BATON_INSECURE: "true"`, which exists for test environments. It disables the check that the node is the one it claims to be, so do not use it against production ISE. > [!WARNING] > > **Use a dedicated ERS account, not one a person signs in with.** ISE suspends an administrator account after a number of consecutive failed sign-ins. For admin accounts that setting is **Administration** > **System** > **Admin Access** > **Authentication** > **Lock/Suspend Settings**, not the internal-user password policy under Identity Management. The ISE administrator sets how many failed attempts trigger it and how long it lasts. > > Those attempts are counted per account across everything that uses it, so a connector configured with the wrong password suspends the account for the people who share it, and a person mistyping it suspends the connector. A suspended account is refused over ERS even with the right password. ISE answers that with 401, which the connector reports as an authentication error, the same shape as a wrong password. > > That setting offers **Lock** or **Suspend**. Waiting out the window only works for Suspend. With Lock, another administrator has to reset the account before ERS will accept it again. > > Expect recovery to take longer than the configured window. On ISE 3.4, a suspended account stayed refused well past the window while a self-hosted connector kept retrying it. Correcting the password does not end an active suspension. Stop the sync attempts first, then wait the window out. > > How you stop them depends on the deployment. For a **self-hosted** connector, scale the Deployment to 0, correct `BATON_PASSWORD` in the Secret, wait, then scale it back up. For a **cloud-hosted** connector, select **Pause** on the connector in C1, correct the credentials there, and resume it after the window. > > Give the connector an administrator of its own, in the ERS group it needs and used by nothing else, so a suspension costs you that connector and nothing else. > [!WARNING] > > **Admin groups are identified by name.** ERS 3.4 serves no admin-group collection, so the groups come from the `adminGroups` field of the administrators themselves and the group's name is the only identifier ISE publishes for it. Two consequences: renaming an admin group in ISE reads as deleting one group and creating another, which drops the memberships C1 recorded against the old name until the next sync rebuilds them under the new one; and a group whose name contains a comma cannot be read correctly, because ISE packs an administrator's groups into one comma-separated string with no escaping. Enable Admin Groups together with Admin Users — the groups are derived from the administrators, so selecting the groups alone syncs them with no members. > [!WARNING] > > Admin user and admin group syncing is opt-in, and it fails closed. Not every ISE deployment lets an ERS account read administrator accounts — that access comes from the account's ISE admin group membership, not from a permission you request. If you enable Admin Users or Admin Groups for an account that cannot read administrator accounts, the entire sync stops with a permission error, so accounts and identity groups do not finish syncing either. Either leave both resources disabled, or use an ISE administrator whose admin group is allowed to read administrator accounts. Admin groups are derived from those administrators, so enable them together. ## Gather Cisco ISE credentials > [!WARNING] > > To configure the Cisco ISE connector, you need a dedicated ISE administrator with ERS (External RESTful Services) API access — create one for the connector rather than sharing a person's **Super Admin** account. Membership in the **ERS Operator** group is enough to sync access data. For C1 to also provision access — create and delete internal users, and change identity group membership — the account needs to be in the **ERS Admin** group. The steps below cover creating that account. ### Create an ERS administrator account **Step 1** Sign in to the Cisco ISE admin console as a Super Admin. **Step 2** Enable ERS: Navigate to **Administration** > **System** > **Settings** > **API Settings** > **API Service Settings** and enable **ERS (Read/Write)** on the Policy Administration Node. **Step 3** On the same page, under **CSRF Check (only for ERS Settings)**, select **Disable CSRF For ERS Request** and save. C1 cannot provision access while the CSRF check is enabled. **Step 4** Create or designate an admin user in the right ERS group: Go to **Administration** > **System** > **Admin Access** > **Administrators** > **Admin Users** and create a new administrator for this connector, in the **ERS Operator** group to sync internal users and identity groups, or in the **ERS Admin** group if C1 also provisions access. Create one rather than reusing an existing account. A **Super Admin** account does satisfy both groups, but sharing it with the connector means a wrong password on either side suspends it for both. Leave **Admin Users** and **Admin Groups** disabled unless this account can read `/ers/config/adminuser`. That read is granted by the admin group, and membership in ERS Operator or ERS Admin does not by itself show that it is allowed. Without it those two opt-in types fail the whole sync. **Step 5** Note the ISE hostname (e.g., `ise.example.com`), the admin username, and password. These are the credentials C1 will use. That's it! For more information, see [Cisco ISE API Framework](https://developer.cisco.com/docs/identity-services-engine/latest/). ## Configure the Cisco ISE connector > [!WARNING] > > To configure this connector, you need the **Connector Administrator** or **Super Administrator** role in C1 and the Cisco ISE hostname, ERS administrator username, and ERS administrator password. **Cloud-hosted** Follow these instructions to use a built-in, no-code connector hosted by C1. **Step 1** In C1, navigate to **Apps** > **Connectors** and click **Add connector**. **Step 2** Search for **Cisco ISE** and click **Add**. **Step 3** Choose where to add the connector: **Create a new app**, or **Add to an existing app** (then select the app). If you're creating a new app, choose whether to link it to an application discovered from your identity provider: select **Yes** and pick the IdP application, or **No** to continue with just the connector. **Step 4** Set the connector's **Name** and, optionally, a **Description**. **Step 5** Click the pencil icon next to **Owners** to choose who can configure and manage this connector. **Step 6** Click **Add**. The connector is created and its configuration page opens. **Step 7** Find the **Settings** area of the page and click **Edit**. **Step 8** Enter the required configuration: * **Hostname**: The ISE PAN hostname (e.g. ise.example.com). An IP address fails TLS verification when the certificate has no IP SAN. * **Username**: ERS API administrator username * **Password**: ERS API administrator password **Step 9** Click **Save**. **Step 10** The connector's label changes to **Syncing**, followed by **Connected**. You can view the logs to ensure that information is syncing. **Done.** Your Cisco ISE connector is now pulling access data into C1. **Self-hosted** Follow these instructions to use the [Cisco ISE](https://github.com/conductorone/baton-cisco-ise) 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. ### Resources * [Official download center](https://dist.conductorone.com/ConductorOne/baton-cisco-ise): For stable binaries (Windows/Linux/macOS) and container images. * [GitHub repository](https://github.com/conductorone/baton-cisco-ise): Access the source code, report issues, or contribute to the project. ### Step 1: Set up a new Cisco ISE connector **Step 1** In C1, navigate to **Apps** > **Connectors** > **Add connector**. **Step 2** Search for **Baton** and click **Add**. **Step 3** Choose where to add the connector: **Create a new app**, or **Add to an existing app** (then select the app). If you're creating a new app, choose whether to link it to an application discovered from your identity provider: select **Yes** and pick the IdP application, or **No** to continue with just the connector. **Step 4** Set the connector's **Name** and, optionally, a **Description**. **Step 5** Click the pencil icon next to **Owners** to choose who can configure and manage this connector. **Step 6** Click **Add**. The connector is created and its configuration page opens. **Step 7** In the **Settings** area of the page, click **Edit**. **Step 8** Click **Rotate** to generate a new Client ID and Secret. Carefully copy and save these credentials. ### Step 2: Create Kubernetes configuration files Create two Kubernetes manifest files for your Cisco ISE connector deployment: #### Secrets configuration ```yaml expandable theme={"theme":{"light":"css-variables","dark":"css-variables"}} # baton-cisco-ise-secrets.yaml apiVersion: v1 kind: Secret metadata: name: baton-cisco-ise-secrets type: Opaque stringData: # C1 credentials BATON_CLIENT_ID: BATON_CLIENT_SECRET: # Cisco ISE credentials BATON_HOSTNAME: BATON_USERNAME: BATON_PASSWORD: # Optional: include if you want C1 to provision access using this connector BATON_PROVISIONING: "true" # Test environments only: uncomment to skip verification of ISE's TLS # certificate. Against production ISE, trust the certificate instead. # BATON_INSECURE: "true" ``` See the connector's README or run `--help` to see all available configuration flags and environment variables. #### Deployment configuration ```yaml expandable theme={"theme":{"light":"css-variables","dark":"css-variables"}} # baton-cisco-ise.yaml apiVersion: apps/v1 kind: Deployment metadata: name: baton-cisco-ise labels: app: baton-cisco-ise spec: selector: matchLabels: app: baton-cisco-ise template: metadata: labels: app: baton-cisco-ise baton: "true" baton-app: cisco-ise spec: containers: - name: baton-cisco-ise image: public.ecr.aws/conductorone/baton-cisco-ise:latest imagePullPolicy: IfNotPresent env: - name: BATON_HOST_ID value: baton-cisco-ise envFrom: - secretRef: name: baton-cisco-ise-secrets ``` ### Step 3: Deploy the connector **Step 1** Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files. **Step 2** Check that the connector data uploaded correctly. In C1, click **Applications**. On the **Managed apps** tab, locate and click the name of the application you added the Cisco ISE connector to. Cisco ISE data should be found on the **Entitlements** and **Accounts** tabs. **Done.** Your Cisco ISE connector is now pulling access data into C1. *** > [!TIP] > > All versions of this connector are available at [dist.conductorone.com](https://dist.conductorone.com/ConductorOne/baton-cisco-ise).