Non-human identities (NHI) page and connector updates

baton/active-directory.mdx

@@ -2,7 +2,7 @@
 title: "Set up an Active Directory connector"
 og:title: "Set up an Active Directory connector"
 description: "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."
 og:description: "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."
 sidebarTitle: "Connector setup"
 ---
 
@@ -16,7 +16,7 @@
 | :--- | :--- | :--- |
 | Accounts | <Icon icon="square-check" iconType="solid" color="#c937ae"/> | <Icon icon="square-check" iconType="solid" color="#c937ae"/> |
 | Groups | <Icon icon="square-check" iconType="solid" color="#c937ae"/> | <Icon icon="square-check" iconType="solid" color="#c937ae"/> |
 | Group Managed Service Accounts (gMSAs) | <Icon icon="square-check" iconType="solid" color="#c937ae"/> | <Icon icon="square-check" iconType="solid" color="#c937ae"/> |
 
 The Active Directory connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning). When a new account is created by C1, the account's password is sent to a [vault](/product/admin/vaults).
 
@@ -29,11 +29,13 @@
 - Account provisioning (create/delete) requires LDAPS (`ldaps: true`).
 - Provisioning is idempotent: re-granting a group membership a user already holds, revoking one they don't have, or creating an account or group that already exists is treated as success rather than an error — so overlapping grants during a role change don't fail. An account that already exists is returned unchanged (its password is not reset).
 
 User profiles include UAC-derived state booleans, FILETIME timestamps, and configurable extension attributes — see [User profile attributes](#user-profile-attributes) under Reference.
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ### 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):
 
@@ -119,7 +121,7 @@
   </Step>
 </Steps>
 
 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:
 
@@ -208,7 +210,7 @@
 **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](#multi-domain-and-cross-forest-sync).
 
 **Identity:**
 
@@ -451,7 +453,7 @@
 |---|---|---|---|
 | `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. A **write-capable** connection resolves a **writable** DC so provisioning works (skipping RODCs; if the site has only Read-Only DCs, AD site coverage returns the nearest writable DC in another site). A **read-only** connection resolves the in-site DC (an RODC is fine), keeping reads local. See [Domain controller selection and RODCs](#domain-controller-selection-and-rodcs) for the full behavior matrix. Example: `US-DC-01` |
 | `mode` | string | `winldap` | Connection mode: `winldap` (default; `wldap32.dll` system calls with GSSAPI) or `ldap` (go-ldap library, e.g. for Simple Bind) |
 | `ldaps` | bool | `false` | Enable LDAPS (TLS). Required for account provisioning. |
 | `ldaps-port` | int | `636` | LDAPS port. Use `3269` for Global Catalog over LDAPS. |
@@ -482,8 +484,8 @@
 | `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`) |
 | `sync-extension-attributes` | bool | `false` | Sync `extensionAttribute1`–`extensionAttribute15` on every user profile. Equivalent to listing all 15 names in `custom-user-attributes`. |
 | `use-display-name` | bool | `false` | Use the LDAP `displayName` attribute as the C1 resource label instead of `cn`. Falls back to `cn` when `displayName` is empty. Applies to user and gMSA resources. |
@@ -494,8 +496,8 @@
 | 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:**
 
@@ -557,7 +559,7 @@
 
 #### 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:
 
@@ -565,7 +567,7 @@
 Get-ADTrust -Filter * | Select-Object Name, Direction, TrustType, ForestTransitive
 ```
 
 **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:
 
 ```powershell
 Add-DnsServerConditionalForwarderZone `
@@ -581,19 +583,19 @@
 Resolve-DnsName -Name "DC01.remote-forest.example.com"
 ```
 
 **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):
 
   ```powershell
@@ -604,7 +606,7 @@
 - **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. Note that `ldaps-skip-verify` is a **global** setting — it applies to every configured domain (including the primary), not just this one, so prefer Option A or B for production.
 - **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.
 
 **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`.
 
@@ -616,7 +618,7 @@
 |---|---|---|---|
 | `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 |
@@ -626,8 +628,8 @@
 | `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 |
 
@@ -636,8 +638,8 @@
 #### 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
@@ -653,8 +655,8 @@
 - **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
 
@@ -704,7 +706,7 @@
 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
 
@@ -773,17 +775,17 @@
         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`.
 
 Arguments are delivered to the script's `param()` block with their declared types — a `bool` binds a real boolean (works for `[bool]` and `[switch]`), an `int` binds a number, and a `string` binds a literal value. String values are passed as data (not spliced into the command line), so content such as quotes, `$(...)`, or `;` is inert and cannot inject PowerShell. Write your script with a `param()` block matching the declared argument names, and signal the outcome with an explicit exit code (`exit 0` for success, a non-zero `exit N` for failure) — the connector reports that exit code back to C1.
 
 ### User profile attributes
 
 Synced user profiles carry the standard AD attributes (display name, email, manager, department, etc.) plus three groups of extra fields the connector populates from AD: read-only state booleans, FILETIME timestamps, and any custom attributes you list in `custom-user-attributes`.
 
 #### Read-only state attributes
 
 Six booleans are surfaced on every user profile:
 
 | Field | Source | Meaning |
 |---|---|---|
@@ -832,8 +834,8 @@
 | `lockoutTimeAt` | `lockoutTime` | FILETIME |
 | `badPasswordTimeAt` | `badPasswordTime` | FILETIME |
 | `lastLoginAt` | `lastLogon` or `lastLogonTimestamp` | FILETIME |
 | `whenChangedAt` | `whenChanged` | generalizedTime |
 | `whenCreatedAt` | `whenCreated` | generalizedTime |
 
 **Sentinel handling:** values that AD encodes as "never" (`0`) or "never expires" (`0x7FFFFFFFFFFFFFFF` for FILETIME) cause the parsed `*At` key to be omitted — no year-1601 or year-30828 dates leak into a profile view.
 
@@ -844,7 +846,7 @@
 | `custom-user-attributes: [pwdLastSet]` | valid FILETIME | `pwdLastSet` (raw) + `pwdLastSetAt` (parsed) + `passwordLastSet` (legacy alias) |
 | `custom-user-attributes: [accountExpires]` | sentinel `9223372036854775807` | neither key (both suppressed) |
 | `custom-user-attributes: [lastLogon]` | sentinel `0` | neither key (both suppressed) |
 | `custom-user-attributes: [whenChanged]` | valid generalizedTime | `whenChanged` (raw) + `whenChangedAt` (parsed) |
 | (default — not listed in `custom-user-attributes`) | any non-sentinel | parsed `*At` only |
 
 <Note>
@@ -852,7 +854,7 @@
 </Note>
 
 <Note>
 **Backwards-compat aliases (v0.5.5 transition):** for one release, the connector also emits each renamed FILETIME canonical key under its pre-v0.5.5 name — `passwordLastSet` (alongside `pwdLastSetAt`), `lockedOutAt` (alongside `lockoutTimeAt`), and `lastBadPasswordAt` (alongside `badPasswordTimeAt`) — so downstream automations reading the older keys continue to work. The new generalizedTime keys (`whenChangedAt`, `whenCreatedAt`, `lastLoginAt`) have no legacy aliases since they're introduced in this release. Legacy aliases will be dropped in a future release; new consumers should target the canonical `*At` form.
 </Note>
 
 #### Push attributes
@@ -886,14 +888,14 @@
 | `physicalDeliveryOfficeName` | Address | Office location |
 
 <Note>
 Pre-v0.5.5 push rules used snake_case field names (`first_name`, `display_name`, `email`, etc.). Those rules continue to work — the connector resolves both the canonical AD names listed above and the legacy snake_case aliases to the same target attribute. New push rules should prefer the AD-canonical names so the C1 UI's "App attribute" column matches what AD actually expects.
 </Note>
 
 <Warning>
 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.
 </Warning>
 
 The `update_user_attrs` global action recognizes the 23 fields above (plus their legacy snake_case aliases for backwards compatibility), plus 15 extension attribute names (`extensionAttribute1` through `extensionAttribute15` — also accepted as `extension_attribute_1`–`extension_attribute_15`). 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.
 
 ### Troubleshooting "search returned 0 entries"
 
@@ -903,15 +905,15 @@
 
 2. **The DN doesn't exist as written** — the connector logs the exact `base` string sent to AD. Copy it verbatim into `dsquery * "<base>" -limit 1` on the DC to confirm.
 
 3. **The bound DC isn't authoritative for the search base** — when you narrow `user-search-dn` or `group-search-dn` into a delegated OU, a child-domain OU, or a Read-Only DC subtree, the bound DC may answer with `LDAP_REFERRAL` (result code 10) or `LDAP_PARTIAL_RESULTS` (9) instead of entries. The connector surfaces this case explicitly: alongside the zero-entries INFO, look for a WARN log of the form `ldap_ext_search: non-success result code_name=LDAP_REFERRAL r1=10`. The same condition surfaces in the C1 sync-failure panel as `LDAP error: LDAP_REFERRAL`, so it's identifiable from the platform side too without needing log access.
 
    **The connector does not chase referrals.** WinLDAP's referral-chasing option (`LDAP_OPT_REFERRALS`) is explicitly disabled — it has to be, to work around an [AD pagination bug](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/ldap-paged-queries-subordinate-referrals-not-chased) where chased subordinate referrals confuse the paging control and corrupt the page cookie. Re-enabling chasing would also introduce an authentication-security risk (chased referrals can authenticate against arbitrary servers). The remediation is to **adjust the search configuration so the bound DC is authoritative for the subtree**:
 
    - Widen the search base (e.g. move from `OU=Sub,OU=Parent,DC=corp,DC=example,DC=com` up to `OU=Parent,...` or to the partition root `DC=corp,DC=example,DC=com`).
    - Configure a different bind DC that *is* authoritative for the OU — pass `--sitename` to scope discovery to a site that includes an authoritative DC, or set up [`additional-domains`](#multi-domain-and-cross-forest-sync) if the subtree belongs to a different partition.
    - For multi-domain forests, use [`additional-domains`](#multi-domain-and-cross-forest-sync) so the connector binds separately against each partition's authoritative DC instead of chasing referrals from one DC.
 
 ### Domain controller selection and RODCs
 
 The connector performs both directory **reads** (sync) and **writes** (provisioning: grant/revoke, account and group creation, enable/disable, set-manager, and similar) over a **single connection per domain**. Writes cannot be served by a **Read-Only Domain Controller (RODC)** — an RODC answers every write with `LDAP_REFERRAL` (result code 10), referring the client to a writable DC.
 
@@ -921,23 +923,23 @@
 - An **additional domain** is write-capable only when `read-only: false` (see [Additional domain fields](#additional-domain-fields)); otherwise it is read-only. Note that setting `bind-type` on an additional domain (even without bind credentials) flips its `read-only` default to `false`, making it write-capable — set `read-only: true` explicitly if you use it only for authenticated reads, so its DC selection stays in-site.
 - The **Global Catalog** scope (`sync-scope: GlobalCatalog`) is always read-only — it binds the read-only GC port (`3268`, or `3269` over LDAPS), and provisioning is not performed over a Global Catalog connection.
 
 **Behavior by connection type and site topology.** The configured `sitename` is a *preference* (locate the closest DC); the writable requirement, when it applies, is a *hard filter*. AD **site coverage** means a writable DC in another site automatically "covers" a site that has none, so a writable DC is still located when the local site has only RODCs.
 
 | Connection | Writable DC in the configured site? | DC the connector binds | Reads | Writes |
 |---|---|---|---|---|
 | **Write-capable** (primary, or additional `read-only: false`) | Yes | the in-site writable DC | local to the site | ✅ succeed |
 | **Write-capable** | No — site has only RODCs | nearest **writable** DC covering the site (another site) | traverse a site link (not local) | ✅ succeed |
 | **Write-capable** | No writable DC reachable **anywhere** | native discovery fails → DNS-SRV fallback may bind an RODC (logged with a prominent warning) | succeed | ❌ fail with `LDAP_REFERRAL` until a writable DC is reachable |
 | **Read-only** (additional `read-only: true`) | Yes | the in-site DC (writable or RODC — nearest) | local to the site | n/a (writes blocked by config) |
 | **Read-only** | No — site has only RODCs | the in-site **RODC** | local to the site | n/a |
 
 The selection is logged with `writable=true`/`writable=false`. The practical upshot: a **write-capable** connection whose site has only RODCs trades read locality for working provisioning (reads move to the covering writable DC); a **read-only** connection always keeps reads on the in-site DC.
 
 **Symptom this prevents.** Before this behavior, a site containing an RODC could cause the connector to bind that RODC: sync succeeded (reads work against an RODC) but every write action later failed with `LDAP error: LDAP_REFERRAL` in the C1 action-failure panel, and `ldap_modify: ret code_name=LDAP_REFERRAL r1=10` in the connector log.
 
 **If no writable DC is reachable at all** (a genuine outage, or a network segment that can only reach RODCs), native discovery fails and the connector falls back to DNS SRV, which cannot distinguish an RODC from a writable DC. The connector logs a prominent warning in this case (`native writable-DC discovery failed; falling back to DNS SRV which cannot guarantee a writable DC …`). If an RODC is then bound, sync works but provisioning will fail with `LDAP_REFERRAL` until a writable DC is reachable in or covering the configured site.
 
 **Requirement.** A writable DC must be reachable in, or covering, the configured `sitename` for provisioning to work. This is the normal AD topology (every domain has at least one writable DC, and writable DCs cover sites that have none of the needed type).
 
 ### LDAPS troubleshooting
 
@@ -953,7 +955,7 @@
   certutil -addstore Root <path-to-ca.cer>
   ```
 
 - **LDAP mode** (go-ldap library): TLS validation uses Go's TLS stack. `ldaps-skip-verify: true` (the default) disables hostname and chain validation, which lets self-signed AD certs work in lab environments. For production, set `ldaps-skip-verify: false` and either trust the CA at the OS level or import it into the connector machine.
 
 If `mode: ldap` doesn't connect on a Windows host (typical when the AD server requires channel binding or LDAP signing), switch to `mode: winldap`.
 
@@ -970,8 +972,8 @@
 Common LDAPS failure signatures and what they mean:
 
 - **`x509: certificate signed by unknown authority`** (go-ldap mode) — the connector machine doesn't trust the CA that issued the DC certificate. Import the CA root or set `ldaps-skip-verify: true` for testing only.
 - **`tls: failed to verify certificate: x509: certificate is valid for X, not Y`** — certificate Subject/SAN doesn't include the hostname the connector is connecting to. Verify you're targeting a DC hostname that matches the cert (DCs typically have multiple SAN entries).
 - **`LDAP Result Code 81 "Server is unavailable"`** in WinLDAP mode — usually a TLS handshake failure where Schannel rejected the cert. Check the Windows event log under `LDAP-Client` and `Schannel` sources for the rejection reason.
 - **Connection times out on port 636** — port not open between the connector host and the DC, or LDAPS isn't enabled on the DC. Confirm the DC has a Server Authentication EKU certificate in its Personal store.
 
 For multi-domain setups, `test-ldaps` checks every entry in `additional-domains` plus the primary, so a single run covers your whole topology.
@@ -980,7 +982,7 @@
 
 On Windows, the connector can encrypt sensitive config values (`client-id`, `client-secret`, `bind-password`, and the `bind-password` of every `additional-domains` entry) using Windows DPAPI machine-scoped encryption. Encrypted values are prefixed `dpapi:` in the YAML config and are decrypted transparently at startup.
 
 Secrets are encrypted for you on the paths that write the config: `setup` encrypts any plaintext secrets before it locks the file down (pass `--no-encrypt` to skip, for troubleshooting), and the GUI Configuration Editor encrypts on save. You only need to run this manually if you edited `config.yaml` by hand or generated it with your own tooling:
 
 ```console
 baton-active-directory.exe encrypt-config
@@ -993,7 +995,7 @@
 
 If a host's `config.yaml` has been readable by `BUILTIN\Users` — check with `icacls "C:\ProgramData\ConductorOne\baton-active-directory\config.yaml"` — then every local account on that server could read *and* decrypt its secrets. Encrypting or locking the file now does not undo that: **rotate the C1 client credentials and the AD bind password**, then store the new values with `setup` or `encrypt-config`.
 
 Machine scope also means **an encrypted config is not portable**. Do not copy a config that has been through `setup` or `encrypt-config` to another server, or capture it into a golden image or a config repository that redeploys it — the connector cannot decrypt it there and will fail at startup. Distribute the plaintext config and let each host encrypt its own copy.
 </Note>
 
 #### Restricting the config directory
@@ -1029,8 +1031,8 @@
 baton-active-directory.exe config-editor
 ```
 
 The editor exposes every YAML config field across a tabbed layout (Connection, Authentication, Search, gMSA, Multi-Domain, Advanced). Notable toggles on the Advanced tab include `Lockout Status Behavior` (`locked-account-is-disabled`), `Sync Extension Attributes` (`sync-extension-attributes`), and `Use displayName as Resource Label` (`use-display-name`). Secret fields (bind passwords, client secret) are write-only — entering a new value encrypts it via DPAPI on save, and leaving a field blank keeps the stored value. A stored value that is still plaintext (from a hand-edited config) is encrypted on the next save; the cue next to each field shows which state it is in.
 
 ## 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.

baton/aws.mdx

@@ -2,7 +2,7 @@
 title: "Set up an AWS connector"
 description: "C1 provides identity governance for AWS. Integrate your AWS instance with C1 to run user access reviews (UARs) and enable just-in-time (JIT) access requests."
 og:title: "Set up an AWS connector"
 og:description: "C1 provides identity governance for AWS. Integrate your AWS instance with C1 to run user access reviews (UARs) and enable just-in-time (JIT) access requests."
 sidebarTitle: "AWS"
 ---
 
@@ -36,13 +36,15 @@
 
 [This connector can sync secrets](/product/admin/inventory) and display them on the **Inventory** page.
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ## AWS STS web identity action
 
 The connector exposes the global `assume_role_with_web_identity` action for
 approved, short-lived AWS credential vending. C1 supplies a request-scoped OIDC
 token and age encryption recipient. The connector exchanges the token with AWS
 STS, encrypts the returned credential envelope before it crosses the connector
 boundary, and returns ciphertext plus expiration and assumed-role audit
 metadata.
 
 The action accepts:
@@ -69,7 +71,7 @@
 topology from its configured issuance mode and apply the corresponding AWS
 limit.
 
 ## Sparse ACLs: Organizations and permission sets as scoped bindings
 
 When both **Enable support for AWS Organizations** and **Enable support for AWS IAM Identity Center** are turned on, the connector also models Identity Center permission set assignments as **Sparse ACL** bindings, alongside the existing flat per-account entitlement model. This introduces four resource types:
 
@@ -114,7 +116,7 @@
 
 To sync IAM data (like users, roles, and groups) from multiple AWS child accounts, C1 uses a secure, read-only mechanism called **cross-account access**. This setup works by allowing a central role in your root account to temporarily assume a specific role in each child account. This method ensures that the connector can gather the necessary data without storing credentials or requiring permanent access.
 
 If you're using this setup, make sure to click **Enable support for AWS Organizations** when setting up the connector in the C1 web UI. You may also enable **Enable support for AWS IAM Identity Center** at the same time. By default, enabling Identity Center alongside Organizations syncs only Identity Center data (users, groups, permission sets, account assignments) and skips cross-account IAM. To also sync IAM users, roles, and groups from every child account in this combined mode, additionally enable **Also sync cross-account IAM when Identity Center is enabled**. This flag is off by default so existing Identity Center deployments don't suddenly require child-account `sts:AssumeRole` access.
 
 **In order to use the connector to gather IAM AWS data, you'll need to configure each sub-account to have a role with a trust policy.** There are two options here:
 
@@ -135,7 +137,7 @@
     </Step>
     <Step>
     Choose how to set up the new AWS 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
     </Step>
@@ -347,7 +349,7 @@
     </Step>
     <Step>
     Choose how to set up the new AWS 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
     </Step>
@@ -776,7 +778,7 @@
 
 <Steps>
     <Step>
     Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
     </Step>
     <Step>
     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 AWS connector to. AWS data should be found on the **Entitlements** and **Accounts** tabs.

baton/azure-infrastructure.mdx

@@ -2,7 +2,7 @@
 title: "Set up a Microsoft Azure Infrastructure connector"
 description: "C1 provides identity governance and just-in-time provisioning for Microsoft Azure Infrastructure. Integrate your Azure Infrastructure instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:title: "Set up a Microsoft Azure Infrastructure connector"
 og:description: "C1 provides identity governance and just-in-time provisioning for Microsoft Azure Infrastructure. Integrate your Azure Infrastructure instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Microsoft Azure Infrastructure"
 ---
 
@@ -26,8 +26,10 @@
 | Storage accounts | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 | Containers | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 
 The Microsoft Azure Infrastructure connector works optimally when connected to a tenant licensed with either Microsoft Entra ID P2 or Microsoft Entra ID Governance. Other license types are supported, but the connector is not able to provide the same level of detail in all synced information. See the instructions below about using the **Skip Entra ID P2 License Features** configuration option if you do not have one of these license types.
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ## Gather Azure Infrastructure credentials
 
 Configuring the connector requires you to pass in credentials generated in Azure Infrastructure. Gather these credentials before you move on.
@@ -40,7 +42,7 @@
 
 <Steps>
   <Step>
   In Microsoft Entra admin center, navigate to **App registrations**.
   </Step>
   <Step>
   Click **New registration**.
@@ -167,7 +169,7 @@
   </Step>
   <Step>
   Choose how to set up the new Azure Infrastructure 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
   </Step>
@@ -209,7 +211,7 @@
   **Optional.** Check the box if you want to **Enable syncing external resources** (identities from a shared identity source).
   </Step>
   <Step>
   If you are **NOT** running Azure infrastructure on an **Entra ID P2** or **Entra ID Governance** license, click to enable **Skip Entra ID P2 License Features**. If this option is not checked and you do not have one of the license types above, the connector will fail to sync properly.
   </Step>
   <Step>
   Click **Save**.
@@ -250,7 +252,7 @@
   </Step>
   <Step>
   Choose how to set up the new Azure Infrastructure 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
   </Step>
@@ -356,7 +358,7 @@
 
 <Steps>
   <Step>
   Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
   </Step>
   <Step>
   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 Azure Infrastructure connector to. Azure Infrastructure data should be found on the **Entitlements** and **Accounts** tabs.

baton/databricks.mdx

@@ -1,8 +1,8 @@
 ---
 title: "Set up a Databricks connector"
 og:title: "Set up a Databricks connector"
 description: "C1 provides identity governance and just-in-time provisioning for Databricks. Integrate your Databricks instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance and just-in-time provisioning for Databricks. Integrate your Databricks instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Databricks"
 ---
 
@@ -16,14 +16,16 @@
 | Service principals | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 | Workspaces | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 
 The Databricks connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning).
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ## Gather Databricks credentials
 
 Configuring the connector requires you to pass in credentials generated in Databricks. Gather these credentials before you move on.
 
 <Warning>
 A user with the **Account admin** role in each Databricks workspace you want to sync must perform this task.
 </Warning>
 
 ### Look up your Databricks account ID
@@ -40,29 +42,29 @@
   </Step>
 </Steps>
 
 ### Generate Databricks credentials
 
 You have three authentication choices when setting up the Databricks connector:
 
 - **OAuth** (syncs info from all Databricks workspaces)
 
   <Steps>
     <Step>
     Follow the [Databricks OAuth authentication documentation](https://docs.databricks.com/en/dev-tools/auth/oauth-m2m.html) to create a service principal and create an OAuth secret.
     </Step>
     <Step>
     Assign the service principal as an admin to each Databricks workspace you want to sync. The connector can only sync and provision a workspace's data if the service principal has admin access to that workspace.
     </Step>
     <Step>
     Carefully copy and save the OAuth client ID and secret.
     </Step>
   </Steps>
 
 - **Personal access token** (syncs info from a single Databricks workspace)
 
   <Steps>
     <Step>
     In Databricks, navigate to **Settings** > **Developer** > **Access tokens** and click **Manage**.
     </Step>
     <Step>
     Click **Generate new token** and create a new token.
@@ -73,10 +75,10 @@
   </Steps>
 
   <Note>
   Group provisioning isn't supported with a personal access token, because the Databricks API doesn't allow provisioning account groups this way. To provision groups, use the OAuth setup method instead.
   </Note>
 
 - **Username and password** (syncs info from all Databricks workspaces)
 
   You do not need to generate any additional credentials to use this method.
 
@@ -100,7 +102,7 @@
 
 Next, move on to the instructions for your chosen setup method.
 
 ## Configure the Databricks connector
 
 <Warning>
 To complete this task, you'll need:
@@ -122,7 +124,7 @@
   Search for **Databricks** and click **Add**.
   </Step>
   <Step>
   Choose how to set up the new Databricks 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
@@ -148,9 +150,9 @@
   Enter the required OAuth, token, or username and password credentials into the other two fields.
   </Step>
   <Step>
   **Google Cloud Platform and Azure Databricks customers only:** Enter your Databricks account hostname and hostname in the relevant fields.
     - For more on how to look up these values for GCP, see the GCP Databricks [REST API reference](https://docs.databricks.com/api/gcp/account/introduction) and [identifiers for workspace objects](https://docs.gcp.databricks.com/en/workspace/workspace-details.html) documentation.
     - For more on how to look up these values for Azure Databricks, see the the Azure Databricks [REST API reference](https://docs.databricks.com/api/azure/account/introduction) and [identifiers for workspace objects](https://learn.microsoft.com/en-us/azure/databricks/workspace/workspace-details) documentation.
   </Step>
   <Step>
   Click **Save**.
@@ -160,12 +162,12 @@
   </Step>
 </Steps>
 
 **Done.** Your Databricks connector is now pulling access data into C1.
 
 </Tab>
 <Tab title="Self-hosted">
 
 **Follow these instructions to use the Databricks 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.
 
@@ -185,8 +187,8 @@
   Search for **Baton** and click **Add**.
   </Step>
   <Step>
   Choose how to set up the new Databricks 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
   </Step>
@@ -210,7 +212,7 @@
 
 ### Step 2: Create Kubernetes configuration files
 
 Create two Kubernetes manifest files for your Databricks connector deployment:
 
 #### Secrets configuration
 
@@ -227,7 +229,7 @@
   BATON_CLIENT_SECRET: <C1 client secret>
 
   # Databricks credentials, option 1
   BATON_ACCOUNT_ID: <Databricks account ID>
   BATON_DATABRICKS_CLIENT_ID: <OAuth client ID>
   BATON_DATABRICKS_CLIENT_SECRET: <OAuth client secret>
 
@@ -287,13 +289,13 @@
 
 <Steps>
   <Step>
   Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
   </Step>
   <Step>
   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 Databricks connector to. Databricks data should be found on the **Entitlements** and **Accounts** tabs.
   </Step>
 </Steps>
 
 **Done.** Your Databricks connector is now pulling access data into C1.
 
 </Tab>

baton/github.mdx

@@ -2,7 +2,7 @@
 title: "Set up a GitHub connector"
 og:title: "Set up a GitHub connector"
 description: "C1 provides identity governance and just-in-time provisioning for GitHub. Integrate your GitHub instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 og:description: "C1 provides identity governance and just-in-time provisioning for GitHub. Integrate your GitHub instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 sidebarTitle: "GitHub"
 ---
 
@@ -19,7 +19,7 @@
 | Accounts | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 | Repositories | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 | Teams | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 | Orgs | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |
 | GitHub Apps (NHI) | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 | Secrets - API keys | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 
@@ -29,6 +29,8 @@
 
 [This connector can sync secrets](/product/admin/inventory) and display them on the **Inventory** page. 
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ## Gather GitHub credentials 
 
 Configuring the connector requires you to pass in credentials generated in GitHub. Gather these credentials before you move on. To set up the GitHub connector, you can choose to create a personal access token (classic), a fine-grained access token, or a GitHub app. 
@@ -71,7 +73,7 @@
    - **user** - select all
 
    <Warning>
    The **write::org** scope is used by C1 when automatically provisioning and deprovisioning GitHub access on your behalf. **If you do not want C1 to perform these tasks for you, do not give your token this scope.**
    </Warning>
 </Step>
 <Step>
@@ -182,7 +184,7 @@
 Check the **Expire user authorization tokens** and **Enable Device Flow** checkboxes to enable these settings.
 </Step>
 <Step>
 In the **Webhook** section of the page, uncheck the **Active** checkbox to disable this setting.
 </Step>
 <Step>
 In the **Permissions** section of the page, give the app the following permissions:
@@ -257,7 +259,7 @@
 <Step>
 Choose how to set up the new GitHub 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)
 
@@ -300,7 +302,7 @@
 
    1. **Optional.** Click to enable **Sync secrets**. [Synced secrets](/product/admin/inventory) are displayed on the **Inventory** page.
 
    1. **Optional.** If you do not want to include archived repos in syncs, click to enable **Omit archived repositories**.
 
    1. **Optional.** If your GitHub organization has thousands of repositories or members, click to enable **Optimize sync for large organizations**. See [Optimize sync for large organizations](#optimize-sync-for-large-organizations) for what changes when this option is enabled.
 </Step>
@@ -338,7 +340,7 @@
 <Step>
 Choose how to set up the new GitHub 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)
 
@@ -462,7 +464,7 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 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 GitHub connector to. GitHub data should be found on the **Entitlements** and **Accounts** tabs.

baton/google-cloud-platform.mdx

@@ -2,7 +2,7 @@
 title: "Set up a Google Cloud Platform with Google Workspace connector"
 og:title: "Set up a Google Cloud Platform with Google Workspace connector"
 description: "C1 provides identity governance and just-in-time provisioning for Google Cloud Platform with Google Workspace. Integrate your Google Cloud Platform with Google Workspace instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance and just-in-time provisioning for Google Cloud Platform with Google Workspace. Integrate your Google Cloud Platform with Google Workspace instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Google Cloud Platform with Google Workspace"
 ---
 
@@ -42,6 +42,8 @@
 
 [This connector can sync secrets](/product/admin/inventory) and display them on the **Inventory** page.
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ## Gather Google Cloud Platform with Google Workspace credentials
 
 Configuring the connector requires credentials from both Google Cloud Platform and the Google Workspace Admin console. You'll complete the following steps:
@@ -296,7 +298,7 @@
 <Step>
 Choose how to set up the new Google Cloud Platform with Google Workspace 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)
 
@@ -330,7 +332,7 @@
 **Optional.** Check the box if you want to skip syncing Google Cloud Platform system accounts.
 </Step>
 <Step>
 **Optional.** Uncheck the box (which is checked by default) if you want to sync Google Cloud Platform default projects.
 </Step>
 <Step>
 **Optional.** In the **Project IDs** field, enter a list of project IDs to limit the connector's sync to only those projects. Be sure to enter project IDs, not project names.
@@ -403,7 +405,7 @@
 <Step>
 Choose how to set up the new Google Cloud Platform with Google Workspace 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)
 
@@ -525,7 +527,7 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 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 Google Cloud Platform with Google Workspace connector to. Data should be found on the **Entitlements** and **Accounts** tabs.

baton/google-workspace.mdx

@@ -2,7 +2,7 @@
 title: "Set up a Google Workspace connector"
 og:title: "Set up a Google Workspace connector"
 description: "C1 provides identity governance and just-in-time provisioning for Google Workspace. Integrate your Google Workspace instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance and just-in-time provisioning for Google Workspace. Integrate your Google Workspace instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Google Workspace"
 ---
 
@@ -27,29 +27,31 @@
 
 The connector also supports group creation (via the `create_group` connector action) and deletion, [continuous sync](/baton/faq#syncing), and targeted sync for accounts, groups, and roles.
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ### 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.
 
 | Action name | Additional fields | Description |
 |-------------|-------------------|-------------|
 | update_user_status | `resource_id` (string, required)<br/>`is_suspended` (boolean, required) | Suspends or activates a user account |
 | disable_user | `user_id` (string, required) | Suspends a user account (idempotent) |
 | enable_user | `user_id` (string, required) | Unsuspends a user account (idempotent) |
 | change_user_primary_email | `resource_id` (string, required)<br/>`new_primary_email` (string, required) | Updates a user's primary email address |
 | transfer_user_drive_files | `resource_id` (string, required)<br/>`target_resource_id` (string, required)<br/>`privacy_levels` (string, optional) | Transfers Google Drive ownership from one user to another. Accepts `private` or `shared` for privacy_levels |
 | transfer_user_calendar | `resource_id` (string, required)<br/>`target_resource_id` (string, required)<br/>`release_resources` (boolean, optional) | Transfers Google Calendar data from one user to another |
 | change_user_org_unit | `user_id` (string, required)<br/>`org_unit_path` (string, required) | Moves a user to a different organizational unit |
 | offboarding_profile_update | `user_id` (string, required)<br/>`archive_account` (boolean, optional) | Comprehensive offboarding: removes from GAL, clears recovery details, deletes addresses/phones, optionally archives |
 | sign_out_user | `user_id` (string, required) | Signs user out of all sessions and resets sign-in cookies |
 | delete_all_oauth_tokens | `user_id` (string, required) | Revokes all third-party app authorizations |
 | delete_all_application_passwords | `user_id` (string, required) | Deletes all app-specific passwords |
 | create_group | `email` (string, required)<br/>`name` (string, required)<br/>`description` (string, optional) | Creates a new Google Workspace group |
 | modify_group_settings | `group_key` (string, required)<br/>`allow_external_members` (boolean, optional)<br/>`allow_web_posting` (boolean, optional)<br/>`who_can_post_message` (string, optional)<br/>`message_moderation_level` (string, optional) | Update settings for an existing Google Group |
 | update_user_manager | `user_id` (string, required)<br/> `manager_email` (string, required) | Updates the manager relation for a user in Google Workspace. Updates the 'manager' entry in the user's Relations field |
 | update_user_profile | `user_id` (resource ID, required)<br/>`given_name` (string, optional)<br/>`family_name` (string, optional)<br/>`recovery_email` (string, optional)<br/>`recovery_phone` (string, optional)<br/>`department` (string, optional)<br/>`job_title` (string, optional)<br/>`cost_center` (string, optional)<br/>`employee_type` (string, optional)<br/>`employee_id` (string, optional)<br/>`manager_email` (string, optional)<br/>`custom_schemas` (JSON string, optional) | Applies a partial update to a user's profile using patch semantics (only the provided fields change). Supports name fields, recovery details, Employee Information attributes (department, job title, cost center, employee ID, employee type), the manager relation, and custom-schema attribute values. Custom-schema definitions must already exist in the Workspace tenant. At least one updatable field is required. One narrow exception: an `employee_id` change that reduces the number of external IDs on the account (clearing it, or consolidating duplicate entries down to the new value) uses a full-object update instead of a sparse patch (Google does not reliably shrink a repeated field via patch), which widens the read-modify-write window to the whole user for that specific call. An empty or invalid `manager_email` does not fail the call when another provided field is valid — see the partial-success note below. |
 | update_user | `user_id` (resource ID, required)<br/>`user_profile` (JSON string, required) | Updates a user's profile from a `user_profile` JSON object (keys: `given_name`, `family_name`, `recovery_email`, `recovery_phone`, `department`, `job_title`, `cost_center`, `employee_type`, `employee_id`, `manager_email`, `custom_schemas`). Consumed by C1 push rules for automated profile sync. Same partial-success behavior as `update_user_profile` for `manager_email`. |
 | make_admin | `user_id` (resource ID, required)<br/>`status` (boolean, required) | Promotes (`status=true`) or demotes (`status=false`) a user to/from super administrator |
 
 <Note>
 The synced user profile exposes the job title under both `title` and `job_title`, for backward compatibility. `update_user`'s `user_profile` JSON object accepts any of `job_title`, `jobTitle`, or `title` as the source key. `update_user_profile` has a fixed argument schema and only exposes `job_title` — pass the value under that key.
@@ -397,7 +399,7 @@
 | `admin.directory.group.readonly` | Read and sync Google Groups |
 | `admin.directory.group.member` | Write. Manage group memberships, adding or removing users from groups |
 | `admin.directory.rolemanagement` | Write. Manage role assignments, granting or revoking roles |
 | `admin.directory.user` | Write. Provision and deprovision accounts, update user profiles and custom-schema values, and promote/demote super administrators |
 | `admin.reports.audit.readonly` | Sync usage events and admin events, used with continuous sync |
 | `admin.datatransfer` | Write. Transfer user data between Google accounts |
 | `admin.directory.group` | Write. Provision groups |
@@ -408,7 +410,7 @@
 </Tabs>
 
 <Warning>
 The write scopes let C1 provision and deprovision access. **If you don't want C1 to perform these tasks, use the read-only scope set.** Read-only still syncs users, groups, and roles, so it's sufficient when you use Google Workspace as your [directory](#set-google-workspace-as-your-c1-directory) and run access reviews.
 </Warning>
 
 ### Find your customer ID and primary domain
@@ -452,7 +454,7 @@
 <Step>
 Choose how to set up the new Google Workspace 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)
 
@@ -604,7 +606,7 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 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 Google Workspace connector to. Google Workspace data should be found on the **Entitlements** and **Accounts** tabs.
@@ -648,7 +650,7 @@
 
 ## What's next?
 
 If Google Workspace is your company's identity provider (meaning that it is used to SSO into other software), the integration sync will automatically create applications in C1 for all of your SCIMed software. Before you move on, review the [Create applications](/product/admin/applications) page for important information about how to set up integrations with the SCIMed apps.
 
 ## Troubleshooting the Google Workspace integration
 

baton/grafana.mdx

@@ -1,8 +1,8 @@
 ---
 title: "Set up a Grafana connector"
 og:title: "Set up a Grafana connector"
 description: "C1 provides identity governance and just-in-time provisioning for Grafana. Integrate your Grafana instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance and just-in-time provisioning for Grafana. Integrate your Grafana instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "Grafana"
 ---
 
@@ -16,24 +16,26 @@
 | Roles | <Icon icon="square-check" iconType="solid" color="#c937ae"/> | |
 | Service accounts | <Icon icon="square-check" iconType="solid" color="#c937ae"/> | |
 
 Team membership can be granted and revoked. Grafana RBAC roles that a team holds (IRM and OnCall plugin roles such as **Schedules Editor**) are synced as read-only assignments and require Grafana Cloud or Enterprise. Service accounts are synced with their organization role; they are read-only.
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 <Note>
 **Roles are optional**
 
 IRM / OnCall RBAC roles are available only on Grafana Cloud and Enterprise. Role sync is disabled by default — enable the **Role** resource type in the connector's settings in C1 when your instance has access-control.
 </Note>
 
 The Grafana connector supports both **self-hosted Grafana** instances and **Grafana Cloud**. The required credentials and provisioning behavior differ between the two — see [Gather Grafana credentials](#gather-grafana-credentials) below.
 
 The Grafana connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning).
 
 For self-hosted Grafana, when a new account is created by C1, the account's password is sent to a [vault](/product/admin/vaults).
 For Grafana Cloud, account creation is invite-based and no connector-generated password is returned.
 <Warning>
 **Grafana Cloud: enabling the basic login form is a prerequisite for creating brand-new users**
 
 Grafana Cloud instances ship with the basic login form **disabled** by default (users authenticate through grafana.com / SSO). While it is disabled, Grafana rejects instance-level invites for users who do not yet exist in the instance, and account creation fails with:
 
 ```
 Cannot invite external user when login is disabled.
@@ -43,26 +45,26 @@
 
 * **Users who already exist in the instance** (provisioned earlier via SSO, SCIM, or grafana.com) are added to the organization normally — account provisioning works for them without any change.
 * **Brand-new users** cannot be created until you either:
   * enable [SCIM provisioning](https://grafana.com/docs/grafana/latest/setup-grafana/configure-access/configure-scim-provisioning/) (Grafana's recommended path for automatic user lifecycle in Cloud), so users are provisioned by your identity provider before C1 assigns organization roles; or
   * enable the basic login form on the instance (set `disable_login_form = false`), which permits instance-level invites for external users.
 
 Managing membership directly through the grafana.com portal is a separate API and credential (a Grafana Cloud Access Policy token) that the connector's instance service-account token cannot use.
 </Warning>
 
 <Note>
 **Grafana Cloud: provisioning organization roles for externally synced users**
 
 In Grafana Cloud, users who sign in through an external identity provider (such as Grafana.com SSO, Okta, Azure AD, or any OAuth/SAML provider) have their organization roles controlled by that provider. By default, Grafana blocks API-level role changes for these users, which prevents C1 from provisioning organization entitlements for them.
 
 To allow C1 to manage organization roles for these users, enable **Skip org role sync** for the relevant SSO provider in your Grafana instance:
 
 1. In Grafana, go to **Administration** → **Authentication**.
 2. Select the SSO provider your users log in with.
 3. Enable **Skip org role sync** (equivalent to setting `skip_org_role_sync = true`).
 
 Once this is enabled, Grafana stops overriding org roles on login and C1 becomes the authoritative source for role assignments. This is a global setting that applies to all users under that provider.
 
 This step is not required for self-hosted Grafana instances using basic (username/password) authentication.
 </Note>
 
 ## Account access origin
@@ -71,25 +73,25 @@
 
 | Attribute | Type | Present | Meaning |
 | :--- | :--- | :--- | :--- |
 | `is_externally_synced` | Boolean | Only when Grafana returns the flag (Grafana Cloud) | `true` when the user's **organization role** is managed by an external identity provider (role sync), taken verbatim from Grafana's native `isExternallySynced` flag; `false` when the role is managed locally. Omitted entirely when Grafana does not return the flag (see below). |
 | `auth_labels` | String | Externally authenticated users only | The external authentication provider(s) associated with the user (for example, `grafana.com` or an OAuth/SAML provider name), joined with `; ` when there is more than one. Absent — not an empty string — for local users. |
 
 `is_externally_synced` surfaces Grafana's native `isExternallySynced` flag verbatim and only when Grafana actually returns it. Whether the flag is returned depends on the endpoint the connector reads, which differs by mode:
 
 * **Grafana Cloud** reads the organization users endpoint (`/api/org/users`), which always returns the flag, so `is_externally_synced` is present and mirrors Grafana's value exactly. It reflects **only** whether the user's organization role is managed by an external identity provider (role sync) — it is **not** derived from `auth_labels`, which is a different concept (how the user authenticated). In Grafana Cloud every user authenticates through grafana.com, so `auth_labels` is effectively always `grafana.com`; an admin whose role is managed locally therefore reports `is_externally_synced: false` even though their `auth_labels` show `grafana.com`.
 * **Self-hosted Grafana** reads the global users endpoint (`/api/users`), which does not return the flag. Rather than derive a value from a different concept, the connector omits `is_externally_synced` from the profile entirely. Use `auth_labels` to reason about authentication provenance in this mode.
 
 ## Gather Grafana credentials
 
 Configuring the connector requires credentials obtained in your Grafana instance. The credentials you need depend on whether you are connecting to **Grafana Cloud** or a **self-hosted Grafana** instance.
 
 <Tabs>
 <Tab title="Grafana Cloud">
 For Grafana Cloud, the connector authenticates using a **service account token**. Basic username/password authentication is not supported in Cloud mode.
 
 To create a service account token:
 
 1. In your Grafana Cloud instance, go to **Administration** → **Users and access** → **Service accounts**.
 2. Click **Add service account**, give it a name, and assign it the **Admin** role.
 3. Open the new service account and click **Add service account token**.
 4. Copy and save the generated token — it will not be shown again.
@@ -98,32 +100,32 @@
 
 You will need:
 
 * Your Grafana Cloud instance URL (e.g., `https://your-org.grafana.net`)
 * The service account token generated above
 
 **Done.** Next, move on to the connector configuration instructions.
 </Tab>
 <Tab title="Self-hosted Grafana">
 For self-hosted Grafana, the connector authenticates using the username and password of a Grafana admin account.
 
 You will need:
 
 * The username and password for a Grafana account with **admin-level permissions**
 * Your Grafana instance URL
 
 On Grafana Enterprise that account also needs `teams.roles:read`, which team sync reads for every team, plus `roles:read` when Role sync is enabled. On OSS, leave Role sync disabled — the access-control API is not present, and the connector skips that step instead of failing.
 
 **Done.** Next, move on to the connector configuration instructions.
 </Tab>
 </Tabs>
 
 ## Configure the Grafana connector
 
 <Warning>
 To complete this task, you'll need:
 
 - The **Connector Administrator** or **Super Administrator** role in C1
 - Access to the set of Grafana credentials gathered by following the instructions above
 </Warning>
 
 <Tabs>
@@ -138,9 +140,9 @@
 Search for **Grafana** and click **Add**.
 </Step>
 <Step>
 Choose how to set up the new Grafana 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)
 
@@ -158,14 +160,14 @@
 Find the **Settings** area of the page and click **Edit**.
 </Step>
 <Step>
 Paste your Grafana instance URL into the **Instance URL** field.
 </Step>
 <Step>
 Enter your credentials based on your Grafana deployment type:
 
    - **Grafana Cloud**: Select "API Key" as the auth method and paste your service account token into the **API Token** field.
 
    - **Self-hosted Grafana**: Select "Basic Authentication" as the auth method and paste the admin account's username and password into the **Username** and **Password** fields.
 </Step>
 <Step>
 Click **Save**.
@@ -175,11 +177,11 @@
 </Step>
 </Steps>
 
 **Done.** Your Grafana connector is now pulling access data into C1.
 </Tab>
 
 <Tab title="Self-hosted">
 **Follow these instructions to use the Grafana 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.
 
@@ -187,7 +189,7 @@
 
 * [GitHub repository](https://github.com/conductorone/baton-grafana): Access the source code, report issues, or contribute to the project.
 
 ### Step 1: Set up a new Grafana connector
 
 <Steps>
 <Step>
@@ -197,9 +199,9 @@
 Search for **Baton** and click **Add**.
 </Step>
 <Step>
 Choose how to set up the new Grafana 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)
 
@@ -225,9 +227,9 @@
 
 ### Step 2: Create Kubernetes configuration files
 
 Create two Kubernetes manifest files for your Grafana connector deployment. Use the secrets configuration that matches your Grafana deployment type.
 
 #### Secrets configuration — Grafana Cloud
 
 ```yaml expandable
 # baton-grafana-secrets.yaml
@@ -249,7 +251,7 @@
   BATON_PROVISIONING: true
 ```
 
 #### Secrets configuration — Self-hosted Grafana
 
 ```yaml expandable
 # baton-grafana-secrets.yaml
@@ -311,12 +313,12 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 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 Grafana connector to. Grafana data should be found on the **Entitlements** and **Accounts** tabs.
 </Step>
 </Steps>
 
 **Done.** Your Grafana connector is now pulling access data into C1.
 </Tab>

baton/jumpcloud.mdx

@@ -2,7 +2,7 @@
 title: "Set up a JumpCloud connector"
 og:title: "Set up a JumpCloud connector"
 description: "C1 provides identity governance for JumpCloud. Integrate your JumpCloud instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance for JumpCloud. Integrate your JumpCloud instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "JumpCloud"
 ---
 
@@ -19,6 +19,8 @@
 | Applications | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 | Roles | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ## Gather JumpCloud credentials 
 
 Configuring the connector requires you to pass in credentials generated in JumpCloud. Gather these credentials before you move on. 
@@ -66,7 +68,7 @@
 <Step>
 Choose how to set up the new JumpCloud 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)
 
@@ -120,7 +122,7 @@
 <Step>
 Choose how to set up the new JumpCloud 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)
 
@@ -208,7 +210,7 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 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 JumpCloud connector to. JumpCloud data should be found on the **Entitlements** and **Accounts** tabs.
@@ -221,7 +223,7 @@
 
 ### What's next?
 
 If JumpCloud is your company's identity provider (meaning that it is used to SSO into other software), the connector sync will automatically create applications in C1 for all of your SCIMed software. Before you move on, review the [Create applications](/product/admin/applications) page for important information about how to set up connectors for the SCIMed apps.
 
 ## Troubleshooting the JumpCloud integration
 

baton/microsoft-entra.mdx

@@ -1,13 +1,13 @@
 ---
 title: "Set up a Microsoft Entra ID connector"
 og:title: "Set up a Microsoft Entra ID connector"
 og:description: "C1 provides identity governance and just-in-time provisioning for Entra ID. Integrate your Entra ID instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 description: "C1 provides identity governance and just-in-time provisioning for Entra ID. Integrate your Entra ID instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 sidebarTitle: "Microsoft Entra ID"
 ---
 
 <Note>
 This page covers the Entra ID **connector**, which syncs and provisions access data for identity governance. It does not control how you sign in to C1. To set up signing in to C1 with your Entra ID account, see [Authenticate with Microsoft](/product/how-to/qs-set-up-c1#authenticate-with-microsoft).
 </Note>
 
 ## Capabilities
@@ -22,13 +22,13 @@
 | Managed identities | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 | Service principal credentials | <Icon icon="square-check" iconType="solid"  color="#c937ae"/> |  |
 
 The Entra ID connector supports [automatic account provisioning and deprovisioning](/product/admin/account-provisioning). 
 
 When a new account is created by C1, the account's password will be sent to a [vault](/product/admin/vaults).
 
 #### Account creation fields
 
 The following fields are available when provisioning a new Entra ID user account:
 
 | Field | Required | Description |
 | :--- | :--- | :--- |
@@ -42,12 +42,12 @@
 | `employeeId` | No | Employee identifier assigned by the organization (max 16 characters) |
 | `jobTitle` | No | The user's job title |
 | `department` | No | The department the user works in |
 | `manager` | No | Manager identifier: Entra object ID (GUID), UPN, or employee ID |
 | `additionalAttributes` | No | JSON object of additional Microsoft Graph user properties (see below) |
 
 If manager resolution fails, the user is still created and a warning is logged.
 
 The `additionalAttributes` field accepts a JSON string containing any writable [Microsoft Graph user property](https://learn.microsoft.com/en-us/graph/api/user-post-users). For example: `{"city":"Springfield","usageLocation":"US","companyName":"SNPP"}`. This field cannot override any of the explicitly named fields listed above.
 
 <Note>
 **Tip:** If you plan to assign licenses to the user (either directly or via a group), include `usageLocation` in `additionalAttributes`. Microsoft requires a usage location before a license can be assigned.
@@ -55,44 +55,46 @@
 
 *Due to limitations of the Microsoft Graph API and Office 365 Exchange Online API, the connector cannot provision Mail Enabled Security groups or Distribution groups using OAuth. 
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ### 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.
 
 | Action name | Additional fields | Description |
 |-------------|-------------------|-------------|
 | enable_user | `user_id` (string, required) | Enables a disabled Microsoft Entra user account |
 | disable_user | `user_id` (string, required) | Disables an active Microsoft Entra user account |
 | update_user | `user_id` (string, required)<br/>`user_profile` (JSON string, required) | Updates user account attributes including profile information, employment details, and contact information |
 | set_manager | `user_id` (string, required)<br/>`manager_identifier` (string, optional) | Sets or updates a user's manager relationship. Accepts manager ID, UPN, or Employee ID. Leave manager_identifier empty to remove the current manager. |
 | check_upn | `proposed_upn` (string, required) | Checks if a User Principal Name (UPN) is available. If taken, finds an available UPN by appending incrementing numbers. |
 | update_profile | `user_id` (string, required)<br/>Plus optional profile fields | Updates user profile attributes including mail, displayName, jobTitle, employeeId, department, companyName, country, and extensionAttribute1 through extensionAttribute15. |
 | create_group | `displayName` (string, required)<br/>`group_type` (string, required): `security` or `microsoft_365`<br/>`mailNickname` (string, optional): auto-generated from display name if omitted<br/>`description` (string, optional)<br/>`isAssignableToRole` (bool, optional): security groups only<br/>`owner` (resource ID, optional): initial group owner<br/>`userMembers` (resource ID list, optional): initial group members | Creates a new Entra ID group. Supports security and Microsoft 365 (unified) group types with assigned membership. Requires the `Group.Create` permission. |
 | revoke_sessions | `user_id` (string, required) | Revokes all active sign-in sessions for a user by invalidating their refresh tokens, forcing re-authentication (`POST /users/{id}/revokeSignInSessions`). Refresh tokens are invalidated immediately, but existing access tokens can remain valid for up to ~1 hour unless Continuous Access Evaluation (CAE) is enabled. Requires the `User.RevokeSessions.All` permission. |
 | revoke_mfa | `user_id` (string, required) | Deletes a user's registered MFA (authentication) methods, forcing re-registration at next sign-in. Lists the user's methods and deletes each deletable one; password methods are skipped. Graph refuses to delete the user's default method while other methods remain (HTTP 400), so MFA may not be fully revocable in one invocation — per-method failures are reported and do not abort the action. Returns `success` (true only if every deletable method was deleted), `deleted_count`, `failed_count`, `skipped_count`, and per-method `results`. Requires the `UserAuthenticationMethod.ReadWrite.All` permission. |
 
 ## Gather Entra ID credentials 
 
 Configuring the connector requires you to pass in credentials generated in Entra ID. Gather these credentials before you move on. 
 
 <Tip>
 If you prefer to set up a cloud-hosted Entra ID connector using OAuth, skip ahead to the **OAuth** tab below.
 </Tip>
 
 <Warning>
 A user with the **Global Administrator** permission in Entra ID must perform this task.
 </Warning>
 
 ### Create a new Entra application 
 <Steps>
 <Step>
 In Entra admin center, navigate to **App registrations**.
 </Step>
 <Step>
 Click **+ New registration**. 
 </Step>
 <Step>
 Give the application a name, such as "C1", and select the supported account type relevant to your Entra installation. You do not need to set a redirect URL. 
 </Step>
 <Step>
 Click **Register**. 
@@ -116,7 +118,7 @@
 The client secret is generated. Carefully copy and save the **Secret Value**.  
 </Step>
 </Steps>
 ### Give the new Entra app API permissions
 <Steps>
 <Step>
 Click **API permissions**.
@@ -172,9 +174,9 @@
    User.EnableDisableAccount.All 
    ```
 
    To set or rotate passwords for non-admin users, the app requires, in addition to the stated permissions, a privileged role such as Helpdesk Administrator or Password Administrator. **To set or rotate passwords for users with admin roles, the app must be assigned Privileged Authentication Administrator (or Global Administrator).**
 
    To deprovision users who have a privileged role assigned to them, the app requires, in addition to the stated permissions, a privileged role such as Global Administrator or Privileged Authentication Administrator.
 
    <Note>
    **Optional:** To enable group management (creating groups via connector actions), add the following permission in addition to the provisioning permissions above:
@@ -187,7 +189,7 @@
    </Note>
 
    <Note>
    **Optional:** To enable the offboarding connector actions (`revoke_sessions` and `revoke_mfa`), add the following permissions in addition to the provisioning permissions above:
 
    ```bash
    User.RevokeSessions.All
@@ -218,14 +220,14 @@
 ## Optional: Configure Exchange groups provisioning with client secret-based auth
 
 <Note>
 This section requires assigning the **Exchange Administrator** role to the connector's app registration. This is required because distribution lists and mail-enabled security groups are Exchange-only objects — Microsoft Graph API has no support for managing them, so the Exchange Online admin API (the same mechanism used by Exchange Online PowerShell) is the only Microsoft-supported path. If you'd rather not grant this role, you can skip this section: the rest of the connector (users, Entra ID groups, licenses, and so on) will keep working normally — you just won't get provisioning for Exchange distribution lists and mail-enabled security groups.
 </Note>
 
 To set up the connector to support provisioning owners and members to Exchange groups, which are distribution lists and mail-enabled security groups, follow these steps:
 
 <Steps>
 <Step>
 In the Microsoft Entra Admin Center, navigate to **App registrations** and click the name of the app you created for this connector. 
 </Step>
 <Step>
  In the application dashboard, click **API permissions** > **Add a permission**. 
@@ -268,13 +270,13 @@
 </Steps>
 **Done.** Your connector is now ready to allow the provisioning of users as owners and members in Exchange groups.
 
 ## Configure the Entra ID connector
 
 <Warning>
 To complete this task, you'll need:
 
 - The **Connector Administrator** or **Super Administrator** role in C1
 - Access to the set of Entra ID credentials generated by following the instructions above
 </Warning>
 
 <Tabs>
@@ -288,9 +290,9 @@
 Search for **Entra ID** and click **Add**. 
 </Step>
 <Step>
 Choose how to set up the new Entra ID 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)
 
@@ -311,30 +313,30 @@
 Select **Client secret**.
 </Step>
 <Step>
 Paste the tenant ID into the **Entra tenant ID** field.
 </Step>
 <Step>
 Paste the client ID into the **Entra client ID** field.
 </Step>
 <Step>
 Paste the client secret into the **Entra client secret** field.
 </Step>
 <Step>
 **Optional.** Check the box if you want to **Skip syncing Active Directory Server groups**.
 </Step>
 <Step>
 **Optional.** If you enabled **Skip syncing Active Directory Server groups** in the previous step, you can also enable **Include on-premises users in cloud group memberships**. This keeps on-premises synced users as members of cloud-native Entra groups. See [Hybrid AD configuration](#hybrid-ad-configuration) below for details. This setting has no effect if **Skip syncing Active Directory Server groups** is disabled.
 </Step>
 <Step>
 **Optional** If you connect to a Microsoft Graph API domain other than graph.microsoft.com, specify your domain in the **Microsoft Graph domain** field.
 </Step>
 <Step>
 **Optional.** To capture Entra usage data, click to enable **Fetch user sign-in activity**.
 
    The usage data feature requires a Microsoft Entra ID P1 or P2 license. Usage data collection is not supported on Microsoft Entra ID Free licenses.
 </Step>
 <Step>
 **Optional.** Click to opt into **Schedule SCIM provisioning**, which forces an Entra SCIM sync when a new entitlement is provisioned for a user in C1.
 </Step>
 <Step>
 **Optional.** Click to **Disable resource changed event feed**. These logs are enabled by default.
@@ -356,7 +358,7 @@
 The connector's label changes to **Syncing**, followed by **Connected**. You can view the logs to ensure that information is syncing.
 </Step>
 </Steps>
 **Done.** Your Entra ID connector is now pulling access data into C1.
 </Tab>
 
 <Tab title="Certificate">
@@ -368,12 +370,12 @@
 In C1, navigate to **Integrations** > **Connectors** and click **Add connector**.
 </Step>
 <Step>
 Search for **Entra ID** and click **Add**.
 </Step>
 <Step>
 Choose how to set up the new Entra ID 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)
 
@@ -394,7 +396,7 @@
 Select **Certificate**.
 </Step>
 <Step>
 Paste the tenant ID into the **Entra tenant ID** field.
 </Step>
 <Step>
 Paste the client ID into the **Client ID** field.
@@ -409,18 +411,18 @@
 **Optional.** Check the box if you want to **Skip syncing Active Directory Server groups**.
 </Step>
 <Step>
 **Optional.** If you enabled **Skip syncing Active Directory Server groups** in the previous step, you can also enable **Include on-premises users in cloud group memberships**. This keeps on-premises synced users as members of cloud-native Entra groups. See [Hybrid AD configuration](#hybrid-ad-configuration) below for details. This setting has no effect if **Skip syncing Active Directory Server groups** is disabled.
 </Step>
 <Step>
 **Optional.** If you connect to a Microsoft Graph API domain other than graph.microsoft.com, specify your domain in the **Microsoft Graph domain** field.
 </Step>
 <Step>
 **Optional.** To capture Entra usage data, click to enable **Fetch user sign-in activity**.
 
    The usage data feature requires a Microsoft Entra ID P1 or P2 license. Usage data collection is not supported on Microsoft Entra ID Free licenses.
 </Step>
 <Step>
 **Optional.** Click to opt into **Schedule SCIM provisioning**, which forces an Entra SCIM sync when a new entitlement is provisioned for a user in C1.
 </Step>
 <Step>
 **Optional.** Click to **Disable resource changed event feed**. These logs are enabled by default.
@@ -442,7 +444,7 @@
 The connector's label changes to **Syncing**, followed by **Connected**. You can view the logs to ensure that information is syncing.
 </Step>
 </Steps>
 **Done.** Your Entra ID connector is now pulling access data into C1.
 </Tab>
 
 <Tab title="OAuth">
@@ -457,9 +459,9 @@
 Search for **Entra ID** and click **Add**. 
 </Step>
 <Step>
 Choose how to set up the new Entra ID 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)
 
@@ -480,24 +482,24 @@
 Select **OAuth**. 
 </Step>
 <Step>
 Specify the ID of the Entra tenant you're integrating in the **Entra tenant ID** field. 
 </Step>
 <Step>
 **Optional.** Check the box if you want to **Skip syncing Active Directory Server groups**.
 </Step>
 <Step>
 **Optional.** If you enabled **Skip syncing Active Directory Server groups** in the previous step, you can also enable **Include on-premises users in cloud group memberships**. This keeps on-premises synced users as members of cloud-native Entra groups. See [Hybrid AD configuration](#hybrid-ad-configuration) below for details. This setting has no effect if **Skip syncing Active Directory Server groups** is disabled.
 </Step>
 <Step>
 **Optional** If you connect to a Microsoft Graph API domain other than graph.microsoft.com, specify your domain in the **Microsoft Graph domain** field.
 </Step>
 <Step>
 **Optional.** To capture Entra usage data, click to enable **Fetch user sign-in activity**.
 
    The usage data feature requires a Microsoft Entra ID P1 or P2 license. Usage data collection is not supported on Microsoft Entra ID Free licenses.
 </Step>
 <Step>
 **Optional.** Click to opt into **Schedule SCIM provisioning**, which forces an Entra SCIM sync when a new entitlement is provisioned for a user in C1.
 </Step>
 <Step>
 **Optional.** Click to **Disable resource changed event feed**. These logs are enabled by default.
@@ -516,7 +518,7 @@
 Click **Login with OAuth**. 
 </Step>
 <Step>
 Log in and authorize C1 with your Entra ID instance.
 
    In order for the integration to work properly, you must consent to all permissions. 
 </Step>
@@ -526,7 +528,7 @@
 
 <Steps>
 <Step>
 In the Entra ID control panel, navigate to **Enterprise Applications**.
 </Step>
 <Step>
 Click the **C1 Integration** app (not to be confused with the **C1 SSO** app, which is used to log into C1, not to synchronize your data).
@@ -545,7 +547,7 @@
 
 <Steps>
 <Step>
 Return to the Entra ID integration in C1 by clicking the **Entra ID** tile on the **Integrations** page.
 </Step>
 <Step>
 Click the **Entra ID** connector link that shows today's date in the **Connected on** column.
@@ -555,11 +557,11 @@
 </Step>
 </Steps>
 
 **Done.** Your Entra ID connector is now pulling access data into C1.
 </Tab>
 
 <Tab title="Self-hosted">
 **Follow these instructions to use the Entra ID 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.
 
@@ -567,7 +569,7 @@
 
 * [Official download center](https://dist.conductorone.com/ConductorOne/baton-microsoft-entra): For stable binaries (Windows/Linux/macOS) and container images.
 
 ### Step 1: Set up a new Entra ID connector
 <Steps>
 <Step>
 In C1, navigate to **Integrations** > **Connectors** > **Add connector**.
@@ -576,9 +578,9 @@
 Search for **Baton** and click **Add**.
 </Step>
 <Step>
 Choose how to set up the new Entra ID 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)
 
@@ -603,7 +605,7 @@
 </Steps>
 ### Step 2: Create Kubernetes configuration files
 
 Create two Kubernetes manifest files for your Entra ID connector deployment:
 
 #### Secrets configuration
 
@@ -691,23 +693,23 @@
 ### Step 3: Deploy the connector
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files. 
 </Step>
 <Step>
 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 Entra ID connector to. Entra ID data should be found on the **Entitlements** and **Accounts** tabs.
 </Step>
 </Steps>
 **Done.** Your Entra ID connector is now pulling access data into C1.
 </Tab>
 </Tabs>
 
 ## Hybrid AD configuration
 
 Organizations that use Microsoft Entra Connect to sync on-premises Active Directory with Entra ID have a mix of cloud-native and on-premises synced objects. The connector provides two settings to control how these are handled:
 
 ### Skip Active Directory Server groups (`--skip-ad-groups` / `BATON_SKIP_AD_GROUPS`)
 
 When enabled, the connector excludes groups that originate from on-premises Active Directory (where `onPremisesSyncEnabled` is `true`). Only cloud-native Entra groups are synced.
 
 By default, this also filters out on-premises synced users from the membership lists of cloud groups. This means that if a cloud group contains both cloud-native and on-premises synced users, only the cloud-native members will appear as grants.
 
@@ -720,7 +722,7 @@
 - On-premises AD **groups** are still skipped (not synced)
 - On-premises synced **users** who are members of cloud groups are included in those groups' membership grants
 
 This is useful in hybrid environments where cloud-native Entra groups contain a mix of cloud and on-premises synced users, and you want full visibility into who has access to what through those cloud groups.
 
 <Warning>
 This setting has no effect unless **Skip Active Directory Server groups** is also enabled. When **Skip Active Directory Server groups** is disabled, all groups and all their members are synced regardless of this setting.
@@ -728,7 +730,7 @@
 
 ### What's next?
 
 If Entra ID is your company's identity provider (meaning that it is used to SSO into other software), the integration sync will automatically create applications in C1 for all of your SCIMed software. Before you move on, review the [Create applications](/product/admin/applications) page for important information about how to set up integrations with the SCIMed apps.
 
 
 

baton/okta.mdx

@@ -1,17 +1,17 @@
 ---
 title: "Set up an Okta connector"
 og:title: "Set up an Okta connector"
 description: "C1 provides identity governance and just-in-time provisioning for Okta. Integrate your Okta instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 og:description: "C1 provides identity governance and just-in-time provisioning for Okta. Integrate your Okta instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 sidebarTitle: "Okta"
 ---
 
 <Tip>
 **This is an updated and improved version of the Okta connector!** If you're setting up Okta with C1 for the first time, you're in the right place.
 </Tip>
 
 <Note>
 This page covers the Okta **connector**, which syncs and provisions access data for identity governance. It does not control how you sign in to C1. To set up signing in to C1 with your Okta account, see [Authenticate with Okta](/product/how-to/qs-set-up-c1#authenticate-with-okta).
 </Note>
 
 ## Capabilities
@@ -33,72 +33,72 @@
 </Note>
 
 <Note>
 **Resource sets and resource set bindings require Sync Custom Roles.** These two resource types model Okta's custom-role machinery: a resource set is the collection of Okta objects a custom role applies to, and a binding pairs a resource set with a custom role. Granting a binding assigns a user or group to that custom role over that resource set. Both are synced and provisioned only when **Sync Custom Roles** is enabled.
 </Note>
 
 <Note>
 The standard roles **Workflows Administrator**, **Access Certifications Administrator**, and **Access Requests Administrator** appear as Custom Roles in C1. Enable **Sync Custom Roles** to see them. The Okta API returns these roles through the same endpoint as custom roles.
 </Note>
 
 <Note>
 Synced groups expose their source type on the resource profile as **`type`**. Today, Okta defines three values:
 
 - **`OKTA_GROUP`** — a group created and managed natively in Okta.
 - **`APP_GROUP`** — a push group created when a SCIM-integrated app mirrors its groups into Okta.
 - **`BUILT_IN`** — a system group provided by Okta (these are also marked immutable).
 
 The connector surfaces whatever value Okta returns, so any future group types Okta introduces will appear here verbatim.
 
 Use this attribute in policies and access profiles to verify that bindings and grants reference the intended kind of group, especially when an Okta-native group and an app push group share the same name.
 </Note>
 
 <Note>
 **Continuous sync via event feed.** In addition to scheduled full syncs, the Okta connector polls Okta's system log for near-real-time changes and applies them between syncs ([continuous sync](/baton/faq#syncing)). This works with either authentication method. Event feed coverage varies by resource type:
 
 | Resource | Events captured |
 | :--- | :--- |
 | Accounts | Lifecycle changes: create, activate, deactivate, suspend, unsuspend, reactivate, profile updates |
 | Groups | Membership changes: group creation, user membership add/remove |
 | Applications | Lifecycle and membership changes: create, update, activate, user membership add/remove |
 | Roles | Membership changes: role grant/revoke via privilege events |
 </Note>
 
 The Okta connector supports [automatic account provisioning](/product/admin/account-provisioning).
 
 The Okta connector supports account deprovisioning through C1 resource deletion. It first deactivates the user to the `DEPROVISIONED` state and then permanently deletes the user. The same operations are available separately through the `deactivate_user` and `delete_user` connector actions. These operations require an API token or OAuth app with `okta.users.manage` scope.
 
 #### Account creation profile fields
 
 When you configure account provisioning for Okta, C1 shows the following optional fields on the account creation form (in addition to first name, last name, email, and login):
 
 | Field | Values | Default | What it does |
 | :--- | :--- | :--- | :--- |
 | **Password Change Required on Login** | `True` / `False` | Off | When creating an account with a random password, requires the user to change that password on first login. |
 | **Create Inactive** | `True` / `False` | Off | Creates the user in Okta as staged (inactive) without activating them. |
 | **Send Activation Email** | `True` / `False` | `True` | When set to `False`, activates the user without sending Okta's activation email. Use this when C1 (or another system) owns user communication. |
 | **Provider Type** | `OKTA` / `FEDERATION` | Okta's default (local) provider | Set to `FEDERATION` to create a federated user with no local Okta password. Common in hub-and-spoke / Org2Org designs where the hub IdP owns credentials. |
 | **Additional Attributes** | Map of Okta profile keys | — | Extra Okta profile attributes (standard or custom schema) to set on the user. |
 
 <Note>
 **Provider Type** `FEDERATION` cannot be combined with a random-password credential option (federated users have no Okta password). **Send Activation Email** `False` cannot be combined with **Password Change Required on Login** `True` when creating with a random password (that combination cannot set Okta's change-password-on-login flag). With a no-password credential option, Password Change Required on Login has no effect and does not conflict. If **Create Inactive** is `True`, the connector leaves the user staged and does not run the activation step — Create Inactive takes precedence over Send Activation Email.
 </Note>
 
 <Note>
 **Okta Staged status (sign-in to Okta, not C1).** In Okta, **Staged** means the account was created but not activated yet, so the user cannot sign in to Okta. That is an Okta lifecycle state — it is not about signing in to ConductorOne. Staged users sync as **disabled** in C1 so sync matches the lifecycle actions: `disable_user` is a no-op on staged accounts, and `enable_user` activates them (`/lifecycle/activate` without sending another activation email). After activation the account becomes **Active** or **Provisioned** (Provisioned only means they have not completed first login yet).
 
 Default **Create Account** does not leave users staged: the connector activates them or sends Okta's activation email. Users stay staged only when **Create Inactive** is `True`, an Okta admin created them without activating, or an incomplete create left them there. The raw Okta status string stays on the resource details, so Staged remains distinguishable from Suspended or Deprovisioned. After you upgrade a connector that previously reported staged users as enabled, the next sync flips those resources to disabled — review any automations that key off user enabled/disabled status.
 </Note>
 
 <Note>
 **Recovering an account left staged by an interrupted create.** With **Send Activation Email** set to `False`, account creation spans several calls, so a failure partway through can leave the Okta user created but not activated.
 
 Retrying the same create does not finish the job. Okta rejects the duplicate login, the connector returns the account it found, and the user stays **Staged** — a staged account left behind this way is indistinguishable from one created deliberately with **Create Inactive**.
 
 Run the `enable_user` action against the account to finish activating it.
 </Note>
 
 <Note>
 **A deprovisioned login cannot be reused by Create Account.** If the login you are creating already belongs to a **Deprovisioned** (deactivated) Okta account, the create fails with an error instead of returning that account. The connector cannot reactivate a deprovisioned user, so returning it would hand back an account that can never be used. Reactivate the user directly in Okta, or delete and recreate the account, to reuse the login.
 </Note>
 
 <Note>
@@ -109,50 +109,52 @@
 
 [This connector can sync secrets](/product/admin/inventory) and display them on the **Inventory** page. 
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ### Connector actions
 
 Connector actions are custom capabilities that extend C1 automations with app-specific operations. The Okta connector's actions are reached from **two different automation steps**, and which step offers an action is determined by the action itself — you cannot choose:
 
 | Automation step | Actions offered | How the target is selected |
 |-----------------|-----------------|----------------------------|
 | [Perform connector action](/product/admin/automations-steps-reference#perform-connector-action) | `deactivate_user`, `delete_user`, `create`, `modify_group` | Varies by action. The two user actions use a resource selector on the **User** resource type. `modify_group` takes the Okta group ID as a plain text field, and `create` has no target at all. |
 | Account lifecycle action | `enable_user`, `disable_user` | The step's own **Target account** selector — either the account in context or a specific account. |
 
 In the Perform connector action step, actions are listed under their resource type and display name rather than their raw action name: `deactivate_user` and `delete_user` appear as **`user - Deactivate User`** and **`user - Delete User`**, and `modify_group` as **`group - Modify Group`**. An action with no display name registered falls back to its raw name, so `create` appears as **`group - create`**.
 
 `enable_user` and `disable_user` take `user_id` as a plain string, and `modify_group` takes `group_id` the same way. Pass the raw Okta ID (for example `00u1abc2def3GHI4jk5`), not the C1 resource ID — the connector sends the value to Okta unchanged, and a C1 resource ID returns a not-found error. `deactivate_user` and `delete_user` take a resource selector instead, so the Okta ID is resolved for you.
 
 | Action name | Additional fields | Description |
 |-------------|-------------------|-------------|
 | enable_user | `user_id` (string, required) | Enables an Okta user account: unsuspends a suspended account, and activates a staged one without sending an activation email. Returns success without calling Okta when the account is already enabled. Does **not** reactivate a deactivated (`DEPROVISIONED`) account — that returns an error. Okta's activate API can do that transition, but this action treats reactivation of a deactivated user as a separate decision from enable. |
 | disable_user | `user_id` (string, required) | Suspends an Okta user account. Returns success without calling Okta when the account is already suspended, deactivated, or still staged. |
 | deactivate_user | `user_id` (Okta user resource, required) | Destructively deprovisions the selected user from assigned applications and leaves the Okta user record in `DEPROVISIONED`. A user already in that state succeeds without another mutation. |
 | delete_user | `user_id` (Okta user resource, required) | Ensures the selected user is deactivated, then permanently deletes the user. A user that is already absent succeeds so workflow retries are safe. |
 | update_profile | `user_id` (resource ID, required), 18 optional profile fields (`login`, `email`, `secondEmail`, `firstName`, `lastName`, `middleName`, `displayName`, `title`, `department`, `division`, `organization`, `employeeNumber`, `costCenter`, `userType`, `primaryPhone`, `mobilePhone`, `countryCode`, `managerId`), `additionalAttributes` (map) | Updates an existing Okta user's profile attributes. At least one profile field must be provided. |
 | update_user | `user_id` (string, required), `user_profile` (JSON object, required) | Updates a user's profile from a JSON object of Okta profile attributes — accepts any attribute, not limited to update_profile's curated list. This is the action C1's automated profile-push pipeline uses. |
 | create | `name` (string, required), `description` (string), `userMembers` (resource ID list) | Creates a new Okta group with optional initial members |
 | modify_group | `group_id` (string, required), `name` (string), `description` (string) | Updates the name and/or description of an existing Okta group. Returns success without calling the Okta API if the supplied values already match the group's current name and description (idempotent). |
 
 <Note>
 `update_user` (global action, takes `user_profile` as a JSON object) is the action required for C1's automated profile-push pipeline — a push rule that syncs Okta profile fields specifically looks up this global action shape. `update_profile` (resource-scoped, individual typed fields) is for manual/UX invocation from a workflow step; it does not satisfy the push-rule lookup on its own. Named profile fields and `user_profile` JSON keys use Okta's camelCase attribute names (e.g. `firstName`, not `first_name`).
 </Note>
 
 <Warning>
 `deactivate_user`, `delete_user`, and C1 account deprovisioning are destructive. Deactivation removes the user's assigned-app provisioning and can destroy downstream data such as email or files. Deletion permanently removes the Okta user and cannot be recovered. Use workflow approval gates where appropriate.
 </Warning>
 
 <Note>
 `disable_user` is not an alias for deactivation: it suspends sign-in while retaining group and application assignments, and `enable_user` can reverse it. Use `deactivate_user` only when the workflow intends Okta deprovisioning, and `delete_user` only when it intends permanent removal.
 </Note>
 
 <Note>
 `deactivate_user` is **not** available from the Account lifecycle action step — that step offers only `enable_user` and `disable_user`. An existing offboarding automation built on Account lifecycle action therefore reaches Okta *suspend*, not deprovision. To deprovision from a workflow, add a **Perform connector action** step and select `user - Deactivate User`.
 </Note>
 
 <Note>
 **`enable_user` does not clear a credential problem.** Okta treats **Recovery**, **Password expired**, and **Locked out** as enabled statuses — the account exists and is not suspended, it just cannot complete a sign-in. `enable_user` reports those accounts as already enabled and makes no call to Okta, so it neither unlocks the account nor resets the password.
 
 Clear these in Okta, or with a password-reset or unlock flow. `enable_user` covers only the two transitions it names: unsuspending a **Suspended** account and activating a **Staged** one.
 </Note>
 
 <Note>
@@ -162,23 +164,23 @@
 baton-okta --api-token $BATON_API_TOKEN --domain $BATON_DOMAIN --delete-resource "<okta-group-id>" --delete-resource-type "group"
 ```
 
 Use the raw Okta external ID (e.g. `00g1abc2def3GHI4jk5`), not the C1 resource ID. Group deletion is not available through the C1 UI or the Automations tab.
 </Note>
 
 ## Authentication methods
 
 The Okta connector supports two authentication methods:
 
 | Method | Description | Best for |
 | :--- | :--- | :--- |
 | **API Token** | Uses an Okta API token tied to an admin account | Quick setup, broad access |
 | **OAuth 2.0 Private Key** | Uses an Okta OIDC app with client credentials flow | Least-privilege scopes, short-lived tokens, easier credential rotation |
 
 The **OAuth 2.0 Private Key** method is recommended for production environments because it provides scoped access with short-lived tokens rather than a long-lived API token.
 
 ## Gather Okta credentials 
 
 Configuring the connector requires you to pass in credentials generated in Okta. Gather these credentials before you move on.
 
 ### API token permissions and C1 capabilities
 
@@ -191,24 +193,24 @@
 | Review application assignment    | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>              | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>                                  | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>          |
 | Provision application assignment |                      | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>                                  | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>          |
 | Review admin roles               | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>   |                                          | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>          |
 | Create Okta group (action)       |                      | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>                                  | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>          |
 | Modify Okta group (action)       |                      | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>                                  | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>          |
 | Delete Okta group                |                      | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>                                  | <Icon icon="square-check" iconType="solid"  color="#c937ae"/>          |
 
 To learn more about Okta roles, visit [the Okta documentation on administrator roles and permissions](https://help.okta.com/en/prod/Content/Topics/Security/administrators-admin-comparison.htm). 
 
 <Tip>
 The **Custom Read-Only Admin Role** provides the minimum permissions required to read admin role assignments in Okta.
 This role is necessary when admin roles are assigned to Okta groups. Without it, the connector will fail during synchronization if it encounters a group that's assigned to an admin role, as it won't have permission to read the group's membership.
 </Tip>
 
 ### (Optional) Create a custom read-only admin role
 
 To give the C1 integration limited read-only admin permissions, create a custom Okta admin role and resource set and assign them to the admin you'll use to generate the API key. 
 
 <Steps>
 <Step>
 In Okta, log in to the Admin Dashboards and navigate to **Security** > **Administrators** > **Roles**.
 </Step>
 <Step>
 Click **Create new role**.
@@ -255,7 +257,7 @@
 
 ### (Optional) Create a service account for the API token
 
 If desired, you can create a service account user in Okta that has the permissions for the API token.
 
 <Steps>
 <Step>
@@ -271,7 +273,7 @@
 Click **Save**.
 
    <Tip>
    At this point, if you've created a custom read-only role, stop here and return to the instructions above. If you're using a standard Okta admin role, continue on.
    </Tip>
 </Step>
 <Step>
@@ -293,17 +295,17 @@
 We strongly recommend creating a dedicated token for the C1 integration so you can manage the token's lifespan and control per-token rate limits. 
 
 <Tip>
 When **creating** an API token, Okta assigns the permissions of the _currently logged-in user_ to the token. If, for example, you wish to use a Read Only Admin-scoped API token, you must log in to Okta as a user with the Read Only Admin role assigned.
 </Tip>
 
 <Steps>
 <Step>
 Log into Okta with the account you'll use to generate the API token.
 
    The account must have **Super Administrator,** the custom read-only role you created above, or a combination of **Read Only/App Admin/Group Admin** privileges. The permissions on the API token affects what features and functionality are available from C1. Before you begin, review the chart in [API permissions and C1 capabilities](/baton/okta#api-token-permissions-and-conductorone-capabilities) to make sure you're creating a token with the right permissions for your needs.
 </Step>
 <Step>
 In the Okta console, navigate to **Security > API** and click **Tokens**.
 </Step>
 <Step>
 Click **Create Token**.
@@ -324,7 +326,7 @@
 
 <Steps>
 <Step>
 In Okta, navigate to **Applications** > **Applications** and click **Create App Integration**.
 </Step>
 <Step>
 Select **API Services** and click **Next**.
@@ -339,14 +341,14 @@
 In the **Client Credentials** section, select **Public key / Private key** as the client authentication method.
 
 <Note>
 **Leave the DPoP setting at its default.** The connector supports Demonstrating Proof of Possession (DPoP), so you do not need to change the **Proof of Possession** option — whether **"Require Demonstrating Proof of Possession (DPoP) header in token requests"** is checked (Okta's default for new API Services apps) or unchecked, the connector authenticates successfully. If you disabled DPoP for an existing app on the advice of an earlier version of this page, you can safely re-enable it.
 </Note>
 </Step>
 <Step>
 Click **Add Key**, then either generate a new key pair or paste your own public key. Save the private key securely — you'll need it when configuring the connector.
 
 <Note>
 After clicking **Add Key**, click **Done** in the key dialog **and then click Save** in the outer Client Credentials panel. Okta's UI requires both clicks; missing the outer Save silently discards the key and the connector will fail with `"The client does not have a JWKSet configured, but the client_assertion requires one"`.
 </Note>
 </Step>
 <Step>
@@ -363,14 +365,14 @@
    - `okta.devices.read` (required when the **Device** resource type is enabled)
 
 <Note>
 After clicking **Grant** for each scope, refresh the page and visually verify that all granted scopes appear under "Granted scopes." Okta's API Services app config can silently discard incomplete saves. If scopes are missing, the connector will fail with `"You are not allowed any of the requested scopes"`.
 </Note>
 </Step>
 <Step>
 Navigate to the **Admin Roles** tab and assign an appropriate admin role to the app (e.g., **Super Administrator** or a custom role with the permissions you need).
 
 <Note>
 **This step is required, and skipping it does not always produce an error.** Granting OAuth scopes is not sufficient on its own — the scopes are present in the token, but Okta still evaluates the app's admin role when serving each request.
 
 Without an admin role assignment, and even when all OAuth scopes are granted correctly:
 
@@ -390,16 +392,16 @@
 - **PKCS#1** — header line `-----BEGIN RSA PRIVATE KEY-----`
 - **PKCS#8** — header line `-----BEGIN PRIVATE KEY-----` (what OpenSSL 3.0+ produces by default)
 
 The key must be RSA. Okta's DPoP implementation does not accept elliptic-curve keys, and the connector rejects an EC key with `"Okta DPoP requires RSA"`.
 </Note>
 
 ## Configure the Okta connector
 
 <Warning>
 To complete this task, you'll need:
 
 - The **Connector Administrator** or **Super Administrator** role in C1
 - Access to the set of Okta credentials generated by following the instructions above
 </Warning>
 
 <Tabs>
@@ -414,9 +416,9 @@
 Search for **Okta v2** and click **Add**.
 </Step>
 <Step>
 Choose how to set up the new Okta 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)
 
@@ -437,13 +439,13 @@
 Select your authentication method: **API Token** or **OAuth 2.0 Private Key**.
 </Step>
 <Step>
 Enter your Okta domain hostname, e.g. `<YOUR DOMAIN>.okta.com`, into the **Okta domain** field. The `https://` prefix is optional.
 </Step>
 <Step>
 Enter your credentials:
 
    - For **API Token**: paste your API token into the **API token** field.
    - For **OAuth 2.0 Private Key**: enter your **Okta Client ID**, **Okta Private Key ID**, and paste the **Okta Private Key** (PEM-encoded).
 </Step>
 <Step>
 **Optional.** If desired, click the checkbox to **Sync custom roles**.
@@ -452,10 +454,10 @@
 **Optional.** If desired, click the checkbox to **Skip secondary emails** when syncing user information.
 </Step>
 <Step>
 **Optional.** If desired, click the checkbox to **Skip app groups** to exclude Okta push groups (APP\_GROUP type) from sync. This is useful when push groups created by SCIM-integrated apps are not needed for access management workflows.
 </Step>
 <Step>
 **Optional.** Inactive (disabled) Okta applications are synced by default. Clear the **Sync inactive apps** checkbox to exclude them.
 </Step>
 <Step>
 **Optional.** Enable **Sync secrets** to display them on the [Inventory page](/product/admin/inventory).
@@ -471,11 +473,11 @@
 </Step>
 </Steps>
 
 **Done.** Your Okta connector is now pulling access data into C1.
 </Tab>
 
 <Tab title="Self-hosted">
 **Follow these instructions to use the Okta 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.
 
@@ -485,7 +487,7 @@
 
 * [GitHub repository](https://github.com/conductorone/baton-okta): Access the source code, report issues, or contribute to the project.
 
 ### Step 1: Set up a new Okta connector
 
 <Steps>
 <Step>
@@ -495,9 +497,9 @@
 Search for **Baton** and click **Add**.
 </Step>
 <Step>
 Choose how to set up the new Okta 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)
 
@@ -523,7 +525,7 @@
 
 ### Step 2: Create Kubernetes configuration files
 
 Create two Kubernetes manifest files for your Okta connector deployment:
 
 #### Secrets configuration
 
@@ -593,17 +595,17 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 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 Okta connector to. Okta data should be found on the **Entitlements** and **Accounts** tabs.
 </Step>
 </Steps>
 
 **Done.** Your Okta connector is now pulling access data into C1.
 </Tab>
 </Tabs>
 
 ### What's next?
 
 If Okta is your company's identity provider (meaning that it is used to SSO into other software), the connector sync will automatically create applications in C1 for all of your SCIMed software. Before you move on, review the [Create applications](/product/admin/applications) page for important information about how to set up connectors for the SCIMed apps.

baton/onelogin.mdx

@@ -2,7 +2,7 @@
 title: "Set up an OneLogin connector"
 og:title: "Set up an OneLogin connector"
 description: "C1 provides identity governance and just-in-time provisioning for OneLogin. Integrate your OneLogin instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 og:description: "C1 provides identity governance and just-in-time provisioning for OneLogin. Integrate your OneLogin instance with C1 to run user access reviews (UARs), enable just-in-time access requests, and automatically provision and deprovision access."
 sidebarTitle: "OneLogin"
 ---
 
@@ -27,6 +27,8 @@
 
 *You can opt into syncing privilege data; this is not synced by default. 
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ## Gather OneLogin credentials 
 
 Configuring the connector requires you to pass in credentials generated in OneLogin. Gather these credentials before you move on. 
@@ -121,7 +123,7 @@
 <Step>
 Choose how to set up the new OneLogin 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)
 
@@ -184,7 +186,7 @@
 <Step>
 Choose how to set up the new OneLogin 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)
 
@@ -277,7 +279,7 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
 </Step>
 <Step>
 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 OneLogin connector to. OneLogin data should be found on the **Entitlements** and **Accounts** tabs.
@@ -290,5 +292,5 @@
 
 ### What's next?
 
 If OneLogin is your company's identity provider (meaning that it is used to SSO into other software), the connector sync will automatically create applications in C1 for all of your SCIMed software. Before you move on, review the [Create applications](/product/admin/applications) page for important information about how to set up connectors for the SCIMed apps.
 

baton/openai.mdx

@@ -2,7 +2,7 @@
 title: "Set up OpenAI connector"
 og:title: "Set up OpenAI connector"
 description: "C1 provides identity governance and just-in-time provisioning for OpenAI. Integrate your OpenAI instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 og:description: "C1 provides identity governance and just-in-time provisioning for OpenAI. Integrate your OpenAI instance with C1 to run user access reviews (UARs) and enable just-in-time access requests."
 sidebarTitle: "OpenAI"
 ---
 
@@ -31,6 +31,8 @@
 * Organization custom roles (dynamic, fetched per organization)
 * Project custom roles (dynamic, fetched per project)
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 <Note>
 **Group member listing requires a paid plan.** Listing group members and syncing group-inherited role grants requires a Business, Enterprise, or higher OpenAI plan. Free plan accounts will not have group membership grants synced.
 </Note>
@@ -178,7 +180,7 @@
   </Step>
   <Step>
   Choose how to set up the new OpenAI 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
   </Step>
@@ -227,7 +229,7 @@
   </Step>
   <Step>
   Choose how to set up the new OpenAI 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
   </Step>
@@ -311,7 +313,7 @@
 
 <Steps>
   <Step>
   Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files.
   </Step>
   <Step>
   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 OpenAI connector to. OpenAI data should be found on the **Entitlements** and **Accounts** tabs.

baton/salesforce.mdx

@@ -1,8 +1,8 @@
 ---
 title: Set up a Salesforce connector
 og:title: Set up a Salesforce connector - C1 docs
 og:description: Integrate your Salesforce instance with C1 to run user access reviews, enable just-in-time access requests, and easily provision and deprovision access.
 description: C1 provides identity governance for Salesforce. Integrate your Salesforce instance with C1 to run user access reviews (UARs) and enable just-in-time access requests.
 sidebarTitle: "Salesforce"
 ---
 
@@ -34,27 +34,29 @@
 
 The Salesforce connector supports [automatic account provisioning](/product/admin/account-provisioning).
 
 This connector does not support account deprovisioning. You must deprovision accounts directly in Salesforce.
 
 **Territories require Enterprise Territory Management 2.0 to be enabled in your Salesforce org. If this feature is not enabled, the connector will return an error when attempting to sync territories.**
 
 ***Agents (Agentforce agents and Einstein Bots, backed by the `BotDefinition` object) are opt-in and disabled by default. Enable the Agent resource type in C1 to sync them. Agentforce or Einstein Bots must be enabled in your Salesforce org; otherwise the connector skips agents cleanly.**
 
 ### Optional fields for custom validation rules
 
 Some Salesforce orgs have custom validation rules that require additional fields to be set when creating a user (for example, a rule that requires `FederationIdentifier` for SSO).
 
 To add an optional field mapping in C1, use the exact Salesforce field API name as the mapping key (for example, `FederationIdentifier`, `Department`, `CommunityNickname`) allowing you to satisfy any validation rule.
 
 *You have the option to sync user accounts that use non-standard licenses. 
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ### 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.
 
 | Action name | Additional fields | Description |
 |-------------|-------------------|-------------|
 | update_user_status | `resource_id` (string, required) <br/>`is_active` (Boolean, required) | Updates a Salesforce user's status to active or inactive |
 
 ## Gather Salesforce credentials 
 
@@ -135,7 +137,7 @@
 <Step>
 Expand **OAuth Settings** and configure the following:
 - **Callback URL**: enter any valid URL
 - **Selected OAuth Scopes**: add **Full access (full)**, **Manage user data via APIs (api)**, and **Perform requests at any time (refresh_token, offline_access)**
 - Under **Flow Enablement**, check **Enable JWT Bearer Flow**. A **Certificate Upload** field will appear — upload your certificate (`.pem`). You will need the corresponding private key (`.pem`) later when configuring the connector.
 </Step>
 <Step>
@@ -225,7 +227,7 @@
 <Step>
 Choose how to set up the new Salesforce 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)
 
@@ -348,7 +350,7 @@
 <Step>
 Choose how to set up the new Salesforce 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)
 
@@ -453,7 +455,7 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files. 
 </Step>
 <Step>
 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 Salesforce connector to. Salesforce data should be found on the **Entitlements** and **Accounts** tabs.

baton/snowflake.mdx

@@ -1,8 +1,8 @@
 ---
 title: Set up a Snowflake connector
 og:title: Set up a Snowflake connector - C1 docs
 og:description: Integrate your Snowflake instance with C1 to run user access reviews, enable just-in-time access requests, and easily provision and deprovision access.
 description: C1 provides identity governance for Snowflake. Integrate your Snowflake instance with C1 to run user access reviews (UARs) and enable just-in-time access requests.
 sidebarTitle: Snowflake
 ---
 
@@ -31,9 +31,11 @@
 
 [This connector can sync secrets](/product/admin/inventory) and display them on the **Inventory** page.
 
+[This connector syncs non-human identities](/product/admin/nhi) and displays them on the **Identities & NHI** dashboard.
+
 ### Connector actions
 
 Connector actions are custom capabilities that extend C1 automations with app-specific operations.
 
 | Automation step | Actions offered | How the target is selected |
 |-----------------|-----------------|----------------------------|
@@ -61,7 +63,7 @@
 <Tip>
 **For best results, use a dedicated service account.** C1 will use the `DEFAULT_WAREHOUSE`, `DEFAULT_NAMESPACE`, and `DEFAULT_ROLE` properties of the user used for the integration. For this reason, we recommend creating a dedicated service account in Snowflake for integrating with C1 with these default user properties. 
 
 Give the service account the `MONITOR USAGE` and `MANAGE GRANTS` global permissions for the default warehouse and namespace, plus the `MONITOR` privilege on each user secret and database. 
 </Tip>
 
 ### Generate a private key and set the public key on a Snowflake user
@@ -129,7 +131,7 @@
 <Step>
 Choose how to set up the new Snowflake 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)
 
@@ -195,7 +197,7 @@
 <Step>
 Choose how to set up the new Snowflake 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)
 
@@ -288,7 +290,7 @@
 
 <Steps>
 <Step>
 Create a namespace in which to run C1 connectors (if desired), then apply the secret config and deployment config files. 
 </Step>
 <Step>
 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 Snowflake connector to. Snowflake data should be found on the **Entitlements** and **Accounts** tabs.
@@ -304,11 +306,11 @@
 
 If you're seeing a `422 unprocessable entity` or `401 unauthorized` error in the logs, make sure that your service account has the `DEFAULT_WAREHOUSE`property, and that you've correctly looked up your Snowflake account identifier. 
 
 ### Connector fails when Snowflake IP allowlisting is enabled
 
 If your Snowflake account has a [network policy](https://docs.snowflake.com/en/user-guide/network-policies) configured that restricts access by IP address, you must add C1's egress IP addresses to the allowlist. Otherwise, Snowflake will reject connections from the connector.
 
 For **cloud-hosted connectors**, C1 manages the connector infrastructure. Add C1's connector egress IPs to your Snowflake network policy. See [C1 egress IP addresses](https://www.c1.ai/docs/product/admin/egress-ips) for the current list.
 
 For **self-hosted connectors**, the connector runs on your own infrastructure, so you should add the outbound IP addresses of your own environment instead.
 

docs.json

@@ -313,6 +313,7 @@
             "pages": [
               "product/admin/query",
               "product/admin/inventory",
+              "product/admin/nhi",
               "product/admin/external-insights",
               "product/admin/findings"
             ]

product/admin/nhi.mdx

@@ -0,0 +1,48 @@
+---
+title: "Non-human identities (NHI)"
+og:title: "Non-human identities (NHI)"
+og:description: "See how C1 classifies and surfaces non-human identities across your connected sources."
+description: "See how C1 classifies and surfaces non-human identities across your connected sources."
+sidebarTitle: "Non-human identities"
+---
+
+{/* Editor Refresh: 2026-09-02 */}
+
+The **Identities & NHI** dashboard gives you one place to see every identity C1 discovers across your connected sources — human and non-human alike — including a dedicated view for non-human identities (NHIs).
+
+<Note>
+**NHI capabilities are under active development.** Classification, ownership, and policy support for non-human identities will keep expanding: follow the [release notes](/product/release-notes) for updates.
+</Note>
+
+## What counts as an NHI
+
+In C1, a non-human identity (NHI) is a resource classified as one of the following:
+
+- **App registration** — for example, an Entra enterprise app, OAuth app, GitHub App, or Databricks service principal.
+- **Assumable role** — for example, an AWS IAM role or GCP workload identity.
+- **Managed identity**
+
+Service accounts, secrets, and agents are related but separate categories that C1 tracks on the same dashboard — see [Find identities across your environment](#find-identities-across-your-environment) below. They aren't classified as NHIs.
+
+## Find identities across your environment
+
+Navigate to **Identity security** > **Identities & NHI** to view the dashboard. It has a tab for each identity category C1 tracks — **Human users**, **Service**, **Secrets**, **Agents** — plus a dedicated **NHI** tab scoped to the app registrations, assumable roles, and managed identities described above.
+
+<Frame>
+  <img src="/images/product/assets/nhi-identities-table.png" alt="The Identities & NHI dashboard's NHI tab, listing app registrations and assumable roles grouped by connected app, with columns for owner, type, subtype, and findings." />
+</Frame>
+
+Each tab lists its identities grouped by the connected app they came from, with:
+
+- **Type and subtype** — the resource's classification (app registration, assumable role, or managed identity) alongside a more specific detail string, such as `entra.enterprise_application` or `aws.role.lambda`.
+- **Owner** — who owns the identity, if anyone. Unowned NHIs are one of the most common gaps this dashboard surfaces.
+- **Findings** — any open [findings](/product/admin/findings) tied to the identity, such as an unowned non-human identity.
+
+Search by name, or filter by app, owner, type, or **Has findings** to narrow the list down.
+
+Click an identity's finding to open its detail view, with the same evidence, remediation guidance, and activity trail described in [Findings](/product/admin/findings#work-with-a-finding).
+
+<Frame>
+  <img src="/images/product/assets/nhi-finding-detail.png" alt="Finding detail panel for an unowned non-human identity, showing its age, remediation guidance, and activity history." />
+</Frame>
+