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.

[jennyado]

Hi,

Thank you for the suggestion.

I was able to get information from: pep show user query usr <user>:

A bit of background: when we initially integrated Microsoft Entra ID with the Remote Access VPN, authorization was implemented through an inline layer using Access Roles. Shortly after the implementation, we noticed that a significant amount of VPN traffic was reaching the Cleanup Rule of that inline layer instead of matching the expected child rules. As a temporary workaround, the Cleanup Rule was changed to Accept to avoid impacting users.

The TAC then recommended creating ordered rules using the same Access Roles and authorization logic as the inline layer, with the goal of eventually replacing the nested layer.

After implementing those ordered rules:

• The ordered rules started receiving hits as expected.
• The child rules inside the inline layer stopped receiving hits.
• However, traffic is still hitting the Cleanup Rule of the inline layer.

This is why I am not fully convinced the issue is related to identity learning itself. Authentication works correctly, identities are learned, and traffic matches the expected ordered rule. However, the same VPN traffic is still reaching the Cleanup Rule in the inline layer.

Have you seen a scenario where identity and Access Role matching appear correct, but VPN traffic still reaches the Cleanup Rule of an inline layer that should theoretically no longer be used?

Thanks for your input.

[perfect4situa]

I’m also using Entra ID for Remote Access VPN authentication.

I’ve never used Access Roles with an Inline Layer, so there might be some unexpected behavior there. However, what seems strange to me is that your pdp command doesn’t return anything.

In my case (the user is authenticated and connected), pdp correctly shows the authenticated user and the associated information, including EXT_ID_, and my Access Role is successfully matched based on that information.

The only limitation I’m aware of with Access Roles and Inline Layers is that you cannot use the VPN Community in the parent rule that points to the Inline Layer. You can, however, use it inside the Inline Layer itself, so I don’t think that is your issue.

You may also find this useful for PEP/PDP info, although some parts are not particularly clear:

https://support.checkpoint.com/results/sk/sk86441

It’s difficult to say for sure from here, but I would ask TAC to verify that the firewall is correctly mapping the Entra ID group to the expected Access Role. Based on what you’ve described, I don’t think the issue is related to the rules themselves.

Hopefully TAC can shed some light on it. Looking forward to your good news!