Creating New Objects in JumpCloud
To demonstrate a simple object creation use case, we’ll use Figure 1 below. In this model, you can see that the JumpCloud group exists and it contains two objects: a security group, ‘Sales’ and a single user, ‘Jim’. Each object has an explanation of what, exactly is created. Note specifically the nested group ‘Sales - Boulder’ and the creation behavior within JumpCloud.
Assume in the model above that the user object ‘Jim’ pre-existed in JumpCloud. When all qualifying metadata of the incoming AD user matches a user object in JumpCloud (via email if defined or logon - firstname.lastname@example.org), the incoming AD user will commandeer the pre-existing JumpCloud user and take ownership of it. Groups will behave in the same way (matching by Group Name).
Removing Objects from JumpCloud
When an AD administrator modifies User and Group members of the ‘JumpCloud’ AD Security Group, this will perform reverse behavior to the creation and syncing of user and group objects in JumpCloud. The use cases below will illuminate these use cases:
When an AD user is removed from JumpCloud sync:
- If the corresponding User in JC is not bound to any other AD synced Groups, the User will be removed (deleted) from JumpCloud.
- If the corresponding User in JC is bound to an AD security Group synced with JumpCloud, the user will not be removed from JumpCloud (the user must be removed from any and all AD groups synced with JumpCloud).
When an AD security Group is removed from JumpCloud sync:
- If the corresponding Group in JC only contains AD managed users, the Group is deleted from JC
- If the corresponding Group in JC contains some JC managed users, it is disowned, the Group is not deleted and is now managed by JC