In an on-premises Active Directory environment, there can be application or service which required integration with Active Directory. With AD integration, the application can search for AD users, allow login, assign permissions, etc. This integration part is usually done using the Lightweight Directory Access Protocol (LDAP). By default, traffic over LDAP is not encrypted. Due to the vulnerabilities, Microsoft now recommends only to use secure LDAP (LDAPS, LDAP over SSL) connections to Domain Controllers.

Azure Active Directory Domain Services (Azure AD DS) also support for secure LDAP connections. Most of the time the LDAP connection to Azure AD DS will be initiated over the public internet. So, it is important to have encryption in place to prevent man-in-the-middle attacks.

In this post, I am going to demonstrate how to enable secure LDAP for Azure AD DS. Before we start make sure you have the following prerequisites in place.

1. Valid Azure Subscription
2. Valid Azure Active Directory Domain Services (Azure AD DS) setup – I assume you already have Azure AD DS configured. More info about Azure AD DS setup can find under https://docs.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance
3. Valid SSL certificate – We need a valid SSL certificate to enable secure LDAP. If Azure AD DS uses custom domain name, we can use public CA (3rd party) or enterprise CA to issue a certificate for it. If Azure AD DS is using Microsoft default domain .onmicrosoft.com, we have to use self-sign certificate for it as public CA can’t issue certs for the default domain. In this demo, I will be using a self-sign certificate for the configuration.
4. Test PC – We need a PC to test the secure LDAP connectivity.

Before we enable secure LDAP, we need to create a certificate for it. In this demo, my Azure AD DS instance is using default Microsoft domain name rebeladmlive.onmicrosoft.com. So, I have to use a self-sign certificate for it. To generate a self-sign certificate, we can use the following PowerShell commands. This can be run from any PC.

$domainname=”rebeladmlive.onmicrosoft.com”
$certlife=Get-Date
New-SelfSignedCertificate -Subject *.$domainname -NotAfter $certlife.AddDays(365) -KeyUsage DigitalSignature, KeyEncipherment -Type SSLServerAuthentication -DnsName *.$domainname, $domainname

In above, replace rebeladmlive.onmicrosoft.com with your Azure AD DS instance name. As we can see, it created a wild card SSL for rebeladmlive.onmicrosoft.com under Computer account.

We need to export this certificate as .PFX file with private key to,

1. Use it during the secure LDAP setup and upload it to Azure
2. Import it to any other PC which like to initiate secure LDAP connection (The certificate must be imported into Computer Account\Personal\Certificates as well as Trusted Root Certification Authorities\Certificates. This is because the certificate is self-sign cert and it doesn’t have trusted root certificate)

To export certificate,

1. Right-click on the certificate and go to All Tasks | Export

2. It will open up the certificate export wizard, click on Next to start the process.

3. In the next window select Yes, export the private key, and click on Next.

4. In the Export file format window, match the following selection, and click on Next.

5. In the next window, define the password for the export file and click on Next.

6. Then, select the file path for the output and click on Next.

7. In the next window, click on Finish to complete the Export process.

Now we have the .PFX file. The next step is to import it again to Trusted Root Certification Authorities\Certificates. This is required as we are using a self-sign certificate for the exercise.

The latency between two servers located in two regions is normally higher than the latency between two servers located in the same data center or the same rack. High latency between application servers has a direct impact on the overall performance of the application. By placing applications servers in the same physical location, we can reduce the latency.

When it comes to Azure VMs, we can reduce the latency between servers by placing those in the same Azure region or in the same availability zone. But this doesn’t mean the servers are running from the same data center. As Azure grows a region can have multiple data centers. But now with proximity placement groups, we can co-locate Azure VMs to the same data center.

The proximity placement group can have stand-alone VMs, VM scale sets or VM availability sets. Once the proximity placement group is created, we can deploy new servers to it or move existing servers to it. It is recommended to use accelerated networking with the virtual machine in proximity placement group to further reduce the latency. Also, if possible, use one VM template for virtual machines in the same proximity placement group. This is because some datacentres only support certain VM SKUs and sizes.

In this demo, I am going to demonstrate how we can create a proximity placement group and deploy a virtual machine to it. I also going to demonstrate how to move the existing virtual machine to the proximity placement group.

For the configuration process, I will be using PowerShell. Therefore, please make sure you have an Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-3.8.0

