ADFS and 3rd party MFA integration tip

Securing access to authentication provided through ADFS is important and whilst Microsoft’s Azure MFA services will integrate perfectly with it many organisations choose to use utilise their existing MFA solution of which there are a number supported by Microsoft – plus others that aren’t certified.

I’ve performed a few installations now using 3rd party MFA solutions and just wanted to briefly write about an issue I’ve had with using two different solutions.

During the installation of the agent on the first (primary) ADFS server I carefully followed the instructions from the supplier and the agent would install and present the MFA login screen correctly but when it came to installing the agent on additional servers in the same farm I encountered errors with the MFA option not loading.

Neither instruction set from the suppliers made mention of what should be done on additional servers in a farm so I was left with a little trial and error to discover a workaround.

The procedure I’ve found that worked for me (and there may be alternatives or exceptions to this) was to:

1) Install the MFA agent on Primary ADFS server
2) Disable the agent (usally through the agent software) or through the AD FS Management console
3) Move the Primary ADFS role onto the second server (plus update all the others to secondary)
4) Install the MFA agent
5) Repeat steps 2-4 for any additional servers in the farm

After doing this the MFA process worked for traffic going to all the servers in the farm, I’m not sure why the documentation didn’t account for multiple ADFS servers in the farm as after all I’d like to think that running two ADFS servers in a farm should be the most common scenario to provide HA capabilities.

Hope it helps.

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.