Azure Multi-Factor Authentication – een overzicht

De afgelopen jaren heeft Microsoft hard gewerkt om Azure Multi-Factor Authentication in de One-stop-shop voor MFA te integreren. Lees in deze Engelse blog verder over Azure Multi-Factor Authentication – een overzicht.

Over the past years Microsoft has been working hard to integrate Azure Multi-Factor Authentication your one-stop-shop for MFA.

Integrations for Azure MFA are available nowadays in/for:

• Azure services (who knew right?)
• Office 365
• ADFS
• RADIUS (using the NPS Extension on the existing NPS-role)

Most people know about the first 2, yet for some reason the last 2 are rather unknown. But this means that you can integrate Multi-Factor Authentication in most of your (on-premises) systems, yay!

Additionally, Microsoft started out with a separate solution/configuration for its MFA- and its Self-Service Password Reset (SSPR)-functionality. As these two often use the same data (your mobile phone number is the same, whether you use it to reset your password or to provide an additional authentication factor by receiving a call) it’s impractical to have to set up both mechanisms separately.

Azure MFA and SSPR – The new/converged experience

Microsoft has set out to combine both the Azure MFA and SSPR configuration in what they call the (new and improved) “Converged Experience”. Other than just fancy language, this provides you with a more efficient, practical and user-friendly experience.

Although still in public preview, we have had very good experiences with this new converged way of working. You can offer your user a one-time “wizard runthrough” in a single location, after which they can use their configuration to both provide MFA when prompted ànd be able to do a self-service password reset with those same authentication factors.

If you are not using this already, we suggest testing this functionality at your earliest convenience. We do, however, recommend doing so in a testing-environment first, or via a rollout for a specific group of users. How you ask? Well that’s easy:

