Azure Announcements March 2018

azureIt’s been a few months since I wrote my last ‘Azure Announcements’ blog post so thought it would be worth sharing a number of features which I have my eye on.

Reserved Instances

VM’s we all love them, and guess what they will probably continue to be part of all public cloud deployments.

Certain IaaS VM’s that run applications such as Active Directory Domain Services will be on 24x7x365, why not reserve these instances and enjoy up to 82% savings versus Pay As You Go.

Essentially you commit to either a year or three years upfront.  The good news is, if anything changes you get an adjusted refund.

More details here.

Azure Network Watcher

Azure Network Watcher went GA on 29th January 2018.  A great tool to have in your toolkit, features include:

  • Connectivity Checks
  • Hop by hop latency
  • A graphical view from source to destination
  • Number of packets dropped

It also enables a connectivity check for ExpressRoute which is in preview.

More details here.

Cost Management

Monitoring spend in the cloud has always been a pain.  With the acquisition of Cloudyn last year, Microsoft have made consumption insights much easier.

  • Ability to schedule reports to be emailed to recipents
  • Carry Tags across to view application service or grouped component cost
  • Review ‘heavy hitters’ in terms of consumption

Great news is until June 2018, Cost Management is free.

More details here.

Azure Availability Zones (Preview)

This is a key features that customer have been crying out for (shame it’s still in preview).  Essentially Availability Zones protect from data centre level failures, something with Availability Sets do not currently do.

More details here.

Azure Migrate

To start the journey to public cloud services, you need to understand your application estate.  This is a process which should not be under estimated as many customer environments are poorly documented, application owners have left the business, operations and IT don’t really understand how an application is coupled together so trying to migrate anything but low hanging fruit often gets placed into the ‘too hard to deal with bucket’.

To counter act this, Microsoft have announced Azure Migrate which uses an application based approach for the following:

  • Discovery and assessment for on-premises virtual machines
  • Inbuilt dependency mapping for high-confidence discovery of multi-tier applications
  • Intelligent rightsizing to Azure virtual machines
  • Compatibility reporting with guidelines for remediating potential issues
  • Integration with Azure Database Management Service for database discovery and migration

More details here.

Just in Time Access (Preview)

Consider for a moment, the attack vector on your virtual machines.  You may have some ports exposed to the public internet , however these are likely to be protected using Next Generation Firewalls and perhaps even a DDoS scrubbing service from your ISP.

Perhaps the largest attack vector are your management ports such as SSH, RDP and WMI to name but a few.  When these ports are open, it allows anyone to try and obtain access  whether it is a authorised or not.

This is where ‘Just in Time Virtual Machine Access’ steps in to reduce your overall attack surface.  Access to management ports are closed and access is only granted from either trusted IP’s or per request.

More details here.

Part 2 – Configuring Azure Application Gateways with AD FS

In Part 1 of Configuring Azure Application Gateway with AD FS  we covered the existing architecture AD FS and the target AD FS architecture.  Finally we deployed an Application Gateway with a basic configuration.

So lets have a look at the logical configuration of what AD FS with a Application Gateway running a Web Application Firewall will look like.

Azure AD FS WAF Logical v0.1

Now we are ready to get cracking with some configuration work!

Backend Pools

This is where the Application Gateway will be delivering interesting traffic too.  In this case it will be the following virtual machines:

  • VMF-WE-WAP01
  • VMF-WE-WAP02

Select Application Gateway > Backend Pool and then add in your virtual machines.  It should look something like this.

WAF 03

Frontend Listener

This is the external port that the Application Gateway listens for interesting traffic.  In Part 1, we chose HTTP, the reason for this is so that we can configure HTTPS and go through the steps in more detail.  Plus we get to use our own naming convention rather than Microsoft’s!

Select Application Gateway > Frontend Listeners and enter out configuration details, which are:

  • Name 443_Listener
  • Front End Port Name 443_Port
  • Port 443
  • Protocol HTTPS

We now need our certificate in PFX format, so time to grab that before we move on.

The screenshot below shows the deployed configuration.

WAF 04

HTTP Settings

To ensure that we receive end to end SSL, we need to use a HTTPS setting under HTTP settings (I’m sure Microsoft could come up with a better name).   The HTTP setting which is the backend needs to be trusted by the Frontend, to do this we need to take our original certificate which was .pfx and make sure it’s .cer format.

