How I Set Up SCIM Provisioning From Microsoft Entra ID to JumpCloud
Last week I got a task from a client, through Cloud Knowledge, that sounded simple on paper: “We want every new employee added in Entra ID to automatically show up in JumpCloud, without anyone in IT manually creating the account.” No custom scripts if we could help it. No middleman database. Just Entra pushing identities straight into JumpCloud the moment someone joins.
It ended up being a genuinely fun problem to solve, and along the way I hit a couple of errors that I think are worth writing about, because I couldn’t find great documentation on them when I went looking. So here’s the whole thing – why this matters, how I built it, and where it broke before it worked.
Why bother automating this in the first place?
If you’ve ever worked an IT helpdesk during a hiring wave, you already know the answer. But for anyone who hasn’t lived through it:
- Manual account creation doesn’t scale. One new hire, fine. Ten new hires in the same week, and someone’s account is going to get created a day late, or with a typo in their email, or forgotten entirely until they ping IT on day one asking why they can’t log in.
- Offboarding is the scarier half of this problem. A departing employee who still has an active JumpCloud account three weeks after their last day isn’t a hypothetical risk – it’s the kind of thing that shows up in a security audit with your name next to it.
- Consistency. When a human is manually copying fields from Entra into JumpCloud, small mistakes creep in – a middle name in the wrong field, a mismatched username format. Automated provisioning means every account is built the same way, every time.
- It frees up IT to do literally anything else. Account provisioning is not where you want your team’s attention going. It’s repetitive, low-value, and exactly the kind of task automation exists for.
This is the whole pitch behind SCIM (System for Cross-domain Identity Management) provisioning – it’s a standard protocol that lets one system (in our case, Entra ID) push user data into another system (JumpCloud) automatically, using a defined schema both sides understand.
Why JumpCloud, specifically?
Quick bit of context here, because it matters for anyone trying to follow along and test this themselves without a company budget behind them.
Most well-known SaaS platforms – think Notion, Figma, Canva, even Zoom – gate SCIM provisioning behind their Enterprise tiers, which usually means talking to a sales rep and signing a contract before you can even test the connection. Not exactly friendly for a hands-on lab, or honestly, for a small business trying to get this working without a huge budget.
JumpCloud is one of the few identity platforms that offers genuine SCIM support on its free tier – up to 10 users, no credit card needed to sign up. It also runs a real SCIM server on its side, meaning it’s actually built to receive provisioning pushes, not just to send them. That distinction turned out to be important – more on that in the errors section below.
What you’ll need before starting
- A free JumpCloud account, with an admin login that has permission to generate API keys
- A Microsoft Entra ID tenant, with a Cloud Application Administrator (or Global Administrator) account
- About 20–30 minutes if nothing goes sideways, longer if you hit the same snags I did
Step-by-step: Connecting Entra ID to JumpCloud
Step 1 – Generate a JumpCloud API key
Log in to the JumpCloud Admin Console, open your admin profile, and go to API Settings. Generate a new key and copy it somewhere safe – you’ll paste this into Entra shortly.
Step 2 – Create a non-gallery app in Entra
Here’s the first thing that surprised me: JumpCloud isn’t listed in Microsoft’s Entra application gallery. So instead of searching for it by name, you create it as a custom app:
- Go to Microsoft Entra admin center → Identity → Applications → Enterprise Applications
- Click + New Application → Create your own application
- Name it something clear, like
JumpCloud SCIM - Select “Integrate any other application you don’t find in the gallery (Non-gallery)” → Create
Step 3 – Set up the single sign-on tab
Even though we’re only doing provisioning here, Entra still wants this tab configured. Set it to Disabled or Password-based – JumpCloud doesn’t support SAML through this app, so there’s no SSO configuration to actually do here.
Step 4 – Configure provisioning
This is the part that actually connects the two systems:
- Click Provisioning in the left nav
- Set Provisioning Mode to Automatic
- Under Admin Credentials, enter:
Tenant URL: https://api.jumpcloud.com/scim/v2/?aadOptscim062020
Secret Token: [your JumpCloud API key from Step 1](If your JumpCloud org is hosted in the EU, use api.eu.jumpcloud.com instead.)
Click Test Connection. If everything’s right, you’ll get a clean success message.
Step 5 – Fix the attribute mappings
This step is easy to skip past, and if you do, your sync will fail silently or reject users. By default, Entra’s mapping template doesn’t line up cleanly with what JumpCloud expects. Two changes made the difference for me:
| Entra Attribute | Change to |
|---|---|
| userName | Source: mailNickname |
Source: userPrincipalName |
I’d also recommend scrolling through the rest of the default attribute list and removing anything JumpCloud clearly won’t use – extra unmapped attributes don’t break anything, but they clutter the mapping screen if you ever need to come back and debug it.
Step 6 – Turn off group provisioning
Under Mappings → Provision Microsoft Entra ID Groups, switch this to No. JumpCloud doesn’t support real-time group import through this connector, and leaving it on just generates errors in your provisioning logs for no benefit.
Step 7 – Assign users and go live
- Go to Users and groups → + Add user/group, and assign your test users (or your whole org, if you’re confident in the mapping)
- Back on the Provisioning overview page, toggle Provisioning Status to On
- Save
Entra runs an initial sync almost immediately, then checks for changes roughly every 40 minutes after that. For testing, don’t wait – use Provision on demand to force an instant sync for a specific user.
Step 8 – Verify it actually worked
Head over to your JumpCloud console and check Users. Your Entra-assigned users should now appear – typically in a “password pending” state, since Entra doesn’t (and shouldn’t) push real passwords across.
The errors I actually ran into
I’ll be honest – this didn’t work on the first try, and I think the failures are more useful to document than the happy path.
My first instinct was to try this exact setup against a plain Okta org instead of JumpCloud, since I’d assumed a similar Tenant URL / Secret Token pattern would work universally. It didn’t – Entra returned a 404 immediately. It turns out this comes down to a fundamental difference between the two platforms: Okta is built to act as a SCIM client, not a SCIM server, meaning there’s no endpoint on Okta’s side for an external system like Entra to push users into. JumpCloud, on the other hand, genuinely runs a SCIM server, which is exactly why the same style of connection succeeds here. Worth knowing before you assume this pattern is universal across every identity platform.
Before I corrected the userName and mail source attributes, provisioning would either silently skip users or throw mapping errors in the Entra provisioning logs. The fix was exactly the mapping change described in Step 5 – this is genuinely the most common failure point people report with this integration, and it’s not something Entra warns you about upfront.
This one wasted more of my time than it should have. It’s not a bug – it’s a permissions issue. JumpCloud restricts API key generation to specific admin roles (Administrator, Owner, or Manager with Billing access). If you’re logged in under a limited admin role, this screen blocks you outright. Check your role under Settings → Administrators before assuming something’s broken on JumpCloud’s end.
Was it worth it?
Genuinely, yes. Once this was live, new hires in Entra showed up in JumpCloud within the hour without anyone touching a keyboard – and just as importantly, when someone’s Entra account gets disabled, JumpCloud reflects that too. That second half is honestly the bigger win. Nobody remembers to manually deprovision an old account on a Friday afternoon, but automation doesn’t forget.
If you’re evaluating whether this is worth setting up for your own org, my honest take: if you’re manually creating or deleting more than a handful of accounts a month, this pays for itself in the first week just in IT time saved – before you even factor in the security upside of not having stale accounts sitting around.
Frequently Asked Questions
Yes, for up to 10 users. JumpCloud’s free tier includes real SCIM support, no credit card required at signup. If you’re just testing this out or running a small team, you won’t hit a paywall for the provisioning feature itself.
It simply isn’t listed as a pre-built gallery app the way tools like Salesforce or ServiceNow are. That’s not a limitation though – you set it up as a “non-gallery” custom application in Entra instead, which takes the same amount of effort and works just as reliably once configured.
No – and this tripped me up too. Okta is built to act as a SCIM client, not a SCIM server, so there’s no endpoint on Okta’s side for Entra to push users into. You’ll get an HTTP 404 on the test connection if you try. JumpCloud works here specifically because it runs a genuine SCIM server.
The very first sync runs almost immediately after you turn provisioning on. After that, Entra checks for changes roughly every 40 minutes. If you’re testing and don’t want to wait, use the “Provision on demand” option to force an instant sync for a specific user.
Yes. When a user is disabled or removed in Entra, that change flows through to JumpCloud on the same sync cycle. This is honestly the more valuable half of the automation – it closes the gap where offboarded employees are forgotten about and left with active accounts.
Entra’s default mapping template isn’t built specifically for JumpCloud’s schema, so a couple of fields need to be re-pointed – userName to mailNickname, and mail to userPrincipalName. Skip this step and you’ll likely see silent sync failures or rejected users in the provisioning logs.
Just users. JumpCloud doesn’t support real-time group provisioning through this connector, so that mapping should be switched off in Entra to avoid unnecessary errors in your logs.
Need this set up for your organization?
This is exactly the kind of identity automation work we do at Cloud Knowledge – Entra, Okta, JumpCloud, and everything in between.
Get in touch →Have questions about your own Entra-to-JumpCloud setup, or hit a different error along the way? Drop a comment below or reach out directly – happy to help troubleshoot.