1. Open the Azure portal with an account that has administrative permissions (https://portal.azure.com),
2. Browse to Azure Active Directory> User settings > Manage settings for access panel preview features,
3. Under Users can use preview features for registering and managing security info, you can choose whether to enable the functionality for a Selectedgroup of users or for All users

After doing, you will need to wait for some time (a few hours mostly) to be able to access the new converged experience (at https://aka.ms/setupsecurityinfo). If you get that nasty error-page, you’ve tried to soon, get a coffee, read your e-mail and then try again.

Note!: Additionally, after you “flip the switch”, users that have not yet set up their MFA/SSPR setting can get prompted to set up configure their registration. It they have already set this up previously, Simply reviewing and confirming will suffice.

What changed?

OK, so you have enabled that new experience, what changed exactly? Well:

• Whereas you used to have to go to https://aka.ms/mfasetup to setup and manage your Azure MFA, and to https:/aka.ms/ssprsetup to setup and manage your SSPR, you now only to go to https://aka.ms/setupsecurityinfo, the one-stop-shop!
• You can manually enter an authentication phone-number to use for MFA
• Now you can also set up Microsoft Authenticator registrations on multiple devices (so for example on both your personal- as well as your business mobile phone)
• Or you can go to https://aka.ms/sspr to reset your password in case you forgot

On the right you can see what the Setup Security Info page looks like for me for example.

Azure MFA and ADFS

Now let’s talk a bit about using Azure MFA with your existing ADFS-setup.

Over the past years ADFS has become more understandable and some bits are now easier to set up. Multi-Factor Authentication can nowadays be set up using Access Control Policies. ADFS also has the ability to use Azure MFA as an authentication-mechanism built-in.

What’s important to note here, is that (Azure) MFA is often seen as an additional means of security, often complementary to a password-based authentication that you already “did” beforehand (often using Single Sign On). While that is of course a good and secure option, there is also an option to only do an Azure MFA challenge. This enables users to only have to do an “Approve” in their Authenticator-app for some applications for example, and no (additional) username/password is required. This is similar to Microsoft’s password less options. Maybe that is suitable for some of your scenarios?

So how do you set this up? This is done by registering the ADFS-servers with Azure and enabling them to provide the Azure MFA functionality. This “trust” is set up on a certificate-basis (and yes, this certificate expires, so make note of its expiry date once you configure this):

After doing so, it’s a matter of creating the right authentication policies, making sure everyone’s enrolled in Azure MFA, and applying the appropriate policy to the relying party trusts (your incoming authentications). Depending on each “application’s” (Relying Party Trust’s) requirements you may choose to apply different policies (and stringent security policy) per application to fit you and your organization’s security requirements.

Azure MFA en radius (NPS-extension)

I believe most of you know RADIUS, the standard means of authentication supported by many (network-related) components. It is often used to provide WiFi-network- and VPN-authentication. As it is a global standard, it is embedded into many network components such as VPN-gateways (Cisco, Meraki, Fortinet, NetScaler etcetera).

Microsoft has provided the means of doing RADIUS-authentication against the (internal) Active Directory for quite some time now, nowadays by means of the Network Policy Server (in short NPS). This enables you to verify incoming requests against the internal Active Directory. That’s great but, in for example VPN-gateways, you often want an additional verification method (another factor) for authentication. That’s where the NPS Extension comes in. It enables you to send that same RADIUS authentication-request but send the user that is attempting to connect/log on an Azure MFA challenge.

Do devices/applications understand Azure MFA via the RADIUS extension?

You may wonder if all applications and devices can work this way. Though RADIUS may be supported, can the device/application understand that is waiting for an Azure MFA challenge to complete? Maybe the user has the SMS-authentication option set as his/her default and the need to input the verification code? Does the application provide for that?

Good call, this may be something to investigate. There are two types of Azure MFA authentication methods:

• On/Off (1/0): The user must approve their request, or presses “#” on their phone if it’s them trying to authenticate. Authentication methods are:
  • Verification Phone call
  • Authenticator App Approval
• Input feedback: The user receives/sees an authentication code and has to input that into a feedback-window that the application/device provides. Authentication methods are
  • SMS Verification code
  • Authenticator App code
  • OATH Token code (physical token)

In the case of the “input feedback” options, it is important that your device/application has capabilities built-in to provide for this. You might imagine your VPN-client has to show you an input-window for the code, or your NetScaler needs to show you an additional webpage to input the code. NetScaler (and its Gateway) provide this option, but make sure your users choose either an “On/Off” method of configuration that does not require input, or your application/device can support “Input feedback” in order to be able to deal with all types of Azure MFA methods.

Can we load-balance those NPS-machines for authentications?

Sure! You can simply build two NPS-machines and load-balance them by means of a (hardware) load-balancer if you want. When building something as critical as an authentication-solution you want it to be high available, that is certainly possible. You will require a load-balancing solution though.

An example would be load-balancing via a NetScaler, on which Carl Stalhood (a long-time Citrix veteran) wrote some manuals. The thing to keep in mind is that it is very important to make sure all related requests are sent to the same NPS-server, to make sure sessions don’t get balanced to another server in the middle of an authentication attempt. You can do so by implementing persistence/stickiness.

Great, another local server…

Ah yes, going to the cloud does require you to still have local server, right? Noop, not always!

You might think: “I am going to the cloud, but now I need another local server?! Come on!”. Sure, building this type of Azure MFA integration requires a Windows-machine, but why host it on-premises? You could consider hosting the machine in Azure and by using Active Directory Domain Services (or in short ADDS) hook up the machine to the AD. That way it can do AD- and Azure MFA-authentication. If you (are planning to) go all-cloud that might be the way to go.

Do keep in mind, you will need some kind of load-balancing mechanism if you want to have the functionality to be high available. Azure can of course also cater for that.

Final words

For years ‘n years we have be focused on having passwords for everything, preferably different ones which preferably should be changed about once a week. Unfortunately, most of us don’t have that kind of time, memory and calmness available to “password manage” our lives in that way. As we are slowly moving away from a “passwords for everything” type world, this might be a good time to consider what the most secure ànd user friendly way to authenticate is for your environment.

Because we all know; if our colleagues (and maybe ourselves as well?) need to change a password monthly, we either add 1 to our digit, switch from that one familiar password to that other one, or put down a Post-it note on the screen that has the password on it. Why not make it easier on ourselves and our colleagues by taking advantage of, and implementing, those cool new possibilities Microsoft is making available for us?

Need any help figuring out where and/or how you can make things easier ànd more secure for your environment? Reach out to me or one of my colleagues; we’re happy to help!