Active Directory is the foundation for secure access to corporate resources by users, services, and connected devices. It does this by providing identity management capabilities such as authentication, authorization, and access control to secure the resources of your business or organization. Active Directory can be implemented either on-premises using the well-known Windows Server Active Directory Domain Services (AD DS) or you can make use of Azure Active Directory (Azure AD), which is Microsoft’s multi-tenant cloud-based directory and identity management service hosted in Microsoft Azure. Or you can do both by using Azure AD Connect (AAD Connect) to create a hybrid Active Directory environment that provides the best of both worlds by joining your on-premises AD DS environment with Azure AD and other Microsoft cloud platforms like Office 365.
The hybrid approach is popular with many companies, so let’s focus there for the moment. Once you’ve set up your Active Directory infrastructure, you can register your Windows 10 devices by either by using Domain Join, whereby Windows 10 domain-joined devices are automatically registered with Azure AD, or you can opt to use the newer Azure AD Join, where you register your devices directly with Azure AD without first joining them to your on-premises AD DS domain. That latter option sounds pretty neat, but you need to know the pros and cons of this approach before you try to implement it.
Understanding the pros
The really cool thing about Azure AD Join is that it provides users with a self-service experience for joining their devices to the company network. By contrast, joining a computer to an on-premises Active Directory domain is done either by an administrator or is built into the imaging process when creating corporate images for installing Windows.
And since Azure AD Join implements a self-service model, it enables users to join their devices to Active Directory from anywhere as long as they have connectivity with the Internet. This can be helpful if your company has lots of mobile users who travel and employ a variety of Windows 10 devices to perform their work.
From the perspective of the administrator, Azure AD Join also has a number of pluses associated with it. For example, in a traditional on-premises implementation of Active Directory, the standard method for managing devices is to use Group Policy, a mature technology that lets administrators specify managed configurations for users and computers across an enterprise, together with System Center Configuration Manager (SCCM), a comprehensive solution for change and configuration management that is part of the System Center family of products by Microsoft.
While the combination of Group Policy with SCCM is powerful, it can also be complex to implement and maintain, and when you need to manage modern devices running Windows 10 in mobile scenarios where the environment is in a state of flux, it’s kind of like trying to swat a fly with a sledgehammer (or to say it more nicely, it’s too much of a good thing).
In that case you’ll probably want to use a Mobile Device Management (MDM) approach instead of the Group Policy/SCCM method, and Azure AD Join is great if your plan is to manage your users’ devices using MDM. In addition, administrators can set up conditional access policies that can ensure that only compliant devices are allowed access to corporate apps and services in the cloud. And with Azure AD Join, administrators can not only allow users to join Azure AD from a running device, they can also enable joining Azure AD during the out-of-box experience stage of setting up a new Windows 10 device for a user.
Finally, using Azure AD Join automatically enables users to enjoy all the extra benefits that come from using Azure AD in the first place, including enterprise roaming of user settings across domain-joined devices, single-sign on (SSO) to Azure AD apps even when your device is not connected to the corporate network, being able to access the Windows Store for Business using your Active Directory account, and so on. To understand all the benefits and how everything works under the hood with Azure AD and Azure AD Join, a good place to start is by reading some of the posts on the blog of Jairo Cadena, a program manager in the Identity Services Division at Microsoft who has written extensively and in detail about these technologies.
Recognizing the cons
However, not everything is as rosy as it first appears when you start thinking about using Azure AD Join in your environment. In the first place, it’s a matter of intention because the target scenario for implementing Azure AD Join is enterprises that adopt a cloud-first or cloud-only infrastructure paradigm. That basically means Azure AD Join is intended mainly for small- and mid-sized businesses that don’t have (and don’t intend having) an on-premises Active Directory infrastructure built on Windows Server.
Now this does not mean that Azure AD Join is off-limits to large enterprises that have been using AD DS internally for years to authenticate users and control access to corporate resources. These enterprises could in fact implement Azure AD Join for example to let users authenticate their own personal bring-your-own-device (BYOD) mobile devices for corpnet access even if these devices are incapable of traditional domain join. Enterprises might also use Azure AD Join for a subset of users who only need access to Office 365 for reading their email on the road. But it’s important to realize that adding Azure AD Join capability to the Active Directory infrastructure of a large enterprise also adds another layer of management complexity to the job of administering that infrastructure.
Basically, it all depends on how committed your organization is toward moving into the cloud. And with any large enterprise there are always more compliance and regulatory issues associated with it compared to what small and midsized businesses usually need to deal with. As a result, it might be technically straightforward to provision new cloud-based identities for users in Microsoft Azure while for policy-based reasons it may be a requirement to have only local accounts that can be maintained on-premises in your AD DS directory.
Finally, one needs to understand that Azure AD (which Azure AD Join lets you easily join to) is not really a complete enterprise directory service in every sense of the word. What I mean is that a traditional directory service like AD DS that uses Lightweight Directory Access Protocol (LDAP) for authentication also includes other bits and pieces such as network policies, security policies, and so on. Azure AD, on the other hand, basically (in its current rev at least) only provides identity management capabilities (using REST instead of LDAP), which means that Azure AD is mainly intended for running apps in Software as a Service (SaaS) clouds. On the other hand, Azure AD and Azure AD Join are continuing to evolve under Microsoft’s cloud-first, mobile-first strategy championed by CEO Satya Nadella, so large traditional enterprises should keep an eye on it while smaller companies jump on the train and enjoy the ride.