Global Protect do not ask for OTP

[Michael.Thyme]

Hello,

i had configured a radius server (freeradius) that work with google_authenticator and active directory. So far this works that way:

- login via Global Protect Client with username and AD Password+OTP (password and OTP in 1 promt)

I need to enter the OTP seperate and not together with the password. How can i achieve this??

The portal and the gateway had the same authentication profile (use the radius server for both, first google_authenticator (forward_pass to AD). Also i do not understand the "Componets that required Dynamic Passswords (Two Factor Authentication) option, if i enabled thsi for ext. Gateway or Portal the behavior did not change i had to enter password+otp in one promt.

Maybe i had to configure this on the radius server, but if i login via SSH using radius the client ask for the "verification Code" after the password is entered so i think it should be configured on the firewall.

any ideas?

[Remo]

Hi @Michael.Thyme

Do you use the same Authentication Profile for GP and for admin access?

[Michael.Thyme]

Hi vsys_remo,

yes for the login into the web gui i use the same auth profile. 

[Remo]

Hmn ... actually this is a setting on the RADIUS server where you define how the RADIUS server expects the password/otp, because the firewall only sends what it get from the user. The RADIUS server then answers with an ACCESS-ACCEPT, ACCESS-REJECT or ACCESS-CHALLENGE where the last one tells the firewall to show an additional inputprompt to the user where the OTP has to be entered.

[Michael.Thyme]

ok thx.. i will take a look at RADIUS site and hopefuly change the behavior...

what do you think about the following workaround...:

1. Authtentication to Portal via LDAP auth profile (AD User + PW)

if success -->

2. Authentication to Gateway via RADIUS auth profile (Username (same format as AD Username) + OTP)

i do not know if this is the good practise or insecure...

Is it possible to connect to the Gateway without connecting to the Portal first?

In this case that wouldnt be a workarround for us...

[Remo]

Is your portal and gateway on the same device? If yes, then the chances that a client will connect directly to the portal are somewhere between low and not existent. Specially if you have the portal on another device than the gateway then the client will connect directly to the gateway if the portal is not available (if the client was already once connected and has a cached config)

... but if your RADIUS is already doing what you need for the admin login, then there has to be a setting to force it this way ...

[Michael.Thyme]

yes we host the Portal and the Gateway on the same device.. I was wondering that you wrote its "between low and not existent"  because my GP Clients always try to connect to the Portal and the Gateway.. So my plan was to use the password field as the input for the token only ..  so our active directory is called first while connecting to the portal (portal --> auth profile ldap)

if thsi is successful our clients try to connect to the Gateway where another authentication profile is set, wich only checks RADIUS (and the Radius do only check OTP via pam_google_authenticator), so the second Authentication process (connecting to the Gateway) is asking for username and password as usual but this time we only enter the OTP as the password.. but this only make sense for me if it is not possible to connect to portal or gateway seperatly.. you know what i mean? 

if i set the authentication profile to  2FA for the admin login then it does the same as for GP it ask for username and password+OTP in one single promt.. 

If the password(+OTP) is right the RADIUS is allways sending a "ACCESS-ACCEPT" instead of "ACCESS-CHALLENGE " i think.

So far as i understood, this behavior is made by the pam module (i.e. pam_google_authenticator) so i decide to install linOTP to my radius server, i think they use another pam module, maybe this is able to promt for OTP seperatly..

I will write if i had success..

[Remo · Accepted solution]

@Michael.Thyme

I understood how you want to use the two authentications of the portal and gateway and I wrote of low chances because it might be possible that somehow the process for the portal could have a problem while the gateway still works properly. Ok, the propability is extremely low, but in theory it is possible.

I also read some things about the google_authenticator pam module and I came to the same conclusion as you: without some rewriting of the module it isn't possible that this authentication module will be access-challenge compatible.

LinOTP is a very good idea I think. This way you will be able to configure the login flow in the LinOTP application (and in addition this software gives you way more possibilities about other configurations, user self registration, logging, ...)

[Michael.Thyme]

yes i think the possibility that this can be happen is important..

we will see how linotp+freeradius+palo alto works for 2fa

Thank for your reply... 

[${userLoginName}]

Hi Michael, did you success with this case, I also want to do the same authentication flow as your case (first username+password and then OTP)