Part 1: Using Azure to remove to HQ dependency for AD

Scenario

Currently HQ is a single point of failure, this is the only site within the network to host Domain Controllers. These are responsible for authentication to Office 365, external applications that are served via Azure AD, and all of the Users and Computers within the company. This has been highlighted twice in the past few months, during which time HQ experience an internet outage, and a separate incident where the ASM VPN went down.

During these times, users are unable to authenticate with cloud apps, including Outlook, Onedrive and Sharepoint. Users in the remote offices also connect back across Site to Site VPNs for authentication to file shares and applications. The network grounded to an halt.

Current Setup

From the diagram below, the red line indicates the way end points connect back to HQ to authenticate. As you can see from the image, all traffic heads back to HQ from both Azure VPN environments. ADFS servers currently site in ASM and are dependent on the ASM VPN tunnel remaining up.

The network sits in a Hub/Spoke topology where all traffic between remote sites will traverse through the HQ. MPLS and ultimately ExpressRoute was deemed too expensive.

To Note: The Azure portal also uses ADFS for authentication so could lose our login ability to Azure aswell.

Azure Resource Manager to ASM (Classic) vnet peering

A client I’ve been carrying out some Azure work for over the past few months has a split environment between Azure Resource Manager (ARM) & Azure Service Manager (Classic and/or ASM). Their ADFS infrastructure and System centres all currently live in ASM and there was no direct connection through to ARM meaning without some funky routing via the VPNs through the Head Office.

The fix is to setup vnet peering through the portal. This is done via the virtual network > Peering > Create

You’ll need to fill in the following details:

I then got this error:

Failed to add virtual network peering ‘<peering name>’. Error: Subscription <ID> is not registered with NRP.

It was quite difficult to find information on this error message and initally I thought it was due to lack of permissions.

However, the following script fixed the issue (Note: It can take a bit of time for this to go through as it registers extensions with your subscription).

Afterwards you should be able to to create your vnet peering across subscriptions.

Import-Module azurerm
Login-AzureRmAccount

Get-AzureRmProviderFeature -FeatureName AllowClassicCrossSubscriptionPeering -ProviderNamespace Microsoft.Network

#Register the preview capability in your Azure subscription
Register-AzureRmProviderFeature -FeatureName AllowClassicCrossSubscriptionPeering -ProviderNamespace Microsoft.Network
Get-AzureRmProviderFeature -FeatureName AllowClassicCrossSubscriptionPeering -ProviderNamespace Microsoft.Network
 
Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network
Get-AzureRMResourceProvider -ProviderNamespace Microsoft.Network