Azure B2B and internal applications

Azure Active Directory released the functionality for B2B a few months ago. This new feature enables companies to extend their identity service as well as their applications beyond traditional borders. Say, you want to provide your vendor a mailbox in YOUR Office 365 tenant. That way the vendor can still read/write emails on behalf of your company, while your company policies and governance still applies.

In the “old” days you had to create a whole new account for that user and manage their account completely. Things became worse if your on-premises SharePoint or application required access for external people. You where left with either an Active Directory domain trust, fiddling around with ADFS or creating and managing accounts for these users.

B2B – how to use it

But now, we have Azure B2B.. what is it? Well in short, you can invite external users into your Azure AAD tenant and assign them permissions to your applications. In AAD (new portal) go to Users and select the New Guest User button from the top ribbon. Type the email address of the user you want to add and click invite (and yes you can specify a custom message..)


Once invited, the invitee will receive an email with the invite:

The user needs to click the Get Started link, and that is all that is required for accessing the services.

Inside AAD (or Office 365) you can now select if you want to grant a user a license for access to (for example SharePoint) or any other application. Just by selecting their name next to the application itself. The users can be identified by their username being <user_domain>#EXT#@<youdomain>

After allowing them access to the applications, these users have access using their own credentials from their source AAD .. When they go to, they can click their name and actually select which tenant applications they want to see. (in the picture below shown as 9172 and Studio Graphic – WAAD)

AAD Proxy and external accounts

But what if we have AAD Proxy and we want to publish an internal application (like a website, or SharePoint) to these users. By default these users do not have an internal AD account, and if we were to create them, we certainly don’t want to manage these users passwords and such. Luckily we have Kerberos Constraint Delegation with Protocol Transition.

Our internal application needs to talk Kerberos and it needs to be published through AAD Application Proxy. The setup of this is already discussed somewhere else on this blog.

When the external user wants to login to the on-premsies application, an error will be created on the Proxy Connector server, and that error tells us all that we need to know to allow access

As you can see from the error message, the username/password is wrong for this particular user. The Application Proxy server simply can’t convert the inbound claim for username to an actual user in AD. So, the solution is to create a user object, with this particular UPN and give it any complex password. Given we use Kerberos Constraint Delegation with protocol transition, the user never has to know the actual password.

So create a user in AD and give it any name:

Give it a very complex password and create the user. Set the password to never expire to avoid future problems, or make sure to reset the password on behalf of the userobject regularly.

After the object is created, open the attribute editor (Advanced Mode on in AD Users & Computers) and go to the userPrincipalName attribute. Paste the name from the eventlog error in there and click OK.

After the user is created, access is now granted to the internal application using their own AAD account protected by your AAD policies. For example, if you state that for your application MFA is required, the user will be forced to enroll in the MFA service.. the initial login comes from their AAD, the MFA from yours..