If your organization has on-premise Active Directory (AD) or Azure Active Directory (AAD) joined Windows devices, you can install the JumpCloud agent on those devices and bring them into your JumpCloud org. Doing so enables the administrator to remotely and securely manage the device as well as take advantage of JumpCloud’s System Insights feature.
Currently, if you bind users to an on-premise Active Directory domain joined device, the device will ignore the binding and you will be unable to verify your identity on the device. However, if the device leaves the domain, the JumpCloud agent will automatically bind the user to the device.
If a JumpCloud-managed device with JumpCloud users bound to it joins an on-premise AD domain, those user accounts will be suspended. This is expected behavior as user management is not supported on on-premise AD domain-joined devices.
If you attempt to bind an Azure AD imported user to an Azure AD joined device, this may result in unexpected behavior.
Why Use the JumpCloud Agent for Domain Joined Devices?
The table below shows the features that are supported on JumpCloud devices, Active Directory devices, and Azure Active Directory devices:
When you install the JumpCloud agent on domain joined devices, you can take advantage of JumpCloud’s System Insights feature and view information such as:
- Reliability of your organization systems: Gather information about system uptime to leverage when diagnosing system issues.
- Memory and storage statistics: Gather information about your org system memory and storage capacity to leverage when making system upgrade decisions.
- Systems that are protected by disk encryption: See which org systems are protected by disk encryption and which systems you need to update with encryption protection.
- Hardware inventory details: Gather inventory information such as vendor, model, serial number, and more.
Applying Policies for AD Joined Devices
For a given policy, an on-premises AD policy will override a JumpCloud policy. For example, if you have an AD policy that configures the screensaver, and a JumpCloud policy that also configures the screensaver, the AD policy will take effect, ignoring the JumpCloud policy. To avoid unexpected behavior, JumpCloud recommends that you only set JumpCloud policies rather than setting both a JumpCloud policy and an AD policy.
For troubleshooting, you can use the Resultant Set of Policy snap in console. In this console, JumpCloud policies display as “Local Group Policy” and AD policies show as group policies. Group policies override local policies.
The following policies are currently unsupported on AD joined devices:
- Rename Local Administrator Account
- Enable/Disable Local Administrator Account
- Rename Local Guest Account
- Enable/Disable Local Guest Account
Regarding the lock screen, if policies are set in both JumpCloud and Active Directory, whichever policy has the lowest timeout will take effect.
Full Disk Encryption with Bitlocker
BitLocker is an encryption feature built into computers running Windows. It secures your data by scrambling it so it can’t be read without using a recovery key. BitLocker differs from most other encryption programs because it uses your Windows login to secure your data; no extra passwords necessary. Once you’re logged in, you can access your files normally. After you log out, everything’s secured.
Windows Automated Patch Management
JumpCloud’s automated patch management helps you monitor which version and release your Windows, macOS, or Linux devices are currently using, and remotely schedule and install updates. You can create an OS patch management policy to control which devices will have the policy applied and when it will be applied.
Installing the JumpCloud Agent on Domain Joined Windows Devices
You install the JumpCloud Agent on domain joined Windows devices using the same process as installing it on non-domain joined devices.
If you are migrating from Active Directory to JumpCloud, ensure that you bind the device’s users to the device through JumpCloud before you remove the device from Active Directory. Doing so ensures that the device remains active and the user can continue to use it.
Note:
After the initial restart after a JumpCloud device joins Active Directory, the user will see a tile on the login screen where they will be prompted for their JumpCloud credentials. However, they will not be able to log in using those credentials. Instead, they will log in using the “Other User” tile with their Active Directory credentials. This is the correct behavior, and on subsequent logins, the user will not see the tile for their JumpCloud user account.
User Functionality on AAD Joined Devices
If you have a device that is already part of an AAD domain, your device will already have an account for each user. When you add that device to your JumpCloud domain, a separate JumpCloud account will be created for each user on that device as well. Nothing will change for the AAD account–that account is the one that the user will use for any AAD programs and files on the device. The JumpCloud account can be used for user management features, such as identity verification.
These accounts are not linked.
This process will be simplified in a future update.
Features Unsupported by On-Premise AD Joined Devices
The following JumpCloud features are unsupported by on-premise AD domain joined devices at this time:
- User Management
- Locked User use cases
- Password Expiration
- Password Change
- Account Takeover
- Admin User
- Binding User to Device
- Device MFA
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article