User Management

This chapter describes how to manage passwords, user accounts, roles, authentication servers, system groups, and Gaia WebUI clients.

Change My Password

A Gaia user can change his or her own Gaia password.

Change My Password - WebUI

To change your current user password:

1. In the tree view, click User Management > Change My Password.
2. In Old Password, enter your old password.
3. In New Password and in Confirm New Password, enter the new Password.
4. Click Apply.

Change My Password - CLI (selfpasswd)

set selfpasswd

Users

Use the WebUI and CLI to manage user accounts. You can:

• Add users to your Gaia system.
• Edit the home directory of the user.
• Edit the default shell for a user.
• Give a password to a user.
• Give privileges to users.

These users are created by default and cannot be deleted:

• admin — Has full read/write capabilities for all Gaia features, from the WebUI and the CLI. This user has a User ID of 0, and therefore has all of the privileges of a root user.
• monitor — Has read-only capabilities for all features in the WebUI and the CLI, and can change its own password. You must give a password for this user before the account can be used.

New users have read‑only privileges to the WebUI and CLI by default. You must assign one or more roles before they can log in.

When you create a user you can add pre-defined roles (privileges) to the user. For more information, see "Role-Based Administration".

Managing User Accounts - WebUI

To see a list of all users

Choose User Management > Users in the navigation tree.

You can also see your username in the toolbar of the WebUI.

To add a user

1. Open the User Management > Users page.
2. Click Add
3. In the Add User page, enter the following:
   • Login Name - (1–31 characters),
   • Home Directory - for the new user. Must be subdirectory of /home
   • Password.
   • Confirm Password
4. Click OK

To delete a user

1. Open the User Management > Users page.
2. Select the User
3. Click Delete.

User Account Fields- WebUI

Managing User Accounts - CLI (user)

add user <username> uid VALUE homedir

set user <username>

	gid VALUE 

	homedir VALUE 

	newpass VALUE 

	password 

	password-hash VALUE 

	realname VALUE 

	shell VALUE
	uid VALUE 

delete user VALUE

show users 

show user <username> 

	gid 

	homedir 

	realname 

	shell 

	uid 

Roles

Role-based administration (RBA) lets you create administrative roles for users. With RBA, an administrator can allow Gaia users to access specified features by including those features in a role and assigning that role to users. Each role can include a combination of administrative (read/write) access to some features, monitoring (read‑only) access to other features, and no access to other features.

You can also specify which access mechanisms (WebUI or the CLI) are available to the user.

Gaia includes these predefined roles:

• adminRole - Gives the user read/write access to all features.
• monitorRole- Gives the user read-only access to all features.

You cannot delete or change the predefined roles.

Configuring Roles - WebUI

Roles are defined in the User Management > Roles page of the WebUI.

To see a list of existing roles, select User Management > Roles in the navigation tree.

To add new role or change an existing role:

1. Select User Management > Roles in the WebUI navigation tree.
2. To add a new role, click Add and enter a Role Name. The role name can be a combination of letters, numbers and the underscore (_) character, but must start with a letter.
3. To change permissions for an existing role, double-click the role.
4. In the Add or Edit Role window, click a feature (Features tab) or extended command (Extended Commands tab).
5. Select None, Read Only or Read/Write from the options menu.

   

To delete a role:

1. Select User Management > Roles in the navigation tree.
2. Select a role to delete.
3. Click Delete.

You can assign many users to a role from the Roles window.

To assign users to a role:

1. Select User Management > Roles in the WebUI navigation tree.
2. Click Assign Members.
3. In the Assign Members to Role window:
   1. Double-click a user in the Available Users list to add that user to the role.
   2. Double-click a user in the Users with Role list to remove that user from the role.

You can assign the many roles to a user from the Users page. You must work with the Users page to define access mechanism permissions (Web and/or command line) for users. A

To assign roles and access mechanisms to a user:

1. Select User Management > Users in the WebUI navigation tree.
2. Double-click a user in the list.
3. In the Edit User window:
   • Double-click a role in the Available Roles list to assign that role to the user.
   • Double-click a role in the Assigned Roles list to remove that role from the user.
   • Select an Access Mechanisms permission (Web or Command Line) to let the user to work with it.
   • Clear an Access Mechanisms permission (Web or Command Line) to prevent the user from working with it.

