{"id":43163,"date":"2019-12-03T08:00:00","date_gmt":"2019-12-03T08:00:00","guid":{"rendered":"https:\/\/jumpcloud.com\/?p=43163"},"modified":"2024-12-20T15:00:20","modified_gmt":"2024-12-20T20:00:20","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 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
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 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
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
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
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. 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 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 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 Now, Azure AD does have some great features, there\u2019s no denying that. Because it doesn\u2019t disrupt customers with their existing IdP, but provides a way for users to connect to Office 365 and other services, it\u2019s 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\u2019t have to purchase other web app SSO solutions. However, if you\u2019re 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. <\/p>\n\n\n\n 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\u2019s managed services. Azure AD \u2014 like Active Directory \u2014 is also a complex beast with a sharp learning curve, and requires extensive training to fully manage and operate. And while it\u2019s 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<\/em>. First of all, you\u2019re not switching to the cloud with Azure AD, you\u2019re 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 \u2014 and it does keep the credentials in sync \u2014 any write-back flows<\/a> require a paid Azure AD tier. And lastly, if you\u2019re extending your on-prem AD to the cloud with Azure (in order to establish the two as your combined IdP), you\u2019re that much more locked in to Microsoft solutions \u2014 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. <\/p>\n\n\n\n There is an alternative when it comes to establishing and managing your IdP however, whether you\u2019re 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.\u00a0<\/p>\n\n\n\n This is where JumpCloud can make a real difference. It\u2019s an open directory platform with a simple, user-friendly interface that is agnostic to user system, location, protocol, and provider. It\u2019s 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.\u00a0<\/p>\n\n\n\n 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<\/a> or check out our YouTube channel<\/a>. Having a central IdP has never been more important, but there\u2019s confusion about how Azure AD provides Identity and Access Management (IAM) for IT Admins.<\/p>\n","protected":false},"author":93,"featured_media":43164,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_oasis_is_in_workflow":0,"_oasis_original":0,"_oasis_task_priority":"","inline_featured_image":false,"footnotes":""},"categories":[2781],"tags":[],"collection":[2777],"platform":[],"funnel_stage":[3016],"coauthors":[2599],"acf":[],"yoast_head":"\n
<\/p>\n\n\n\nSo is Azure Active Directory an Identity Provider?<\/h2>\n\n\n\n
What Azure AD Was Made For<\/h2>\n\n\n\n
\n
<\/p>\n\n\n\nThe High Cost of Azure AD + AD<\/h2>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n\n\n\nJumpCloud: The Future of IdP<\/h2>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"