{"id":60004,"date":"2022-03-08T10:18:18","date_gmt":"2022-03-08T15:18:18","guid":{"rendered":"https:\/\/jumpcloud.com\/?p=60004"},"modified":"2023-03-08T15:29:07","modified_gmt":"2023-03-08T20:29:07","slug":"best-practices-for-migration-of-device-permissions-from-a-user-to-a-group","status":"publish","type":"post","link":"https:\/\/jumpcloud.com\/blog\/best-practices-for-migration-of-device-permissions-from-a-user-to-a-group","title":{"rendered":"Best Practices for Migration of Device Permissions from a User to a Group"},"content":{"rendered":"\n
JumpCloud is the one-stop solution for centralizing access for users across devices, applications, directories, and endpoints. Customers can now manage privileged access and\/or permissions across multiple devices to ensure sensitive, administrative rights are maintained by leveraging the power of User Groups.<\/p>\n\n\n\n
JumpCloud enables administrators to manage permissions on devices requiring Administrator\/Sudo or Passwordless Sudo permission (the latter is only available on Mac and Linux). This allows administrators to have better control and visibility over who has access to which devices. Recently, JumpCloud released two new features that allow administrators to control these permissions at the User Group level, as well as per User Group to Device Group bind for more granular control. As a result, any user that\u2019s a member of the User Group automatically inherits permissions set at the group level.<\/p>\n\n\n\n
This best practices blog:<\/p>\n\n\n\n
There are four different ways a user can have Administrator\/Sudo permissions applied for a given device. The following illustration is a visual representation of how these permissions can be applied and\/or cascaded based on where the permission is configured.<\/p>\n\n\n\n
The administrator can choose any of these methods based on the organization\u2019s need to control individual devices and the roles the users will hold through the lifecycle of the identity.<\/p>\n\n\n\n Result:<\/em> The Administrator\/Sudo permission is being applied to all bound Device Groups and their bound devices, which grants all users within the User Group Administrator\/Sudo access to all bound devices.<\/p>\n\n\n\n Result: <\/em>The Administrator\/Sudo permission is being applied on the User Group\u2019s bind to selected Device Groups. Devices that are bound to a Device Group with Administrator\/Sudo enabled receive Administrator\/Sudo access. As a result, bound users in the User Group will inherit Administrator\/Sudo access on those select devices<\/p>\n\n\n\n Result:<\/em> This user has Administrator\/Sudo permissions for all devices they are bound to, both indirectly and directly<\/p>\n\n\n\n Result: <\/em>The Administrator\/Sudo permission is being applied to the user\u2019s direct bind to a specific device.<\/p>\n\n\n\n Direct Bind<\/strong><\/p>\n\n\n\n Direct bind (indicated by the darker blue checkbox) indicates direct permissions that were applied on the association with selectable user inputs from the UI or the API (as illustrated below).<\/p>\n\n\n\n Indirect Bind<\/strong><\/p>\n\n\n\n An indirect bind (indicated by the lighter blue checkbox) indicates that the device is indirectly bound to the user through a Device Group which is, in turn, bound to a User Group. (as illustrated below)<\/p>\n\n\n\n Why is this important?<\/strong><\/p>\n\n\n\n These differences are crucial in determining if the device would be needed to get converted into a new type of association using groups.<\/p>\n\n\n\n Initially, we recommend administrators check the type of bind users may already have in the JumpCloud Admin Portal.<\/p>\n\n\n\n Complete the following steps to check what devices are bound to the user<\/strong>:<\/p>\n\n\n\n If the checkbox for devices (first column on the Devices<\/strong> tab) is checked and darker in color, this indicates a direct bind exists between the device and the user. If the checkbox for a device is checked and lighter in color, this indicates an indirect bind exists between the user and the device.<\/p>\n\n\n\n You can also enable privileged access on all devices by checking Enable as Global Administrator\/Sudo on all device associations<\/strong> on a user, which elevates permissions on all devices associated with that user. Complete the following steps to enable global permission on a user<\/strong>: <\/p>\n\n\n\n This will result in the user having Administrator\/Sudo permissions on all devices associated with that user.<\/p>\n\n\n\n This illustrates that a global setting takes precedence over associations<\/em> on all devices that the user is associated with. One can use this setting if the desire is to promote all devices for a user with global Administrative\/Sudo or Passwordless Sudo with a direct or indirect bind of the devices with the user.<\/p>\n\n\n\n Removing this direct association on the user will result in a state where the user still shows a combination of direct and indirect binds for devices and the states of these devices. This is due to the group-based association newly introduced within JumpCloud that allows management of devices using User Groups and Device Groups. One can proceed to undo the above change if there is a preference to control individual devices or inherit and manage permissions using groups.<\/p>\n\n\n\n Complete the following steps to remove Global Administrator\/Sudo permissions between users and devices<\/strong>:<\/p>\n\n\n\n Complete the following steps to manage individual devices<\/strong>:<\/p>\n\n\n\n To manage multiple individual devices, we suggest using Device Groups, to which individual devices can be bound. Permissions can then be applied to Device Groups when the Device Group is bound to a User Group. Group-level permissions can be set on a User Group to Device Group bind, or globally at the User Group level, applying to all Device Groups.<\/p>\n\n\n\n Elevated permissions that are set on an individual device bind or globally for the user should be removed for any group-level permission to take effect.<\/p>\n\n\n\n Complete the following steps to downgrade individual devices to having no elevated permissions<\/strong>:<\/p>\n\n\n\n Note<\/strong>: The No Elevated Permissions<\/strong> option removes the Sudo permissions, but leaves the bind.<\/p>\n\n\n\n After saving the user, the user will still have an indirect bind to that device.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Path 1: Global Administrator\/Sudo Enabled on User Group<\/h3>\n\n\n\n
Path 2: Administrator\/Sudo Enabled on Select Device Group(s) Assigned to a User Group<\/h3>\n\n\n\n
Path 3: Global Administrator\/Sudo Enabled on an Individual User<\/h3>\n\n\n\n
Path 4: Administrator\/Sudo Enabled on User\u2019s Direct Bind to a Device<\/h3>\n\n\n\n
Checking What Binds You Have<\/h2>\n\n\n\n
\n
<\/figure>\n\n\n\n
Setting Global Permissions on a User<\/h2>\n\n\n\n
Note<\/strong>: This setting takes the highest precedence for all the user’s devices and overrides all other settings that individual devices may have with the user.<\/p>\n\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
\n
Setting Administrative Permissions on Individual Devices<\/h2>\n\n\n\n
\n
<\/figure>\n\n\n\n
\n
Important Considerations<\/h3>\n\n\n\n
\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\n
\n
<\/figure>\n\n\n\n