Configuring Roles - CLI (rba)

add rba role <Name> domain-type System 

   readonly-features <List>

   readwrite-features <List>

add rba user <User name> access-mechanisms [Web-UI | CLI]

add rba user <User Name> roles <List>

delete rba role <Name>

delete rba role <Name>

   readonly-features <List>

   readwrite-features <L

delete rba user <User Name> access-mechanisms [Web-UI | CLI]

delete rba user <User Name> roles <List>

CLI Procedures

To define a new role or add features to an existing role:

Run:

add rba role <Name> domain-type System readonly-features <List>

readwrite-features <List>

• role <Name> - Role name as a character string that contains letters, numbers or the underscore (_) character. The role name must with a letter.
• readonly-features <List> - Comma separated list of Gaia features that have read only permissions in the specified role.
• readwrite-features <List> - Comma separated list of Gaia features that have read/write permissions in the specified role.

To remove features from an existing role:

Run:

delete rba role <Name> readonly-features <List> readwrite-features <List>

• role <Name> - Role name as a character string that contains letters, numbers or the underscore (_) character. The role name must with a letter.
• readonly-features <List> - Comma separated list of Gaia features that have read only permissions in the specified role.
• readwrite-features <List> - Comma separated list of Gaia features that have read/write permissions in the specified role.

To assign or remove roles to a user:

Run:

add rba user <User Name> roles <List>

delete rba user <User Name> roles <List>

• user <User name> - User to which access mechanism permissions and roles are assigned.
• roles <List> - Comma separated list of role names that are assigned to or removed from the specified user.

To Assign or remove access mechanisms (WebUI or CLI) for a user:

Run:

add rba user <User name> access-mechanisms [Web-UI | CLI]

delete rba user <User Name> access-mechanisms [Web-UI | CLI]

• user <User name> - Comma separated list of role names that are assigned to or removed from the specified user.
• Web-UI - Add or remove permissions to use the WebUI.
• CLI - Add or remove permissions to use the Gaia CLI.

Password Policy

This section explains how to configure your platform to:

• Enforce creation of strong passwords.
• Monitor and prevent use of already used passwords.
• Force users to change passwords at regular intervals.

One of the important elements of securing your Check Point network security platform is to set user passwords and create a good password policy.

To set and change user passwords, see Users and Change My Password.

Password Strength

Strong, unique passwords that use a variety of character types and require password changes, are key factors in your overall network security.

Password History Checks

The password history feature prevents from users using a password they have used before when they change their password. The number of already used passwords that this feature checks against is defined by the history length. Password history check is enabled by default.

The password history check

• Applies to user passwords set by the administrator and to passwords set by the user.
• Does not apply to SNMPv3 USM user pass phrases.

These are some considerations when using password history:

• The password history for a user is updated only when the user successfully changes password. If you change the history length, for example: from ten to five, the stored passwords number does not change. Next time the user changes password, the new password is examined against all stored passwords, maybe more than five. After the password change succeeds, the password file is updated to keep only the five most recent passwords.
• Passwords history is only stored if the password history feature is enabled when the password is created.
• The new password is checked against the previous password, even if the previous password is not stored in the password history.

Mandatory Password Change

The mandatory password change feature requires users to use a new password at defined intervals.

Forcing users to change passwords regularly is important for a strong security policy. You can set user passwords to expire after a specified number of days. When a password expires, the user is forced to change the password the next time the user logs in. This feature works together with the password history check to get users to use new passwords at regular intervals.

The mandatory password change feature does not apply to SNMPv3 USM user pass phrases.

Deny Access to Unused Accounts

You can deny access to unused accounts. If there has been no successful login attempt in a set period of time, the user is locked out and cannot log in. You can also configure the allowed number of days of non-use before a user is locked-out.

Deny Access After Failed Login Attempts

You can deny access after too many failed login attempts. The user cannot log in for a configurable period of time. You can also allow access again after a user has been locked out. Also, you can configure the number of failed login attempts that a user is allowed before being locked out. When one login attempt succeeds, counting of failed attempts stops, and the count is reset to zero.

