While closing up on one of my projects we started a proof of concept with two factor authentication based on Microsoft Azure MFA. Azure Multi-Factor Authentication is the service that requires users to also verify sign-ins by using a mobile app, phone call, or text message. You can use it together with Azure AD or together with custom applications and directories by using the SDK. You can also use it together with on-premises applications by using Multi-Factor Authentication Server.
Together with my colleague Tony Mels I configured Azure MFA on a dedicated server and a NetScaler Gateway. The idea was to configure their Office 365 access with Azure MFA and their remote access solution based on the NetScaler Gateway. The following configuration was needed to make sure that the remote access was configured with two-factor authentication via Azure MFA. Marius Sandbu has written a similar blogpost on his blog: Azure Multifactor authentication and Netscaler AAA vServer.
For this Proof of Concept we started with Automated phone calls to enable MFA as two-factor authentication method for this remote access solution. As this customer was already running on a NetScaler VPX 200 we decided to add another VIP for AGEE so we would be running into issues with the VIP that was running in production (as we need to alter the authentication method for this VIP).
We started by creating a new Authentication Policy called AG_RADIUS_MFA, which would be ‘true’ as there aren’t any other authentication methods configured for this VIP.
Next step was to setup a new Server, which we named Auth_Server_MFA01. MFA will act as a normal RADIUS server although you’ll probably need to increase the time out time to 30 or 60 seconds in order to receive the call to validate your logon. We changed it from 3 seconds to 60 seconds to be sure that the phone call would be received.
One of the discussions we had was the way to validate our user, Azure MFA has a couple of possibilities:
- Multi-Factor Authentication apps are available for Windows Phone, Android, and IOS devices. Users can download the free app from the device store and activate it by using a code that they get during setup. When the user signs in, a notification is pushed to the app on their mobile device. The user taps to approve or deny the authentication request. Cellular or Wi-Fi access is required for installing and setting up the app. After the app is installed, it can operate in the following modes to provide the additional security that a multi-factor authentication service can provide:
- Notification. In this mode, the Multi-Factor Authentication app prevents unauthorized access to accounts and stops fraudulent transactions. It accomplishes this by using a push notification to the phone or registered device. The user simply views the notification, and if it is legitimate, selects Authenticate. Otherwise, the user can choose to deny, or choose to deny and report, the fraudulent notification. For information about reporting fraudulent notifications, see How to configure and use Fraud Alert for Azure Multi-Factor Authentication.
- One-Time Passcode. In this mode, the Multi-Factor Authentication app can be used as software token to generate an Open Authentication (OATH) passcode. The user can then enter this passcode along with the user name and password to provide the second form of authentication. This option is useful in instances of spotty phone coverage.
- Automated phone calls can be placed by the Multi-Factor Authentication service to any phone, whether landline or mobile. The user simply answers the call and presses the pound key (#) on the phone to complete the sign-in.
- Text messages can be sent by the Multi-Factor Authentication service to any mobile phone. Each text message contains a one-time passcode. The user is prompted to either reply to the text message by using the passcode or enter the passcode on the sign-in screen.
To start this POC we used notification by a simple phone call.
These are the global settings for notifications for our users, we can decide what to do when there’s no Internet connection and we can configure the user defaults and the default PIN rules. As I’ve said, for this POC we went with the Phone call option.
Just like the (probably) more familiar Microsoft NPS you’ll have to configure a client within your RADIUS server. Remember that authentication traffic from NetScaler will have your NSIP as SOURCEIP so fill in the NSIP into the Client IP.
After configuring the basics we can go to the User Configuration, it will need the phone number and email address (which I anonymised for obvious reasons). You can change the two-factor authentication method per user here. As you can see we used the company settings as a default for this user.
To make sure that our NetScaler could reach the RADIUS server we opened up the firewall so that the NetScaler could reach the RADIUS server on the following ports:
- 1812/1813 (UDP)
- 1645/1646 (UDP)
When we configured the NetScaler/MFA combination we tested the configuration, after hitting the page in our browser we got a prompt for username/password. We pushed our credentials into the NetScaler and we got a phone call for verification. After answering the call by pressing the # sign we were automatically got logged on.
Latest posts by Kees Baggerman (see all)
- Recovering a Protection Domain snapshot to a VM - September 13, 2019
- Checking power settings on VMs using powershell - September 11, 2019
- Updated: VM Reporting Script for Nutanix with Powershell - July 3, 2019
- Updated (again!): VM Reporting Script for Nutanix AHV/vSphere with Powershell - June 17, 2019
- Updated: VM Reporting Script for Nutanix AHV with Powershell - April 8, 2019