Share This Article
A while back we kicked off a new series of whiteboard videos where we discuss the cloud IAM space and how JumpCloud’s Directory-as-a-Service® is challenging traditional identity management methods. The ultimate goal of these whiteboard videos and accompanying blog posts like this one is to simplify complex topics within cloud IAM. In this post, we discuss JumpCloud’s AD Bridge.
The AD Bridge extends Active Directory® identities to the cloud and enables these identities to be deployed to non AD bound resources through the JumpCloud platform.
You are more than welcome to skip straight to the video which you can find below, or continue reading to learn how our AD Bridge can extend your Active Directory identities to Mac and Linux systems, cloud servers, and help reel in your remote offices.
Active Directory and JumpCloud
The first step in AD Bridge is identifying the Active Directory domain controller itself. Active Directory lives on a Windows 2008, 2012, or 2016 server as a role that is configured during the deployment of the server. The next component is JumpCloud and our cloud-based directory services. The integration of these two components is what allows your organization to propagate AD identities out to resources not directly bound to AD.
Integrating AD with JumpCloud
Below we’ll explain how to achieve this integration between Active Directory and JumpCloud in three steps. See the Support Center for AD Bridge for more in-depth instructions.
1. Install the JumpCloud AD Bridge Agent on Domain Controller(s)
The first thing that an IT admin will be doing is installing a special JumpCloud domain controller agent. This agent is installed on every AD domain controller. If you have a fairly elaborate forest of domain controllers that are interconnected, each of those domain controllers must have the AD Bridge agent installed on it. This is to ensure that password propagations – no matter where the authentication changes are coming in from – get properly caught and then securely transmitted out to JumpCloud.
Support Page: Installing AD Bridge
2. Select Users to Extend from AD to JumpCloud
Once the AD Bridge agent is installed onto your domain controllers, it automatically creates the connection to JumpCloud, which is your directory in the cloud. But that doesn’t mean that all of your user accounts in Active Directory are automatically created in JumpCloud. In fact, when you install the agent onto your domain controller, you get to be very selective on what you choose to propagate to JumpCloud. Perhaps there’s just a single subset of your organization that needs to be propagated across to some cloud resources. In that case, then you can use the AD Bridge with just that subset.
Support Page: AD Bridge User and Group Synchronization
3. Create a JumpCloud Group
Once you have identified the users and groups that need to be transported into JumpCloud, the next step is to create a security group called ‘JumpCloud’. When users and other ancillary nested groups are added to this security group, they will be carried across into JumpCloud along with all of their members. So what you get on the other end is literally an instantiation or a copy of those user/group objects from AD. Again, it’s important to emphasize that these objects are still managed by Active Directory. AD remains the source of truth and any users and groups that you’ve added to JC group are kept in sync automatically.
Support Page: Using AD Bridge
How the Directories Sync
The AD Bridge agent is very similar to JumpCloud’s system agent in that it polls for changes on a cadence. In this case, the AD Bridge agent pulls on a roughly 90 second cadence, listening for events like password changes, group membership changes, new users that get added, users that have their names changed, and so on. All of those changes are replicated, fired across, and kept in sync with their JumpCloud versions.
The main point to really drive home here is that JumpCloud is not the authoritative source when the AD Bridge is in place. In this case, that‘s what we’re using AD for. When JumpCloud receives those user identities in security groups, they are replicas. This is in contrast to using JumpCloud as your single, unified cloud directory, which is another use case for Directory-as-a-Service.
Now, what you do with them, this is sort of where the magic comes in.
What does AD Bridge Extend to?
Outside of this AD Bridge relationship, JumpCloud is a full-blown directory. In fact, in many cases it is a replacement of or an alternative to AD, but many of our customers do enjoy using Active Directory and that’s awesome. In this case because we’re a full-fledged directory, it means you get to utilize the benefits of the protocols available via the JumpCloud platform. So now let’s walk through some of the protocols we leverage, and how they enable JumpCloud to meet the needs of a wide range of use cases.
Use Case: Connecting Mac and Linux Systems
First, let’s talk about systems. Through our own system agent, JumpCloud is able to support Windows, Mac, and Linux systems. So, let’s say you have a Macbook that’s owned by a remote employee. The JumpCloud system agent is installed on the Macbook. Your user account that has been propagated over from AD is then utilized to authenticate and gain access to that machine without a VPN. The most important thing to understand here is that while this machine is tied to JumpCloud, there is no domain. Instead, our agent and its connection to JumpCloud is the binding element. So no VPN and no domain is required in our transaction. You simply manage these systems through the JumpCloud admin console.
Support Page: How the JumpCloud System Agent Works
Use Case: Connecting Cloud-Based Servers
Another major use case very similar to an employee’s MacBook, Linux, or Windows instance is cloud-based servers. Again these cloud-based servers could be hosted through AWS, Google Cloud Platform (GCP), or Azure. It doesn’t matter. Just like your workstations or laptops they have the JumpCloud system agent installed and the same process occurs –– port 443, no VPN. If you wish to safeguard your environment behind a firewall or VPN for privileged access to your environment, you can continue to do so. Our agent simply requires that port 443 be available for the agent to receive updates from the JumpCloud admin console. That’s the nuance that’s really important to understand.
Use Case: Connecting Remote Offices
Another very robust use case is having a remote office. You need people authenticating securely with their AD credentials, but you don’t want to have to do all this elaborate networking, tunneling, and – again – VPNs. So this is where RADIUS comes in. Again, the user identities are all AD-controlled identities but our RADIUS protocol services can be used to add remote offices, and have them effectively authenticate to wireless networks using JumpCloud’s RADIUS-as-a-Service. For example, these networks can be configured on Meraki, Mist, or Rukus access points. All of that can be achieved utilizing our RADIUS infrastructure. It’s all managed in the cloud. You don’t touch any servers. You just have to propagate the identity from AD over into JumpCloud.
Use Case: Connecting LDAP Resources
Let’s say you have on-prem resources or resources that access authentication through LDAP. Now clearly AD is the “go-to” place for that, and – in fact – it’s built upon the premise of LDAP. But let’s say you have an app that is running on a Linux sever up in AWS. Let’s also assume it’s an app that is critical like JIRA, Confluence, or some major ticketing system. In this particular case, your application, whether it is web-based or on-prem, can authenticate through LDAP, and again it is the AD credentials that are being used in order to authenticate and gain access to that particular application.
Use Case: Connecting Web-Based Applications
So far we’ve talked about system agents, RADIUS, and LDAP. We also support SAML. The same AD set of credentials can use SAML to federate to about 150 web-based apps that we have supported in the product without the installation of Azure AD Connect (formerly known as Dirsync). Install the agent, select your users and group to propagate to JumpCloud, point and click and give them access to a variety of web apps with minimal complication of networking and other pain that is often associated with trying to work with on-prem directories.
The Big Picture
In all of these various use cases, JumpCloud – as a directory – is playing the role of an extension of your authoritative directory (Active Directory). The vision here is to provide the ability for AD-managed identities to get propagated out and use various authentication methods (LDAP, SAML, RADIUS, etc.). By taking a multi-protocol approach, users can easily gain access to all of the resources they need, and IT effectively controls their environment without a great cost to their time, money, and space.
To view a diagram of our reference architecture, you can click here.
Learn more about JumpCloud and AD Bridge
If you would like to learn more about our cloud identity bridge, reach out to us on the contact page. You are also encouraged to sign up for a free demo, or if you’re ready to try it out for yourself, sign up for a free cloud identity management account. Your first ten users are free forever.