Configuring Password Policy- WebUI

1. In the tree view, click User Management > Password policy.
2. Configure the password policy options:
   • Password Strength
   • Password History
   • Mandatory Password change
   • Deny Access to Unused Accounts
   • Deny Access After Failed Login Attempts
3. Click Apply.

Password Strength

Password History

Mandatory Password Change

Deny Access to Unused Accounts

Deny Access After Failed Login Attempts

Note - These configurations do not apply to the admin user. The admin user is not blocked irrespective of failed login attempts.

Configuring Password Policy- CLI (password-controls)

Use these commands to set a policy for managing user passwords.

Password Strength

set password-controls 

  min-password-length <6-128>

  palindrome-check <on |off>

  complexity <1-4>

complexity <1-4>

Password History

set password-controls  

  history-checking <on|off>

  history-length <1-1000>

Mandatory Password Change

set password-controls 

  password-expiration <never, 1-1827>

  expiration-warning-days <1-366>

  expiration-lockout-days <never, 1-1827>

  force-change-when <no|password>

Deny Access to Unused Accounts

set password-controls 

  deny-on-nonuse enable <off|on>

  deny-on-nonuse allowed-days <30-1827>

Deny Access After Failed Login Attempts

set password-controls 

  deny-on-fail allow-after <60-604800>

  deny-on-fail failures-allowed <2-1000>

  deny-on-fail enable <off|on>

Note - These configurations do not apply to the admin user. The admin user is not blocked irrespective of failed login attempts.

Monitoring Password Policy

Use these commands to view password Policy configuration

 show password-controls 

   all

   complexity

   deny-on-fail allow-after

   deny-on-fail enable

   deny-on-fail failures-allowed

   deny-on-nonuse allowed-days

   deny-on-nonuse enable

   expiration-lockout-days

   expiration-warning-days

   force-change-when

   history-checking

   history-length

   min-password-length

   palindrome-check

   password-expiration

Example

> show password-controls all

Password Strength

    Minimum Password Length 6

    Password Complexity 2

    Password Palindrome Check on

Password History

    Password History Checking off

    Password History Length 10

Mandatory Password Change

    Password Expiration Lifetime 5

    Password Expiration Warning Days 8

    Password Expiration Lockout Days never

    Force Password Change When no

Configuration Deny Access to Unused Accounts

    Deny Access to Unused Accounts off

    Days Nonuse Before Lockout 365

Authentication Servers

You can configure Gaia to authenticate Gaia users even when they are not defined locally. This is a good way of centrally managing the credentials of multiple Security Gateways. To define non-local Gaia users, you define Gaia as a client of an authentication server.

Gaia supports these types of authentication servers:

RADIUS

RADIUS (Remote Authentication Dial-In User Service) is a client/server authentication system that supports remote-access applications. User profiles are kept in a central database on a RADIUS authentication server. Client computers or applications connect to the RADIUS server to authenticate users.

You can configure your Gaia computer to connect to more than one RADIUS server. If the first server in the list is unavailable, the next RADIUS server in the priority list connects.

TACACS

The TACACS+ (Terminal Access Controller Access Control System) authentication protocol users a remote server to authenticate users for Gaia. All information sent to the TACACS+ server is encrypted.

Gaia supports TACACS+ for authentication only. Challenge-response authentication, such as S/Key, is not supported.

You can configure TACACS+ support separately for different services. The Gaia WebUI service is one of those for which TACACS+ is supported and is configured as the http service. When TACACS+ is configured for use with a service, Gaia contacts the TACACS+ server each time it needs to examine a user password. If the server fails or is unreachable, the user is authenticated via local password mechanism. If the user fails to authenticate via the local mechanism, the user is not allowed access.

Configuring RADIUS Servers - WebUI

To configure a RADIUS server:

1. In the tree view, click User Management > Authentication Servers.
2. In the RADIUS Servers section, click Add.

   The Add New RADIUS Server window opens.

3. Enter the RADIUS Server parameters.
4. Click OK.
5. Optional: Select the Network Access Server (NAS) IP address.
6. Optional: Select the Super User ID.
7. Click Apply.

RADIUS Server Parameters

