topic MFA Behavior on Gaia Portal – R81.20 Jumbo Hotfix Take 118 and 113 in General Topics

MFA Behavior on Gaia Portal – R81.20 Jumbo Hotfix Take 118 and 113

ByTi — Tue, 04 Nov 2025 20:22:35 GMT

Hi everyone,

I need some help because I’m experiencing strange behavior on the Gaia portal.

Environment:

Check Point version: R81.20
Jumbo Hotfix: Take 118 and Take 113
MFA configured on Gaia portal
Browser: Google Chrome

Issue: I successfully log in to the Gaia portal using username, password, and MFA token. After finishing my work, I log out from the portal and close the tab, but I do not close the browser. Later, when I reopen the Gaia portal, I log in with username and password and enter a completely incorrect MFA code (for example: 123456). The login is still successful. The same happens if I open a new browser tab or even a new browser window alongside the old one. I tested this on multiple gateways and got the same result.
Additionally, if the Gaia portal logs me out automatically because the session expired, I can still log in afterward with any MFA code.

My questions:

Did I misconfigure something?
Or is this a known issue in these versions?

Thanks in advance for your help!

Re: MFA Behavior on Gaia Portal – R81.20 Jumbo Hotfix Take 118 and 113

PhoneBoy — Wed, 05 Nov 2025 00:08:14 GMT

A TAC case is probably in order here.

Re: MFA Behavior on Gaia Portal – R81.20 Jumbo Hotfix Take 118 and 113

the_rock — Fri, 07 Nov 2025 02:59:13 GMT

Is it same issue with a different browser?

Re: MFA Behavior on Gaia Portal – R81.20 Jumbo Hotfix Take 118 and 113

ByTi — Fri, 07 Nov 2025 08:13:19 GMT

Same result here, tested with multiple browsers.

Additional information:
At no point is the correct token required for login; even the first attempt accepts an invalid token. SSH also does not request any verification code.
Gateways were upgraded from R81.10 to R81.20 using Gaia Fresh Install + upgrade. Open servers are running a completely fresh R81.20 installation.

I noticed that on the tested gateways, under User Management → Roles, the adminRole group has 203 features. There is another gateway that was delivered later with R81.20 pre-installed – MFA works correctly on both the web and SSH interfaces there, and its adminRole contains 214 features.

Audit log snippet with invalid token:
type=LOGIN msg=audit(1762336201.069:613): pid=9951 uid=0 subj=kernel old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=88 res=1
type=USER_START msg=audit(1762336201.069:614): pid=9951 uid=0 auid=0 ses=88 subj=kernel msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits acct=root exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
type=CRED_DISP msg=audit(1762336201.092:615): pid=9951 uid=0 auid=0 ses=88 subj=kernel msg='op=PAM:setcred grantors=pam_rootok acct=root exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
type=USER_END msg=audit(1762336201.092:616): pid=9951 uid=0 auid=0 ses=88 subj=kernel msg='op=PAM:session_close grantors=pam_loginuid,pam_keyinit,pam_limits acct=root exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
type=USER_AUTH msg=audit(1762336304.985:617): pid=10906 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='op=PAM:authentication grantors=pam_dof_tally,cp_pam_tally,pam_unix acct="userxxx" exe="/usr/sbin/sshd" hostname=10.10.0.100 addr=10.10.0.100 terminal=ssh res=success'

Re: MFA Behavior on Gaia Portal – R81.20 Jumbo Hotfix Take 118 and 113

ByTi — Fri, 07 Nov 2025 10:12:50 GMT

I found the root cause of the issue.

On the non-working gateway, in Expert mode, the /etc/pam.d/system-auth file looks like this:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authselect is run.
auth        required      pam_env.so
auth        required      pam_dof_tally.so deny=10 unlock_time=1200 even_deny_root_account onerr=fail file=/etc/loginhist/%u nop
auth        required      cp_pam_tally.so
auth        [success=done new_authtok_reqd=done auth_err=ignore perm_denied=ignore conv_err=die default=ignore]    pam_radius_auth.so
auth        sufficient    pam_unix.so try_first_pass nullok
auth        required      pam_deny.so

account     required      cp_pam_tally.so
account     required      pam_unix.so
account     required      pam_nonuse.so

password    sufficient    pam_unix_passwd.so try_first_pass nullok sha512 shadow
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

And on the working gateway, it looks like this:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authselect is run.
auth        required      pam_env.so
auth        required      pam_dof_tally.so deny=10 unlock_time=1200 even_deny_root_account onerr=fail file=/etc/loginhist/%u nop
auth        required      cp_pam_tally.so
auth        [success=done new_authtok_reqd=done auth_err=ignore perm_denied=ignore conv_err=die default=ignore]    pam_radius_auth.so
auth        required      pam_unix.so try_first_pass nullok
auth        required      pam_google_authenticator.so nullok noskewadj secret=/etc/2fa_keys/${USER}/.google_authenticator user=0

account     required      cp_pam_tally.so
account     required      pam_unix.so
account     required      pam_nonuse.so

password    sufficient    pam_unix_passwd.so try_first_pass nullok sha512 shadow
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The correct configuration exists on the problematic gateways as well, but only in temporary files that were never activated. I still need to test whether a reboot will revert to the incorrect settings.

Re: MFA Behavior on Gaia Portal – R81.20 Jumbo Hotfix Take 118 and 113

PhoneBoy — Fri, 07 Nov 2025 17:53:24 GMT

The difference in PAM configuration would definitely cause the issue.
Why it happened is a different question.

Re: MFA Behavior on Gaia Portal – R81.20 Jumbo Hotfix Take 118 and 113

the_rock — Sat, 08 Nov 2025 13:36:27 GMT

Here is what it looks like in my lab. Just run chattr +i on the file, will survive the reboot.

[Expert@CP-GW:0]#
[Expert@CP-GW:0]# more /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authselect is run.
auth required pam_env.so
auth required pam_dof_tally.so deny=10 unlock_time=1200 even_deny_root_account onerr=fail file=/etc/loginhi
st/%u nop
auth required cp_pam_tally.so
# aaa placeholder - start
auth [success=done new_authtok_reqd=done auth_err=ignore perm_denied=ignore conv_err=die default=ignore] pam_
radius_auth.so
auth [success=ok new_authtok_reqd=ok ignore=ignore default=2] pam_unix.so try_first_pass nullok
auth required pam_google_authenticator.so nullok noskewadj secret=/etc/2fa_keys/${USER}/.google_authenticato
r user=0
auth sufficient pam_permit.so
# aaa placeholder - end
auth required pam_deny.so

account required cp_pam_tally.so
account required pam_unix.so
account required pam_nonuse.so

password sufficient pam_unix_passwd.so try_first_pass nullok sha512 shadow
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
[Expert@CP-GW:0]#