Support Center > Search Results > SecureKnowledge Details
Troubleshooting RADIUS authentication related issues in Gaia Technical Level
Solution

Table of Contents

  • Scenario 1: RADIUS authentication fails when using 'radius-group-xxx'
  • Scenario 2: RADIUS-authenticated users are not able to run external commands in Gaia Clish
  • Scenario 3: Users that are defined only on the RADIUS server and not locally are unable to login on the Gaia-based machine
  • Scenario 4: RADIUS authentication for local administrators does not work after upgrading from SecurePlatform to Gaia

This article discusses scenarios occurring on the Gaia OS. Scenarios that we have encountered and dealt with are detailed below.

An excellent reference is sk72940: How to configure RADIUS authentication on Gaia OS.

Scenario 1

Title: RADIUS authentication fails when using 'radius-group-xxx'

Symptoms:

  • 'radius-group-XXX' does not work when using RADIUS Authentication for non-local users on Gaia OS.
  • 'radius-group-any' works correctly.
Show / Hide this section

Root Cause:

"Class" attribute is not set, or it is not tied to the Group on the RADIUS server.

There is a special RADIUS group called "any". When this group is present in the group list of the Gaia machine, ALL users defined on the RADIUS server are able to log in to the Gaia machine.

After users and groups are configured in RADIUS, the RADIUS client handles authentication and examines the specified RADIUS class to retrieve the user's groups. (The RADIUS "Class" attribute holds the group name).

After the RADIUS group is retrieved, the RADIUS client maps the RADIUS group to the appropriate RADIUS client group.

Solution:

Part 1 (Gaia Portal):

Configure Gaia as a RADIUS Client:

  1. Configure the role for the RADIUS client:

    • If no group is defined on the RADIUS server for the client, then define the role: radius-group-any

    • If a group is defined on RADIUS server for the client (group XXX, for example), then define the role: radius-group-XXX


  2. Configure the features for the role.

    Refer to Gaia Administration Guide for your version.

Part 2 (RADIUS server):

On the RADIUS Server, modify the RADIUS group to include a "Class" attribute.

The attribute value should be the RADIUS group name.
If this does not work, use a different attribute.
For example, for Reply-Message has an attribute number 18.
Then, change the :radius_groups_attr (18) property. The default value is "25" (for Class).

Related solution:

Scenario 2

Title: RADIUS-authenticated users are not able to run external commands in Gaia Clish

Symptoms:

  • External users that are authenticated by RADIUS are not able to run external commands in Gaia Clish.
  • External commands are commands added to Gaia Clish with the "add command" command.
Show / Hide this section

Root Cause:

User does not have sufficient privileges to Gaia shell.

Solution:

Make sure the following vendor specific attribute is set to "1" in RADIUS server:

CP-Gaia-SuperUser-Access = 1

Set SuperUser UID for RADIUS users on Gaia OS to "0" in one of these ways:

  • In Gaia Clish

    set aaa radius-servers super-user-uid 0

    save config

  • In Gaia Portal

    Make sure the View mode is "Advanced".

    Click "Authentication Servers".

    Under RADIUS Servers Advanced Configuration, select Super User UID from the drop-down menu to be "0" (zero).

Scenario 3

Title: Users that are defined only on the RADIUS server and not locally are unable to login on the Gaia-based machine

Version: R75.40, R75.40VS, R75.45, R75.46

Symptoms:

  • Users that are defined only on the RADIUS server and not locally are unable to login on the Gaia-based machine.
  • In Gaia Portal, this error appears: "You are not configured for web access."
Show / Hide this section

Solution:

This problem was fixed. The fix is included starting from

Check Point recommends to always upgrade to the most recent version (Security Gateway / Security Management Server).

If you do not wish to upgrade, do one of the following to allow RADIUS users to log in on the Gaia-based machine:

  • Define the user RBA permissions locally on the Gaia-based machine, as done for a local (non-RADIUS) user. OR
  • Define a global role for all RADIUS users using a role called "radius-group-any":
    HostName> add rba role radius-group-any domain-type System [all-features|readonly-features|readwrite-features [feature]]
    HostName> save config

    Example:
    HostName> add rba role radius-group-any domain-type System readonly-features arp

Scenario 4

Title: RADIUS authentication for local administrators does not work after upgrading from SecurePlatform to Gaia

Symptoms:

  • RADIUS authentication for local administrators does not work after upgrading from SecurePlatform to Gaia

Show / Hide this section

Root Cause:

The PAM statement is missing from the /etc/ssh/sshd_config file.

In a fresh installation, this does not apply as this parameter is set by default.

Solution:

Note: Starting from R80.40 Jumbo Hotfix Take 83, instead of editing/backing up the "/etc/ssh/sshd_config" file, you must edit/backupthe "" /etc/ssh/templates/sshd_config.templ" file and then run the "/bin/sshd_template_xlate < /config/active" command.
  1. Edit the file:

    [Expert@HostName]# vi /etc/ssh/sshd_config

  2. Add the following line to the file:

    UsePAM yes

  3. Modify the line:

    AllowGroups root

    To:

    #AllowGroups root

  4. Save changes to the file and exit from Vi editor.

  5. Restart the SSHD service:

    [Expert@HostName]# service sshd restart
Applies To:
  • sk91640, sk92454, sk82120, and sk87000 were integrated into this sk article.

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment