So you're ready to disconnect Active Directory?

[urvashi]

This is an edited transcript of the 03.22.24 IT Hour

Overview

• Rodger Bright, Senior Sales Engineer outlines how to disconnect from Active Directory after migrating users to JumpCloud. 
• He does a demo of the process and answers questions from the audience about how this migration affects devices, and addresses the modernization of roaming profiles. 

Transcript

Rodger: Hi everybody, I appreciate the warm welcome to my inaugural IT Hour. So the question really is about shutting off Active Directory - decommissioning the domain controllers and disconnecting Active Directory from JumpCloud. The intention here is that you’ve migrated from Active Directory to JumpCloud but Active Directory is still connected to your JumpCloud environment and you have to figure out the process to deprecate Active Directory once and for all. 

We have a lot of documentation about how to incorporate Active Directory, how to extend Active Directory to JumpCloud but we don’t have a ton of documentation about this last step. So we’re here today to help you through that last step. 

There’s a fairly typical journey from Active Directory to JumpCloud: 

1. The first step is what we call “Extending Active Directory to JumpCloud” where Active Directory is fundamental to your business and JumpCloud is really complementing Active Directory. 
2. The next step tends to be shrinking your Active Directory footprint to just the core services. So you retain Active Directory specifically for legacy applications. Which means moving all end user computers, Windows 10/11 machines over and keeping Active Directory just for core application servers. 
3. Then there’s the final leg in the journey where you’re disconnecting Active Directory from JumpCloud completely. Active Directory is no longer needed and you migrate away completely from AC and fully into JumpCloud. But there’s still kind of an unspoken connectivity to Active Directory that you need to get rid of. 

So how do you actually cut that cord? What do you actually do? Here’s a few things to consider:

1. How is your JumpCloud Active Directory Integration (ADI) set up? There’s the Import Agent to move data from JumpCloud  into JumpCloud and the Sync Agent that moves data from JumpCloud to JumpCloud . So do you have:
1. Both the Sync and Import Agents?
2. Import only?
3. Sync only?
2. Are you currently using Entra /Azure AD Connect to get users from JumpCloud  to Entra/Azure?

Entra User Management - Transferring Ownership

If you’re using Entra Connect, you’re propagating users from JumpCloud  up to Entra using this tool. When we sever the connection between JumpCloud  and JumpCloud , there’s going to be an issue because your users sitting in Entra are actually JumpCloud  sync users that are controlled by JumpCloud. So prior to cutting the cord you absolutely must migrate your Entra users from JumpCloud  to JumpCloud. We’re going to assume you’ve already configured your JumpCloud Cloud Directory connector for Entra. There’s a prescribed process from MS and this is how MS wants you to do it. So in your Entra Connect tool you’re monitoring specific OUs which are inside of your JumpCloud  domain, that are determining the propagation of users to Entra. 

1. You want to deselect Monitored OU (Organizational Unit) inside of JumpCloud  which will effectively delete the user in Entra. That sounds scary but it’s not. This is the method MS wants you to use. 
2. Then you go into Entra and undelete that user. Now you’ve converted that user from a directory sync user to a cloud only user. 
3. And then you take over ownership. You assume control of that user inside of JumpCloud . Then you’re going to bind that user to that cloud directory connector and now JumpCloud owns the user in Entra. 
1. “Owns” meaning - pushing of various attributes that you choose to push - user state, user password, even potentially user group membership because we can control user groups inside of Entra.

My most stern recommendation is to test this and understand these steps before you actually process your entire user directory. So what the looks like is:

1. Create a test OU
2. Monitor that test OU
3. Create a test user in that OU
4. Let that user get propagated up into Entra and then 
5. Remove the test OU from the monitoring piece of the Entra Connect tool. 
6. Watch what happens to that test user
7. Undelete the test user 
8. Take ownership of the test user from inside JumpCloud 

Disconnecting - Import & Sync Agents / Sync Agent Only

If you’ve deployed JumpCloud ADI with the Sync Agent installed, there’s a couple of options. Note - if you have only the Sync Agent, JumpCloud has total control over the password. If you have Import & Sync, we have shared control. 

The Easy Way

The easy off button is that you literally just turn off your Domain Controllers (DC) and you’re done. It’ll work and nothing will happen to your environment. It’s not very pretty inside your environment though. You’re still going to see an ADI setup. You’ll still see the little “Active Directory” moniker on your users, but you know that you’ve shut the Active Directory DCs off. 

The Clean Way

