In-Depth

Give Anyone Credentials with Azure Active Directory

The new Azure Active Directory B2B aims to simplify how administrators offer controlled access to partners, suppliers and customers.

• By Brien Posey
• 07/21/2017

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.

In order to give a few editors access to the application, the easiest way in the past was to create a couple of accounts on BrienPosey.com. Even though this solution is easy to implement, it's not ideal. Creating and managing the accounts would have meant more work with one more set of credentials for my editors to manage.

Azure AD B2B solves this problem by allowing me to grant application access based on an external e-mail address. I can now easily grant access to the BrienPosey.com domain to someone with a Redmondag.com address, for example. In the past, this sort of thing would've only been possible through the use of an AD trust, but Azure AD B2B allows you to grant access to external users without having to set up a trust.

From an administrative standpoint, setting up Azure AD B2B access really isn't much different than setting up application access for an employee. An administrator would create a group within Azure, and then assign the group access to the application. From there, the administrator could simply add the external user's e-mail address to the list of users who have access to the application.

At this point, Azure sends an e-mail message to the address added to the application. The recipient opens the message, and clicks on a Get Started link found within the message. Upon clicking this link, the user is directed to Azure, and is prompted to create a password. Azure also provides the user with a registration code that the user must use to prove their identity. Once the user's identity has been confirmed, they'll be able to go to the Azure application portal, log in using the e-mail address and the password provided, and gain access to any applications provisioned for their use.

It's important to note that the user isn't accessing Azure applications without an account. Instead, Azure is creating an account for the user behind the scenes, based on the user's e-mail address and the password that they provide. Also, the user can use any e-mail address. They can use a managed address (one associated with an AD domain). The user can even use a non-managed address, such as Gmail or Outlook.com. Furthermore, the user doesn't require Azure AD in order for this to work.

Azure AD B2B is going to radically simplify the process of granting application access to external users. In fact, an administrator can grant access to an external user by simply specifying that user's e-mail address.

Microsoft has also built-in provisions for larger organizations. It's possible for users to self-register for access to an application -- for example, if the user's e-mail address is from a domain authorized by an administrator. Likewise, there are also controls in place for providing conditional access and for requiring multi-factor authentication.