What is an Active Directory Bridge?

An Active Directory^® (AD) bridge is a tool that allows organizations to continue using AD as their authoritative source of identity, while extending it to systems, apps, and protocols that it cannot natively manage as well as modernizing their access control. Other terms for this type of solution are an Active Directory extension or a cloud identity bridge.

If you’re looking for information specifically on JumpCloud’s AD bridge offering, it’s called Active Directory Integration (ADI). Visit the product page for a full rundown of features and screenshots. The AD bridge extends identities to the cloud and enables these identities to be deployed to non-AD bound resources through JumpCloud’s open directory platform.

You’ll find a more detailed definition of an AD bridge below, along with some background on the state of AD, the directory services landscape, and why so many organizations are looking to modernize or replace legacy AD deployments with more productive alternatives.

Why Modernize Active Directory?

If you look back to the turn of the century, you would see a primarily Windows on-prem environment across organizations. Users walked into the office each day, sat down at their desks, plugged into a private network, and authenticated their identities against an on-prem Active Directory domain controller (DC). Microsoft stored user identities on private Windows servers in a data center somewhere on-site, which enabled seamless access to resources like Windows-based applications, productivity platforms, and storage devices to name a few.

Things look very different today. Other operating systems (e.g., Android, Linux, Mac, and Windows), wireless access points (WAPs) and networks, remote users, and cloud resources are the norm. While these and many other aspects have changed, one thing has stayed the same — namely, Active Directory. AD is a legacy technology that’s central to many digital estates, but it doesn’t meet requirements anymore. Microsoft positions AD as a legacy technology because of its functional constraints and security issues.

Active Directory Limitations

Many organizations still leverage AD for directory services, and it’s especially true when they have more mature IT infrastructures. The challenge for these types of organizations is extending user credentials to manage resources that fall outside of the Active Directory domain, namely, non-Windows systems, applications, and cloud resources. It also lacks modern authentication.

Cross-OS Device Management

For example, centralized management for Mac and Linux systems has always been notoriously painful to implement and maintain with AD. 

At the same time, AD is so entrenched within the infrastructure of an organization that getting rid of it is improbable. As a result, it is not uncommon for these non-Windows systems to go unmanaged, which is something that Microsoft’s new access control model for AD and Zero Trust modernization plan discourage.

Access Control

AD was designed and built to manage Windows endpoints, and managing a heterogeneous OS environment requires additional solutions. More importantly, not every device that accesses resources via AD has to be compliant or managed. Therefore, it’s possible for attackers to take advantage of poorly managed trusted PCs as an entry point into networks. 

AD also fails to explicitly validate trust for all access requests. This weakness, along with security vulnerabilities within Windows, can lead to privilege escalation using techniques such as forged Kerberos trust tickets to gain unauthorized access within AD domains. AD treats the firewall, not identities, as the only perimeter. That is a dated approach that has security risks.

AD also requires add-ons to provide single sign-on (SSO), privileged access management (PAM), and multi-factor authentication (MFA). AD lacks essential identity and access management (IAM) capabilities that are required for modern IT environments. Those include:

• Single sign-on
• MFA/user verification
• Conditional access/ZTNA policies
• Modern authentication schemes like OIDC
• Advanced user lifecycle management
• Cross-platform device management

Lifecycle management and authorization are also limited in AD, which increases security risks and management overhead. Members of child groups in AD inherit the entitlements of their parent group(s), which can result in unintended entitlements, entitlement conflicts, troubleshooting challenges, etc., especially when there’s a complex organizational structure.
Fortunately, JumpCloud’s AD bridge, ADI, makes it possible to extend multi-domain environments to the cloud in order to modernize AD for Zero Trust, and gives the choice to either keep AD as the authentication store or use a cloud identity provider (IdP) such as JumpCloud.

Breaking Up with Active Directory

Don’t let your directory hold you back. Learn why it’s time to break up with AD.

Read Now

Active Directory and JumpCloud

JumpCloud integrates cloud IAM with universal endpoint management (UEM) and other essential tools that are necessary to manage your devices like patch management and remote access with remote assistance. JumpCloud also increases IT efficiency by providing automations for device and user lifecycle management through dynamic groups, which is a more mature and admin-friendly approach. ADI has flexible configuration options, and is simple to set up. It makes it easy to get started by syncing users, groups, and passwords between JumpCloud and on-premise or off-premise AD. ADI supports several use cases, including:

• Extending your AD instance to support additional capabilities in the cloud
• Minimizing AD’s footprint without replacing your current implementation
• Migrating away from AD entirely

Integrating AD With JumpCloud

Below, we’ll explain how to achieve integration between Active Directory and JumpCloud in three steps, based upon your use case. See the Support Center for ADI for in-depth guidance.

1. Prepare for the Agent Installations in AD

The first step in using ADI is to identify the Active Directory domain controller (or member servers) where the ADI Sync Agents will be installed. Your use case will determine which agents are required, the direction of the sync, and which directory serves as the authority. 

Please review the following chart to select the appropriate deployment configuration:

Installing agents on each DC ensures that password propagations — no matter where the authentication changes come from — get properly identified and then securely transmitted to JumpCloud. Sync Agent services use TLS for all communication and traffic is outbound (only) to console.jumpcloud.com. ADI supports multi-domain workflows as a migration path.

