Capabilities
The Cisco Ise connector syncs the following resources:
Additional functionality:
The Cisco ISE connector supports automatic account provisioning and deprovisioning.
Account creation fields
When provisioning a new Cisco ISE internal user, C1 prompts for the following fields:
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
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.
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.
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.
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 <address> 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.
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.
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.
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
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
Sign in to the Cisco ISE admin console as a Super Admin.
Enable ERS:Navigate to Administration > System > Settings > API Settings > API Service Settings and enable ERS (Read/Write) on the Policy Administration Node.
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.
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.
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.
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.
Follow these instructions to use a built-in, no-code connector hosted by C1.In C1, navigate to Apps > Connectors and click Add connector.
Search for Cisco ISE and click Add.
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.
Set the connector’s Name and, optionally, a Description.
Click the pencil icon next to Owners to choose who can configure and manage this connector.
Click Add. The connector is created and its configuration page opens.
Find the Settings area of the page and click Edit.
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
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. Follow these instructions to use the 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
Step 1: Set up a new Cisco ISE connector
In C1, navigate to Apps > Connectors > Add connector.
Search for Baton and click Add.
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.
Set the connector’s Name and, optionally, a Description.
Click the pencil icon next to Owners to choose who can configure and manage this connector.
Click Add. The connector is created and its configuration page opens.
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.
Step 2: Create Kubernetes configuration files
Create two Kubernetes manifest files for your Cisco ISE connector deployment:Secrets configuration
See the connector’s README or run --help to see all available configuration flags and environment variables.Deployment configuration
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 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.