Two-Factor Admin Login on a Check Point Gaia Gateway

Before you run this

This guide points Gaia's administrator authentication (the WebUI, SSH, and console logins on a Check Point gateway) at an external RADIUS server that enforces a second factor — a push, an OTP, or an SMS code. The gateway itself has no built-in TOTP; it delegates authentication to RADIUS, and the RADIUS/MFA server is where the second factor actually lives. Get that mental model straight before you touch anything: if the RADIUS server is unreachable or misconfigured, admin login can fail.

You need a Gaia administrator account with read/write access (config-lock) to make these changes, plus admin rights on the RADIUS/MFA server. These are configuration changes, not a script — nothing is deleted, but a wrong authentication order or an unreachable RADIUS server can lock you out of gateway management, so treat it with the same caution.

Rules I do not skip on any gateway change:

• Keep a separate console/serial session open (or an SSH session you do not close) as admin throughout, so if RADIUS login breaks you still have a way in.
• Keep the built-in local admin account working with a local password. It is your fallback. Do not convert every admin to RADIUS-only in one pass.
• Take a Gaia snapshot before you start (below). That is your rollback path.
• Do this in a maintenance window, and test on a lab gateway or a spare appliance first — never a production perimeter box on the first attempt.

One scope note: this covers Gaia OS admin logins on the gateway/appliance. Second-factor login for SmartConsole administrators on the management server is a separate mechanism and is not what this guide configures.

Assumptions

• Gaia R81.20 on a Security Gateway or appliance, managed via the Gaia Portal (WebUI) and clish.
• You already have a RADIUS server that performs MFA — for example a Duo Authentication Proxy or a Microsoft NPS server with the Azure MFA extension. Configuring that server is out of scope; I assume it answers RADIUS on UDP/1812 and challenges for the second factor.
• The MFA flow you use works over PAP between the gateway and the RADIUS server. Most OTP/push proxies expect PAP so the primary password and OTP pass through cleanly; MS-CHAPv2 often breaks OTP. Confirm which protocol your proxy wants before you commit.

Step 1 — Snapshot first

From clish:

# Acquire config lock if another session holds it
set config-lock on override

# Create a full system snapshot you can revert to
add snapshot pre_2fa_change
show snapshots

You can also do this in the WebUI under Maintenance > Snapshot Management. To revert later, use that same page (or the documented set snapshot command for your build — check the exact syntax in the Gaia Administration Guide rather than guessing).

Step 2 — Add the RADIUS server to Gaia

WebUI path (the mainstream way):

1. Log in to the Gaia Portal.
2. Go to User Management > Authentication Servers.
3. Under RADIUS Servers, click Add.
4. Set:
   • Priority — 1 for your primary.
   • Host — your RADIUS server IP, e.g. 10.10.10.5.
   • UDP Port — 1812.
   • Shared Secret — the secret you configured on the RADIUS server.
   • Timeout — raise this well above the default (e.g. 20–60 seconds). Push MFA needs time for the user to approve; a 3-second timeout will fail every push.
   • Protocol — match what your MFA proxy expects (commonly PAP; see the assumption above).
5. Save.

The clish equivalent:

add aaa radius-servers priority 1 host 10.10.10.5 port 1812 secret <SHARED_SECRET> timeout 20
save config

Replace 10.10.10.5 with your RADIUS server and <SHARED_SECRET> with the real shared secret. Newer and older builds vary in which extra options add aaa radius-servers accepts (the authentication protocol, for one), so confirm the parameter list against the RADIUS section of the Gaia Administration Guide for R81.20 before relying on it. save config is what makes a clish change survive a reboot — do not skip it.

Step 3 — Map RADIUS users to a Gaia role

Gaia needs to know what role a RADIUS-authenticated admin gets. That mapping is driven by Check Point vendor-specific attributes returned by the RADIUS server — the documented attributes are named along the lines of CP-Gaia-User-Role (the Gaia role, e.g. the built-in adminRole) and CP-Gaia-SuperUser-Access (for full expert-mode/shell access).

I am deliberately not printing the numeric vendor and attribute IDs here, because getting them wrong on your RADIUS server is exactly the kind of small error that produces a login that authenticates but lands with no privileges. Pull the exact attribute names, the vendor ID, and the accepted values from the RADIUS VSA table in the Gaia Administration Guide and the matching Check Point support article for authenticating Gaia with RADIUS, then configure your RADIUS policy to return them.

You also need to tell Gaia to accept users that are not defined locally and give them a default role/shell, or define each admin as a local Gaia user set to authenticate via RADIUS. Both approaches are documented on the same User Management > Authentication Servers / Users pages. Choose one, and for the non-local option set a sane default role. When in doubt, check the exact toggle wording in the admin guide rather than clicking blindly — the field names have shifted between versions.

Step 4 — Test with a second browser, do not log out

This is the step people skip and regret.

Keep your existing admin console/SSH session open. In a separate browser (private window) or a second SSH client, log in as a RADIUS user:

1. Enter the username and primary password.
2. Complete the second factor (approve the push / enter the OTP).
3. Confirm you land with the expected role — you can read/write config if that is what you assigned.

Only once a full RADIUS + MFA login succeeds in the second session should you trust it.

Verify

Confirm the pieces are in place from clish:

# List the configured RADIUS servers and their settings
show aaa radius-servers

# Confirm your snapshot exists as a rollback point
show snapshots

On the RADIUS/MFA server, check its authentication log for the Access-Request from the gateway and an Access-Accept after the second factor — that end-to-end trail is the real proof it worked, not just that Gaia has a server configured.

Undo / roll back

If a RADIUS login misbehaves and you are still in your open admin session:

• Remove or fix the RADIUS server in User Management > Authentication Servers, or in clish:

  delete aaa radius-servers priority 1
  save config
  

• Revert the ordering / non-local setting you changed so local admin login is authoritative again.

• If configuration is tangled, revert the snapshot from Maintenance > Snapshot Management (pre_2fa_change). A snapshot revert reboots the appliance and returns it to the pre-change state.

Because you kept the local admin account and a live session throughout, none of this leaves you locked out — which is the whole point of doing it in that order.