Azure Active Directory: Overview, AD Connect and B2B

Azure Active Directory (Azure AD) enables team members to access external resources including cloud applications. As an Identity as a Service, Azure AD provides access to applications across cloud and on-prem.

In this article we are going to see how to implement an Azure Active Directory (Azure AD) B2B Connect using Azure External Identities. Companies migrating to Azure often seek external Cloud SME expertise to rapidly achieve digital transformation. This feature of Azure Active Directory enables seamless collaboration with guests, consultants and other organizations while maintaining strict security controls.  

Azure Active Directory (Azure AD) & AD Connect

Let’s assume there are two Azure AD tenants named “Marvel” and “DC”, by default guest users can be invited from any tenant to the Marvel tenant, if the inviter has  the proper privileges. If two organizations are collaborating this model would not be scalable as the number of users increases.  Instead by leveraging Azure Active Directory (Azure AD) and External Identities, as we will see below, it is possible to delegate user access between organizations while maintaining security controls.

Consider the other tenant named “DC” and for compliance reasons we need a setup where only users from the DC tenant can be invited as a guest user into Marvel tenant. To do so we have to navigate to Azure AD->External identities->external collaboration settings and under collaboration restriction, select “Allow invitations only to the specified domains (most restrictive)” and we can add the domain name of the DC tenant there.

Figure1: Adding DC tenant under external identities settings

Now only DC tenant users can be invited as guest users in the Marvel tenant. Imagine that they’re going to be hundreds of users from DC who need guest access to the  Marvel tenant. Inviting and constantly managing each individual would be an overhead to the administrator of the Marvel tenant. So, we are going to implement a setup where there will be a delegator in the Marvel tenant who will provide privileged access to a delegatee in the DC tenant. This delegatee will then invite the DC tenant users to Marvel tenant and manage the lifecycle of those guest users. To do so, the delegator can assign the “Guest inviter” role to the delegatee. Here in our example Ironman from Marvel tenant is the delegator and Batman from DC tenant is delegatee. In the below picture you can find that the user Batman is invited and assigned with Guest inviter role in Marvel tenant.

Figure 2: Ironman (Delegator) assigned Guest Inviter role to Batman (Delegatee)

So, now Batman can invite guest users from only the DC tenant to the Marvel tenant and can’t invite users from any other tenant since only the DC tenant is added under Azure external identities settings. In the below picture Batman under Marvel tenant, tries to invite users from another tenant and is prompted with an error.

Figure 3: Batman failed to invite Sakthi man user from another tenant into Marvel tenant

Now assume Batman invited all the four users in DC to the Marvel tenant. And all the four users have redeemed the invitation. Now the setup will be looking like the illustration below.

Figure 4: Setup after Batman invites all the users from DC to Marvel

Now we have another requirement that not all the invited users from the DC tenant should be able to access the Marvel tenant at any time. Only a few specific users from DC should be able to access the Marvel tenant from time to time and the solution should be scalable. For this we are going to leverage the Azure external identities B2B Connect feature. First, we need to create an Azure AD group in the DC tenant and add the users who should be given access to the Marvel tenant into that group, like the below snip.

Figure 5: AD Group in DC for the user who need access to Marvel tenant

Copy the object ID of this AD group and save it for the steps that we are going to do perform next.

Figure 6: Object ID of the Multi-Universe-group

Then in the Marvel tenant navigate to Azure AD->External identities->cross-tenant access settings and select the inbound access settings of the DC tenant which is highlighted below.

Figure 7: Configuring Inbound settings for DC Tenant under Marvel tenant

After selecting the Inbound access, under the B2B collaboration menu select the ‘customize settings’ option and select the ‘Allow access’ then select the ‘Add external users and group’ option.

Figure 8: Selecting the add external users or group option

Now paste the object ID of the group we copied earlier and click the save button.

Figure 9: Adding the Object ID of “Multi-Universe-Group” from DC Tenant

Now only the users in the “Multi-Universe-Group” can access the Marvel tenant. If any other user from DC tries to access Marvel they will be prompted with an error as below.

Figure 10: Wonder women user from DC prompted with error when trying to access Marvel tenant

The setup will be looking like the one below after implementing this procedure.

Note: This particular feature of adding object id of group/user needs Azure AD Premium P1/P2 license.

Figure 11: Setup after adding the group object id under B2B collaboration setting

Now let’s assume there is a VM named Krypton-VM in Marvel tenant and guest users with the job title “Kryptonians” should only be able to access it dynamically. For this requirement we can use Azure AD Dynamic Group. We can create a dynamic group with a rule of job title=”Kryptonians”. Then users with that job title will be automatically added into that group. In the below snip you can see a group with such a membership rule.

Note: We can create an Azure AD dynamic group only if we have Azure AD Premium P1/P2 License.

Figure 12: Dynamic membership rule

The users Superman and Supergirl are having the attribute Job title as “Kryptonians”. So, they’ll be automatically added into this dynamic group.

Figure 13: Superman and Supergirl with job title “Kryptonians”

Then the appropriate RBAC role is assigned to the dynamic group. So, all the users in the group will inherit the access.

Figure 14: RBAC role assignment to Dynamic group

The final setup after doing all the steps mentioned above will be as depicted below.

Figure 15: Final setup illustration