The cleaner way is a little bit more of a lift. And that is actually removing Active Directory from JumpCloud completely. You get Active Directory out of JumpCloud and then change the “Externally Managed” flag for that user with Powershell. We have to tell JumpCloud that that user is now just a straight JumpCloud user. There’s more information on how to to change the “Externally Managed” flag via Powershell here. 

Disconnecting - Import Agent Only 

In this case your passwords are managed by Active Directory. JumpCloud doesn’t own that password. So you have to go through this process - You must remove Active Directory from JumpCloud and you must change the Externally Managed flag for those users. This is what the technical procedure looks like: 

1. Stop the JumpCloud services on all your DCs or members servers where the JumpCloud agents are running. You can set them to Disable as well so that they don’t automatically restart when you reboot the machine. 
2. In the ADI settings page, on the Domain Agents tab, pause the Import Agents. 
3. Wait for about 15 minutes for the Import Agents to become deletable
4. Delete the Domain Agents in JumpCloud. At this point, the Users tab will still show the “AD integration” flag, which means that the “Externally Managed” flag is set to “True. 
5. Delete the entire domain from JumpCloud completely. 
6. Convert the “Externally Managed” flag to “False”. You can start off by doing one user at a time and then do all the users in the org. 

There’s a Help Center Article that has these commands and tells you how to do this. And you can find information about our Powershell Module and connecting to your org through Powershell. 

And now we’ve cut the cord from Active Directory. Once you understand what the process is, it becomes a very simple thing to do. If you ever need to reincorporate Active Directory you would just go through the same process that you did the first time. 

Q&A

Q: But JumpCloud is super limited on attributes that it can sync, which can lead to issues where you may still need to use manual processes to set up accounts..

A: We are actively working on Active Directory synchronization. Fingers crossed for Q2 deployment of being able to do all attributes, including custom attributes, between Active Directory and JumpCloud. Um, this is the one environment that we are the most limited in our attributes today. Any SAS app that supports SCIM provisioning, the world is our oyster. It's specifically with the Active Directory Integration, where we have this limited set of attributes. But very, very soon you will see support for a significantly larger portion, including custom attributes. 

Q: What about device management? 

A: The Active Directory Integration is about user management and the ability to sync users. Part of the process to shrink the Active Directory footprint is to move the end user devices to JumpCloud device management. So that would probably come before you pulled the plug on user synchronization. We even have an Active Directory Migration Utility (Active DirectoryMU) that programmatically converts the Active Directory user on the machine to a local user, removes the machines from Active Directory, installs the JumpCloud Agent, and then associates a jumpcloud user to that local user, which binds the machine to a user inside JumpCloud.

Q: There’s a gap that I hope JumpCloud can cover - the concept of shared devices, being able to log into any device on the domain. 

A: I think what you’re talking about is roaming profiles. Roaming profiles are really an aspect specifically of Active Directory from an era where we primarily had physical servers, pre virtualization. Everybody had wired connections. Wifi was rare and everybody had desktop machines, or if they had a laptop, it was a big clunky laptop, right? And the idea of being on the same broadcast domain and everybody being physically in one space made a ton of sense and still to this day roaming profiles are really an aspect of Active Directory specifically. 

So JumpCloud’s method for this is really more about auto binding users to all devices. We have lots of customers who are running medical facilities and whatnot. And they have 20 people, 20 machines. Everybody logs into whatever machine they want. So the intention here is you can easily set up a user group that's called “All Users”. And then you can set up a device group that's called “All Windows Devices”, and you can cross bind those two groups together. And now all the users from that user group will automatically be bound to all devices.

Then users can now log into each device. Of course, this is not a roaming profile. So they're Desktop isn't necessarily following them, but this works really well in the modern era where everything is done online. The vast majority of companies are just starting a browser. So if all you need to do is authenticate a user to a device and enforce MFA to log into that device and then let them start a browser, right? Having this individual profile on each machine is a really viable solution. We call it hot desking. That's kind of the new-ish term. The idea with hot desking is you just set this up automatically.

Nowadays, with JumpCloud, we have dynamic groups. You can have a dynamic group that's “All Windows Machines”. You set up a dynamic group that's “All Users” or all users of a certain department. That user can automatically be assigned to a group and then will automatically be provisioned to all 500 machines that you have. And then when you decommission that user, when you suspend that user within 60 seconds or so, they are suspended on every single one of those computers that cannot log in, their account is disabled.

So we have a solution. It doesn't exactly mirror roaming profiles, but I think as Active Directory becomes less and less prevalent, at some point, Active Directory will go away, and then the older concept of roaming profiles will go away as well.