To edit a RADIUS server:

1. In the tree view, click User Management > Authentication Servers.
2. Select a RADIUS server.
3. Click Edit.

   The Edit RADIUS Server window opens.

4. You can edit the Host name, UDP port number, Shared secret, and Timeout. You cannot change the Priority.
5. Click OK.

To delete a RADIUS server:

1. In the tree view, click User Management > Authentication Servers.
2. Select a RADIUS server from the table.
3. Click Delete.

   The Remove RADIUS Server window opens.

4. Click OK to confirm.

Configuring RADIUS Servers - CLI (aaa)

Description

Use the aaa radius-servers commands to add, configure, and delete Radius authentication servers.

Syntax

To configure RADIUS for use in a single authentication profile:

add aaa radius-servers priority VALUE host VALUE [ port VALUE ] 

   prompt-secret timeout VALUE

   secret VALUE timeout VALUE

To delete a RADIUS configuration:

delete aaa radius-servers 

   priority VALUE

   NAS-IP

To change the configuration of a RADIUS entry:

set aaa radius-servers priority VALUE 

   host VALUE

   new-priority VALUE

   port VALUE

   prompt-secret

   secret VALUE

   timeout VALUE

set aaa radius-servers 

   super-user-uid VALUE

   NAS-IP VALUE

To view a list of all servers associated with an authentication profile:

show aaa radius-servers list

To view the RADIUS server configuration:

show aaa radius-servers priority VALUE 

   host

   port

   timeout

show aaa radius-servers 

   super-user-uid

   NAS-IP

Parameters

Example

show aaa radius-servers priority 1 host

Configuring Gaia as a RADIUS Client

Gaia acts as a RADIUS client. You must define a role for the RADIUS client, and the features for that role.

To configure Gaia as a RADIUS Client

1. Define the role for the RADIUS client:
   • If no group is defined on the RADIUS server for the client, define the role:
     radius-group-any
   • If a group is defined on RADIUS server for the client (group XXX, for example), define the role:
     radius-group-XXX
2. Define the features for the role.

For instructions, see Roles.

Configuring RADIUS Servers for Non-Local Gaia Users

Non-local users can be defined on a RADIUS server and not in Gaia. When a non-local user logs in to Gaia, the RADIUS server authenticates the user and assigns the applicable permissions. You must configure the RADIUS server to correctly authenticate and authorize non-local users.

To configure a RADIUS server for non-local Gaia users

1. Copy the applicable dictionary file to your RADIUS server:

   Steel-Belted RADIUS server

   1. Copy /etc/radius-dictionaries/checkpoint.dct to the server directory.
   2. Add the following lines to the vendor.ini file on RADIUS server (keep in alphabetical order with the other vendor products in this file):

vendor-product = Check Point Gaia

dictionary = nokiaipso

ignore-ports = no

port-number-usage = per-port-type

help-id = 2000

1. Add to the dictiona.dcm file the line:
   “@checkpoint.dct”

FreeRADIUS server

1. Copy /etc/radius-dictionaries/dictionary.checkpoint (on Gaia) to /etc/freeradius/ (on the RADIUS server).
2. Add to /etc/freeradius/dictionary the line:
   “$INCLUDE dictionary.checkpoint”

OpenRADIUS server

1. Copy
   /etc/radius-dictionaries/dict.checkpoint
   on Gaia to
   /etc/openradius/subdicts/
   on the RADIUS server.
2. Add the line
   $include subdicts/dict.checkpoint
   to
   /etc/openradius/dictionaries
   immediately after dict.ascend

1. Define the user roles.

   Add this Check Point Vendor-Specific Attribute to users in your RADIUS server user configuration file:

   CP-Gaia-User-Role = "role1,role2,...

   For example:

   CP-Gaia-User-Role = "adminrole, backuprole, securityrole"

   Note - Make sure the role names match the existing roles in the Gaia system.

2. Define the Check Point users that must have superuser access to the Gaia shell. Add this Check Point Vendor-Specific Attribute to users in your RADIUS server user configuration file:

   CP-Gaia-SuperUser-Access = <0|1>

   0 - This user cannot receive superuser permissions

   1 - This user can receive superuser permissions

