{"id":43163,"date":"2019-12-03T08:00:00","date_gmt":"2019-12-03T08:00:00","guid":{"rendered":"https:\/\/jumpcloud.com\/?p=43163"},"modified":"2024-01-26T15:12:04","modified_gmt":"2024-01-26T20:12:04","slug":"is-azure-ad-an-identity-provider","status":"publish","type":"post","link":"https:\/\/jumpcloud.com\/blog\/is-azure-ad-an-identity-provider","title":{"rendered":"Is Azure AD an Identity Provider?"},"content":{"rendered":"\n

Having a central Identity Provider (IdP) for your IT administration has never been more critical for an enterprise\u2019s security and productivity, and likewise, as an industry term it\u2019s never had more meanings. But more often than not, when someone mentions their IdP they\u2019re usually talking about Microsoft\u00ae Active Directory\u00ae and its role in Identity and Access Management (IAM).
<\/p>\n\n\n\n

But let\u2019s 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. 
<\/p>\n\n\n\n

\n
\n \"JumpCloud\"\n <\/div>\n
\n

\n Breaking Up with Active Directory <\/p>\n

\n Don\u2019t let your directory hold you back. Learn why it\u2019s time to break up with AD. <\/p>\n <\/div>\n

\n Read Now<\/a>\n <\/div>\n<\/div>\n\n\n\n\n

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.<\/p>\n\n\n\n

For this particular foray into the IdP discussion, we\u2019ll be focusing primarily on Active Directory\u2019s role as an IdP, the advent of Azure Active Directory after it, and how the two interweave to create IdP options for today\u2019s sysadmins.<\/p>\n\n\n\n

Active Directory\u2019s Origins<\/h2>\n\n\n\n

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.
<\/p>\n\n\n\n

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\u2019t 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.
<\/p>\n\n\n\n

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 \u2014 and there was no theoretical limit to how many you could make. Given enough storage, you could create billions of objects. <\/p>\n\n\n\n

IdP Becomes Mission Critical<\/h2>\n\n\n\n

With all of this power and control centralized within one directory services platform under the IT admin, the importance of an enterprise\u2019s IdP could not (and still cannot) be overstated. 
<\/p>\n\n\n\n

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).
<\/p>\n\n\n\n

Thus, as your company grows, it becomes even more crucial that your IdP and it\u2019s requisite extensions are airtight, nimble and running like a well-oiled machine; that it\u2019s kept up-to-date with patches and protocols; and that it\u2019s 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. <\/p>\n\n\n\n

Shifting IdPs to the Cloud<\/h2>\n\n\n\n

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.
<\/p>\n\n\n\n

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\u00ae 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. 
<\/p>\n\n\n\n

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\u2019t going to sit back and become obsolete. This brings us to Azure Active Directory. <\/p>\n\n\n\n

The Introduction of Azure<\/h2>\n\n\n\n

Many people oversimplify Azure AD by saying it is the cloud version<\/a> of Active Directory, when really it\u2019s an extension of AD into the cloud, and has a number of different capabilities.
<\/p>\n\n\n\n

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\u2019s 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. <\/p>\n\n\n\n

So is Azure Active Directory an Identity Provider?<\/h2>\n\n\n\n

The answer is both yes and no, depending on how limited or comprehensive your preferred definition of an IdP is. <\/p>\n\n\n\n

While Azure is touted as a cloud-based identity solution, it was really created as a directory extension<\/em> and still requires dedicated servers on-prem to manage and operate. It\u2019s 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. <\/p>\n\n\n\n

(To be clear, you can run Azure AD as a standalone without Active Directory, but you\u2019ll 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).<\/p>\n\n\n\n

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).  <\/p>\n\n\n\n

Given these parameters, one can see why Azure cannot fully function as a complete IdP on its own \u2014 at the end of the day, it struggles with both non-Azure services (outside of the select web applications it\u2019s tied in with) as well as on-prem IT resources. <\/p>\n\n\n\n

What Azure AD Was Made For<\/h2>\n\n\n\n

Azure AD was never meant to be a cloud replacement for Active Directory, but a cloud complement<\/em> to AD\u2019s on-prem directory service. Think of it this way: Microsoft didn\u2019t 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. <\/p>\n\n\n\n

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: <\/p>\n\n\n\n