Client VPNs have come along way in recent years and are still a necessity for organisations protecting their backend services that cannot be published to the public internet securely. The nirvana is having data presented by web applications and use SAML authentication to any good identity provider that supports MFA. This world still doesn’t exists in its entirety and you wont be the first or last to say that you have some old application that runs as a fat client on desktop machines with non standard protocols. Client VPNs will remain relevant until all these applications adopt modern web authentication frameworks.
Azure Active Directory is a great cloud based identity and authentication provider with lots of built in functionality to explore in the security space. If you’re using Office 365, then you already have one, and more bells and whistles can be turned on to include features like Multi Factor Authentication.
Most good firewall products will have a Client VPN that supports radius as a second factor of authentication, but sometimes that’s where the documentation finishes.
How do I get my firewall VPN authentication to talk to Azure MFA if all I have available is radius?
The article today talks explicitly about Palo Alto Global Protect client and VM Series firewall, but there is no reason if other firewall VPN supports radius that you couldn’t perform the same architecture.
Palo Alto Configuration
The following authentication settings needs to be configured on the Palo Alto firewall. I won’t bore you with every step, cause if you administering a firewall then I’ll assume a certain level of knowledge. The authentication flow will be:
- LDAP authentication with username and password (connected to Active Directory)
- Radius authentication using the NPS Azure MFA Extension
Configure LDAP as per normal, nothing special to note here. This will be the first factor of authentication in the VPN login sequence.
Radius Server Profile
- Device > Server Profiles > Radius and Add a profile.
- Enter a Profile Name to identify the server profile.
- Enter a Timeout interval in seconds after which an authentication. request times out (default is 3; I’ve changed this to 30 seconds to allow for cloud connectivity and then messages to client devices).
- Select the Authentication Protocol (PAP) that the firewall uses to authenticate to the RADIUS server.
- Add a new RADIUS server and enter the IP, Secret and Port (1812).
Radius Authentication Profile
- Select DeviceAuthentication Profile and Add a profile.
- Set the Type to RADIUS.
- Select the Server Profile you configured.
- Select Retrieve user group from RADIUS to collect user group information from VSAs defined on the RADIUS server. I’d recommend an ‘All Staff’ approach as this won’t be the restrictive policy to allow VPN.
Network Policy Server Configuration
Follow Micrsoft’s guide to deploying the NPS:
The incoming request condition for policies can be the NAS Identifier which will be the name of your authentication profile in the Palo Alto, the example I named profile ‘Radius Authentication’ so therefor this will be presented on incoming connection from the Palo to NPS.
Make sure for your authentication method you have PAP selected. The rest of the settings can be default. (CHAP/MS-CHAP while more secure was problematic in my deployment, therefor PAP was used). The traffic flows from the internal trusted interface of a firewall to a port on a trusted network segment encryption is not the major security control for this request.
After you install the Azure NPS Extension (make sure you reboot). This extension as great as it is, isn’t heavily customisable, which is why I strongly suggest this be a seperate radius server. Think of this NPS server as the MFA radius server as the extensions will intercept all requests regardless of policy. You don’t want this extension on an existing radius server that maybe used for WiFi authentication using certificates (EAP) for domain joined workstations etc.
Test the solution
Before you test end to end, a simple test of only the Radius configuration for MFA can be done by the firewall CLI. Log in via SSH and test the profile.
test authentication authentication-profile "Radius Authentication" username email@example.com password
If it fails, do a quick sanity check on your test user:
- Synced to Azure Active Directory.
- Assigned a MFA license (P1 etc).
- Enrolled in MFA (https://aka.ms/MFASetup).
If you find that you’re not successfully completing the above CLI in the Palo SSH session, then here are some places to look for troubleshooting.
Follow the Radius Authentication Flow
Do a quick visual traffic check in the GUI to make sure the radius authentication is leaving to the correct destination:
Monitor > Logs > Traffic > Enter this search criteria ( port.dst eq 1812 )
Do a packet capture
Monitor > Packet Capture add a filter, just choose the interface that the Palo should talk to the radius server on. Leave everything else blank and it just look like this afterwards.
Under the capture configuration, we need to choose a ‘stage’ and give the file a name, I’ve left packet count and byte count blank.
What we want to find is source IP of the Palo (.4) with destination port 1812. If its not here then its going out a different interface. We can modify the default interface for a service in the Palo if incorrect using service routes.
Here we can see the radius protocol inside the UDP packet. If we aren’t seeing the request make it to the radius server we may not be allowing 1812 on UDP on the ACL between the firewall appliance and radius server.
If we see the Access-Request on its way to the radius server we can do a few checks inside the Windows Server OS to validate the NPS configuration.
Check the radius server
Event Viewer > Custom Views > Server Roles > Network Policy and Access Service review the log entries for each authentication request. If the request is being denied by the NPS server then make sure it’s being handled by the correct policy. A failed authentication request will show you which profile determined it was a failure, if it isn’t matching your NPS rules for connection request and network policy review the NAS Identifier the request is sending in the authentication packet.
Review the MFA extension logs via Event Viewer > Applications and Services > Microsoft > AzureMFA.
If all is successful we would see a return UDP packet in the capture with response ‘Access-Accept’ from the radius (.10) to Palo (.4).
In the above image you can see the value for ‘Time from request: 11.78794200 seconds‘, this is why I recommend a longer timeout duration on the Radius Server Profile in the Palo Alto configuration. I did it in 11 seconds, but your end users will probably be less efficient than I am.
You can complete the MFA via the Authenticator application on your mobile device via an ‘Approve/Deny’ choice in the notification area or if you’re using SMS code (OTP) the Global Protect client will prompt after successful username and password which is nicely named by default.
8 thoughts on “Azure MFA with Palo Alto Client VPN”
Great article but I have some questions. Is the leap auth profile and radius profile under both the portal and gateway config? Does OTP for gateways need to be enabled? I’ll keep trying. There isn’t a video present anywhere but you could be the first.
Hello there, to have the NPS extension installed, you need the Azure AD Premium P1 or P2 right? You cannot do MFA for Palo Alto GlobalProtect CLient VPN with the free Azure Active Directory.
Hi Edwardo, P1 & P2 is access to Conditional Access for creating ADFS like rules, but since sometime in late 2019 Microsoft added something called ‘security defaults’ allow MFA for everyone. This maybe an option. You’ll find more about it here: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults
The opening 3 paragraphs explain the options:
Gateway > Authentication > Authentication Profile > Radius Authentication
Portal > Authentication > Authentication Profile > LDAP Authentication
OTP would be turned on via the Azure MFA Settings.
I have configured the MFA integration with Palo Alto successfully but the user experience as below:-
– the domain user account already found in the VPN client configuration so once we open the client the MFA screen showed and we provide the 2nd factor.
– another screen showed to provide the domain user password, then the 2nd factor again thein the user able to log in.
in this case, we need to configure SSO for the VPN or what can we do to enhance the experience to provide the MFA only one time within the connecting.
It could be one of two things, either between the different authentication profiles you are using for Portal and Gateway the username isn’t constructed the same so it isn’t matching them, therefor re-prompting for credentials. Or, the other thing you should look at is the cookie settings for generation and acceptance of authentication override in the Agent configurations.
I used MS Authenticator application to complete the authentication via an ‘Approve/Deny’. However, my request still connect even tapping ‘Deny’. I
checked my NPS events and I’m getting access granted because the host met the defined health policy. But the MFA NPS extension logs is sending a ACCESS_REJECT message. Any thoughts of this?
Hi Alberto, Health Polices were apart of older versions of Windows NPS, I’ve performed the NPS installation on both 2016 & 2019. Both of these OS’s don’t have Health Policies in NPS anymore. So I’m not sure where this is coming from if your using a newer OS version. The key to making the correct policy activate in using conditions, where the value for NAS Identifier matches your Palo Policy Name. Additionally there is a registry key that you can set on a server to bypass the authentication failures if the user hasn’t configured 2FA yet, but I don’t think this is your problem.