Check out the step-by-step configuration guide that aligns with your use case:

• Configure ADI: Manage users, security groups, and passwords in AD
• Configure ADI: Manage users, groups, and passwords in either, or both, AD and JumpCloud
• Configure ADI: Manage users, groups, and passwords in JumpCloud 

The installation steps may vary depending on your use case, but may include:

• Completing the prerequisite checklist
• Determining the Root User container in AD
• Creating the JumpCloud ADI Integration Security Group in AD
• Creating the AD Import Service Account
• Creating the AD Sync Service Account
• Delegating control for the AD Import and AD Sync Service Accounts

2. Create an ADI Instance in JumpCloud

The next step is to create a new ADI instance, following the directions from your configuration guide. This is done through the Directory Integrations blade of the JumpCloud Admin Portal. You’ll be guided through the process of selecting your use case to download the Import Agent and/or Sync Agent. There will be installation and post-installation steps to follow to get the service started and to configure the agent(s). These steps are documented in the guides linked above.

3. Use and Manage the AD Bridge (ADI)

Once the AD bridge agents are installed onto your domain controllers (or member servers) and configured, they automatically create the connection to JumpCloud. You can assign a subset of your organization that needs access to cloud resources or device management. The support article linked below provides a detailed description of how to use the agents to manage users, groups, and passwords in JumpCloud as well as some best practices for managing ADI. 

Support page: Use and Manage the Active Directory Integration

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 user updates, user edits, etc. Changes are replicated and synced with corresponding JumpCloud directory objects. Here’s an overview of the synchronization workflows:

AD Import Only – Single Domain Workflow

AD Import Only – Multiple Domain Workflow

Two-Way Sync – Single Domain Workflow

Two-Way Sync – Multiple Domain Workflow

What Does AD Bridge Extend To

Beyond this AD bridge relationship, JumpCloud is an open directory platform. In many cases it is a replacement or alternative to AD; it makes modernization and extending AD possible. In this case, because JumpCloud is 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 and how they enable JumpCloud to meet the needs of a wide range of use cases.

Use Case: Connecting Android, Mac, and Linux Systems

JumpCloud is able to manage Windows, Android, Mac, and Linux endpoints through its agent or mobile device management (MDM). 

No VPN or domain is required; you simply manage these systems through the JumpCloud admin console using pre-built or custom policies, commands, or optional remote access. You can even deploy applications via a custom repository to streamline onboarding. MDM provides assurance that security settings are enforced, and access to resources on Macs and Windows can be pretended by a phishing-resistant credential. 

JumpCloud even federates with other IdPs, such as Okta, for cross-OS device management.

Support page: How the JumpCloud System Agent Works

Use Case: Connecting Cloud-Based Servers

Managing cloud-based servers on AWS, Google Cloud Platform (GCP), or Azure is another use case. 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.

Use Case: Connecting Remote Offices

Another robust use case involves the remote office. 

You need people to authenticate securely with their AD credentials, but you don’t want to have to do elaborate networking, tunneling, or use VPNs. So this is where RADIUS comes in. Again, the user identities are all AD-controlled identities but RADIUS protocol services can be used to add remote offices, and have them effectively authenticate to wireless networks using JumpCloud’s Cloud RADIUS. 

For example, these networks can be configured on Meraki, Mist, or Ruckus access points. All of this can be achieved utilizing JumpCloud’s RADIUS infrastructure from the cloud. Just use the AD bridge to propagate identities from AD into JumpCloud. JumpCloud provides environment-wide MFA, including certificate-based authentication for RADIUS to eliminate passwords and strengthen security.

Use Case: Connecting LDAP Resources

Let’s say you have on-prem resources or resources that access authentication through LDAP. JumpCloud’s cloud LDAP service provides MFA-protected access to resources with no hardware requirements. This is useful for applications and hardware that have network compliance requirements for MFA. JumpCloud helps to secure your network infrastructure.

Use Case: Connecting Web-Based Applications

So far we’ve talked about system agents, RADIUS, and LDAP. JumpCloud also supports SAML and OIDC. 

Optional conditional access helps to secure access to resources, especially for privileged accounts. The same set of AD credentials can use web protocols to federate to SSO apps that JumpCloud supports in the product without the installation of Entra AD Connect (Azure AD Connect). Install the agent, select your users and groups to propagate to JumpCloud, point and click, and give them immediate access to a variety of web apps.

Learn More About JumpCloud and AD Bridging (ADI)

JumpCloud’s AD bridge solution, ADI, makes it easy to extend/modernize your Microsoft AD-managed identities to authenticate with cloud-based and non-Windows resources that aren’t supported by AD directly. It also provides cross-OS device management, advanced lifecycle management, and modern authentication to reestablish the strong access control AD once had.

Extending Active Directory isn’t for every organization. If you have no directory or if you have limited investment in your existing Active Directory infrastructure, it probably makes more sense to transition completely to a cloud-based directory. JumpCloud has the resources to support you.

To learn more about how JumpCloud’s AD Integration can benefit your organization, drop us a note. We invite you to get started with JumpCloud for free to see if ADI is the right fit for your organization.