All resources in JumpCloud are implicitly denied, which means that by default, new users don't have access to a resource endpoint until they are explicitly connected to it directly or through group membership. You can bind the user to any of the resources connected to JumpCloud from a device to applications, networks, etc. If the user is created in a Staged user state, they won't gain access to their assigned resources until they're activated. See Manage User States for specific information about when a user is provisioned or assigned resources.
- The JumpCloud Agent must be installed and active on the system.
- The user must be connected to the system in the Admin Portal.
- The user must not exist as a local user account on the Linux System.
Access to resources may be granted by connecting a user to any of the following:
- User Groups
Binding a user to a group of users is an organizational construct. No access is granted until that group has been bound to a resource. You can edit group membership in this view.
Binding a user directly to a device is good practice if this will be a one-to-one relationship. For example, a single user is bound to their work device to which no one else can have access. A user bound via a (user) group can also be bound directly to the device to enable a custom permission to be set on only that device. UI behavior for group and direct connection is explained further in Get Started: Devices. When a user is bound to a device, it either creates a new local user account or takes over an existing account of the same username. See Take Over an Existing User Account with JumpCloud.
This can include Google Workspace, Microsoft 365, and/or JumpCloud LDAP. These resources are generally accessed by groups of people. So binding directly to the user, while possible, isn't generally recommended. Rather, bind the user to a group that has already been granted access to the directory. A direct connection can't be made if the user is already bound to the resource via a group of users.
User Group Bindings
Access to resources may be granted by connecting a User Group to any of the following:
- Device Groups
Binding a user to a group of users is an organizational construct, no access is granted until that group has been bound to a resource. You can edit group membership via the User tab.
Binding via device group is recommended when there are one-to-many or many-to-many relationships. For example, a group of admins needs access to a production environment. All members of the User Group will be granted access to all devices in the Device Group. When a user is connected to a device, a new local user account will be created or an existing account of the same username will be taken over. See Take Over an Existing User Account with JumpCloud. It's possible to be bound to the device both directly and via group membership. UI behavior for group and direct binding is explained further in Get Started: Devices.
Admins know that they can bind a user to resources through groups, but that this is the mechanism by which they can assign permissions to those groups.
Binding a user group to a device group will create a local user account for each user in the user group on each device in the device group. Adding a large number of user accounts to a device may prevent it from operating correctly. Proceed with caution.
Applications and RADIUS Servers
To grant access, a user must be a member of a group. You may create one or many groups of users to bind to one or many resource types. After the group is bound to the application, any member of that group will be allowed to log in.
This can include Google Workspace, Microsoft 365, or JumpCloud LDAP to Create an LDAP Group. Binding a User Group to a directory is possible even if a user has already been granted direct access to that directory.
The following table illustrates which JumpCloud resources can be bound.
|User||Device||User Group||Device Group|
✓ - The resources can be bound.
X - The resources can't be bound.