To log in as a superuser

A user with super user permissions can use the Gaia shell to do system-level operations, including working with the file system. Super user permissions are defined in the Check Point Vendor-Specific Attributes.

Users that have a UID of 0 have super user permissions. They can run all the commands that the root user can run. Users that have a UID of 96 must run the sudo command to get super user permissions. The UIDs of all non-local users are defined in the file /etc/passwd

To get super user permissions (for users that have a UID of 96)

1. Log into the system using command line.
2. Enter expert mode to go to the Gaia shell.
3. Run
   sudo /usr/bin/su -

The user now has superuser permissions

Configuring TACACS+ Servers - WebUI

To configure a TACACS+ server:

1. In the tree view, click User Management > Authentication Servers.
2. In the TACACS+ Configuration section, select Enable TACACS+ authentication.
3. Click Apply.
4. Configure one or more TACACS+ servers. In the TACACS+ Servers section, for each TACACS+ server:
   1. Click Add.

      The Add new TACACS+ Server window opens.

   2. Configure the TACACS+ parameters.
   3. Click OK.

TACACS+ Parameters

To disable TACACS+ authentication:

1. In the tree view, click User Management > Authentication Servers.
2. In the TACACS+ configuration section, clear Enable TACACS+ authentication.
3. Click Apply.

To disable a TACACS+ server:

1. In the tree view, click User Management > Authentication Servers.
2. In the TACACS+ Server section, select a server.
3. Click Delete.

To make sure the logged in user is enabled for Tacacs+, run:

show tacacs_enable

Configuring TACACS+ Servers - CLI (aaa)

add aaa tacacs-servers priority VALUE server VALUE key VALUE timeout VALUE

set aaa tacacs-servers priority VALUE 

   key VALUE

   new-priority VALUE

   server VALUE

   timeout VALUE

set aaa tacacs-servers state VALUE

delete aaa tacacs-servers priority VALUE

show aaa tacacs-servers 

   list

   priority VALUE server

   priority VALUE timeout

   state

set aaa tacacs-servers priority 2 server 10.10.10.99 key MySharedSecretKey timeout 10

Configuring Gaia as a TACACS+ Client

Gaia acts as a TACACS+ client for Gaia users that are defined on the TACACS+ server and are not defined locally on Gaia. The admin user must define a role called TACP-0 for the TACACS+ users, and the features for the TACP-0 role.

Privilege Escalation

The Gaia admin user can define roles that make it possible for Gaia users to temporarily get higher privileges than their regular privileges. For example, Gaia user Fred needs to configure the firewall, but his role does not support firewall configuration. To configure the firewall, Fred uses his user name together with a password given him by the admin user. This password let him change role to one that allows him to configure the firewall.

There are sixteen different privilege levels (0 – 15) defined in TACACS+. Each level can be mapped to a different Gaia role. For example, privilege level 0: monitor-only. Privilege level 1: Basic network configuration. Privilege level 15: admin user.

By default all non-local TACACS+ Gaia users are assigned the role TACP-0. The Gaia admin can define for them roles with the name TACP-N, that give them different privileges. N is a number from 1 to 15. The TACACS+ users can changes their own privileges by moving to another TACP-N role. To do this, the TACACS+ users need to get a password from the Gaia admin user.

To configure Gaia as a TACACS+ Client:

1. Connect to Gaia as the admin user.
2. Define the role TACP-0
3. Define the features for the role.

   For instructions, see Roles.

4. Optional: Define one or more roles with the name TACP-N where N is a number from 1 to 15, and define the features for each role.

To raise TACP privileges using the CLI:

1. Connect to Gaia CLI as a TACACS+ user.
2. Enter the username and password of the user.

   After you are authenticated by the TACACS server, you will see the clish prompt. At this point you have the privileges of the TACP-0 role.

3. Run:
   tacacs_enable TACP-N

   Where N is the new TACP role (an integer from 1 to 15).

4. When prompted, enter the applicable password.

To go back to the TACP-0 role, press Cntl+D.

To show if the currently logged in user is authenticated by TACACS+, run:

show tacacs_enable

To raise privileges using the WebUI

