[MUSIC]
Bailey Bercik: Welcome to the Azure AD Architecture Deep
Dive Series. My name is Bailey Bercik and I’m a Program
Manager on the Azure AD Engineering team at Microsoft.
Jef Kazimer: Hello. My name is Jef Kazimer and I’m also a
Program Manager on the Azure AD Engineering team.
In this video from the Azure AD Architecture Series, we are
going to cover Azure MFA for accessing applications and
services using RADIUS.
Bailey: So, Jef, since many of our viewers may not be
familiar with RADIUS authentication, what kind of applications
and services typically use RADIUS for authentication?
Jef: Many customers may be using RADIUS for authenticating
the access VPN network services, remote desktop to servers,
or for managing network equipment, such as routers and
switches.
Bailey: So when organizations want to have more than just
username and password for those scenarios, how can they
use Azure MFA to provide those controls?
Jef: Today, customers can add an additional layer of security
controls to the RADIUS scenarios by using Azure MFA
extensions for the Windows Server Network Policy Server
feature, also known as NPS. Since users can have different
types of authentication methods, such as push notifications,
phone calls or time based one-time passcodes, Azure MFA
can be used to invoke the MFA challenge as part of the
authentication flow.
Bailey: So, if a user is accessing VPN services where a
customer has deployed Azure MFA for RADIUS, what does
that flow look like? Let’s walk through that flow and see the
steps for complete authentication process.
Jef: So here, we have a typical scenario where a customer
has deployed their VPN network access services using RADIUS.
And they have decided they want to provide additional controls
by using the Azure MFA feature of Azure Active Directory. In
this scenario, the user is wanting to connect to the corporate
network via VPN. The user opens her VPN client, is presented
with a dialog box requesting the user to enter their username
and credential. Now that the user has provided their username
and password to the VPN client to the VPN service, the VPN
server now presents that credential pair to the NPS server
as a RADIUS request to authenticate the user. And it waits
for a response to determine if the user is authenticated to
access the service or not.
The NPS server now uses the credentials in that request to
validate the password against Active Directory. And if that
is successful, it will then invoke MFA for the user provided.
Bailey: In looking at the flow, it would seem there are two
steps to the authentication process for the user. Is this
correct?
Jef: Yes. The primary authentication using NPS is against
the on-premises Active Directory. And then once
authenticated, the secondary step is to invoke the MFA
challenge using the Azure MFA service before returning the
response to the VPN server.
Bailey: How does the NPS server invoke the MFA challenge
using the Azure MFA service in the cloud?
Jef: When the NPS server administrator installed the Azure
MFA NPS extension on the server, the process registered
itself in the associated Azure Active Directory, which issued
a certificate identifying the specific instance. When the
Azure MFA extension goes to invoke Azure MFA, it
authenticates to Azure Active Directory using that certificate
to authenticate and open a secure connection to send a
request to invoke the default MFA authentication for that
user.
Bailey: The user has registered for Azure MFA. And if they
have more than one authentication method, they can set
one of them as their default method. In this scenario, the
user has set their default method to one of the notification
methods, such as Microsoft Authenticator or phone calls.
So, when the Azure MFA service goes to invoke the MFA
request from the NPS extensions, it looks up the user’s
MFA details and invokes the MFA challenge using that
method.
Jef: So, what happens when the user’s default method is a
push notification or a phone call? How does the user receive
the request?
Bailey: The Azure MFA service interacts with the infrastructure,
such as initiating a push notification to the user’s registered
Microsoft Authenticator device or dialing the phone number
that they have registered to receive the phone call.
Jef: So, it is at that point where the user can receive the call
or push notification and either approve or deny the Azure
MFA request?
Bailey: Yes, Jef. The user who receives the request can either
choose to approve or deny the request, which sends that
response back to the Azure MFA service. The Azure MFA
service provides this response back to the NPS extension
on the NPS server.
Jef: Now that the NPS has an authentication response, it will
now pass the RADIUS response back to the VPN server. If
the response was an accept, then the VPN server would
complete the connection and respond back to the VPN client
that they are now connected. Also, if they received a reject,
MFA access would not be granted.
Since users may have other authentication methods set as
their default, such as an OTP or one-time passcode, let’s show
the differences in the authentication flow.
Bailey: So when the user’s method is a time based one-time
passcode or TOTP, such as the verification code generated in
the Microsoft Authenticator mobile application, it requires the
user to provide that code as a response. When using web
browser scenarios, we can ask them to enter the code into
the browser, but how does that work with RADIUS scenarios?
Jef: When the user’s default method is a TOTP verification code,
we first do the primary authentication using their username
and password credentials entered into the VPN client. But
when we invoke the MFA service, it looks up the MFA details.
And now, it responds with a session ID and challenge message
and the request for an access challenge is sent back to the
NPS server extension.
The NPS server responds back to the VPN server with an
access challenge with that session ID or the state and the
challenge message, which passes this on back to the VPN
client.
If the VPN client supports presenting a dialog box to ask the
user for the access challenge by presenting the message
and asking the user for the TOTP code in this scenario. It
is important to know that not all RADIUS clients support
asking for an access challenge, so it’s important to verify that
it is supported with a network service using RADIUS.
Bailey: So, the user would get the TOTP verification code
from the Microsoft Authenticator application and enter it
into the VPN client?
Jef: Yes. Then the VPN client responds to the VPN server with
the enter TOTP code and the session ID as a RADIUS request
to the NPS server. The NPS extension authenticates itself and
it validates the TOTP and session ID with the Azure MFA
service and returns the RADIUS response back to the VPN
server as either an accept or reject.
The VPN server receives the response from the NPS server
and provides this response back to the VPN client. The final
response is returned to the VPN client and, if successful, the
VPN connection could be established.
Bailey: So in our previous architecture videos as we covered
modern authentication and legacy authentication, and since
the VPN client is asking for their password, is this modern
authentication?
Jef: Well, many network services also support modern
authentication through more modern protocols like SAML
or OAuth today, in the scenario above, RADIUS would not
be considered modern authentication, since we are providing
our credentials directly to the VPN application instead of
Active Directory itself. This is another scenario where having
MFA in addition to a username and password is a good idea.
Windows Services cannot use more modern protocols for
additional controls.
Bailey: We hope you found this video useful. We will be adding
different videos on topics like authentication, provisioning,
governance, and many more. If you want to get a copy of
the diagrams we used today or give us feedback and help us
figure out what to cover next, please follow the link in the
description below.
[MUSIC]