ADFS in Azure

I’ve recently deployed a solution for a customer hosting their ADFS and WAP servers in their Azure IAAS tenant and thought I’d share the experience.

Now I know there are many posts on setting up ADFS with WAP so I won’t repeat that here but I’ve not seen many that discuss the networking side and after all Microsoft’s whitepaper just shows the machines in “the cloud” but not how the networking is configured and good security practice dictates that we should restrict traffic to our external facing machines as much as possible as well as restricting their access to internal resources.

Now, in a vNet all subnets are fully route-able between each other so if the WAP is compromised to could gain access to other machines on the network and whilst this might not be too much of a problem (you do have Windows firewall turned on don’t you?) it’s best to replicate an on premise topology with WAP servers in a perimeter network and the ADFS servers safely on a secure internal network.

How do you do this? Well Network Security Groups of course! and whilst I posted a separate post on them in general I thought I’d share design I followed in this instance.

azure adfs


I created two separate Network Security Groups (DMZ_NSG and Internal_NSG) and applied them to their respective subnets, I then set about adding the new rules to restrict traffic as shown in the image above.

Azure Network Security Groups

This week I had an opportunity to implement Network Security Groups(NSG) in Microsoft Azure for a customer and thought I’d share the experience. For those that are unaware NGS’s are rule sets that can be applied to subnets and machines in Azure IAAS tenants, these groups act as access lists and are applied to the traffic entering and leaving the subnet/machine.

This allows for the separation of subnets and clients within the same vNet, NSG’s contain default rules that allow for traffic to flow back and forth within the vNet as well as outbound only to the internet.

The default rules included in the group have a low priority (a high number) assigned, this allows for custom rules to be created and used to block them if so desired. Whilst you can only have 1 NSG assigned to a subnet or machine each group can have 200 rules, which should be enough, I’d hate to be creating that many!

Like most firewall/acl rules you need to specify the direction of the traffic, the source, destination, port and whether it’s for TCP/UDP or both (you can not create rules for ICMP traffic) The source/destination can be either a specific IP address, a subnet, Internet, Virtual_Network (including your Azure IP networks and any onpremise connected via VPN) or Azure_LoadBalancer (to allow health checks if using Azure load balancing)


Firstly you need to create a group with a name and assign it to the correct Azure region, in addition you can assign it a label:

New-AzureNetworkSecurityGroup -Name “GroupName_NSG” -Location “North Europe” -Label “NSG Security Group”

Then you need to assign it to the network or machine, in this example we’re assigning it to a subnet:

Get-AzureNetworkSecurityGroup -Name “GroupName_NSG” | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName ‘my-vNet’ -SubnetName ‘Subnet_Name’

After the group has been created and assigned you can add your rules

Get-AzureNetworkSecurityGroup -Name “GroupName_NSG” | Set-AzureNetworkSecurityRule -Name “Allow_Inbound_internet_HTTPS” -Type Inbound -Priority 150 -Action Allow -SourceAddressPrefix ‘Internet’  -SourcePortRange ‘*’ -DestinationAddressPrefix ‘’ -DestinationPortRange ‘443’ -Protocol TCP

Get-AzureNetworkSecurityGroup -Name “GroupName_NSG” | Set-AzureNetworkSecurityRule -Name “Deny_Outbound_internet” -Type Outbound -Priority 300 -Action Deny -SourceAddressPrefix ‘’  -SourcePortRange ‘*’ -DestinationAddressPrefix ‘Internet’ -DestinationPortRange ‘*’ -Protocol *

TIP! – I found that the type variable was case sensitive and needed to be exactly Inbound or Outbound

TIP! – It is possible to use NSG’s assigned to subnets to block traffic between machines on the same subnet, be careful with your use of subnet masks!