Remote Access VPN + Entra ID + SAML + Access Roles

[jennyado]

Hi all, 

We are troubleshooting an issue in our environment and would like to better understand how group membership is resolved when using Microsoft Entra ID with SAML authentication and Access Roles.

Environment

• Check Point Security Gateway Cluster in Azure with R82
• Remote Access VPN (Endpoint Security) with embbeded browser configuration
• Microsoft Entra ID as Identity Provider
• Identity Awareness enabled
• Access Roles used in the Security Policy
• External groups configured as EXT_ID_*

Current Architecture

Microsoft Entra ID

        |

        | SAML Authentication

        |

        v

Identity Provider Object

(in SmartConsole)

        |

        v

Remote Access VPN

        |

        v

Identity Awareness

        |

        v

Access Roles

        |

        v

Firewall Policy

Authentication Application

We have a dedicated Entra ID Enterprise Application used for authentication.

This application is associated with the Identity Provider object in SmartConsole and contains:

• SAML configuration
• User assignments
• Group assignments
• Claim configuration

Current claim configuration:

group_attr -> user.assignedroles

 This application is successfully authenticating users and VPN connectivity is established without issues.

Authorization Application

We also have a second Entra ID application used for authorization.

This application is associated with the Microsoft Entra ID object configured in SmartConsole.

Configured API permissions:

Device.Read.All

Group.Read.All

User.Read.All

 This application currently does not have group assignments configured.

Current Behavior

Authentication appears to work correctly.

In SmartConsole logs we can see the authenticated user:

 Source User Name:

John Doe ([email protected])

VPN connectivity is established successfully, which suggests SAML authentication itself is working correctly.

The issue is understanding how Access Roles resolve user group membership and whether our current Entra ID configuration is correct.

TAC Recommendation

TAC advised us to:

1. Assign the user groups to the Authorization application.
2. Change the claim configuration from: group_attr -> user.assignedroles to user.groupsHowever, when reviewing the documentation, I could not find a specific reference to using: user.groups as the claim value.

Additional Observation

According to the documentation, the Unique User Identifier claim should be configured as: user.userprincipalname.

However, in our production environment it is currently configured as: user.userprincipalname and authentication is working successfully.

The raises a few questions about what is actually required for authorization and Access Role matching.

Questions

1. When using Remote Access VPN with Entra ID and SAML, where does Check Point actually obtain the group membership information used by EXT_ID_* groups?

2. Is the group membership used by Access Roles derived from:

   • SAML claims?
   • The Authorization application through Microsoft Graph?
   • Identity Awareness queries?
   • A combination of the above?

3. Should the Authorization application contain the user group assignments, even if the Authentication application already contains them?

4. Is using: group_attr -> user.assignedroles a supported and recommended design, or should it always be: group_attr -> user.groups for Access Role authorization?

5. Has anyone successfully implemented Access Roles with: group_attr -> user.assignedroles insted of user.groups?

6. Could the difference between: user.localuserprincipalname an duser.user.principalname affect Identity Awareness group resolution or Access Role matching even if authentication itsekf works correctly?

Goal

The main goal is to understand why authorization is not behaving as expected in our environment and to determine which Entra ID application and attributes are ultimately used by Check Point to resolve group membership for Access Role enforcement.

Any insights, implementation experiences, or best practices would be greatly appreciated.

Thanks!

...

[simonemantovani]

Hello

I usually implemented this kind authentication by only configuring the Identity Provider object in SmartConsole and configuring, into the Multiple Login Option a specific entry to use the Identity Provider.

In this scenario, when the client completes the autentication it returns to the firewall several information (SAML Assertion), one of these is the assigned role, this role is compared with the name of the group with EXT_ID prefix, if there is a match between the role and the text after EXT_ID then the group is matched and the corresponding rules are applied.

In the past, I configured the Entra ID object in SmartConsole to be able to read all the groups and users in Entra ID in the same way you query an LDAP server; and create Access Role by selecting directly the group id as reported in Entra ID.

Using EXT_ID groups or using the Microsoft Entra ID object are two different ways to perform the same authorization.

I've always followed the admin guide and implemented everything using only EXT_ID groups and the assigned roles provide by the Identity Provider in the SAML assertion.

In some cases, I had been asked to authenticate user with Entra ID but authorize them using the Active Directory on-prem; even in this case I configured:

• Identity Provider object in SmartConsole.
• LDAP Account Unit.
• In the multiple login option, I configured the User Directory section to use the specific LDAP account unit.

[perfect4situa]

Hi jennyado,

I don't think the configuration itself is necessarily the problem. I think the important part is to check how the firewall actually sees the information received from SAML.

After authenticating with a test user, I would run on the gateway:

pdp monitor user [email protected]
pep show user query usr [email protected]

This should show you how the identity and group information is being learned by the gateway and should help clarify how you need to reference the groups in the Access Roles.

I think this would be a good starting point for troubleshooting.