GlobalProtect using Azure AD SAML and pre-logon
The setup
Is deployed with a goal of having no user interaction required for the VPN. SAML automatically authenticates the user after they are logged into Windows. Pre-logon enables authentication before Windows login, but no user credentials are stored yet, so the option for automatic connection is using machine certificate.
Azure Enterprise Application
Requires Azure AD and some other server stuff that someone else will configure. Other than that it is quite simple and the integration is A+. I care about the 2 highlighted tabs:
Mainly I just care about the "Single sign-on" tab. When adding a new firewall/gateway, the URL has to be added in here:
The URL to add is the gateway address making the authentication request.
Following the Azure documentation, just download the Federation Metadata XML file. Import it on the PA firewall. If the import is getting stuck or failing, try using Edge or Firefox. There is a common problem with Chrome and PA web.
Firewall Certificate and Authentication Profile
Four certificates:
- 2 internal certificates for pre-logon using machine certificate.
- Azure AD certificate automatically added when importing the XML file
- A certificate for the public DNS of the firewall gateway.
Certificate profile for pre-logon:
Completely standard.
SSL profiles. One for portal and one for gateway. Could just use the same for both, really.
SAML authentication profile:
The pre logon certificate profile doesn't have anything to do with SAML. It's 2 different authentications. However, it's still has to be specified like this.
Firewall Network
Regardless of whether it's in Azure or on-prem, the setup is the same for the first gateway. An internet facing interface in an untrusted zone and a tunnel interface in the GP zone. The tunnel interface doesn't need an IP.
Routing to the client IP addresses is automatically added. The firewall will add as small chunks of the subnet as possible, based on used IP addresses:
A static route can be added to cover the entire scope and redistributed to BGP, if having a lot of small scopes in the route tables is not desirable.
Adding a second gateway is dependent. In Azure, I've configured the interfaces like so:
And add the 10.0.0.5 as a secondary address on the VM NIC in Azure.
For a non-azure deployment and if using shared gateway it's a little different.
https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/virtual-systems/shared-gateway/external-zones-and-shared-gateway.html
With a shared gateway, creating public facing interfaces in different zones is possible like this:
As long as it's a physical interface. If I don't have a physical interface, I can use a loopback with a public address for VPN termination (both GP and S2S). But I can't use the same zone logic as with physical interfaces like this:
Internal packet processing requires a logical interface to be in the same zone as the public interface in the shared gateway:
Firewall GlobalProtect Portal and Gateway
Configuring the portal and gateway was a bit tricky. Mainly because I found the mix of 2 different authentications in the same configuration confusing. One portal and one gateway can handle the configuration. There's no need to create one for pre-logon and one for SAML, which was my first bet.
The agent configurations contain some important bits:
Starting with the portal agent. "Authentication" and "Config Selection Criteria" tabs contain standard config. Internal host detection configuration:
All external gateways configured:
The App page contains some important changes:
Specifically this:
By default, the value is -1. If left at -1, the tunnel that is established with pre-logon, doesn't roll over to a new tunnel, when the user is logged in and authenticated with SAML. Since pre-logon is done using machine certificate and nothing else, it should be a restricted connection.
The agent for SAML is identical, including the "Connect Method":
I had it set to "User-logon (Always On)" when I first implemented this and it didn't work. I figured, the SAML logon is done with user credentials, so of course it's user-logon. No. Pre-logon. The reason for this is because of registry settings on windows.
Gateway authentication is identical to portal:
Tunnel settings are standard:
The Client Settings is where I've differentiated pre logon and SAML:
By splitting into different IP pools, I just use firewall policies to restrict access based on client IP.
Policy Stuff
The windows deployment requires a couple of registry settings changed. In the path:
\HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\PanSetup
2 strings have to be added:
- "Portal" with the FQDN of one of the portals. The GP client will automatically connect to this portal, as soon as it has been installed.
- "Prelogon" with the value of "1". This sets pre-logon active. As shown above, the SAML agent configuration has to have the "Connect Method" set to pre-logon, even though it has nothing to do with it. The GP client downloads the SAML agent configuration settings as the last thing and if pre-logon is not chosen, the registry value will be changed to "0" and pre-logon won't work.
The GP client downloads the configured external gateways from the firewall, which can be viewed in the settings:
It doesn't download the portals and we need that configured to be able to select another gateway:
The portals can be added manually in the GP client, but that is user work we don't want. Instead they can be pushed with registry entries:
Just add the FQDN value in the Settings folder and it'll appear in the client immediately.