Let’s start the configuration process by creating a new resource group.
1. Launch PowerShell console and connect to Azure using Connect-AzAccount as Global Administrator

2. Then create a new resource group using,

New-AzResourceGroup -Name REBELRG1 -Location “East US”

In the above, REBELRG1 is the resource group names and East US is the Azure region.

3. The next step is to create a new virtual network under REBELRG1 resource group.

$vmsubnet = New-AzVirtualNetworkSubnetConfig -Name vmsubnet -AddressPrefix “10.0.2.0/24”

New-AzVirtualNetwork -Name REBELVN1 -ResourceGroupName REBELRG1 -Location “East US” -AddressPrefix “10.0.0.0/16” -Subnet $vmsubnet

In the above, REBELVN1 is the new virtual network name. It has 10.0.0.0/16 address space. It also has a new subnet 10.0.2.0/24 (vmsubnet) for virtual machines

4. As the next step of the configuration, let’s go ahead and create proximity placement group using,

New-AzProximityPlacementGroup -Location “East US” -Name rebelpggrp01 -ResourceGroupName REBELRG1 -ProximityPlacementGroupType Standard

In the above, I created a proximity placement group called rebelpggrp01. The group type is set to standard.

VM Snapshots are the quickest way to recover a VM from a disaster. Snapshot is a copy of the virtual machines’ disk file at a given point of time. There are situations where we may need to get certain data out from snapshot without restoring a complete virtual machine. The best way to do that is to create a virtual machine from the snapshot and then retrieve the relevant data. The same method also can use to test application upgrades or risky changes without affecting production servers.

In this demo, I am going to demonstrate how we can create an Azure Windows VM from a snapshot.

For the configuration process, I will be using PowerShell. Therefore, please make sure you have an Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-3.8.0

As part of the configuration, I am going to do following,

1. Create a new resource group
2. Create a new virtual network
3. Create Azure Windows VM
4. Log in to the new virtual machine and create few test files
5. Create snapshot
6. Create another virtual machine using the snapshot
7. Log in to this new VM and verify it has the test files created in original VM

Let’s start the configuration process by creating a new resource group.

1. Launch PowerShell console and connect to Azure using Connect-AzAccount as Global Administrator
2. Then create a new resource group using,

New-AzResourceGroup -Name REBELRG1 -Location “East US”

In the above, REBELRG1 is the resource group names and East US is the Azure region.

3. The next step is to create a new virtual network under REBELRG1 resource group.

$vmsubnet = New-AzVirtualNetworkSubnetConfig -Name vmsubnet -AddressPrefix “10.0.2.0/24”

New-AzVirtualNetwork -Name REBELVN1 -ResourceGroupName REBELRG1 -Location “East US” -AddressPrefix “10.0.0.0/16” -Subnet $vmsubnet

In the above, REBELVN1 is the new virtual network name. It has 10.0.0.0/16 address space. It also has a new subnet 10.0.2.0/24 (vmsubnet) for virtual machines

4. As the next step of the configuration, I am going to create a new virtual machine under REBELRG1 resource group. This will be used for testing purposes.

$mylogin = Get-Credential

New-AzVm -ResourceGroupName REBELRG1 -Name “REBELTVM01” -Location “East US” -VirtualNetworkName “REBELVN1” -SubnetName “vmsubnet” -addressprefix 10.0.2.0/24 -PublicIpAddressName “REBELVM01IP1” -OpenPorts 3389 -Image win2019datacenter -Size Standard_D2s_v3 -Credential $mylogin

In the above, I am creating a virtual machine called REBELTVM01 in East US Azure region. It is running windows server 2019 data center edition. I have specified it using -Image parameter. It also using Standard_D2s_v3 vm size. For networking, it uses REBELVN1 virtual network and subnet 10.0.2.0/24.

I have a web server running in my on-premises network. I like to allow access to it from the internet via TCP port 443. To do that, I need to create two types of rules in my edge firewall. I need a NAT (Network Address Translation) rule to map a public IP address to the private IP address of the webserver. I also need an ACL rule to allow only relevant traffic (TCP 443). This ensures the traffic to web server from the public is protecting via edge firewall.
In Azure, we can use the same topology to filter inbound internet traffic. For that, we have to use Azure Firewall Destination Network Address Translation (DNAT). This is doing the same thing what NAT rule does but Microsoft calls it as DNAT. In this demo, I am going to demonstrate how to set up Azure Firewall and how to use it to filter incoming internet traffic.

