Radius User - Group Assign Issue

[Numan135363]

Hey everyone,

We’re facing an issue with RADIUS group mapping on a Check Point Remote Access VPN (R81.20).
Users can authenticate successfully through RADIUS, connect via VPN, and receive an Office Mode IP —
but they’re not being assigned to any group, which causes our access policy rules (based on user groups) not to match.

Here’s what we’ve done and verified so far:

Environment

• Check Point R81.20 Gateway

• Remote Access VPN (Endpoint Security Client)

• RADIUS authentication via third-party MFA platform

• Authentication protocol: PAP

• Attributes tested: 11 (Filter-ID), 25 (Class), 26 (Vendor-Specific)

Configuration Steps

RADIUS Server Configuration

• Added the RADIUS server under Servers and OPSEC Applications → New RADIUS Server

• Set protocol = PAP, version = 2.0

• Defined shared secret matching the MFA server

VPN Gateway Configuration

• RADIUS selected as the authentication method under VPN Clients → Authentication

• “Allow newer clients that support multiple login options” and “Ask user for password (auto-answer first challenge)” options are checked

 External User Profile

• Created a  External User Profile with “Match all users”  (profile name generic*)

• Authentication scheme: RADIUS

• Linked to the same RADIUS server object

Group Mapping Setup

• Created a user group named RAD_Test (empty group as required)

• Verified that the group name matches the attribute value sent by RADIUS

GuiDBedit Settings

Under Global Properties → Radius, confirmed the following:

• add_radius_groups = true

• radius_groups_attr = 11

Also tested with attributes 25 and 26, no change.
Policy reinstalled after every modification.

Observed Behavior

• Authentication succeeds, user connects normally.

• Office Mode IP assigned correctly.

• In the logs, user appears authenticated but no group membership is listed.

• Access Control rules based on RADIUS group membership never match.

We’ve captured RADIUS packets and verified that the MFA server does send back the attribute (Filter-ID/Class/VSA) with the expected value.
Still, Check Point does not map the user to any RAD_ group.

Question

Has anyone successfully made RADIUS group assignment work for Remote Access VPN users on R81.20?
Is there any hidden setting, known limitation, or workaround ?

Any insights, working examples, or references would be greatly appreciated 

[PhoneBoy]

You might need to change the RADIUS attribute we're looking at for the RADIUS groups.
See: https://support.checkpoint.com/results/sk/sk115875 

[the_rock]

Apart from sk Phoneboy gave, try running pdp minitor user command as well.

Andy

[Numan135363]

Hi ,

We tried class and VSA but still doesn't work .  

 This is what radius reply. 

 

 

[PhoneBoy]

I would get TAC involved here.

[Duane_Toler · Accepted solution]

You may also need to have Identity Awareness enabled and for "Remote Access":

You can run VPN debug (and IKE debug) to see what response is coming back (which you already see in the packet capture), but also how the VPN daemon is processing it.  If there's a processing error, you should see it there.

Look for the text "CPSC_RADIUS_AUTHENTICATED", and just above that will be the user group mapping messages.  You can also search the debug for "RAD_" and any occurrences of your group name.  The RADIUS group messages will also be identified with the text "radius_update_user_groups".

TAC would still like to know what's going on in case something is still not right.  Always worth a call.

When you do get the mappings fixed, you'll want to use Access Role objects to control policy access through the rulebase, and not use the user group in the Source column (Legacy User Access).  You will add the locally-defined user groups (RAD_foo) into the Access Role.  With Access Roles, you also don't need to use the RemoteAccess community in the VPN column.  Access Roles will allow you to map the same user with any identity source (Remote Access, Identity Collector, whatever) and wherever the user is connected; highly flexible.  You can use them anywhere you want/need in your policy.

[Numan135363]

Thank you Duane

It solved. 

[the_rock]

Great!