Configure Administrative Role Separation on a Check Point Gateway (R81.x)

Shared-admin logins are the quiet risk in a lot of Check Point estates: everyone SSHes in as admin, everyone can do everything, and nobody can tell afterward who changed the routing table. Gaia's Role-Based Administration (RBA) fixes that at the OS level. This guide walks the standard clish procedure to create named accounts that can see or change only what their job requires.

This is the gateway/Gaia OS layer of separation — the accounts that log into the appliance itself. It is a different system from the SmartConsole administrators and Permission Profiles that govern who can edit the security policy on the Management Server; that is configured in SmartConsole under Manage & Settings → Permissions & Administrators and is out of scope here.

Before you run this

• What this does: It creates Gaia OS users and RBA roles on a Check Point appliance, then assigns each user a role that grants read-only or read-write access to specific Gaia features (interfaces, routing, DNS, backups, and so on). The purpose is least-privilege, accountable administration instead of a shared admin account.
• Privileges needed: You must be logged into clish as an account with full read-write RBA rights (the built-in admin account, which holds the adminRole). RBA configuration is done in clish, not expert mode.
• This changes access control. Done wrong, you can lock a legitimate admin out of the box, or hand someone more than you intended. None of it touches the security policy or traffic directly, but it is still worth treating carefully.
• Keep an out-of-band path open. Have a serial console or LOM/IPMI session connected before you start, and do not modify the account you are currently logged in with. Leave the built-in admin account intact as your break-glass login.
• Back up first. Take a Gaia snapshot (add snapshot <name>) and export the current config (save configuration <file>) before changing anything. If you make a mess, set snapshot revert <name> rolls the box back (it reboots). Do this in a maintenance window.
• Test the new login in a second session before you close your working one.

Assumptions for this guide: Gaia R81.10 on a single Check Point Security Gateway, configured over SSH in clish. The syntax is the same on R81, R81.10 and R81.20, and on a Security Management Server running Gaia. Exact feature names (the keywords after readwrite-features) vary by version and licence — I show how to list them rather than hard-coding a list.

Step 1 — Back up before you touch anything

# clish on the gateway
add snapshot pre-rba-change
save configuration /home/admin/config-before-rba.txt

The snapshot is your full rollback; the saved configuration file is a human-readable record of the clish commands currently in effect.

Step 2 — Take the config lock

Only one admin can hold the read-write lock at a time. If someone else has it:

lock database override

Step 3 — Understand the built-in roles

Gaia ships with two predefined roles you cannot delete:

• adminRole — full read-write to everything.
• monitorRole — read-only to everything.

List what exists:

show rba role adminRole
show rba role monitorRole

If "full admin" and "pure read-only observer" cover your needs, you can skip straight to Step 5 and just assign these. Most people want something in between, which is Step 4.

Step 4 — Create a custom role

A role is defined by which features it can read (readonly-features) and which it can change (readwrite-features). To create a role that, say, lets a network team manage interfaces and routing but nothing else:

# Create the role; add the exact feature keywords you need
add rba role NetworkAdmins domain-type System \
  readwrite-features <feature1>,<feature2>

The critical part is <feature1>,<feature2> — these are real Gaia feature keywords (comma-separated, no spaces), not placeholders you can invent. Do not guess them. To see the valid list for your version, press Tab (or Esc Esc) after typing readwrite-features at the clish prompt — Gaia tab-completes the available features. The authoritative list is in the Gaia Administration Guide for your version, under "Role-Based Administration," on the Check Point Support Center.

You can combine read-write and read-only in one role:

add rba role NetworkAdmins domain-type System \
  readwrite-features <routing-feature>,<interface-feature> \
  readonly-features <dns-feature>,<ntp-feature>

To grant access to specific clish/shell commands, RBA also has an extended-commands option. The exact keyword syntax differs by version, so check the same guide section before using it rather than typing it from memory.

Step 5 — Create the Gaia user

Create the login, give it a home directory, and set a password. Replace the name, UID and home path with your own values:

add user alice uid 9001 homedir /home/alice
set user alice password        # prompts for the new password interactively
set user alice realname "Alice Example"

Give additional admins a non-zero UID (here 9001). A UID of 0 makes the account root-equivalent in expert mode, which defeats the point of role separation. Reserve UID 0 for the built-in admin.

Step 6 — Assign the role to the user

add rba user alice roles NetworkAdmins

A user can hold more than one role; run the command again with a different role name to add another, and the effective permissions are the union of them.

Step 7 — Save

Nothing survives a reboot until you commit it:

save config

Verify it worked

Check the role and the assignment from your current (admin) session:

show rba role NetworkAdmins
show rba user alice
show users

show rba user alice should list NetworkAdmins, and show users should show the new account with its UID and home directory.

Now the real test. From a separate SSH session, log in as the new user and confirm the boundaries hold:

# as alice
show rba user alice      # confirm your own roles
set interface eth1 ...    # should SUCCEED for a read-write feature
set dns primary 1.1.1.1  # should FAIL if DNS is read-only / not granted

A denied action returns a permission error rather than applying. If a command you expected to be allowed is denied, the feature keyword in the role is wrong — go back to Step 4 and check it against tab-completion.

Undo / rollback

Everything here is reversible. To remove a role from a user, or delete the account or role entirely:

delete rba user alice roles NetworkAdmins
delete user alice
delete rba role NetworkAdmins
save config

If something went wider wrong — you locked yourself out of a feature, or an account misbehaves — log in via the console as the built-in admin and either reverse the specific commands above, or revert the snapshot:

set snapshot revert pre-rba-change   # reboots into the pre-change state

That snapshot, taken in Step 1, is why you take it in Step 1.

A note on consistency

If you manage several gateways, define the same roles and users on each so an admin's access is predictable everywhere. The clean way to keep that in sync is to script the clish commands and push them, but confirm each box took them with show rba user afterward — RBA is per-appliance, and a half-applied role is exactly the kind of surprise you were trying to design out.