The Truth About Azure Active Directory

Written by Todd Peterson on August 15, 2022

Share This Article

If you listen to Microsoft, the world of technology begins and ends with Azure. While Microsoft Azure has carved out a significant chunk of the technology landscape, it is far from the ubiquitous infrastructure requirement that Microsoft Active Directory represents (the foundation for enterprise deployments of Windows networks). 

The intent of this blog is to make a case for openness and pursuing modern, cloud-based technology initiatives without the monolithic approach that Microsoft so successfully promoted in the pre-cloud world.

To start, we need to level-set on exactly what we are talking about.

  • Azure is Microsoft’s cloud infrastructure platform. All cloud-based solutions that Microsoft offers are embraced within the Azure world. Many non-Microsoft solutions are built on Azure infrastructure. And, a fair number of organizations host their cloud presences on Azure.
  • Azure Active Directory (AAD) is Microsoft’s cloud-based directory service purpose-built to provide access (basically single sign-on) to Microsoft services such as Microsoft 365 (formerly Office 365) Sentinel, Teams, InTouch, etc. AAD can also embrace standards-based, non-Microsoft applications in the same SSO world.
  • Active Directory (AD) is Microsoft’s 20+-year-old on-premises directory service that allowed them to win the networking war and gain a 95% market share. It does not support cloud-based technologies and is similar to Azure AD in name only.

AD and AAD have absolutely no overlap; said another way, AAD is not simply a cloud copy of AD. Until the last on-prem resource is turned off, an AD organization must continue to use AD. For organizations looking to take advantage of Microsoft cloud services such as Microsoft 365, AAD is an absolute necessity – regardless of the existing on-prem AD stance. Microsoft offers integration to synchronize AD and AAD, but the integration is fairly difficult and doesn’t actually duplicate AD-established security and management principles to AAD (or vice-versa).

Microsoft would prefer that all its customers standardize on Microsoft technologies, in particular Azure. All business decisions Microsoft makes are designed to sell Azure, lock customers into Azure, and expand the Azure footprint – and that includes Azure AD.

Considerations for Adopting Azure AD

When evaluating whether to adopt Azure AD, standardize on AAD, or avoid AAD, there are several important considerations.

How does my decision impact future options? 

Azure AD device management is meant to lock deploying organizations into an ever-expanding Microsoft ecosystem. A decision to standardize on AAD will dictate which future technologies you can easily adopt. For example, standardizing on AAD for the sake of using Microsoft 365 will obstruct a future move to Google workspace and stand in the way of easy adoption of Macs.

What compromises do I have to make as I migrate from AD to AAD? 

As mentioned earlier, AAD is not simply a cloud copy of AD. The two have entirely different structures and security models, use different authentication and administration standards, and support different technologies. 

For example if an organization has a well-established group structure in AD that controls access to resources, it is impossible to duplicate that structure in AAD. Consequently, the AAD deployment would have to involve a built-from-scratch security structure (which can have nowhere near the depth, flexibility, and granularity established in AD).

What critical systems does Azure AD not support, and how will I deal with them? 

Virtually everything supported by AD is not supported by AAD. Therefore, access to AD-connected resources such as those requiring LDAP or RADIUS for access cannot be accessed or secured via AAD. The solution requires heavy and troublesome integration efforts, continued siloed management, or purpose-built point solutions to hide the complexity. In addition, it is very difficult to integrate non-Windows systems (such as Macs and Linux) with AD and/or AAD.

Additional Reading: Connecting Your LDAP Server and Resources to Azure AD

Who’s pockets am I lining and do they have my best interests at heart? 

Azure AD is designed to make all users a predictable, locked-in revenue stream for Microsoft. The locked-in nature of the relationship means that Microsoft’s top priority is selling more Microsoft services and standing in the way of adoption of non-Microsoft services – even if those non-Microsoft services are the best solution for the job at your organization. In addition, small-to-medium enterprises are typically those left lacking with regard to support, input, and innovation.

Does adding AAD to my enterprise overcome the security challenges of AD? 

The short answer here is “no”. Since AD and AAD are entirely unrelated and it is nearly impossible to fully migrate away from AD for most organizations, adding AAD to the mix offers false hope. Ninety percent of breaches involve on-prem AD in some form or another, and some attacks (for example the SolarWinds exploit) start with AD vulnerabilities and move quickly into AAD. 

The bottom line is Azure AD will struggle to support areas of your environment that are not firmly entrenched in the Microsoft ecosystem. Consequently, support for legacy resources (such as RADIUS– and LDAP-based systems), non-Windows devices (such as Macs and Linux), and even alternative authentication methods such as non-SAML federation, delegated authentication, non-Microsoft multi-factor authentication, and conditional access are all impossible without significant customized integration efforts or a number of siloed point solutions. In addition, AAD has no native support for alternative sources of identity such as an HRIS system, an alternate IdP such as Google or Okta, or even on-prem Active Directory.

graphic showing what Azure AD supports

Alternative Solutions to Azure AD

In spite of the challenges, the reality for many organizations is that they must have at least some Azure AD presence. But the opportunity to use AAD in the right way without it becoming a barrier to growth, innovation, and change is paramount. JumpCloud’s open directory platform delivers an extremely capable alternative to Azure AD or the way to implement AAD while avoiding the negative consequences detailed above.

  • JumpCloud ensures flexibility and the freedom of choice to grant users the right access, to the right resources, in the right way regardless of what technologies exist (for example AD and AAD) and what may be added in the future.
  • JumpCloud eliminates the compromises of migrating from AD to AAD. JumpCloud can take established AD security structures (for example group memberships) and enforce them on all connected resources – including those that require AAD for access.
  • JumpCloud grants a unified identity, access, and device management paradigm that embraces the full range of connected systems including those using modern protocols such as SAML and SCIM, as well as legacy need such as RADIUS and LDAP, and all device types including Windows, Mac, and Linux.
  • JumpCloud empowers you to implement the technologies that are best for the job. It doesn’t lock you into a monolithic and limited approach (such as standardizing on Microsoft). It integrates with whatever you have, whatever you will be getting, and can change as you evolve.

Try JumpCloud

The JumpCloud Directory Platform is ideally suited to optimize your Azure AD deployment and is free for up to 10 users or devices with complementary chat support available during the initial 10 days of your account’s creation.

Todd Peterson

Continue Learning with our Newsletter