Active Directory was designed to help IT provide secure access to enterprise networks, but its architecture has never lent itself to providing business partners and other external users with access to an organization’s systems and applications. Although there are well-established techniques for providing such access to outside users, it has often proven difficult if impractical. This is especially true for organizations that deal with large numbers of partner organizations, or who need to grant access to users who are independent contractors or who work for a company that doesn’t have an IT department. Recently, however, Microsoft has made it far easier to provide external users with access to resources through Azure Active Directory (Azure AD) B2B.
Azure AD B2B marks a revolutionary shift in digital identity management, and yet at the same time is somewhat evolutionary in nature. Let me explain. IT pros experienced with administering Windows Server networks are familiar with the concept of domain-joining a PC. Simply stated, joining a PC to an AD domain makes the PC a part of that domain. As a domain member, the PC will be subject to any applicable Group Policy settings. It also means that users who have domain accounts will be able to use the domain-joined PC to log into the domain.
For many years, domain-joined PCs were the standard for enterprise networks. Because a domain-joined PC exists as a domain member, such a PC can be tightly controlled, secured and managed. Although domain-joined PCs are still widely used, the mobile device revolution had a major impact on the way that network endpoint devices are used in the enterprise. Seemingly overnight, there was an insatiable demand by users to be able to work from tablets, smartphones and other mobile devices.
However, such devices cannot generally be domain-joined. Therefore, they were largely perceived by IT professionals as being difficult to manage, and potentially introducing new security vulnerabilities. Because there was such an extreme demand for using such devices, the IT industry relented, and non-domain-joined devices became the norm. Of course, this meant that the IT industry had to come up with ways of securing and managing these non-traditional devices.
On the surface, there would seem to be absolutely no link between mobile device use and Azure AD B2B. In many ways, though, the mobile device revolution laid the groundwork for Azure AD B2B. To understand why, it’s important to consider the AD anatomy. Windows PCs are configured with a unique computer name. When a PC is joined to AD, an AD object representing the computer is added to the Computers folder (see Figure 1). This object’s name matches the computer name of the PC that it represents.
Although the AD Users and Computers console makes a computer object look a lot like any other type of AD object, computer objects actually function in a similar manner to user accounts. Like a user account, a computer account even has an associated password, although the use of this password is entirely automated and is hidden from view.
When a device isn’t domain-joined, there’s no computer account representing the device and security policies that are normally applied to such accounts cannot be applied to a such a device. Consequently, Microsoft had to come up with a way of decoupling a device’s identity from computer account objects. Over the years, Microsoft has come up with a few different ways of doing this. Windows Server, for example, includes a mechanism for enrolling a device. Similarly, a device can be registered through Microsoft Intune.
More recently, Microsoft has faced a very similar problem with user accounts, and it’s hardly surprising that the company has solved this problem in a manner similar to how it solved the domain-join problem.
Microsoft has faced problems with user accounts for decades. Specifically, businesses often collaborate with one another. This is true of business partnerships, but it also holds true for other types of business relationships such as supply chains. The problem is how to grant digital resource access to users who don’t actually work for the organization.
Microsoft has introduced several different collaborative mechanisms over the years, but none of these solutions has been perfect. For example, some organizations create user accounts for employees in partner organizations. However, this increases the organization’s software licensing costs. The approach may also drive up the organization’s support costs, because an external user may occasionally require technical support, password resets and so on.
Creating user accounts for external users also complicates things from an administrative standpoint. Administrators must be able to somehow differentiate between an employee’s account and an external user’s account. Because external users are presumably not going to be working on-premises, the organization will also have to provide those users with a VPN or a similar mechanism that they can use to access the organization’s resources externally. Granted, remote access is very common these days, but it’s still something that must be considered when providing access to external users.
Another approach that is sometimes used is directory trusts. In other words, the organization configures its AD environment to trust their partner’s AD domain. Doing so makes it possible to grant resource access to users in the partner organization, without explicitly creating user accounts for those users.
Although this approach works, it’s far from being ideal. For one thing, AD trusts can only be used if both organizations have an AD environment. Furthermore, AD trusts can be complicated to set up, and they tend to raise a lot of questions about security. For example, what happens if you choose to trust an organization that trusts an organization that you do not trust? Incidentally, Microsoft provides the answer to this and many other directory trust questions here. The bottom line is although there are ways of providing resource access to external users, those methods tend to create a support burden, and may not fully meet an organization’s logistical or security requirements.
These are the types of issues that Azure AD B2B is designed to address. With Azure AD B2B, Microsoft has addressed it essentially the same way it handles mobile device enrollment. Even so, the concept seems far more profound when it’s applied to users rather than to devices. In creating Azure AD B2B, Microsoft has separated the user’s account from the user’s identity.
Consider that in the past, users were usually given a username and a password. The username corresponded to an account, and all of the user’s permissions were based on that account. But what if it were possible to control user access without creating user accounts? That’s the focus of Azure AD B2B. Technically, Azure AD B2B doesn’t completely mitigate the need for user accounts. However, it completely changes the account model to something best described as Bring Your Own Account. For example, my primary AD domain is BrienPosey.com. If I have a collaborative application running on Azure and need to give my editors at Redmond access to the application, because I’m a freelance contributor and not an employee, the editors all use accounts that reside in domains I don’t own.