Select Application Gateway > HTTP Settings and enter out configuration details, which are:

  • Name 443_Setting
  • Request Timeout: 30
  • Cookie Based Affinity: Enabled
  • Port 443

The configuration should look something like the screenshot below.

WAF 05


Next we are going to configure a Rule (which we are going to change, but we have to do things in a certain order).

Select Application Gateway > Rules and enter out configuration details, which are:

  • Name 443_Rule
  • Listener 443_Listener
  • HTTP Setting 443_Setting

WAF 06

Now we are cooking on gas and we can remove the default settings.

Remove Default Settings

Lets start with Rules, select ‘Rule1’ and click delete.  Once that has gone, select Listeners and then AppGatewayHTTPListener and click delete.  You will be prompted to confirm that it will make changes to the FrontEndIP and Port, which makes sense as it will no longer listen on Port 80.

Then last of all select HTTP Settings and then appGatewayBackendHttpSettings and click delete.

Sense Check

Right before we go any further we are going to perform a Backend Health Check to see what is occurring.

WAF 07

Man down, I repeat man down!  The reason for this is that the Application Gateway requires specific ports to be opened up for the Health Check API to work which are 65503-65534

I usually apply NSG to subnets as it makes all resources placed within the subnet then inherit the security rules.

As you can see I have created two rules, the first allows HTTPS traffic from the internet and the second allows the Health Check API inbound ports.


If this was a production rollout of a WAF with AD FS I would strongly suggest you create some specific rules to limit traffic flow between subnets within the vNET.  As this is a lab environment which is only up temporarily I shall move on!

Time again for another sense check, lets verify the Backend Health.  Argh, we are still in a man down scenario.

WAF 07

The reason for this is the built-in Application Gateway probes our Web Application Proxies on ports they don’t respond on.  We need to create a Custom Health Probe.

Health Probe

So lets get Backend Health working.  Select Application Gateway > Health Probes > Add.  The configuration details we are going to use are as follows:

  • Name Probe_ADFS
  • Host
  • Procotol HTTPS
  • Path /adfs/ls/idpinitiatedsignon.htm
  • Interval 30 Seconds
  • Timeout 30 Seconds
  • Unhealth Threshold 3

It should look like the picture below.


Finally we need to apply the Custom Health Prove to our HTTP Setting.  Select HTTP Setting > 443_Setting and Tick ‘Use Custom Probe’ > Select Probe_ADFS.


Now lets check the Backend Health one last time.


Excellent the Application Gateway will now be passing traffic correctly to our Web Application Proxies.  All we need to do now is update DNS to point to the Public IP Address of the Application Gateway.


Part 1 – Configuring Azure Application Gateways with AD FS

This is the first in a short series of blog post which is aimed at the configuration of an Azure Application Gateways.

Why might you ask am I creating a blog post series? For two reasons, firstly I think that the Application Gateway provides an extra level of protection for internet facing applications and secondly I found the Microsoft documentation lacking in a few areas.

What is an Application Gateway?

Application Gateways are a dedicated virtual appliance providing application delivery controller services.

Benefits of using Application Gateway are:

  • Provides Layer 7 load balancing and routing
  • SSL Offload, taking the burden of decrypting traffic from Internet facing servers onto the Application Gateway
  • End to End Encryption by terminating SSL connection onto the Application Gateway, applies routing rules and then re-encrypts traffic
  • Cookie Based Session Affinity to ensure users are directed back to the same session
  • Protects web applications from common attack scenarios such as cross-site scripting, SQL injection and session hijacks using web application firewall capabilities
  • Custom health probes enabling specific application paths to be monitored

Drawbacks of using Application Gateway are:

  • Increased complexity versus Load Balancers
  • Can only be deployed when it is the first resource within a subnet

In this scenario I have AD FS running on Windows 2016 which is running on Microsoft Azure and is integrated with Azure AD via Azure AD Connect.  A logical overview of the configuration is shown below.

Azure AD FS v0.1.png

The plan is to extend this design and include an Application Gateway running Web Application Firewall functionality.  A logical configuration of the desired state is shown below.

Azure AD FS WAF v0.1.png

Before we being, I recommend that you verify your AD FS configuration to make sure it’s functioning correctly.  Also you will need your AD FS certificate available in order to undertake the SSL Offload onto the Application Gateway.

Getting Everything Ready

I know you are itching to crack on, but I try and work in a logical order.  So first of all make sure you have your subnets defined correctly in Azure.  The configuration I’m using is as follows:

