Remote SAML VPN doesn't work with returned groups when using external profiles

[sdragon92]

Hello All,

We are using remote access vpn using SAML SSO and it is working however when we return back memberof groups to checkpoint, the access roles doesn't work, the moment we filter using generic* groups. When we switch to filtering using LDAP groups it works perfectly. My question what attribute name does checkpoint waits in the SAML assertion to provide filtering after authentication in the access roles? Thanks.

An update, I used the attribute name group_attr to be returned to the checkpoint and its value is the memberof value mapped from the AD, so it returns multiple values in the assertion. and it still unable to use the access roles. My question is , are the IdP returning the attributes correctly but the identity awareness blade doesn't work on that ? is it must be LDAP profile instead of generic/external ? 

- Dawoud

[PhoneBoy]

For AzureAD, I'm pretty sure this is done through the Graph API (starting from R81).
In R80.40 (which doesn't support Graph API), you have to manually create Identity Tags for the groups you wish to use. 

[sdragon92]

@PhoneBoy Thanks for getting back to us I appreciate it very much. No we are not using Azure AD for this customer, I supposed if the customer has Azure AD we can link checkpoint to it using API calls and it will identify the groups in the identity awareness in the policies but this case is different. This is using normal on prem AD, when I use external profile of generic* users it works but access roles of LDAP groups doesn't work (this is on client VPN). On Mobile access when we send this group_attr it doesnt work at all it says user is unauthorized. Workaround I found is to remove external users (generic) from VPN user directories and depend on LDAP. So is that a normal behavior ? Also can I create a local group on Checkpoint to match what we receive from IdP in SAML assertion "group_attr" in case of using on prem AD (I saw a video from checkpoint stating this workaround until graph API is available to Azure) so since we are not using Azure, is that a valid workaround? Kindly let me know your thoughts. I appreciate your time.

- Dawoud

[PhoneBoy]

Seems reasonable to try and create an Identity Tag that matches the capitalization of what you have in your on-prem AD to see if that works.
@Royi_Priov and team can confirm.
Otherwise, you have to do this with LDAP.

[sdragon92]

@PhoneBoy thanks for your reply. I tried the identity tag but I am not much experienced with it. I created one with a dummy name and sent that dummy name from IdP as group_attr then created an access role with that identity tag ,not sure if that is correct or not. It still don't work, the only option I haven't tried is the local group creation on checkpoint. The steps I did for identity tag I am not sure are complete or not, the other problem with the identity tag is we cannot automate it from IdPfor everyone unless we create a tag for every needed group to be matched. One thing that came in mind, when I was analyzing the SAML traces, the group_attr sends multiple values of the virtual_group attribute from AD, so it sends the groups that the user is part of, does checkpoint checks every entry there or the first entry or the first match only? how does that work? 

Let me know your feedback, I appreciate it

- Dawoud

[PhoneBoy]

You've added the relevant Identity Tags (capitalized exactly as defined in AD) to the appropriate Access Roles, correct?
Only the groups (or identity tags) defined as part of an Access Role will be matched (and multiple can be matched).

[sdragon92]

@PhoneBoy I will try it now and let you now the results (screenshot of SAML assertion/smartconsole config ... Thanks again.

-Dawoud

[sdragon92]

@PhoneBoy Here is the output of my testing:

1- I did create a local group, added to it the LDAP group with the same name and external (generic*) inside and then added that local group to the access role and that failed.

2- Made the local group alone with no inside groups and still no difference (if checkpoint match by name only), I put only LDAP group inside and in access roles still no luck.

3- Created identity tag with same name , I validated the name from SAML assertions correct. So right now the access role have 3 entries, one for local group with same name with no inside groups, one identity tag with same name and one LDAP group with same name and still fails.

4- When I tested this in mobile access I added 3 separate rules, 2 each for specific groups (including local and LDAP) and third for external (generic*) each having a unique website to identify which matched which after authentication and I can tell you, the external is the only one that worked. Please find screenshots of the configuration I have in my test lab.

Not sure what else to test , or I might be doing something wrong in between. So as far as I am experienced with checkpoint I know every feature needs a trigger to work. in Fortinet for example, I need to create a match for the SAML assertion group name one by one if I want to, in Checkpoint is there such a feature to enable it to match with what it gets in group_attr   ?  maybe thats the trick ? I appreciate your feedback in advance !

-- Dawoud

[PhoneBoy]

We may not be reading the groups at all from the SAML assertion...and that may be by design.
However, I don't know for sure and will need some confirmation from R&D.
Recommend a TAC case in parallel if you don't have one already.

[sdragon92]

@PhoneBoy weird thing is from pdp monitor , it knows that the user is part of the correct access roles:

[Expert@fapaccp01:0]# pdp monitor user vicd

Session: e058185b
Session UUID: {7728F8D2-3FE9-17BE-9792-556D9F5D7301}
Ip: 10.55.55.58
Users:
vicd@dawoud.com {993645f2}
LogUsername: Vic DeHurwst (vicd)
Groups: All Users;LDAP_ONLY_AD;ad_group_LDAP_ONLY
Roles: LDAP_ONLY_AR
Client Type: AD Query
Authentication Method: Trust
Distinguished Name: CN=Vic DeHurwst,OU=SOC_CONSULTANT,OU=OPERATIONS,DC=dawoud,DC=com
Connect Time: Tue Nov 15 00:12:41 2022
Next Reauthentication: Tue Nov 15 12:13:11 2022
Next Connectivity Check: Tue Nov 15 12:13:11 2022
Next Ldap Fetch: Tue Nov 15 01:10:11 2022

Packet Tagging Status: Not Active
Published Gateways: Local

I think once the authentication is set to external profiles, this pdp monitor result doesn't matter somehow (correct me if I am wrong), unfortunately this is a test environment used for evaluating integrations at the time being. the customer side doesn't have a problem with the LDAP solution so no TAC needed there. but for myself this is an issue for me, so a question what if we configure Azure AD to be connected to Checkpoint and we send the user roles defined in Azure in the SAML Assertion, does that qualify as a workaround ? Let me know your thoughts. Also I checked the DB and generic_fetch was set to false, I changed it to true but same issue.

- Dawoud

[sdragon92]

@PhoneBoy I saw the documentation video from Checkpoint officially stating to return groups in group_attr while creating internal groups in parallel. I did that and also did the identity tag to match with what we get exactly from IdP, not sure where the trick is. I have a feeling there is something that need to be done to allow checkpoint read the groups, maybe there is a trigger somewhere.. The reason why I think this why also is because when I send group_attr1 for example, it doesn't change anything and break anything which proves Checkpoint is indeed understanding group_attr  but likely not what's inside it for some reason. Also if you know some good commands for SAML assertion and what did checkpoint do after getting it and identifying the user ? What is your thoughts?

- Dawoud

[sdragon92]

@PhoneBoy Hi 🙂 Any luck with anything so far ? thanks again

- Dawoud

[PhoneBoy]

Unless @Royi_Priov or someone on his team has further suggestions, I recommend a TAC case.

[sdragon92 · Accepted solution]

@PhoneBoy I figured it out ! Checkpoint adds EXT_ID_groupname , therefore I created identity tag with value EXT_ID_LDAP_ONLY or local group EXT_ID_LDAP_ONLY and it worked finally ! 

Dawoud

[PhoneBoy]

Turns out this is in an SK: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...