In my demo environment, I have two virtual networks.

• EUSFWVnet1 – This network hosts the Azure firewall.
• EUSWorkVnet1 – This virtual network is the production network. This is where I create VMs.

The above two networks are connected using Azure VNet Peering method. With VNet peering, virtual networks are connected via the Azure backbone network. If we compare this with on-premises network, it is similar to the connection between your local network and edge firewall.

So, in this setup, I am going to allow RDP access to a virtual machine in EUSWorkVnet1 over the internet via Azure Firewall.

For the configuration process, I will be using PowerShell. Therefore, please make sure you have an Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-3.8.0

Setup Resource Group

The first step of the configuration is to create a new resource group. Both virtual networks and other services will be using the same resource group.
To do that,
1. Launch PowerShell console and connect to Azure using Connect-AzAccount
2. Create a new resource group using New-AzResourceGroup -Name REBELRG1 -Location “East US”. Here REBELRG1 is the resource group name and East US is the location.

Setup Azure Firewall Network

The next step is to create a new virtual network for Azure Firewall under REBELRG1 resource group.

$fwsubn1 = New-AzVirtualNetworkSubnetConfig -Name “AzureFirewallSubnet” -AddressPrefix 10.0.0.0/24
$eusfwvnet = New-AzVirtualNetwork -Name EUSFWVnet1 -ResourceGroupName REBELRG1 -Location “East US” -AddressPrefix 10.0.0.0/16 -Subnet $fwsubn1

EUSFWVnet1’s address space is 10.0.0.0/16. It is a class B IP address range. We have one subnet under it. AzureFirewallSubnet (10.0.0.0/24) will be used by Azure Firewall. Azure firewall only can be created in a subnet with name ‘AzureFirewallSubnet’

Setup Production Network

The next step of the configuration is to set up a virtual network for production workloads.

$worksubn1 = New-AzVirtualNetworkSubnetConfig -Name WorkSubnet -AddressPrefix 10.2.0.0/24
$workvnet = New-AzVirtualNetwork -Name EUSWorkVnet1 -ResourceGroupName REBELRG1 -Location “East US” -AddressPrefix 10.2.0.0/16 -Subnet $worksubn1

EUSWorkVnet1’s address space is 10.2.0.0/16. We have one subnet under it called WorkSubnet. This is the subnet we will use for the virtual machine.

When we connect two networks via VPN connection, we only allow certain traffic to pass through (In most scenarios). This is the normal security best practice. We normally use a firewall to do this.

When it comes to Azure, we may also need to connect virtual networks,

• Between Azure and on-premises networks
• Between Azure regions (using VNet-to-VNet)
• Between subscriptions

