Global Protect authentication happened two time while using RADIUS

[AhamadullahM]

Hi Team,

We have faced the Global Protect authentication that happened two times while using the RADIUS server.

First, I am trying to connect to VPN and enter the user name and Password after the OTP has asked then entered the OTP after, again the user name password is asked then OTP is provided after VPN was connected.

We need to avoid the twice authentication.

referred some live community posts and enabled the auth override cookies but no luck.

Kindly help to fix the issue.

Thank you

[aleksandar.astardzhiev · Accepted solution]

Hi @AhamadullahM ,

You can say this behaviour is "bug by design" 🙂

Joke aside, this is indeed by design, let me try to break down why it happening and then what you can do.

GlobalProtect VPN consist of two main components - Portal and Gateway. For sake of simplicity will say that everytime VPN user connect he will first connect to the Portal and then to the Gateway:

- User will connect to GP Portal, which will provide information of how the GP client will behaive and to which Gateways it should try to connect.

- User will then try to establish connect to the provide Gateways. At this point VPN tunnel is established, client is provided with routing information what traffic to forwad over the tunnel.

Now, both of these to connections (to Portal and to Gateway) require authentication. Which means GP client will always authenticate twice - once to the Portal and once to the Gateway. This behaviour is commonly hidden to the end user when using simple user/password authentication. By default GP client will cache the entered credentials, so when user is prompted to authenticate to Portal, client will cache those credentials and use those first when prompted to authenticate to Gateway.  If gateway use the same authentication (which is in most of the cases), user will be connected to the Gateway without prompted to authenticate the second time. But on the background there is actually second authentication.

This is important, because in your case your are using OTP. OTP is ment to be used one-time (according to its name, right). So when user is prompted by Portal to authenticate, he will provide username and password, will be challanged with OTP and he will provide it. After that client will receive the list of Gateways to connect and will need to authenticate to the Gateway. Firewall will first try to use the cached credentials, so it will provide the same OTP that was used to authenticate to the Portal. In this case the OTP provide will reject the authentication, because it will notice that OTP is re-used. Failed authentication will force the client to prompt user to re-enter credentials, which will be accomplimented with fresh OTP.

So as you can see it is not actually a problem of the RADIUS, but how GlobalProtect actually works.

Now of course user experience is very important in such cases, so there is one solution, probably more of a workaround, but since it is the only possible solution I would say it become standard.

Two words - Authentication Override.

GlobalProtect provide you with option to generate authentication cookie once the user is successfully authenticated. This cookie will be stored on the user computer and have configurable life time. The purpose of this cookie is to authenticate the user with this cookie, instead of  using the authentication method you have setup for your GlobalProtect. The flow should be like this:

1. Configure GP Portal to generate authentication cookie with life time of 1min. (Do not enable accept auth cookie, only generate)

2. Configure GP Gateway to accept authentication cookie. Do not enable generate

What will happen is:

- User will be prompted by Portal to authenticate

- User will provide valid username, password and OTP

- Portal will generate auth cookie valid for the next one minute. It will be sent to the client along with the list of Gateways

- GP client will try to connect to GP gateway providing it the auth cookie

- Gateway will validate the cookie and if valid (not expired and not tampered) it will connect the user straight away without prompt him to authenticate

For the enduser it look like he is prompted once and connected to the VPN.

When user disconnect and try to connect again to the Portal, since portal does not accept auth cookie it will ask the user to authenticate again with OTP

If user try to connect directly to Gateway (which accept cookie), gateway will validate the cookie, but it will notice it has expired and will prompt the user to authenticate with OTP

If you search for MFA/OTP with RADIUS in the form you will find a lot of other discussions, where you could even find more detailed config examples.

[IarnoPagliani]

Ciao and thank for the very easy explanation.

A question regarding how is the gateway validation for cookie generate by the portal ?

I mean are all cookies valid in PAN-OS because encrypted by a known CA ? How does it work in multiple gateway enviroment ?

Thanks

[Adrian_Jensen]

Yes, the cookie for authentication bypass is signed by a certificate on the PA. You can find the options to generate and/or accept a cookie for authentication to the Portal and Gateway under:

Network -> GlobalProtect -> Portals -> <portal_config> -> Agent -> <agent_config> -> Authentication

Network -> GlobalProtect -> Gateways -> <gateway_config> -> Agent -> Client Settings -> <agent_config> -> AuthenticationOverride

When the cookie is generated by the Portal or Gateway it is signed using a certificate with a private key on the PA (either a self-signed CA or a certificate signed by your CA infrastructure) and handed to the GlobalProtect client. The client then presents the bypass cookie back to the Portal/Gateway the next time it logs in. If the cookie signature is valid then the PA allows the connection without the normal authentication steps. If you need to allow cookie authentication bypass on multiple Gateways you simply copy the signing certificate across the PAs so all have the same copy.