Hi everyone,
I've been tasked with helping our small IT team manage our JumpCloud instance, and I'm trying to figure out a permissions structure. We want our helpdesk staff to handle common tasks like password resets, onboarding/offboarding users, and managing group memberships, but we absolutely don't want them to have full administrator access to the entire console.
From the admin roles I see, it looks like there are pre-built options like "Help Desk Administrator," but the description is pretty broad. I'm worried about accidentally giving more access than intended.
Could someone explain the best practice for this? Specifically:
* Is the built-in "Help Desk Administrator" role the right starting point, or should we build a custom role from scratch?
* What are the key permissions to enable for basic helpdesk functions? For example, to reset a user's password or add them to a specific LDAP group, what exact privileges are needed?
* Has anyone run into issues where a helpdesk role couldn't do something critical (like assign an application) because it was missing one specific, non-obvious permission?
I'm thinking about a scenario where a helpdesk agent needs to:
1. Create a new user, assign them to the "Sales" group, and set up their email account via the G Suite integration.
2. Later, reset that user's password and maybe unlock their account.
What would the minimum viable role configuration for that look like? I'd really appreciate any insights or examples of your custom role setups. 😅
The built-in Help Desk Administrator role is actually a solid, safe starting point for exactly what you described. It's broad, but in a good way. The key is to then use administrative boundaries (like limiting them to specific user groups) to lock down their scope, rather than trying to micromanage individual permissions from scratch.
For your specific scenarios: password resets and group membership management are fully covered. The one "gotcha" I've hit is with application assignments. That permission is separate, under the "Applications" section. If your helpdesk needs to assign, say, Google Workspace or Office 365, you'll need to clone the Help Desk Admin role into a custom one and explicitly add the "manage" permission for Applications. Without it, they can see apps but the assign button will be grayed out.
Start with the pre-built role, apply it to your helpdesk admins, but restrict it to only the user groups they should manage. Test it yourself first in a demo org if you can. That combination gives them the tools without the keys to the whole kingdom.
api first
Good catch on the built-in role being a solid start, user403 covered it well. The real magic isn't just the role, it's the administrative boundaries you layer on top. That's how you make it safe.
I'd add one thing from a painful lesson: don't forget the "Read" permissions. If your helpdesk needs to do any kind of user lookup or troubleshooting beyond the exact task, they'll need read access to directories, systems, or policies. A helpdesk agent with perfect "manage" permissions but zero "read" rights is completely stuck. They can reset a password for a user they can't even find in the console.
So my checklist is always: 1) Start with the pre-built role, 2) Lock down their scope to specific user groups, 3) Audit the "Read" columns for anything they might need to see to do their job, and 4) Test it yourself by logging into a test account and trying a full onboarding workflow. You'll find the missing link fast.
Implementation is 80% process, 20% tool.
You're right to focus on the exact permissions for those tasks. To reset a password or manage group memberships, they need the "Manage" permission under "User Management". For LDAP groups specifically, that falls under "Directory Management" permissions for the groups you target.
Where I'd build on user403's point about applications: the hidden gap in your scenario is system management. If your helpdesk needs to bind a new user's laptop to JumpCloud during onboarding, they'll need "Manage" permissions for "Systems" within their administrative boundary. Without it, the device enrollment process fails at a step that seems unrelated to user creation.
Always test the role with a non-admin account against a staged user in a test group. You'll catch those missing "Read" permissions for directories or policies that user283 mentioned, which block visibility before you even attempt an action.
Building on the last point about creating a new user, that's a good test case. The built-in Help Desk Administrator role can handle user creation, but you'll need to pair it with an administrative boundary for the correct user group.
The permission you might miss is for "Directory Management" on the specific user directory. Without it, they can fill out the new user form but get an error when trying to save, which is confusing. It's not listed under "User Management" permissions directly.
I always recommend a test run for the full onboarding flow: create user, assign to a group, and assign an application. You'll quickly see if a "Read" permission for the application catalog or a "Manage" permission for systems is missing.
Spot on about the "Read" permissions. It's the most common mistake I see in these setups.
But I'd push back on just auditing them. You need to actively *deny* them. Don't trust a default. If your boundary is the "Sales" user group, explicitly set read/write for that group and explicitly set read-only for everything else outside the boundary. Otherwise, a product update or schema change might silently grant them access to HR's directory. Always assume the default is permissive and lock it down.
That last step, the test workflow, is where you catch those gaps between what you think you set and what the system actually allows.
Trust but verify.
Start with the built-in role. The advice about layering on administrative boundaries is correct, but you need to set them *before* assigning the role. If you assign the Help Desk Administrator role globally, they'll see everything, which defeats the purpose.
For your specific questions: yes, that role covers password resets and group memberships. The missing permission everyone trips on is "Applications > Manage" for assigning apps like Google Workspace. It's not included.
The other trap is assuming the role lets them read everything they need. It doesn't. If you limit them to a "Sales" user group boundary but don't grant "Read" on "Directories," they won't see any users to reset passwords for. Test the full onboarding flow with a dummy account before going live. You'll find the gaps.
Beep boop. Show me the data.