By using Azure Firewall (https://docs.microsoft.com/en-us/azure/firewall/overview), we can control the traffic between virtual networks. More info about Azure firewall also can find in one of my previous posts http://www.rebeladmin.com/2018/07/step-step-guide-azure-firewall-preview/
In this post, I am going to demonstrate how we can control the traffic between two virtual networks in two regions by using Azure Firewall. This same method can use to control traffic between Azure and on-premises or between subscriptions.

In the demo setup, I am using three virtual networks across two Azure regions.

Azure Firewall – This network is purely to host the Azure firewall and VPN gateway. The gateway in this network will use to perform VNet-to-VNet connectivity with Remote network.

Workloads – This network is the back-end network that will hold the VM workloads. Remote network and workloads network will communicate via the Azure Firewall.

Remote network – This virtual network is in UK South region. It is just to represent the “other” network. This can be your on-premises network, virtual network in the same azure subscription, or virtual network in another azure subscription.

Connectivity

In the above two types of connection been used between virtual networks.

• VNet-to-VNet via Azure VPN Gateways – In this method, virtual networks are connected through public internet. In the demo, we are using the same method to connect Azure firewall network and Remote network.

• VNet Peering – With VNet peering, virtual networks are connected via the Azure network backbone. In our scenarios, we are using this method to connect Azure firewall network with workloads network. If we compare this with on-premises network, it is similar to the connection between your local network and edge firewall.
For the configuration process, I will be using PowerShell. Therefore, please make sure you have an Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-3.8.0

Setup Azure Firewall Network

The first step of the configuration is to create a new resource group in East US.

To do that,

1. Launch PowerShell console and connect to Azure using Connect-AzAccount
2. Create a new resource group using New-AzResourceGroup -Name REBELRG1 -Location “East US”. Here REBELRG1 is RG group name and East US is the location.

3. The next step is to create a new virtual network under REBELRG1 resource group.

$fwsubn1 = New-AzVirtualNetworkSubnetConfig -Name “AzureFirewallSubnet” -AddressPrefix 10.0.0.0/24

$gwsubn1 = New-AzVirtualNetworkSubnetConfig -Name “GatewaySubnet” -AddressPrefix 10.0.1.0/24

$eusfwvnet = New-AzVirtualNetwork -Name EUSFWVnet1 -ResourceGroupName REBELRG1 -Location “East US” -AddressPrefix 10.0.0.0/16 -Subnet $fwsubn1,$gwsubn1

EUSFWVnet1‘s address space is 10.0.0.0/16. It is a class B IP address range. We have two subnets under it.

• AzureFirewallSubnet (10.0.0.0/24) – This subnet will be used by Azure Firewall. Azure firewall only can be created in a subnet with name ‘AzureFirewallSubnet‘
• GatewaySubnet (10.0.1.0/24) – This subnet is going to be used by Azure VPN Gateway. The subnet must be named as ‘GatewaySubnet‘ to support the configuration.

Setup Azure VPN Gateway in Azure Firewall network

1. The next step of the configuration is to create public IP address to use with Azure VPN gateway. To do that,

$gatewayip1 = New-AzPublicIpAddress -Name EUSFWVnet1GW1 -ResourceGroupName REBELRG1 -Location “East US” -AllocationMethod Dynamic

In the above, EUSFWVnet1GW1 is the name for the new public IP address. VPN Gateway only supports Dynamic Public IP address allocation. So, it is been set using -AllocationMethod.
2. Before we create the gateway, we need to create ip configuration.

$fwvnet1 = Get-AzVirtualNetwork -Name EUSFWVnet1 -ResourceGroupName REBELRG1
$fwgwsubnet1 = Get-AzVirtualNetworkSubnetConfig -Name “GatewaySubnet” -VirtualNetwork $eusfwvnet
$eusfwgw1ipconf1 = New-AzVirtualNetworkGatewayIpConfig -Name eusfwgw1ipconf1 -Subnet $fwgwsubnet1 -PublicIpAddress $gatewayip1

In above, New-AzVirtualNetworkGatewayIpConfig command used to create an IP configuration for gateway (using previously created gateway subnet & public IP addresses)

3. Finally, we can create the gateway using,

New-AzVirtualNetworkGateway -Name EUSFWGW1 -ResourceGroupName REBELRG1 -Location “East US” -IpConfigurations $eusfwgw1ipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1

In the above, the new VPN gateway is called EUSFWGW1. Its SKU is set to VpnGw1.

There are two methods to connect two virtual networks.

1. Azure VPN Gateways
2. Azure VNET Peering

Azure VNET Peering
Azure VNET peering allows connecting virtual networks seamlessly via Azure backbone infrastructure. This is similar to inter-VLAN routing in on-premises networks. The traffic will not pass via the public internet. It provides low latency, high bandwidth connectivity between virtual networks. VNET peering can use to connect virtual networks in the same Azure region or different Azure regions.

Azure VPN Gateways
If we are connecting virtual networks over the internet, we have to use VPN gateway option. This is the same for connecting Azure networks with on-premises networks. Also, if the encryption is a requirement, we have to use VPN gateways. Azure VPN Gateways can use to connect,

• Virtual Networks in the same region
• Virtual Networks in different regions
• Virtual Networks in different subscriptions

If the connection is over the public internet, it is not possible to guarantee the uptime as it depends on many facts. By using Active-Active Azure VPN gateways to improve the high availability of the VNet-to-VNet connections. This is important if you connecting the virtual network between different Azure regions. We also can use Active-Active Azure VPN gateways with cross-premises VPN connections.

In Active-Active Azure VPN gateway setup,
• There are two Gateway IP configurations with two public IP addresses for one VPN gateway. This allows initiating full-mesh connectivity between two virtual networks.
• VPN gateway SKU must be VpnGw1, VpnGw2, VpnGw3, or HighPerformance
• Supported to use BGP

In this demo, I am going to demonstrate how we can establish VNet-to-VNet connectivity between two Azure regions via Active-Active Azure VPN gateways.

In this demo setup, I got two virtual networks in East US and UK South region. As shown above, I am going to establish a fully mesh connectivity between two virtual networks.
For the configuration process, I will be using PowerShell. Therefore, please make sure you have an Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-3.8.0

Create Active-Active Azure VPN Gateway in East US

Create a resource group in East US

The first step of the configuration is to create a new resource group in East US.
To do that,
1. Launch PowerShell console and connect to Azure using Connect-AzAccount
2. Create a new resource group using New-AzResourceGroup -Name REBELRG1 -Location “East US”. Here REBELRG1 is RG group name and East US is the location.

Create a virtual network

The next step is to create a new virtual network under REBELRG1 resource group.

$subn1 = New-AzVirtualNetworkSubnetConfig -Name VMNet1 -AddressPrefix 10.0.0.0/24

$gwsubn1 = New-AzVirtualNetworkSubnetConfig -Name “GatewaySubnet” -AddressPrefix 10.0.255.0/27

New-AzVirtualNetwork -Name EUSVnet1 -ResourceGroupName REBELRG1 -Location “East US” -AddressPrefix 10.0.0.0/16 -Subnet $subn1,$gwsubn1

EUSVnet1 address space is 10.0.0.0/16. It is a class B IP address range. We do not need the entire range for workloads. Therefore, I am going to create two small subnets under it.

• VM Network – 10.0.0.0/24
• Gateway subnet – 10.0.255.0/27

In the above, VM network is going to use for virtual machines and Gateway Subnet is going to use for the VPN gateway setup.

Virtual Network Gateway can only be created in a subnet with name ‘GatewaySubnet’

By using source network address translation (SNAT), we can translate a local IP address, a pool of local IP addresses, or even a subnet to a specific public IP address for outbound connections. This is important as it will help to control traffic flow through firewalls by using ACLs. In Azure, we can do SNAT by using Azure NAT gateway. This allows virtual machines in the subnet to use a specific static public IP address when initiate outbound traffic.

Azure NAT Gateway has the following characteristics,

• NAT gateway resources can use up to 16 public IP addresses.
• One public IP can provide up to 64,000 concurrent UDP and TCP flows.
• NAT gateway is a fully managed service. No need to worry about high availability.
• NAT is only compatible with standard SKU public IP, public IP prefix, and load balancer resources. It is not supported to work with basic SKUs.

In this blog post, I am going to demonstrate how to set up Azure NAT gateway.

For the configuration process, I will be using PowerShell. Therefore, please make sure you have an Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-3.8.0

Let’s start the configuration by creating a new resource group.

1. Launch PowerShell console and connect to Azure using Connect-AzAccount
2. Then create a new resource group using,

New-AzResourceGroup -Name REBELRG1 -Location “East US”

In the above, REBELRG1 is the resource group names and it is created in the Azure East US region.

3. The next step of the configuration is to create a public IP address to use in Azure NAT gateway.

$REBELPublicIP =
New-AzPublicIpAddress -Name “REBELPUB1” -ResourceGroupName “REBELRG1” -AllocationMethod Static -Location “East US” -Sku “Standard”

In the above, REBELPUB1 is the name for new public IP resources. This New IP address is using Static allocation method and Standard SKU.

4. We also need to create public IP prefix to use with NAT gateway.

$REBELPublicIPPrefix =
New-AzPublicIpPrefix -Name “REBELPUB1PREFIX” -ResourceGroupName “REBELRG1” -Location “East US” -PrefixLength 31

In the above, the prefix name is REBELPUB1PREFIX and prefix length is set to 31.

5. Now we are ready to create NAT gateway. We can do that with following command,

$REBELNATGW =
New-AzNatGateway -Name “REBELNAT1” -ResourceGroupName “REBELRG1” -PublicIpAddress $REBELPublicIP -PublicIpPrefix $REBELPublicIPPrefix -Location “East US” -Sku “Standard” -IdleTimeoutInMinutes 10

The gateway is using Standard SKU. Its idle time out setting is set to 10 minutes.

6. The next step is to create a new virtual network under REBELRG1 resource group.

$vmsubnet = New-AzVirtualNetworkSubnetConfig -Name vmsubnet -AddressPrefix “10.0.2.0/24” -NatGateway $REBELNATGW
$REBELVNET = New-AzVirtualNetwork -Name REBELVN1 -ResourceGroupName REBELRG1 -Location “East US” -AddressPrefix “10.0.0.0/16” -Subnet $vmsubnet

In the above, REBELVN1 is the new virtual network name. It has 10.0.0.0/16 address space. It also has a new subnet 10.0.2.0/24 (vmsubnet) for virtual machines.

Azure VNET peering allows connecting virtual networks seamlessly via Azure backbone infrastructure. This is similar to inter-VLAN routing in on-premises networks. VNET peering can use to connect virtual networks in the same Azure region or different Azure regions. If it is between regions, we call it “Global VNET Peering”.
Global VNET Peering has following benefits,

• Low latency and high bandwidth as it uses Azure network backbone
• No requirement for encryptions, VPN gateways or public internet to connect VNETs

In this demo, I am going to demonstrate how to connect two virtual networks in two different Azure regions using Azure Global VNET peering.
For the configuration process, I will be using PowerShell. Therefore, please make sure you have an Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-3.8.0

As the first part of the configuration, I am going to create two new resource groups and two virtual networks.

1. Launch PowerShell console and connect to Azure using Connect-AzAccount

2. Then create two new resource group using,

New-AzResourceGroup -Name REBELRG1 -Location “East US”

New-AzResourceGroup -Name REBELRG2 -Location “UK South”

In the above, REBELRG1 & REBELRG2 are the resource group names and East US is the resource group names. REBELRG1 is created in Azure East US region and REBELRG2 is created in Azure UK South region.

3. The next step is to create a new virtual network under REBELRG1 resource group.

$vmsubnet = New-AzVirtualNetworkSubnetConfig -Name vmsubnet -AddressPrefix “10.0.2.0/24”
New-AzVirtualNetwork -Name REBELVN1 -ResourceGroupName REBELRG1 -Location “East US” -AddressPrefix “10.0.0.0/16” -Subnet $vmsubnet

In the above, REBELVN1 is the new virtual network name. It has 10.0.0.0/16 address space. It also has a new subnet 10.0.2.0/24 (vmsubnet) for virtual machines.

4. Then let’s go ahead and create another virtual network under REBELRG2 resource group. This will be in UK South Azure region.

$vmsubnet2 = New-AzVirtualNetworkSubnetConfig -Name vmsubnet2 -AddressPrefix “10.1.3.0/24”
New-AzVirtualNetwork -Name REBELVN2 -ResourceGroupName REBELRG2 -Location “UK South” -AddressPrefix “10.1.0.0/16” -Subnet $vmsubnet2

Azure AD authentication is supported for Azure Point-to-Site (P2S) VPN. This means we can use Azure AD features such as conditional access, user-based policies, Azure MFA with VPN authentication. In this Demo, I am going to demonstrate how to enable Azure AD authentication for Azure point-to-site VPN.

As we go along, we will be working on the following tasks,

• Setup Azure point-to-site VPN with native Azure certificate authentication
• Configure OpenVPN for Azure P2S VPN
• Enable Azure AD Authentication for Azure point-to-site VPN
• Configure VPN Client
• Testing

I am going to use Azure PowerShell for configuration. Please make sure you have the Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-2.6.0

Setup Azure point-to-site VPN with native Azure certificate authentication

Before we configure OpenVPN for Azure P2S VPN, first we need to set up Azure P2S VPN with native Azure certificate authentication. To do this,

1. Launch PowerShell console and connect to Azure using Connect-AzAccount (Using Global Administrator Account)
2. Create a new resource group using New-AzResourceGroup -Name REBELVPNRG -Location “East US”. Here REBELVPNRG is RG group name and East US is the location.

3. Now we need to create a new virtual network. We can create a virtual network using,

New-AzVirtualNetwork -ResourceGroupName REBELVPNRG -Name REBEL-VNET -AddressPrefix 192.168.0.0/16 -Location “East US”

In the above, REBEL-VNET is the virtual network name. it uses 192.168.0.0/16 IP address range.

4. Under the virtual network, I am going to create two subnets. One for servers and one for VPN gateway. To create subnets,

$vn = Get-AzVirtualNetwork -ResourceGroupName REBELVPNRG -Name REBEL-VNET
Add-AzVirtualNetworkSubnetConfig -Name “REBEL-SVR-SUB” -VirtualNetwork $vn -AddressPrefix 192.168.100.0/24
Add-AzVirtualNetworkSubnetConfig -Name “GatewaySubnet” -VirtualNetwork $vn -AddressPrefix 192.168.5.0/24
Set-AzVirtualNetwork -VirtualNetwork $vn

In above REBEL-SVR-SUB is the server subnet and its address prefix is 192.168.100.0/24. GatewaySubnet is the VPN gateway subnet and its address prefix is 192.168.5.0/24.

Virtual Network Gateway can only be created in a subnet with name ‘GatewaySubnet’

5. VPN gateway is required a public IP address. To create one use,

$publicip = New-AzPublicIpAddress -Name REBELVPNPublicIP -ResourceGroupName REBELVPNRG -Location “East US” -AllocationMethod Dynamic

VPN Gateway currently only supports Dynamic Public IP address allocation.

Then update ip configuration using,

$vn = Get-AzVirtualNetwork -ResourceGroupName REBELVPNRG -Name REBEL-VNET
$gwsubnet = Get-AzVirtualNetworkSubnetConfig -Name “GatewaySubnet” -VirtualNetwork $vn
$gwipconf = New-AzVirtualNetworkGatewayIpConfig -Name REBELVPNGWipconf -Subnet $gwsubnet -PublicIpAddress $publicip

6. Next step of the configuration is to create a new VPN gateway,

New-AzVirtualNetworkGateway -Name REBELVPNGW -ResourceGroupName REBELVPNRG -Location “East US” -IpConfigurations $gwipconf -GatewayType Vpn -VpnType RouteBased -EnableBgp $false -GatewaySku VpnGw1 -VpnClientProtocol “IKEv2”

In the above, VpnType must be RouteBased. -GatewaySku should not be Basic as we are going to use OpenVPN and IKEv2. This can take up to 45 minutes to create the gateway.

7. Now we have the gateway. The next step is to configure VPN client address pool. In this demo, I am going to use 172.16.25.0/24 as a client pool.

$gw = Get-AzVirtualNetworkGateway -ResourceGroupName REBELVPNRG -Name REBELVPNGW
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -VpnClientAddressPool “172.16.25.0/24”

In my previous blog post, I explained how we can use FIDO2 security keys to perform password-less authentication with Azure AD. You can access it using Step-by-Step Guide: Azure AD password-less sign-in using FIDO2 Security keys
We also can use FIDO2 security keys to sign-in to Azure AD Joined or Hybrid Azure AD Joined Windows 10 devices. In this demo, I am going to demonstrate how we can enable FIDO2 security key sign-in using Azure AD and Microsoft Intune.
Before enabling password-less authentication with FIDO2 security keys, make sure you have,

1. Azure AD and Intune – Make sure you have valid Azure AD and Intune subscription in place.
2. Azure AD Join on Hybrid Azure AD joined Windows 10 Devices – If it is Azure AD Join device, it should run at least Windows 10 version 1903. If it is Hybrid Azure AD joined device at least it should be running Windows 10 Insider Build 18945
3. FIDO2 Security keys – The good people at eWBM provided eWBM Goldengate security key G320 (USB-C) and eWBM Goldengate security key G310 (USB-A) for testing. I will be using eWBM Goldengate security key G320 (USB-C) in this demo with Surface Pro 7.

4. Azure AD user account which completed the FIDO2 security key enrolment process – This explained in details via my previous post http://www.rebeladmin.com/2020/03/step-step-guide-azure-ad-password-less-sign-using-fido2-security-keys/

In this demo, I am going to use a user called Megan Bowen (meganb@M365x620957.onmicrosoft.com) for testing. I already have an Azure AD join device ready for her. It is showing as compliant in the Microsoft Intune portal.

Enable Windows Hello for Business with Intune

Before we create a device configuration profile, we need to enable Windows Hello for Business with FIDO2 security key support. To do that,

1. Log in to Azure Portal as Global Administrator ( https://portal.azure.com/ )
2. Search for Intune in the search box and click on it.

3. Then click on Device Enrolment

4. In the new window click on Windows enrollment | Windows Hello for Business

5. Select Enable for Configure Windows Hello for Business. Then keep the default settings.

6. Also, select Enable for Use security keys for sign-in

This will enable FIOD2 security key support.

7. At the end click on Save to apply the changes.