This is a inherent problem with SAML. When you perform a SAML authentication the server (or PA Portal/Gateway in this case) asks for a SAML token and, if you do not have one, redirects you to a Microsoft gateway to authenticate. If you are doing OTP on the MS authentication gateway then the OTP happens there and it hands you an authentication token. The client then hands the token to the server (PA) and the server verifies the token against the MS gateway.
By default, MS Azure hands out tokens with a 90day lifetime. The client can continue to use this token until expiration and no OTP will reoccur. You can change the SAML token lifetime in Azure, but it changes the lifetime for all SAML authenticated services. There is apparently a way that you may be able to force new OTP for an existing SAML token for particular services on the Azure side, but we have not gotten that far yet.
The GlobalProtect client uses an internal GP browser (seems to be IE) or the system default browser to request and store the SAML token (set in the GP Portal agent config: "Use Default Browser for SAML Authentication"=no <default>). Ideally the GP Portal agent option to not save client authentication details should resolve this, but I have found SAML doesn't work at all when that is selected. If you are using the system default browser you can manually delete the SAML token. There doesn't seem to be any way to manually delete the token if using the GP browser.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!