OTP authentication with GlobalProtect

[JoHyeonJae]

Hello all,

The customer has an inquiry about OTP authentication when logging in to the GP after booting the PC. When I log in again after disconnecting, I can log in without OTP authentication (session authentication is maintained), so is there any way to set up OTP authentication every time I disconnect? 

The authentication method is Azure SAML authentication.

Thanks!

[Adrian_Jensen]

See my other post just made in the other SAML thread. There is apparently a way to force re-OTP of an existing token in Azure using a service authentication policy, but I haven't got that far yet.

https://live.paloaltonetworks.com/t5/globalprotect-discussions/global-protect-saml-auth/m-p/530014/h...

[JoHyeonJae]

Hello @Adrian_Jensen 

Does that mean that Azure SAML has a re-OTP force function, but does not support it, so the above phenomenon occurs? 

Is this a phenomenon that only applies to Azure SAML? Because Okta SAML seems to be working normally.

[Adrian_Jensen]

I have not used Okta, but I would guess that the token lifetimes are much shorter by default. Azure uses a token with a 90 day default lifetime, so it will be good for re-authorization until that is up:

https://learn.microsoft.com/en-us/answers/questions/299782/what-are-*new*-default-refresh-token-life...

https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token...

In Azure there is a token attribute called "Multi-factor Refresh Token Max Age" that can apparently be changed to a much shorter timeframe, its default is either 180 days or "Until-revoked" depending on which MS document you look at, with a minimum lifetime of 10 minutes. From what little I understand of Azure, you can apply a security policy (called "Conditions Access" rules?) to specific Azure services/tenants which change the default lifetimes. So in Azure you would apply a policy to the GlobalProtect authentication service which would force re-OTP at a shorter interval. But... I know very little about Azure, hate dealing with Windows, I am leaving that to our MS guys to figure out all the details.  

https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access...

[JoHyeonJae]

@Adrian_Jensen 

Thank you for providing your professional response.

I want to make one thing clear. Then, if I use Azure SAML, is it a normal act to log out and log in again, the system allows me to connect to GP without OTP authentication?

[Adrian_Jensen]

@JoHyeonJae  - Yes, this will be normal for any SAML provider, though individual providers may apply different time limits to the SAML token. The OTP is happening on Azure, so it is up to Azure to re-issue an OTP on validation of a reoccurring token. As I said, there seems to be a way to change the default timeouts in Azure, but I have not gotten that far yet.

When you are authenticating a user login via Radius/LDAP/etc. with an OTP (through something like a DUO server) the PaloAlto collects the username/password from the client and hands it to the authentication server. The authentication server then validates the user/pass and issues an OTP to the client. If the OTP is successful then the authentication responds to the PA with an authentication pass. The authentication server never really knows if this current authentication attempt is related to a past authentication attempt, so it always performs the full OTP. (Note: There are ways that it can be linked with Radius attributes/etc., i.e. Wifi clients hopping networks without reauth, but that doesn't really happen without custom setups and is beyond the discussion here.)

When you are authenticating a user login via SAML the PA never collects the username/password from the client. The PA requests a token from the connecting client and, if not present, tells the client to redirect to a SAML gateway and request a token for xxx. The SAML gateway requests the user/pass (performs an OTP if configured) and issues a token for a certain user to access xxx. This is done so the third party site requesting authentication never has access to the user/pass (i.e. a compromise of vendor xxx doesn't reveal your domain username/password to access vendor yyy and zzz, though if someone compromises you and gets your token to xxx they can access xxx as you without your user/pass).

The next time the client tries to connect to the PA (which could be immediately after acquiring a token or days later) it presents the token it previously acquired from the SAML gateway to access xxx. The PA queries the SAML gateway to confirm that the token is still valid for xxx. As long as the token has not expired (or been revoked) it is valid for immediate login (this is where the Azure settings come in, essentially pre-expiring the token for certain purposes to force a new token acquisition). Since the token is stored in the client's web browser, it sticks around as long as the browser cache/stored objects exist.

You can try adjusting the GP agent Portal configs to force not saving user credentials. But, for the reason below, this will probably not work. 

Network -> GlobalProtect -> Portals -> [portal_config] -> Agent -> [agent_config] -> Authentication

Components That Require Dynamic Passwords (Two-Factor Authentication):

Portal = yes

    and/or

External gateways-manual = yes

External gateways-auto = yes

You would normally check the Portal/Gateway you that you always want to force a OTP on. This should cause the GP client to acquire new credentials, not reuse saved tokens (same check to force not saving user/pass in other authentication methods). Unfortunately, in our case it broke SAML authentication. The client would successfully gets the SAML token, but never hands it to the Gateway (we use cert authentication to the Portal, SAML authentication on the Gateway). I opened a support ticket and was told this has happened to multiple customers, it has to be unchecked to work...

[RREALICA]

We are going through similar testing with Azure SAML conditional access policies - by no means I'm an expert; this are just my observations:

You can be as aggressive in your sign-in frequency settings for the enterprise app for the portal and gateway and it will be honored, and can have different settings for different type of devices - the end experience (will the user get prompted for password or MFA?) really depends on your Azure SAML authentication setup. The good news is that you can follow the logs from the client to the firewall to Azure and see exactly what is happening and being requested- whether the GP client is requesting a full SAML auth, or using cookies, you can see also what Azure SAML has evaluated in the Azure portal, is the sign conditions for SAML met by a myriad of other conditions such if the machine is azure ad joined, has been unlocked using a work account, using another app, on a trusted network etc, on a compliant device, etc etc.

Hope that helps.