Share This Article
Having a central Identity Provider (IdP) for your IT administration has never been more critical for an enterprise’s security and productivity, and likewise, as an industry term it’s never had more meanings. But more often than not, when someone mentions their IdP they’re usually talking about Microsoft® Active Directory® and its role in Identity and Access Management (IAM).
But let’s not get ahead of ourselves. First and foremost, an identity provider is the secure storage mechanism for employee user identities. When employees leverage these identities as credentials to access IT resources such as systems, applications, file servers, and so on, the IdP acts as the definitive source of authentication (authn) and authorization (authz). This in turn verifies that a user is indeed allowed access to the resource, as well as what they can access within that particular resource.
Breaking Up with Active Directory
Don’t let your directory hold you back. Learn why it’s time to break up with AD.
An IdP can do this because it is also a directory of user attributes, which are critical in better describing the specific employee, their role within the company, and other key traits that help to ultimately give them the authorizations and permissions they need to get work done. Within Active Directory (and in addition to AuthN and AuthZ), it also provides a structure of groups to manage policies, called Group Policy Objects, that admins can use to control whole fleets of systems. In a sense, there are three aspects to the modern definition of an IdP: authentication, authorization, and system management.
For this particular foray into the IdP discussion, we’ll be focusing primarily on Active Directory’s role as an IdP, the advent of Azure Active Directory after it, and how the two interweave to create IdP options for today’s sysadmins.
Active Directory’s Origins
Active Directory was introduced with Windows 2000 as an IdP authentication and authorization database, and the world has never been the same. It replaced the NT4 domain model, which had by then become woefully inefficient.
The NT4 model, for example, had a max size of 40Mb, and a maximum of 26,000 objects in a flat-file receptacle. It contained only five different fixed objects whose properties couldn’t be changed, and it relied on Net BIOS for its name resolution. This meant that many enterprises ended up needing a number of domain databases that had very constrained and complex interactions between them. For a very early directory service it was useful, but the benefits of a directory and how IT organizations wanted to use it far outstripped its capabilities.
AD was remarkably different, and with seemingly limitless potential. It was built upon the X.500 hierarchical network standard, used TCP/IP protocols for communication, and used DNS for name resolution. It also brought with it the idea that there could be a set of rules overseeing everything within it, along with the definitions of not only objects, but their attributes and features, housed within a single domain. These could then be drawn upon and expanded into new features of existing objects, or new objects altogether — and there was no theoretical limit to how many you could make. Given enough storage, you could create billions of objects.
IdP Becomes Mission Critical
With all of this power and control centralized within one directory services platform under the IT admin, the importance of an enterprise’s IdP could not (and still cannot) be overstated.
As the central source of identity and authorization, it is equivalent to the air traffic control tower of an airport; it controls communication between users and resources, telling them who is allowed to do what, where, and how. And as an organization grows, this central authority does as well, increasing in both complexity (i.e. more combinations between objects) and criticality (more users and IT resources relying on it). Over the years, as the IT landscape has grown and changed, the IdP has morphed as well with add-ons such as multi-factor authentication (MFA) and web app single sign-on (SSO).
Thus, as your company grows, it becomes even more crucial that your IdP and it’s requisite extensions are airtight, nimble and running like a well-oiled machine; that it’s kept up-to-date with patches and protocols; and that it’s one step ahead of those who would exploit it at all times. Increasingly, this has meant that IT organizations consider either partially or completely moving to the cloud.
Shifting IdPs to the Cloud
The cloud, of course, changed everything. Most important for our purposes, it brought along web applications, most of which can use SAML-based protocols for user authentication. Beyond these however, cloud infrastructure (e.g. AWS, GCP, and others), the influx of macOS and Linux systems into the workforce, Samba-based file servers, WiFi/VPN networks, and much more created additional challenges for IT organizations.
These new types of IT resources, many not having been created by Microsoft, struggled to connect with AD. The root of the problem was that AD was and is designed to work best with Windows® and on-prem networks, and because of this, a host of add-on solutions began to appear that could bridge the gap between AD and these new resources.
This is when we see the birth of SSO solutions, privileged identity management solutions, Mac/Linux/mobile device management tools, and directory extensions. But Microsoft and Active Directory weren’t going to sit back and become obsolete. This brings us to Azure Active Directory.
The Introduction of Azure
Many people oversimplify Azure AD by saying it is the cloud version of Active Directory, when really it’s an extension of AD into the cloud, and has a number of different capabilities.
Azure AD is essentially a way to manage users on the Azure and Office 365 platforms. AAD is also a web application single sign-on solution that can be used to extend the on-prem AD to these types of applications. Microsoft’s reference architecture for Azure AD includes Active Directory on-prem and other add-ons such as Azure AD Connect, Azure AD DS, and Intune among others.
So is Azure Active Directory an Identity Provider?
The answer is both yes and no, depending on how limited or comprehensive your preferred definition of an IdP is.
While Azure is touted as a cloud-based identity solution, it was really created as a directory extension and still requires dedicated servers on-prem to manage and operate. It’s designed for Azure-based users, systems, and applications, so cannot act alone as an IdP authority for on-prem systems and users; if you want to do that, you have to have both Active Directory and Azure AD.
(To be clear, you can run Azure AD as a standalone without Active Directory, but you’ll need add-ons in order to fully handle components that Azure AD cannot cover. It should also be noted that within this scenario the expectation from Microsoft solutions is that you are largely Windows-centric).
Azure AD also needs a number of expensive and difficult-to-manage added services in order to do what Active Directory and similar IdPs can. For example, if you’re looking to leverage it as an extension of your on-prem AD, it requires Azure AD Connect in order to tether to AD and utilize it for Identity and Access Management (IAM).
Given these parameters, one can see why Azure cannot fully function as a complete IdP on its own — at the end of the day, it struggles with both non-Azure services (outside of the select web applications it’s tied in with) as well as on-prem IT resources.
What Azure AD Was Made For
Azure AD was never meant to be a cloud replacement for Active Directory, but a cloud complement to AD’s on-prem directory service. Think of it this way: Microsoft didn’t want you to stop using AD in favor of Azure AD, but they did see the need for a way to extend AD user identities into the cloud for newer, cloud-based services and SSO capabilities.
So while Azure can manage user identities in the cloud to connect them using SSO to a limited number of web applications, Azure AD alone cannot:
- Push protocols, updates or patches
- Connect users to their networks, WiFi, or RADIUS without the help/purchase of other solutions
- Manage computers, applications, and storage, be they on-prem or in the cloud on other services, like AWS.
- Manage all of your user identities in regard to the device systems they’re working on, unless they’re on Windows 10 or Windows 10 Pro
Now, Azure AD does have some great features, there’s no denying that. Because it doesn’t disrupt customers with their existing IdP, but provides a way for users to connect to Office 365 and other services, it’s a lot easier to leverage those identities for other web apps as opposed to implementing the complex AD FS platform. Assuming your users only need access to the resources Azure AD leverages its SSO capabilities with, this also means that you won’t have to purchase other web app SSO solutions.
However, if you’re thinking of leveraging Azure AD with your existing on-prem AD implementation, be aware that there are other drawbacks apart from those listed in the previous section above.
The High Cost of Azure AD + AD
Running a hybrid IT environment with Azure AD and Active Directory has a big trade off, and requires not just a lot of money up front to establish but continued payment of fees for Microsoft’s managed services. Azure AD — like Active Directory — is also a complex beast with a sharp learning curve, and requires extensive training to fully manage and operate.
And while it’s nice to have a la carte options so that you can only choose those features and services your enterprise specifically needs, the cost of maintaining this kind of IdP can skyrocket fast.
First of all, you’re not switching to the cloud with Azure AD, you’re extending to it, so you still have the cost of managing your on-prem AD operation. This, of course, would include servers, Windows and possibly Exchange licenses, networking and security, backup and redundancy, power and cooling, disks and storage, and the salaries of all the people necessary to manage these necessities and services.
Additionally, features such as directory synchronization from on-prem AD DS to Azure AD requires Azure AD Connect, which costs additional time and resources. And while utilizing a one-way Azure AD sync is free — and it does keep the credentials in sync — any write-back flows require a paid Azure AD tier.
And lastly, if you’re extending your on-prem AD to the cloud with Azure (in order to establish the two as your combined IdP), you’re that much more locked in to Microsoft solutions — and this at a time when branching out from that has never been more advantageous. Users now want to be able to use Mac and Linux operating systems; cloud infrastructure like AWS has enabled widespread innovation; new, cutting-edge web apps are appearing every day, and much, much more.
JumpCloud: The Future of IdP
There is an alternative when it comes to establishing and managing your IdP however, whether you’re looking for a better way to extend your on-prem AD to the cloud, looking for a more robust solution than Azure AD alone can provide, or wanting to replace your directory services altogether.
This is where JumpCloud can make a real difference. It’s an open directory platform with a simple, user-friendly interface that is agnostic to user system, location, protocol, and provider. It’s a centralized, cloud-based identity provider that organizations can leverage for all of their IT resources, because it utilizes core protocols such as LDAP, SAML, RADIUS, SSH, REST, and others. That means it connects to resources on-prem or in the cloud. Additionally, it is quick to learn and to teach, saving you countless work hours.
To learn more about whether Azure AD is an identity provider and how JumpCloud can substantiate or even replace your IdP, feel free to drop us a note for a free demo or check out our YouTube channel.
