I was recently asked to assist with establishing a connection between a client’s Azure tenant with a partner’s tenant and as the two organizations are different companies with no ties, their tenants were in different subscriptions. Prior to November 2019, the only option to achieve this was through the use of a site-to-site VPN but Microsoft has since released the feature to configure VNet Peering across subscriptions that allows organizations to enjoy all the performance benefits of VNet Peering such as traversing through the Azure backbone network rather than the internet (Virtual network peering across Azure Active Directory tenants: https://azure.microsoft.com/en-us/updates/cross-aad-vnet-peering/).
The configuration outlined in the following document was very straight forward:
Create a virtual network peering – Resource Manager, different subscriptions and Azure Active Directory tenants
https://docs.microsoft.com/en-gb/azure/virtual-network/create-peering-different-subscriptions
However, both the administrator and I became lost when we reached step 21 just after entering the Resource ID:
The documentation did not mention what we were supposed to enter or select for the Directory and when we clicked on the dropdown box, no options were displayed:
We went through the documentation together but couldn’t figure out what we were supposed to fill in for the Directory so I ended up opening a support case with Microsoft. The support engineer suggested that we tried to use PowerShell to create the VNet Peering but it did not resolve the issue. It was by chance that I decided to log into the email of the account I used, which had Azure Global Administrator permissions, to see if there was some sort of an invite when the administrator added my account as a Network contributor was when I realized an invitation was sent and required to be accepted:
Accepting the invitation and attempting to create the VNet Peering now displayed the other organization’s directory in the dropdown box:
Selecting the Directory and completing the configuration established the VNet Peering.
Notes
Notes that I feel are worth mentioning are as follows:
- The account you use provide the other tenant’s administrator to be granted Network contributor may not be an account that is regularly used and therefore may not have a mailbox so ensure that you use one that has one
- The account you use isn’t going to be used as a service account so don’t create a dedicated account for this operation
- The guest account you grant Network contributor role from the other tenant can be removed from your Azure AD after the VNet Peering has established (we tested connectivity after removing the account and the peering still works)
- Network Security Groups (NSG) are only can only be associated to NICs or Subnets in your own tenant so to secure your tenant from the peered tenant’s virtual network will require NSGs to be applied to the resources you have in your tenant (you cannot apply an NSG to, say, the peered tenant’s VNet)
Hope this helps anyone who may encounter the same problem as I experienced.
3 Responses
Hi. Thanks for the great article, very useful. Would it be possible to peer between gov cloud tenant and commercial cloud tenant?
yes, that is possible
is it possibile to peering a vnet on different tenant with azure virtual wan and secure hub? i followed the microsoft docs (cross vnet peering azure virtual wan) but whe i try to ping a vm between the tenants doesn't work.