VMF-WE-SUB01 – This subnet is the Trusted Network in the diagram above.

VMF-WE-SUB02 – This subnet is the DMZ Internal Network in the diagram above.

VMF-WE-SUB03 – This subnet is the DMZ External Network in the diagram above and will be used for the Application Gateway

Important, the Application Gateway must be the first resource deployed in a newly created subnet

WAP Servers

We need to get the thumbprint for our AD FS Certificate and ensure this is bound correctly.  Run the following command to obtain the Certificate Hash and Application ID

netsh http show sslcert


Next we need to run the command on both WAP servers

netsh http add sslcert ipport= certhash=f2d9bb93d29a2c2c0835f4a4cb2d67d51efc5706 appid={5d89a20c-beab-4389-9447-324788eb944a}

To verify the command has ran correctly, view your SSL Certificates again and you should see IP:Port tied to your AD FS Certificate.


Deploy Application Gateway

Within the freshly created VMF-WE-SUB03 we are going to deploy an Application Gateway.

Let’s start by entering the basics, I calling mine an imaginative VMF-WE-AG01.  It’s going to be a WAF, so I have selected this.  Finally, I will be using an existing Resource Group.

WAF 01

The VNet is VMF-WE-VNET01 and the subnet is VMF-WE-SUB03.  We are gong tro create a Static Public IP Address (I’m calling mine VMF-WE-AG01-PIP).  Finally we will leave the Listener Configuration as HTTP for now.

WAF 02

That’s the Application Gateway deployment beginning.  It’s going to take a while so suggest you make a brew and get yourself ready for the next instalment.


HPE StoreVirtual for Hyper-V .NET 3.5

VSAAs part of transitioning my lab to Hyper-V I’m using a HPE StoreVirtual VSA to provide shared storage to the Hyper-V Hosts.

When trying to load ‘HPE_StoreVirtual_VSA_2014_and_StoreVirtual_FOM_Installer_for_Microsoft_Hyper_V_TA688-10552’ I encountered the error ‘The Hyper-V for VSA deployment wizard requires version of .NET 3.5 to be installed on the system’.


Easy, I thought go into roles and features and add .NET 3.5.  However, you encounter the following error ‘Do you need to specify an alternate source path? One or more installation selections are missing source files on the destination’.

.NET 3.5 Error


The first thing to do is mount your Windows Server 2016 Datacenter CD.  Once done, select ‘Specify an alternate source path’

.NET 3.5 Resolution 1

Type in G:\Source\SxS and click OK, followed by Install.

.NET 3.5 Resolution 2


Just in Time Virtual Machine Access

Security Centre.png

Consider for a moment, the attack vector on your virtual machines.  You may have some ports exposed to the public internet , however these are likely to be protected using Next Generation Firewalls and perhaps even a DDoS scrubbing service from your ISP.

Perhaps the largest attack vector are your management ports such as SSH, RDP and WMI to name but a few.  When these ports are open, it allows anyone to try and obtain access  whether it is a authorised or not.

This is where ‘Just in Time Virtual Machine Access’ steps in to reduce your overall attack surface.  Access to management ports are closed and access is only granted from either trusted IP’s or per request.

How Does It Work

Just in Time (JIT) works in conjunction with Network Security Groups (NSG) and Role Based Access Control (RBAC) to open up management ports on a timed basis.

  • Works for VMs which are both public and private accessible
  • Requires write access the VM

The second point makes perfect sense, we have customers who have read access to certain elements within the Azure portal to review logs or performance charts, but aren’t allowed access to the virtual machines.

To gain access on a desired management port, the requester must have ‘Contributor’ rights to the VM.  Which means that the following points need to be considered:

  • The requester requires an Azure AD Account
  • RBAC configuration
  • Access for third parties using Azure B2B

Configuration Choices

At the time of writing, you can define the following conditions per VM policy:

  • Port
  • Protocol (TCP/UDP)
  • Allowed Sources either Per Request or IP Range
  • Maximum Request Time  1 to 24 Hours

Requesting Access

Once the JIT policy has been applied to the VM.  A user logs into the Azure Portal and then has to open Security Center.  From within this they need to select Just in time VM access, select the VM and ‘Request Access’ choosing the Ports and Time Frame required.

Final Thoughts

The process to enable JIT is straight forward but does require some detailed consideration on how RBAC is configured.

Requesting access to a VM is currently quite clunky it would be great if a JIT portal was available for this purpose.