Azure Multi-Factor Authentication (MFA) - The Untold Story

There are multiple blogs available on how to integrate Azure Multi-Factor Authentication (MFA) with on-premise applications such as ADFS, RD Gateway, IIS, etc. But in this blog, I’m going to call out certain elements that are not covered until now, and which I experienced as a part of some Azure MFA implementations that I have done.

RD Gateway - highly available deployment considerations

While integrating a highly available RD Gateway service with a master/slave Azure MFA server configuration, one needs to ensure that the below configuration is set.

1. If the below setting is not executed, then once your primary RD Gateway server is down, it will still not use the secondary RD Gateway server for 1st factor authentication because of the low timeout value. It needs time to timeout the authentication with the primary RD Gateway server and needs time to authenticate with the secondary RD Gateway (NPS) server.

2. If the below setting is not executed, then once your master MFA server is offline and your secondary/slave MFA server is promoted to primary it will still not accept connections.

1. On the primary RD Gateway server, open Server Manager. On the menu, click Tools, and then click Network Policy Server.
2. In the NPS (Local) console, expand RADIUS Clients and Servers, and select Remote RADIUS Server.
3. In the details pane, double-click TS GATEWAY SERVER GROUP.
4. In the TS GATEWAY SERVER GROUP Properties dialog box, select the IP address or name of the NPS servers (master and slave MFA servers) you configured to store RD CAPs, and then click Edit.
5. Ensure that the Master MFA (NPS) server has Priority as 1 and Weight as 50 and ensure that the secondary MFA (NPS) server has Priority as 1 and Weight as 50.
6. Repeat the above steps on the secondary RD Gateway server.
7. When you configure a Connection Request Policy in NPS that receives requests from MFA server (to be handled locally), ensure that the Client Friendly Name condition contains both the MFA servers (Master and Slave).
8. You can use the pattern matching suffix to ensure that both the MFA servers are part of the condition. Say for example if your Friendly name of master MFA server is MFA01 and Friendly name of the slave MFA server is MFA02, then your condition can use a pattern matching suffix as MFA0\d which will cover both the MFA servers. 

Important Azure MFA Pointers 

• In case you have multiple Azure MFA on-premise deployments - say for example one for OWA, and one with RD Gateway, then both will have a separate Azure MFA groups. This will mean that the settings across both these MFA groups will be kept separately.
• In addition to the above point, if there is a hybrid Azure MFA deployment - say for example Azure MFA-in-cloud service is used to secure Office 365, whereas Azure MFA on-premise will secure the websites integrated with ADFS, both will again have separate MFA groups.
• If option to sync users from trusted AD domains is enabled in Azure MFA server, you might face issues with synching sometimes. There was a bug detected while synchronizing user accounts from these various trusted domains to the MFA directory. The sync was failing even when there were no functional issues with these trusted AD domains. This was identified to be a bug with the MFA server version 6.3.1.1. On 6th April 2016, Microsoft released v7.0.0.9 of Azure MFA Server, which fixed the bug mentioned above. Ensure that your Azure MFA server version is at least v7.0.0.9 in case you are facing the same issue.
• In case you are installing the MFA user portal and MFA Mobile App portal on the same server(s) as those hosting the Azure MFA server, then you still need an Web Service SDK service account to be created, so that the MobileApp portal can use that account to authenticate with Azure MFA service via Web Service SDK. Also, in case both the User portal and Web service SDK websites have different SSL certificates, then if your user portal is running on port 443, you can set your Web Service SDK portal to run on port 8443. This will allow you to set the Web Service SDK website to use a different SSL certificate (a self-signed certificate generated from IIS server will more than suffice for this purpose).
• In case you are integrating Azure MFA server with RD Gateway, there is very critical user experience behaviour that might impact your design consideration for the RDS solution. In case you have multiple RD Session Collection in your environment, for each RemoteApp / Session Desktop accessed from different session collection the user will be prompted for Azure MFA challenge separately. Although you might be convinced that Azure MFA does its job well, this might not go down well with the Business stakeholders who keep end user experience at the top of their requirements. Hence, ensure to keep the number of RD Sessions collections in your environment as low as possible, to avoid the inconvenience to the users.
• Often you might need to implement Azure MFA for a customer who have employees around the world. In such cases, please do refer to this article that already exists to handle this requirement - https://blog.kloud.com.au/2015/07/01/azure-mfa-server-international-deployment/