1. Connect to Gaia WebUI as a TACACS+ user.
2. Enter the username and password of the user.

   After you are authenticated by the TACACs server you have the privileges of the TACP-0 role.

3. To raise the privileges to the TACP-N role (N is a number from 1 to 15), click Enable at the top of the Overview page.
4. Enter the password for the user.

To go back to the TACP-0 role from a different TACP-N role, press Cntl+D or enter exit at the command prompt. The user automatically exits the current shell and goes back to TACP-0.

Configuring TACACS+ Servers for Non-Local Gaia Users

You can define Gaia users on a TACACS server instead of defining them on the Gaia computer. Gaia users that are defined on a TACACS server are called non-local users.

When a non-local user logs in to Gaia, the TACACS server authenticates the user and assigns the permissions to the user. You must configure the TACACS server to correctly authenticate and authorize non-local Gaia users.

System Groups

You can define and configure groups with Gaia as you can with equivalent Linux‑based systems. This function is retained in Gaia for advanced applications and for retaining compatibility with Linux.

Use groups for these purposes:

• Specify Linux file permissions.
• Control who can log in through SSH.

For other functions that are related to groups, use the role‑based administration feature, described in "Role-Based Administration".

All users are assigned by default to the users group. You can edit a user’s primary group ID (using clish) to be something other than the default. However, you can still add the user to the users group. The list of members of the users group includes only users who are explicitly added to the group. The list of does not include users added by default.

Configuring System Groups - WebUI

To see a list of all groups:

Choose User Management > System Groups in the navigation tree.

To add a group:

1. In the User Management > System Groups page, click Add.
2. Enter the Group Name. 1-8 alphanumeric characters.
3. Enter a Group ID number.

   Group ID ranges 0-99 and 65531-65535 are reserved for system use. (GID 0 is reserved for users with root permissions and GID 10 is reserved for the predefined Users groups). If you specify a value in the reserved ranges, an error message is displayed.

4. Click OK.

To add a member to a group:

1. In the User Management > System Groups page, select a group.
2. Click Edit.
3. Click Add New Member.
4. Select a user.
5. Click OK.

To delete a member from a group:

1. In the User Management > System Groups page, select the group.
2. Click Edit.
3. Select the member
4. Click Remove Member
5. Click OK

To delete a group:

1. In the User Management > System Groups page, select the group.
2. Click Delete.
3. Click OK.

Configuring System Groups - CLI (group)

show group VALUE  

show groups 

set group VALUE gid VALUE

add group VALUE gid VALUE

add group VALUE member VALUE

delete group VALUE member VALUE

GUI Clients

GUI Clients are trusted hosts from which Administrators are allowed to log in to the Security Management Server.

Security Management GUI Clients - WebUI

Define which GUI clients (SmartConsoles) can connect to the Security Management Server.

To configure the GUI clients:

1. In the tree view, click User Management > Gui Clients.
2. Click Add.

   The Add GUI Client window opens.

3. Define the GUI clients (trusted hosts). These are the values:
   • Any.

     All clients are allowed to log in, regardless of their IP address. This option only shows if ANY was not defined during the initial configuration.

   • An IP address
   • A network
   • A range of addresses

     Note - GUI clients can be deleted on the User Management > GUI Clients page.

GUI Clients - CLI (cpconfig)

1. Run: cpconfig.

   A list of configuration options shows. For example:

 Configuration Options:

----------------------

(1)  Licenses and contracts

(2)  Administrator

(3)  GUI Clients

(4)  SNMP Extension

(5)  PKCS#11 Token

(6)  Random Pool

(7)  Certificate Authority

(8)  Certificate's Fingerprint

(9)  Disable Check Point SecureXL

(10) Configure Check Point CoreXL

(11) Automatic start of Check Point Products

1. Enter 3.
2. A list of hosts selected to be GUI clients shows.

   You can add or delete hosts, or create a new list.

   New GUI clients can be added using these formats:

   • IP address.
   • Machine name.
   • "Any" - Any IP without restriction.
   • IP/Netmask - A range of addresses, for example 192.0.2.0/255.255.255.0
   • A range of addresses - for example 192.0.2.10-192.0.2.16
   • Wild cards (IP only) - for example 192.0.2.*