User Management
This chapter describes how to manage passwords, user accounts, roles, authentication servers, system groups, and Gaia WebUI clients.
![](1423.png)
|
Note - When a user logs in to Gaia, the WebUI navigation tree displayed and CLI commands that are available depend on the role or roles assigned to the user. If the user's roles do not provide access to a feature, the user does not see the feature in the WebUI navigation tree or in the list of commands. If the user has read-only access to a feature, they can see the WebUI page but the controls are disabled. Similarly, the user can run show commands but not set , add or delete commands.
|
Change My Password
A Gaia user can change his or her own Gaia password.
Change My Password - WebUI
To change your current user password:
- In the tree view, click > .
- In , enter your old password.
- In and in, enter the new Password.
- Click .
Change My Password - CLI (selfpasswd)
Description
|
Change your own Gaia password, in an interactive dialog.
|
Syntax
|
set selfpasswd
|
Warning
|
It is not recommended to use
set selfpasswd oldpass VALUE passwd VALUE because the passwords are stored as plain text in the command history. Instead, use 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.
|
|
|
![](1423.png)
|
Note - You can assign permissions to all Gaia features or a subset of the features without assigning a user ID of 0. If you assign a user ID of 0 to a user account (you can do this only in the CLI), the user is equivalent to the Admin user and the roles assigned to that account cannot be modified.
|
![](1423.png)
|
Note - Do not define a new user for external users. An external user is one that is defined on an authentication server (such as RADIUS or TACACS) and not on the local Gaia system.
|
When you create a user you can add pre-defined roles (privileges) to the user. For more information, see "Role-Based Administration".
![](1424.png)
|
Warning - A user with read and write permission to the Users feature can change the password of another user, or an admin user. Therefore, write permission to the Users feature should be assigned with caution.
|
Managing User Accounts - WebUI
To see a list of all users
Choose in the navigation tree.
You can also see your username in the toolbar of the WebUI.
To add a user
- Open the page.
- Click
- In the page, enter the following:
- (1–31 characters),
- for the new user. Must be subdirectory of
/home
- .
- Click
To delete a user
- Open the page.
- Select the User
- Click .
User Account Fields- WebUI
Item
|
Description
|
Login Name
|
Name used to identify the user. The valid characters are alphanumeric characters, dash (-), and underscore (_).
Range: 1-32 characters
|
Real Name
|
User's real name or other informative label.
|
Home directory
|
This is the full Linux path name of a directory where the user will log in. The home directory for all users must be in /home.
|
Shell
|
|
Password
|
Use this field to enter a new password if you are changing it.
Range: 6-128 characters. All printable characters are allowed.
Note - If you use an asterisk (*) in a password, users with that password are unable to log in.
|
Reset Password
|
Change the user password.
Important - After resetting the password, tell the user to immediately change their password in .
|
Confirm Password
|
Re-enter the new password if you are changing it.
|
User must change password at next logon
|
Important - After selecting this option, tell the user to immediately change their password in .
|
Access Mechanisms
|
Choose whether the user is able to access Gaia from the command line, from the WebUI, both, or neither.
|
Roles
|
Assign a role to the user. Define the roles in .
|
Managing User Accounts - CLI (user)
Description
|
Manage user accounts. You can add users, edit the home directory of the user, edit the default shell for a user, give a password to a user, and give privileges to users.
|
Syntax
|
To add user accounts:
add user <username> uid VALUE homedir
To modify user accounts:
set user <username>
gid VALUE
homedir VALUE
newpass VALUE
password
password-hash VALUE
realname VALUE
shell VALUE uid VALUE
To delete an existing user:
delete user VALUE
To view configuration and conditions:
show users
show user <username>
gid
homedir
realname
shell
uid
|
Comments
|
You can use the add user command to add new users, but you must use the set user name passwd command to set the password and allow the user to log on to the system.
For information on removing access mechanism permissions from a user, see the delete rba user command.
|
Parameters
|
Parameter
|
Description
|
user <username>
|
Specifies the new user name or an existing user name. The valid characters are alphanumeric characters, dash (-), and underscore (_). Range: 1-32 characters
|
gid VALUE
|
Specifies the ID (0‑65535 ) for the primary group to which a user belongs. Use the group management commands to specify membership in other groups.
|
homedir VALUE
|
Specifies the user's home directory, where the user is placed on login. Enter the full Linux path name. If the directory does not already exist, it is created. The home directory for all users must be in a directory under /home /.
|
newpass VALUE
|
Specifies a new password for the user. If you use this keyword to change the password, you will not be asked to verify the new password and the password you enter is visible on the terminal and is stored as plain text in the command history.
|
password
|
Starts a password change dialog. You will be asked to enter a new password for the user and then asked to verify it by re-entering it. The password you enter will not be visible on terminal.
|
password-hash VALUE
|
An encrypted representation of the password. The password is not visible as text at the terminal or in the command history. Use this option if you want to change passwords using a script. You can generate the hash version of the password using standard Linux hash generating utilities.
|
realname VALUE
|
User's real name or other informative label.
|
shell VALUE
|
Specifies the shell of the user, which is invoked when the user logs in. The default shell is /bin/csh. To change the shell, enter the new shell path name.
/etc/cli.sh - User is allowed to use the full Gaia CLI (clish). This is the default option. By default, some basic networking commands (such as ping) are also available. The Extended Commands mechanism makes it possible to add Linux commands that can be used.
User can run shell to enter the bash shell.
/bin/bash, /bin/csh, /bin/sh, /bin/tcsh - Standard Linux shells. To enter the clish shell, run the command clish .
/usr/bin/scponly - User is allowed to log in only using SCP, and to transfer files to and from the system. No other commands are allowed.
/sbin/nologin - User is not allowed to log in.
|
uid VALUE
|
Unique user ID (Integer 0‑65535 ). This parameter is optional. If a value is not specified, a sequential number is assigned automatically.
|
|
|
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.
![](1423.png)
|
Note - When users log in to the WebUI, they see only those features that they have read-only or read/write access to. If they have read-only access to a feature, they can see the settings pages, but cannot change the settings.
|
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.
![](1423.png)
|
Note - Do not define a new user for external users. An external user is one that is defined on an authentication server (such as RADIUS or TACACS) and not on the local Gaia system.
|
Configuring Roles - WebUI
Roles are defined in the page of the WebUI.
To see a list of existing roles, select in the navigation tree.
To add new role or change an existing role:
- Select in the WebUI navigation tree.
- To add a new role, click and enter a . The role name can be a combination of letters, numbers and the underscore (_) character, but must start with a letter.
- To change permissions for an existing role, double-click the role.
- In the or window, click a feature (tab) or extended command ( tab).
- Select , or from the options menu.
![](82901.png)
![](1424.png)
|
Important - A user with read/write permission to the User Management feature can change a user password, including that of the admin user. Be careful when assigning roles that include this permission.
|
To delete a role:
- Select in the navigation tree.
- Select a role to delete.
- Click .
![](1423.png)
|
Note - You cannot delete the , or default roles.
|
You can assign many users to a role from the window.
To assign users to a role:
- Select in the WebUI navigation tree.
- Click .
- In the window:
- Double-click a user in the list to add that user to the role.
- Double-click a user in the list to remove that user from the role.
You can assign the many roles to a user from the page. You must work with the page to define access mechanism permissions (Web and/or command line) for users. A
To assign roles and access mechanisms to a user:
- Select in the WebUI navigation tree.
- Double-click a user in the list.
- In the window:
- Double-click a role in the list to assign that role to the user.
- Double-click a role in the list to remove that role from the user.
- Select an permission (or Line) to let the user to work with it.
- Clear an permission (or Line) to prevent the user from working with it.
Configuring Roles - CLI (rba)
Description
|
- Add, change or delete role definitions.
- Add or remove users to or from existing roles.
- Add or remove access mechanism (WebUI or CLI) permissions for a specified user.
|
Syntax
|
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>
|
Parameters
|
Role <Name>
|
Role name as a character string that contains letters, numbers or the underscore (_) character. The role name must with a letter.
|
Domain-type System
|
Reserved for future use.
|
readonly-features <List>
|
Comma separated list of Gaia features that have read only permissions in the specified role. You can add read only and read write feature lists in the same command.
|
readwrite-features <List>
|
Comma separated list of Gaia features that have read/write permissions in the specified role. You can add read only and read write feature lists in the same command.
|
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.
|
access-mechanisms
|
Defines the access mechanisms that users can work with to manage Gaia. You can only specify one access mechanism at a time with this command.
|
|
|
Examples
|
add rba role NewRole domain-type System readonly-features vpn,ospf,rba readwrite-features tag,
add rba user Paul access-mechanisms CLI,WebUI
add rba user Daly roles NewRole,adminRole
delete rba role NewRole
delete rba user Daly roles adminRole
|
Comments
|
- There is no set operation for this command.
- Use the
add or delete operations to add and remove features from an existing role. - Use
delete rba role to delete an role.
|
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.
![](1423.png)
|
Note - The password policy does not apply to nonlocal users that authentication servers such as RADIUS manage their login information and passwords. Also, it does not apply to non-password authentication, such as the public key authentication supported by SSH.
|
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
- In the tree view, click > .
- Configure the password policy options:
- Click .
Password Strength
Parameter
|
Description
|
|
The minimum number of characters of a password that is to be allowed for users or SNMP users. Does not apply to passwords that have already been set.
|
|
A palindrome is a sequence of letters, numbers, or characters that can be read the same in each direction.
|
|
The required number of character types. Character types are: Upper case alphabetic (A-Z), Lower case alphabetic (a-z), Digits (0-9), Other (everything else). A value of "1" effectively disables this check. Changes to this setting do not affect existing passwords.
|
Password History
Parameter
|
Description
|
|
Check for reuse of passwords. When a user's password is changed, the new password is checked against the recent passwords for the user. An identical password is not allowed. The number of passwords kept in the record is set by History length . Does not apply to SNMP passwords. Enables or disables password history checking and password history recording, for all users.
|
|
The number of former passwords to keep and check against for each user.
- Range: 1-1000.
- Default: 10.
|
Mandatory Password Change
Parameter
|
Description
|
|
The number of days for which a password is valid. After that time, the password expires. The count starts when the user changes their passwords. Users are required to change an expired password the next time they log in. If set to never , passwords do not expire. Does not apply to SNMP users.
- Range: 1-1827 or Password never expire.
- Default: Password never expire.
|
|
The number of days before the password expires that the user starts getting warned they will have to change it. A user that does not log in will not see the warning.
- Range: 1-366.
- Default: 7.
|
|
Lockout users after password expiration. After a user's password has expired, they have this number of days to log in and change it. If they do change their password within that number of days they will be unable to log in: They are locked out. A value of never allows the user to wait as long as they want to change their password. The administrator can unlock a user that is locked out from the page.
- Range: 1-1827, or Never
- Default: Never lockout users after password expires
|
|
Force users to change password at first login after their password was changed using the command set user <username> password or from the WebUI page.
|
Deny Access to Unused Accounts
Parameter
|
Description
|
|
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.
|
|
Days of non-use before lock-out. The number of days in which a user has not (successfully) logged in before that user is locked out. This only takes effect if is selected.
- Range: 30-1827
- Default: 365
|
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.
Parameter
|
Description
|
|
If the configured limit is reached, the user is locked out (unable to log in) for a configurable period of time.
Warning: Enabling this leaves you open to a "denial of service" -- if an attacker issues unsuccessful login attempts often enough you will be locked out. Please consider the advantages and disadvantages of this option, in light of your security policy, before enabling it.
|
|
This only takes effect if is enabled.
The number of failed login attempts that a user is allowed before being locked out. After making that many successive failed attempts, future attempts will fail. When one login attempt succeeds, counting of failed attempts stops, and the count is reset to zero,
|
|
Allow access again after a user has been locked out (due to failed login attempts). The user is allowed access after the configured time if there have been no login attempts during that time). This setting only takes effect if is selected.
- Range: 60-604800 (seconds)
- Default: 1200 (20 minutes)
Examples:
60 - 1 minute
300 - 5 minutes
3600 - 1 hour
86400 - 1 day
604800 - 1 week
|
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>
|
Parameter
|
Description
|
min-password-length <6-128>
|
The minimum number of characters of a password that is to be allowed for users or SNMP users. Does not apply to passwords that have already been set.
|
palindrome-check
<on |off>
|
A palindrome is a sequence of letters, numbers, or characters that can be read the same in each direction. On prevents passwords that are palindromes.
- Range: On or Off.
- Default: On
|
complexity <1-4>
|
The required number of character types. Character types are: Upper case alphabetic (A-Z), Lower case alphabetic (a-z), Digits (0-9), Other (everything else). A value of "1" effectively disables this check. Changes to this setting do not affect existing passwords.
|
Password History
set password-controls
history-checking <on|off>
history-length <1-1000>
|
Parameter
|
Description
|
history-checking <on|off>
|
Check for reuse of passwords. When a user's password is changed, the new password is checked against the recent passwords for the user. An identical password is not allowed. The number of passwords kept in the record is set by History length . Does not apply to SNMP passwords. Enables or disables password history checking and password history recording, for all users.
- Range: On or Off.
- Default: On
|
history-length <1-1000>
|
The number of former passwords to keep and check against for each user.
- Range: 1-1000.
- Default: 10.
|
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>
|
Parameter
|
Description
|
password-expiration <never, 1-1827>
|
The number of days for which a password is valid. After that time, the password expires. The count starts when the user changes their passwords. Users are required to change an expired password the next time they log in. If set to never , passwords do not expire. Does not apply to SNMP users.
- Range: 1-1827 or never.
- Default: never.
|
expiration-warning-days <1-366>
|
The number of days before the password expires that the user starts getting warned they will have to change it. A user that does not log in will not see the warning.
- Range: 1-366.
- Default: 7.
|
expiration-lockout-days <never, 1-1827>
|
Lockout users after password expiration. After a user's password has expired, they have this number of days to log in and change it. If they do change their password within that number of days they will be unable to log in: They are locked out. A value of never allows the user to wait as long as they want to change their password. The administrator can unlock a user that is locked out using the command set user <username> lock-out .
- Range: 1-1827, or never
- Default: never
|
force-change-when <no|password>
|
Force users to change password at first login after their password was changed using the command set user <username> password or from the WebUI page.
- Range:
no - Disables this functionality.password - Forces users to change their password after their password was changed using the command set user <username> password or from the WebUI page.
- Default: no
|
Deny Access to Unused Accounts
set password-controls
deny-on-nonuse enable <off|on>
deny-on-nonuse allowed-days <30-1827>
|
Parameter
|
Description
|
deny-on-nonuse enable <off|on>
|
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.
- Range: on/off
- Default: off
|
deny-on-nonuse allowed-days <30-1827>
|
Days of non-use before lock-out. The number of days in which a user has not (successfully) logged in before that user is locked out. This only takes effect if set password-controls deny-on-nonuse enable is set to on .
- Range: 30-1827
- Default: 365
|
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.
Parameter
|
Description
|
deny-on-fail enable <off|on>
|
Deny access after too many failed login attempts. If the configured limit is reached, the user is locked out (unable to log in) for a configurable period of time.
Warning: Enabling this leaves you open to a "denial of service" -- if an attacker issues unsuccessful login attempts often enough you will be locked out. Please consider the advantages and disadvantages of this option, in light of your security policy, before enabling it.
- Range: on/off
- Default: off
|
deny-on-fail failures-allowed <2-1000>
|
This only takes effect if set password-controls deny-on-fail enable is set to on .
The number of failed login attempts that a user is allowed before being locked out. After making that many successive failed attempts, future attempts will fail. When one login attempt succeeds, counting of failed attempts stops, and the count is reset to zero,
|
deny-on-fail allow-after <60-604800>
|
Allow access again after a user has been locked out (due to failed login attempts). The user is allowed access after the configured time if there have been no login attempts during that time).
This setting only takes effect if set password-controls deny-on-fail enable is set to on .
- Range: 60-604800 (seconds)
- Default: 1200 (20 minutes)
Examples:
60 - 1 minute
300 - 5 minutes
3600 - 1 hour
86400 - 1 day
604800 - 1 week
|
deny-on-fail failures-allowed <2-1000>
|
This only takes effect if set password-controls deny-on-fail enable is set to on .
The number of failed login attempts that a user is allowed before being locked out. After making that many successive failed attempts, future attempts will fail. When one login attempt succeeds, counting of failed attempts stops, and the count is reset to zero,
|
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:
- In the tree view, click > .
- In the section, click .
The window opens.
- Enter the RADIUS Server parameters.
- Click .
- : Select the IP address.
- Select the .
- Click .
RADIUS Server Parameters
Parameter
|
Description
|
|
The RADIUS server priority is an integer between 0 and 999 (default=0). When there two or more RADIUS servers, Gaia connects to the server with the highest priority. Low numbers have the higher priority.
|
|
RADIUS server host name or IP address.
Note - IPv6 addresses are not supported for RADIUS servers.
|
|
RADIUS server UDP port. The default port is 1812 as specified by the RADIUS standard. The range of valid port numbers is 1 to 65535.
Warning - Firewall software frequently blocks traffic on port 1812. Make sure that you define a firewall rule to allow port 1812 traffic between the RADIUS server and Gaia.
|
|
Shared secret used for authentication between the authentication server and the Gaia client. Enter the shared secret text string without a backslash. Make sure that the shared string defined on the Gaia client matches that which is defined on the authentication server.
Some RADIUS servers have a maximum shared secret string length of 15 or 16 characters. See the documentation for your RADIUS server.
|
|
Optional: Enter the timeout period in seconds. The default value is 3. If there is no response after the timeout period, Gaia tries to connect to a different server.
|
|
Optional: An IP address of the Security Gateway interface. This parameter records the IP address that the RADIUS packet comes from. This address is stored in the RADIUS packet even when the packet goes through NAT or some other address translation, that changes the source IP of the packet. The NAS-IP-Address is defined in RFC2865. If no NAS IP Address is chosen, the IPv4 address of the Gaia host is used.
|
|
Optional: The UID for the RADIUS super user. Select 0 or 96. If the UID is 0 there is no need to run the sudo command to get super user permissions.
|
To edit a RADIUS server:
- In the tree view, click > .
- Select a RADIUS server.
- Click .
The window opens.
- You can edit the name, number, , and . You cannot change the .
- Click .
To delete a RADIUS server:
- In the tree view, click > .
- Select a RADIUS server from the table.
- Click .
The window opens.
- Click 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
Parameter
|
Description
|
priority
|
The RADIUS server priority is an integer between 0 and 999 (default=0). When there two or more RADIUS servers, Gaia connects to the server with the highest priority. Low numbers have the higher priority.
|
new-priority
|
The priority of the new RADIUS server
|
host
|
RADIUS server IP address in dot‑delimited format.
|
port
|
UDP port on the RADIUS server. This value must match the port as configured on the RADIUS server. Typically this 1812 (default) or 1645 (non-standard but a commonly used alternative).
|
prompt secret
|
Shared secret (password) text string. The system prompts you to enter the value.
|
timeout
|
The number of seconds to wait for the server to respond. The default value 3 seconds.
|
secret
|
The shared secret used to authenticate the RADIUS server and the local client. You must define this value on your RADIUS server.
|
super-user-uid
|
The UID for the RADIUS super user. Select 0 or 96. If the UID is 0 there is no need to run the sudo command to get super user permissions.
|
NAS-IP
|
An IP address of the Security Gateway interface. This parameter records the IP address that the RADIUS packet comes from. This address is stored in the RADIUS packet even when the packet goes through NAT or some other address translation, that changes the source IP of the packet. The NAS-IP-Address is defined in RFC2865. If no NAS IP Address is chosen, the IPv4 address of the Gaia host is used.
|
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
- 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
- Define the features for the role.
For instructions, see Roles.
![](1423.png)
|
Note - Do not define a new user for external users. An external user is one that is defined on an authentication server (such as RADIUS or TACACS) and not on the local Gaia system.
|
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.
![](1423.png)
|
Note - If you define a RADIUS user with a null password (on the RADIUS server), Gaia cannot authenticate that user.
|
To configure a RADIUS server for non-local Gaia users
- Copy the applicable dictionary file to your RADIUS server:
Steel-Belted RADIUS server
- Copy
/etc/radius-dictionaries/checkpoint.dct to the server directory. - 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
|
- Add to the
dictiona.dcm file the line:
“@checkpoint.dct”
FreeRADIUS server
- Copy
/etc/radius-dictionaries/dictionary.checkpoint (on Gaia) to /etc/freeradius/ (on the RADIUS server). - Add to
/etc/freeradius/dictionary the line:
“$INCLUDE dictionary.checkpoint”
OpenRADIUS server
- Copy
/etc/radius-dictionaries/dict.checkpoint on Gaia to
/etc/openradius/subdicts/ on the RADIUS server. - Add the line
$include subdicts/dict.checkpoint to
/etc/openradius/dictionaries immediately after dict.ascend
- 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.
- 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)
- Log into the system using command line.
- Enter expert mode to go to the Gaia shell.
- Run
sudo /usr/bin/su -
The user now has superuser permissions
Configuring TACACS+ Servers - WebUI
To configure a TACACS+ server:
- In the tree view, click > .
- In the section, select .
- Click .
- Configure one or more TACACS+ servers. In the section, for each TACACS+ server:
- Click .
The window opens.
- Configure the TACACS+ parameters.
- Click .
TACACS+ Parameters
Parameter
|
Description
|
|
The priority of the TACACS+ server. Must be unique for this operating system. The priority is used to:
- Determine the order in which Gaia makes contact with the servers. The server with the lowest priority number is first. For example, if three TACACS+ servers have a priority of 1, 5, and 10 respectively. Gaia makes contact with the servers in that order, and uses the first server that responds.
- Identify the server in commands. A command with
priority 1 applies to the server with priority 1.
|
|
The TACACS+ server IPv4 address.
|
|
The shared secret used for authentication between the authentication server and the Gaia client. Enter the shared secret text string without a backslash. Make sure that the shared string defined on the Gaia client matches that which is defined on the authentication server.
|
|
The maximum number of seconds to wait for the server to respond.
|
To disable TACACS+ authentication:
- In the tree view, click > .
- In the section, clear .
- Click .
To disable a TACACS+ server:
- In the tree view, click > .
- In the section, select a server.
- Click .
To make sure the logged in user is enabled for Tacacs+, run:
show tacacs_enable
Configuring TACACS+ Servers - CLI (aaa)
Description
|
Use the aaa tacacs-servers commands to configure one or more TACACS+ authentication servers.
|
Syntax
|
To add a TACACS+ server:
add aaa tacacs-servers priority VALUE server VALUE key VALUE timeout VALUE
To change the configuration of a TACACS+ server entry:
set aaa tacacs-servers priority VALUE
key VALUE
new-priority VALUE
server VALUE
timeout VALUE
set aaa tacacs-servers state VALUE
To delete TACACS+ server from the list of servers:
delete aaa tacacs-servers priority VALUE
To see the configuration of the TACACS+ servers
show aaa tacacs-servers
list
priority VALUE server
priority VALUE timeout
state
|
Parameters
|
Parameter
|
Description
|
priority VALUE
|
The priority of the TACACS+ server. Must be unique for this operating system. The priority is used to:
|
server VALUE
|
The TACACS+ server IPv4 address.
|
key VALUE
|
The shared secret used for authentication between the authentication server and the Gaia client. Enter the shared secret text string without a backslash. Make sure that the shared string defined on the Gaia client matches that which is defined on the authentication server.
- Range: Text strings, up to 256 characters, without any whitespace characters.
- Default: No default.
|
timeout VALUE
|
The maximum number of seconds to wait for the server to respond.
|
new-priority VALUE
|
The new priority.
|
state VALUE
|
Range:
- Enable TACACS+ authentication for all servers.
- Disable TACACS+ authentication for all servers.
|
list
|
The list of TACACS+ servers that this system is configured to use.
|
|
|
Example
|
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:
- Connect to Gaia as the
admin user. - Define the role
TACP-0
- Define the features for the role.
For instructions, see Roles.
- 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:
- Connect to Gaia CLI as a TACACS+ user.
- 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.
- Run:
tacacs_enable TACP-N
Where N is the new TACP role (an integer from 1 to 15).
- When prompted, enter the applicable password.
To go back to the TACP-0 role, press .
To show if the currently logged in user is authenticated by TACACS+, run:
show tacacs_enable
To raise privileges using the WebUI
- Connect to Gaia WebUI as a TACACS+ user.
- 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.
- To raise the privileges to the
TACP-N role (N is a number from 1 to 15), click at the top of the page. - Enter the password for the user.
To go back to the TACP-0 role from a different TACP-N role, press or enter 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.
![](1423.png)
|
Note - If you define a TACACS user with a null password (on the TACACS server), Gaia cannot authenticate that user.
|
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 in the navigation tree.
To add a group:
- In the page, click
- Enter the 1-8 alphanumeric characters.
- Enter a 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.
- Click
To add a member to a group:
- In the page, select a group.
- Click
- Click
- Select a user.
- Click
To delete a member from a group:
- In the page, select the group.
- Click .
- Select the member
- Click
- Click
To delete a group:
- In the page, select the group.
- Click
- Click .
Configuring System Groups - CLI (group)
Description
|
The commands in this section allow you to manage groups.
|
Syntax
|
To view existing group members:
show group VALUE
To see existing groups:
show groups
To set the Group ID:
set group VALUE gid VALUE
To add a group or a group member:
add group VALUE gid VALUE
add group VALUE member VALUE
To delete a group or a group member
delete group VALUE member VALUE
|
Parameters
|
Parameter
|
Description
|
group VALUE
|
Name of group. 1-8 alphanumeric characters, Must be unique on your system.
|
gid VALUE
|
Numeric Group ID. Must be unique on your system.
Note - 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.
|
member VALUE
|
Name of an existing user. For example, admin or monitor .
|
|
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:
- In the tree view, click .
- Click .
The window opens.
- Define the GUI clients (trusted hosts). These are the values:
GUI Clients - CLI (cpconfig)
- 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
|
- Enter 3.
- 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.*
|
|