The U.S. Department of Homeland Security Cyber and Infrastructure Security Agency (CISA) recently issued an urgent “shields up” warning in response to an appreciable rise in criminal activity and geopolitical turmoil. In order for IT to accomplish its mission to drive business productivity, company leaders must prioritize IT’s security efforts, since security goes hand-in-hand with using technology productively.
Decisions about which Identity and Access Management (IAM) to adopt for better security aren’t always straightforward; there are many factors to consider. The most significant consideration is, “does my platform follow a Zero Trust approach from end-to-end?”
Lately, the term Zero Trust has become ubiquitous within product marketing in response to these emerging threats. It’s a popular phrase but, too often, is used incorrectly. The simplest definition is: Zero Trust is a concept about how to approach security.
It impacts identity, workloads, devices, networks, and data. IAM is present throughout those segments and plays a vital role in verifying that users and devices are always who and what they say they are, and thus eligible to securely access IT resources.
The JumpCloud Directory Platform and Microsoft’s Active Directory Federation Services (AD FS) are two popular IAM systems that are used to federate identities to IT resources across domains. This article compares AD FS and JumpCloud to help you make an informed decision about which platform is better suited for your Zero Trust IT security strategy.
AD FS Versus JumpCloud
The most immediate difference between these IAM platforms is best illustrated by their architecture. What the user experiences is less significant than what’s happening behind the scenes.
Introduced in Windows 2000, Active Directory was intended to operate behind the firewall to control identity, authentication, and authorization. IT has changed dramatically over the past two decades and SAML-based SSO grew in popularity as a solution that works across domains. AD FS extended Microsoft’s legacy Active Directory architecture to the web, providing SSO everywhere.
However, it accomplishes that in a very convoluted manner: organizations must deploy, configure, and manage a server farm in addition to any requisite network infrastructure (such as load balancers) to make this happen.
It is, by Microsoft’s own admission, very difficult.
“We do not recommend this option [AD FS] unless you need federated single sign-on and on-premise password management. This path is more difficult and expensive, requires the management of multiple servers, and is only relevant for districts with complex security set-up and requirements,” wrote Microsoft in guidance for its customers in education.
Domain controller(s) running the AD FS role and other servers running a Web Application Proxy role are requisite building blocks, which attack surface area and increase IT management overhead. Microsoft requires that you build a server farm just for SSO. However, your domain controller was never intended for SSO across the WAN. AD FS is essentially a hack to deliver it.
In comparison, JumpCloud was intended for the domainless enterprise where a cloud LDAP directory, IAM platform, and lightweight agents deliver easy-to-configure SSO. There’s no legacy, no servers to manage, and more importantly, nothing that wasn’t engineering for the job that it’s performing. Additionally, JumpCloud has a Zero Trust framework where trust isn’t liberally granted to “joined” devices. That’s a key difference: domain controllers are inherently “trusting;” JumpCloud isn’t.
AD FS Violates Zero Trust Principles
Inherent trust, or in Microsoft’s terminology “trust relationship,” is the principle that Active Directory is willing to provide carte blanche access to Windows devices on its domain once the initial access transaction is complete. An entire ecosystem of security tools exist to ensure that a device should be trusted. As you can see, inherent trust is the exact opposite of the Zero Trust ethos. Microsoft domain controllers embrace and trust joined devices. That trust extends to whatever else that domain has access to.
User Authentication Workflows
|Sign into the managed deviceLaunch a user portal sessionEvery instance requires a username and password (or even MFA) to get access to apps.||Log into a domain resource (typically and domain-bound device)The user is then automatically authenticated and authorized to access any given single sign-on (SSO) app.|
As you can see, because there’s fundamental trust in the domain resource itself with AD FS, it is not a Zero Trust-abiding citizen. AD FS is giving the bound device the “keys to the kingdom,” unless IT admins are very careful to harden and secure access using even more services (and costs). It takes a lot of work to secure each of the components in an AD FS configuration.
Securing AD FS is Resource Intensive and Costly
A domain controller’s security is determined by how well it’s maintained through patching, endpoint detection and response (EDR), physical security, and various other considerations. It’s really an uphill battle: there’s a steady flow of new, zero-day vulnerabilities for Windows Server every other Tuesday. It can be difficult for small and medium-sized enterprises (SME) to keep pace with system maintenance. Bad actors are rapidly able to exploit bugs in the wild because they are sophisticated and operate like well-organized corporations. 2021 broke the record for zero-day hacking attacks. Running servers is riskier than ever: these groups are relentless and financially incentivized to keep attacking SMEs.
Don’t just take our word for it: Cozy Bear, a group believed to be affiliated with Russian intelligence, exploited a weakness in AD FS’s authentication stack late last year. Over 140 Microsoft resellers were targeted and of those, 14 organizations were compromised. Even Microsoft certified experts are facing an uphill battle due to AD FS’s high complexity.
You may ask, “Should my mission critical applications automatically trust a domain controller?” No, they should not; however, that trust is fundamentally baked in if you’re using AD FS to enable SSO. That’s definitely not what Zero Trust is. AD FS is a continuation of the vendor lock-in that Active Directory created and an added convenience for IT teams working within the Microsoft ecosystem. But convenience and familiarity aren’t reasons to eschew modern infrastructure.
Security, for a Price
As previously stated, AFDS isn’t completely without security. Windows Server can be locked down fairly well. It’s just impractical to expect SMEs to layer on the services, threat hunting, and other activities that a Security Operations Center (SOC) would perform. Microsoft sells a tangle of services that could increase security, via Azure AD (yet another IAM services platform). There are three different threat and security operations tools for Azure AD alone. Your bills climb, just to keep faithful with Microsoft’s best practices for AD FS deployments, aspirin not included.
It’s possible to enlist experts to handle intensive security for you if you have the budget. Otherwise, you can’t spend your way to security by buying more “stuff”. The quantity of security services that you have probably been deploying isn’t necessarily correlated with actual security. In comparison, the concept of Zero Trust security is already present by design within JumpCloud.
JumpCloud’s Cleaner Architecture Complements Zero Trust
Now, let’s examine the basic JumpCloud SSO workflow, which has distinct and consequential differences from AD FS. The JumpCloud user experience begins similarly to AD FS:
- You sign into the managed device with your credentials.
- You authenticate with multi-factor authentication (push MFA when enabled)
- You launch a user portal session with a username and password to get access to your apps.
But rather than your device being bound to an inherently trusted domain resource, SSO authentication assumes nothing is trusted until you verify your identity. It is distinct from logging into a PC that’s making a single authentication request to the domain controller. JumpCloud also extends MFA to RADIUS and other protocols with the mission being connecting you to more things securely, built upon open standards, not just extending our “stuff” in new ways. This approach is more closely aligned with Zero Trust.
Think back to device trust. Hardening policies (also known as benchmarks) and other rules/policies are automatically applied when users are added to a group or even individual devices. Access is also determined by user attributes that provide an automated “check” on all group memberships and, ultimately, SSO (SAML) access to IT resources. This doesn’t occur with Active Directory, where users can be forgotten and permissions may be elevated due to nested groups. In contrast, JumpCloud provides multiple layers of conditions that reduces the risk of users being overprovisioned with too much access, and they’ll never be “forgotten.”
Greater Security in the Cloud
JumpCloud’s services are assured by reputable independent assessments and audits and the company has completed a SOC 2 Type 2 examination for its Directory platform, which must be renewed and earned indefinitely. We conduct multiple penetration tests annually, practice secure-by-design development, and maintain a vulnerability disclosure program. Let’s be realistic, these audits won’t occur on an SME’s AD FS server farms, unless they’re required.
What’s more, JumpCloud’s Platform Plus adds to your Zero Trust posture by incorporating additional “asks” from a device before permitting access to resources. For instance, Conditional Access rules can specify which apps require MFA every time or cannot be accessed from outside of a specific region. This is exactly the type of Zero Trust configuration that modern IT should strive toward using, especially when authorities are warning that it’s time to have your “shields up.” JumpCloud’s IAM platform can fulfill a crucial role within your Zero Trust strategy.
JumpCloud Puts You in the Driver’s Seat
JumpCloud makes advanced Zero Trust concepts for IAM more approachable, and is designed for the modern “remote work from anywhere” paradigm. Conversely, AD FS was constructed on top of mounds of legacy, and is weighed down by higher management overhead and “trust”. There’s no escaping it: trust underlies every Windows domain controller. That’s just how it works. Organizations that are serious about Zero Trust should take that understanding into account when assessing what to do with their security program and not simply accept the risk.
JumpCloud gives you the option to decide who to use as your Identity Provider (IdP). If you want Azure, just configure JumpCloud to use Azure AD … or Google, or JumpCloud. The choice is yours. With JumpCloud, you don’t have to buy the hardware to run Active Directory (AD DS) over one (or more) domain controllers. JumpCloud operates as a standalone directory or it can import and sync identities. Using Active Directory, users no longer have to consign themselves to AD FS’s legacy “domain trust.” JumpCloud can fully coexist with Microsoft domain controllers to extend Active Directory with JumpCloud’s SSO.
IT admins should ask themselves, “can I do more for less, and will I be secure?”. The answer is a strong “yes.” JumpCloud’s architecture is more attuned to Zero Trust, without piling on additional services, and gets you there faster and more completely than configuring AD FS.
JumpCloud is a cloud directory service with advanced IAM capabilities throughout its platform, securely connecting you to more resources than on-premise solutions at a lower cost. It’s free to try for up to 10 users/devices with complimentary premium support during your first 10 days.