GuidesPush users with SCIM
On this page0

Guide

Push users with SCIM

Let Okta or Microsoft Entra ID create, update and deactivate people in Zonitix the moment they change in your directory.

For: IT administratorPlan: All plans

Before you start

  • This is an IT task. It assumes you know your way around the admin console of Okta or Microsoft Entra ID. If you do not, do this together with whoever administers your identity provider, or hand them this page.
  • SCIM is a standard that lets your identity provider (the service that holds your company’s accounts, such as Okta or Microsoft Entra ID) tell Zonitix about joiners, changes and leavers by itself.
  • Your role must let you manage security settings. In the built-in set, administrators have that permission. The “security_analyst” role has it too; no group carries it, so an administrator gives it to a person by hand, as Roles, groups and permissions shows.
  • Admin access to Okta or Microsoft Entra ID, where you add a SCIM provisioning connection to an app.
  • For the first sync of your existing staff, leave “Start onboarding for new people” off (it is off by default), or everyone gets an onboarding run.
  • People who push into Zonitix sign in through SSO, a magic link or a passkey; SCIM does not give them a password. Set up “SSO (OIDC / SAML)” as well if you want one sign-in.

Connect your identity provider

  1. Step 1: Open the provisioning settings

    Go to Security & ComplianceSecurity SettingsProvisioning (SCIM), in the “Directory & Access” group.

  2. Step 2: Copy the SCIM base URL

    The blue box shows the “SCIM base URL”. Your identity provider needs this address, together with a token. A token is a long secret that proves a request really comes from your provider. If your provider asks how to authenticate, choose HTTP header or bearer token.

  3. Step 3: Generate a token

    In the “API tokens” card, type a “Token name” (for example the name of the provider connection), leave “Connection” on “New identity-provider connection”, and click “Generate token”.

    The “Copy your SCIM token” window shows the token once. Click “Copy to clipboard”, paste it into your provider straight away, then click “I’VE COPIED IT”. Zonitix keeps no readable copy; if you lose it, revoke it and generate a new one. You can have up to 10 active tokens; one per provider connection is enough.

  4. Step 4: Paste both into Okta or Entra

    In your identity provider’s SCIM provisioning settings for the app, enter the base URL and the token as a bearer token, then assign the people and groups to push. Until you issue a token, provisioning is off.

Set the policy

  1. Step 5: Choose whether new people get onboarded

    “Start onboarding for new people” opens the same onboarding run as the Onboard button for each person your provider creates or re-activates. It is off by default. Turn it on after the first sync, when only genuine new joiners arrive.

  2. Step 6: Decide about groups

    “Let the identity provider create groups” is on by default. New groups start with no roles, so they grant nothing until an admin adds one.

    In the “Groups” card, switch on “IdP-managed” for each existing Zonitix group your provider may fill. For a group marked “Privileged”, your provider can only add members if you also switch on “Allow IdP to add members”. It can always remove them.

  3. Step 7: Save

    Click “SAVE PROVISIONING POLICY”. The change is recorded in the audit log.

What SCIM does from now on

  1. Step 8: Joiners and changes

    A new person in your provider becomes an active Zonitix user with the baseline access every employee gets. Name, email, job title, department, phone, employee ID and manager are kept up to date as they change.

  2. Step 9: Leavers

    Deactivating someone in your provider blocks their Zonitix sign-in and starts the same full offboarding as the Offboard button: accounts in connected systems, IT checklists and hardware recovery. If your provider deletes them instead, the same offboarding runs; Zonitix never hard-deletes them.

    Re-activating them later restores the account, through a new onboarding run if “Start onboarding for new people” is on.

Replacing a token? Generate the new one with “Connection” set to “Rotation of …” the old token, so it keeps the people and groups the old one manages. Then “Revoke” the old token. A brand-new connection cannot change people another connection created.

What you should see

The token shows “Active” with a recent “last used” time and a count of the users and groups the connection owns.

People you assigned in your provider appear in AdministrationUsers, and a person you deactivate there shows up as an offboarding run in Workflow Tasks.

If something goes wrong

Your provider reports "This user is owned by another directory … SCIM cannot modify it."
That person came in through a directory connection (Okta, Entra or Google sync). Only that connection manages them. Pick one way to bring each person in.
Your provider reports "The primary administrator cannot be managed by SCIM."
By design, so your instance can never be locked out. Leave that person out of the provisioning assignment.
You re-activated someone in your provider, but they are still blocked in Zonitix.
Someone in Zonitix blocked that account on purpose, and SCIM will not override that; the audit log records the refusal. SCIM only re-activates people who left or were deactivated by SCIM. Review the account in Users.
A warning says users or groups "were provisioned before each connection owned its records".
With one active connection, they are adopted on its next change. With two or more, click Re-bind on the token that should own them.
"At most 10 active SCIM tokens are allowed — revoke an unused one first."
Revoke a token you no longer use in the API tokens card, then generate the new one.
Every call from your provider fails after a token change.
The old token was revoked before the new one was pasted in. Generate a rotation of it and give that to your provider.

Still stuck? See When something goes wrong, or Contact Zonitix support.

Where next