Latest posts by Paul Schnackenburg (see all)
- Project Honolulu - A new way to manage Windows Server - Wed, Nov 22 2017
- Use Azure Managed Service Identity (MSI) to store passwords in your code securely - Thu, Nov 9 2017
- Azure Data Lake overview - Fri, Sep 22 2017
The need to collaborate and share resources with external users is long-standing in the business world. One approach is to create accounts in your directory to represent users from business partners. Apart from being labor-intensive, this is not great from a security perspective. If the IT admins from your partner forget to inform you when someone is no longer employed, the user still has access.
Another approach is federation, wherein you exchange certificates and other data with your counterparts, thus providing a good end user experience. This is better from a security point of view because, when someone leaves the partner organization and their account is (hopefully) disabled by the IT admins, access is automatically revoked.
However, it is still a lot of work to set up the required on-premises infrastructure and maintain it (certificates seem to expire at the most inopportune moments), especially as it must be done for each individual partnership. Another issue is that smaller businesses don’t necessarily have the skills or the infrastructure to set up federated relationships.
Azure B2B overview ^
This service resolves these issues by providing the whole sharing experience as a cloud facility. You are in complete control of what gets shared and with whom; you simply invite users. If they already have an account in Azure Active Directory (AAD), they’re all set. Since AAD is the underlying directory for Office 365, many are already registered.
Users will simply continue to use their current AAD account, but now they will have access to any SaaS, mobile, cloud, or on-premises claims-aware application you give them access to. If you need to revoke access, you don’t need to communicate with their IT department; you can simply do it from your end.
There’s also no on-premises infrastructure for you to configure. AAD uses federation technology behind the scenes but removes the burden of deployment, configuration, and management from your IT team.
If the partner users do not already have an AAD account, they will be provided one for free as part of the B2B process. If you have a lot of partner user accounts to add, you can bulk import up to 2,000 accounts using a CSV file. Note that, at this time, social accounts such as Gmail, Microsoft, and Facebook are not supported. This kind of makes sense as this is about business-to-business collaboration, but I’m sure there will be requests for these types of accounts in AAD UserVoice.
Setting up Azure B2B ^
If you have an AAD tenant, you can follow along to set this up—it’s easy. I’m going to invite John Pardner from another company to have access to resources in my Office 365/AAD tenant.
First, you need to create a CSV file with the required information. Then, log into manage.windowsazure.com (AAD is the last service to move to ARM and the new console), and go to the “users” tab. Click “create new user.” Pick the option for a user in a partner organization, and upload the CSV file.
An invitation email is sent to John, and since he doesn’t have an account in AAD, a directory is created for him. He has now been added to my Office 365 directory, and I can assign him applications that I want him to have access to. The process is really straightforward compared to messing around with federation and the like.
If you have AAD Basic or Premium, you also gain the ability to put external users into groups for easier application access assignment.
The limitations ^
Azure B2B is currently in preview, so there are some rough edges as well as some limitations based on the type of service it is. If you have a multi-factor authentication (MFA) in your organization, external users will not be required to do MFA. However, if they’re already an AAD tenant with MFA configured, they can still do MFA. You can’t invite people manually; a CSV file is always required, and there’s no API access to create invitations.
The main limitation is that the type of applications you can assign to external partners isn’t complete. AAD supports 2,624 (at the time of writing) cloud-based SaaS services (SalesForce, Box, Docusign, and thousands more), so if your users use these and need to collaborate with external users, you’re good to go. Also, you can add your own internal applications to AAD to support using AAD to sign into them, provided they support claims. However, many older in-house applications won’t necessarily work and Azure B2B isn’t the right answer. Then again, on-premises federation isn’t going to cut it for these applications either.
Nevertheless, Azure B2B is an intriguing concept. As more and more business take advantage of SaaS-based services in the cloud, and as collaboration across business boundaries become even more commonplace, I recommend that you check out Azure B2B.