Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
PhoneBoy
Admin
Admin
Jump to solution

SAML Support for Remote Access VPN

This question has come up a lot on the community.
We now have a formally supported solution that allows integration with ADFS and other SAML-based authentication.
This requires Check Point gateways running (at minimum) the following releases:

  • R80.40 JHF 114 or above (not supported with Maestro)
  • R81 JHF 42 or above (not supported with Maestro)
  • R81.10 JHF 9 or above (not supported with Maestro)
  • R81.20 (supported with Maestro) and above

The following VPN clients are supported (minimum versions listed):

  • E84.70 on Windows
  • E85.30 on macOS
  • Capsule VPN clients (see sk181494), which requires the following gateway versions:
    • R81.10 JHF 43 and above
    • R81.20 JHF 113 and above 

This solution is NOT currently supported with:

  • Capsule Workspace
  • Embedded Gaia/SMB Gasteways

If such support is needed, please open an RFE with your local Check Point office.

You can see the details in the R81.20 Remote Access VPN guide under SAML Support for Remote Access VPN and/or sk172909.

See also this video by @Peter_Elmer 

(Last edited April 2024)

125 Replies
Ted_Serreyn
Collaborator

Are there any plans on adding this functionality to SMB realm.  A lot of these smaller clients are going AzureAD route only with no on-premise AD anymore.

 

 

Martijn
Advisor
Advisor

Hi all,

Does anyone has configured this with a on-prem ADFS server using SAML? We are unable to get this working.
Check Point seems to be configured correctly, but ADFS may have not. Not sure what to put where. Is there a method to export the metadata from Check Point so we can import it into the IdP configuration? This way, we do not have to configure ADFS manually.

Tried to find a procedure/manual for configuring remote access and ADFS SAML, but was unable to find one. Is there such a procedure?

Thanks.

Regards,
Martijn

 

support_suppor1
Participant

Hi,

 

We are having a problem now on implementation when using SAML Azure AD authentication. Everything is working - authentication etc. Users can login properly - connectivity is ok. 

My problem is that when we use the access role and choose a specific user / group - the access role is not working and traffic goes thru Clean up rule. Access role works when it is set to "Any Authenticated" but this would not be helpful when there are multiple user with different access.  Is there a special config or is this a limitation? We are running R81 + JHF 56 (latest) Thank you

lrossi89
Contributor

Hi Carsten,

Can you share an example about identity tag? (some screenshot)

Which version are you using?

*Note – In Documentation : Identity Tags are not supported for Remote Access
connections.

Carsten_R
Contributor

Hi @lrossi89,

No, I have no screenshots. I have removed this setup (it was only a testlab), because I was not able to to get the authorization running with AAD groups and/or Identity Tags.

I told my customer to use a LDAP lookup for the authorization and only SAML for authentication.

anstelios
Collaborator

Hello,

 

We are trying to use this with Azure AD on R81.10 jhf 30.
We get pdpd 100% cpu and IA  stops working completely..
Is the documentation still relevant for R81.10 latest jhfs??
Any idea on the pdpd problem??

anstelios
Collaborator

Thanks, 

take 45 doesn't have this issue indeed.
Authentication now works, but we have the issue described just above my post where access roles for Azure AD are not matched and all traffic is matched on the clean up rule.
It seems that authorization from the Azure AD object doesn't work so the access roles using Azure users are not matched.

Any ideas??

Anat_Bar-Anan
Employee
Employee

Hi, 

did you follow step 6 ("configure the group authorization") in the documentation ? 

Ted_Serreyn
Collaborator

does this configuration ever support multiple groups?

Frankie_John-le
Explorer

Hi Anstelios,

Did you ever get a resolution to this?

I've had something similar running R81.10 JHF Take_45 on the SMS and Gateways where authentication works but if you use the the Azure User in the Access Role the traffic is not matched and hits the clean up rule.

I've configured the Cluster to use the on-prem AD (LDAP) for the existing Access Roles and changed the lookup type to email which works.

 

 

 

Paul_Hagyard
Advisor

Check the user information showing in the logs or perhaps "pep show user all". On R80.40 using local AD groups I had to edit $FWDIR/conf/identity_awareness_custom_settings.C

and uncomment the line:

#\,

to be

\,

 

lrossi89
Contributor

Have you solved this problem?

anstelios
Collaborator

Has anyone found a way to require MFA(Azure) every time the user tries to connect to VPN?
Because as it is, if the PC is already logged in any O365 app the VPN will just connect with no prompt at all.. 
Maybe with conditional access rules for the specific Azure applications?? 

Paul_Hagyard
Advisor

All you can do for now is modify the conditional access policies down to the minimum re-authentication timeout of one hour.

I've liased with engineers regarding customising the SAML request to include forceAuthn="true", which would then force re-authentication on every connection.

Agent_Smith
Contributor

I understand running R81.10 with E86.40 allows remote site and auth creation. However we do not see the SAML in the drop down of the remote mass site creation to update the AUTH from RSA to SAML to all users. How would you update the auth on all the clients from RSA to SAML besides manual.

Ted_Serreyn
Collaborator

You must create the authentication type on the management station.  This allows it to be used.  The endpoint management does NOT currently appear to allow this authentication method to be picked, but it can be configured manually on each endpoint.

 

Agent_Smith
Contributor

How do I create the authentication type on the management is that info in this thread? If we create an auth type on the mgt we can mass update?

PhoneBoy
Admin
Admin

You need to follow the instructions linked in the SK that I provide at the root of this thread, which should include the necessary steps.
Once the updated policy is applied to the gateways, end user systems should get updated with the new authentication option next time they connect via VPN.
Otherwise, you'd have to deploy the relevant setting file manually via SCCM or similar or have users delete/re-add the site manually.

Agent_Smith
Contributor

I'm missing something here. We enabled SAML and we can manually edit the Endpoint to connect. What we want to do is use the management station to configure in mass all the endpoints to have a new site and use SAML. And or to make a new site with RSA then let them change to SAML. We are trying to no do things manually.

PhoneBoy
Admin
Admin

If it's an update to an existing site, it should be communicated next time the user connects via VPN.

If a new site is required to be created, that must be pushed by external means.
One way to do that is to force an upgrade of the VPN client to a new version, which can include a new site definition as part of the deployment.
You can package it using: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 
And push from the gateway with: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

nflnetwork29
Advisor

Hello @PhoneBoy   is there any update from checkpoint on when you will be supporting this SAML parameter for the MFA issue? See @Paul_Hagyard  's Post above

See official response from Microsoft below

 

This could happen when your device is registered/Azure AD joined/hybrid joined to your organization's Azure AD, in case of which a PRT (Primary Refresh Token) is issued to the device. The PRT is then used to provide a seamless single sign-on experience by automatically signing in with the account used to log in to the device. If there was MFA prompted initially in the process of device registration/Azure AD joined/hybrid joined, then even MFA claim is stored in PRT.

Now, whenever user tries to access any application from this device, and if there is any conditional access policy which is configured to prompt for MFA while accessing, then Azure AD will make use of this PRT and both first factor authentication and MFA will not be prompted as PRT contains the MFA claim in it.

You can refer below article to know how PRT is utilized during app token requests,
https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#prt-us...

To require users in your organization's directory to prompt for MFA every time they access the application, you need to update your application code to include forceAuthn="true" parameter in the authentication request. This is an SAML parameter that forces interactive authentication regardless of whether a valid PRT and/or Cookies are present or not.

Read morehttps://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol

 

PhoneBoy
Admin
Admin

Offhand, I don't know.
I recommend bringing the requirement through your local office.

nflnetwork29
Advisor

i did that . not gaining much traction. 

Paul_Hagyard
Advisor

> If it's an update to an existing site, it should be communicated next time the user connects via VPN.

I think we found that it required two connections. The first failed as it updated the site, then a second connection required SAML and completed successfully.

biskit
Advisor

Did you get an update on this?  Is it possible to do from the Check Point side?  Or do you know how to force this within Azure?

anstelios
Collaborator

Anyone knows if this forceAuthn="true" is included in R81.20 ???

biskit
Advisor

Just wondering if you found a solution to this?  I want to force MFA on every login too, and I can't figure out how to do it 🙁

nflnetwork29
Advisor

@biskit @PhoneBoy 

Yes, i received a solution from Checkpoint TAC (they sent me a custom file that i had to copy over to my gateway) 

Use ticket reference: 

6-0003339804 - Azure MFA not prompting users 

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events