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

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:

  • R80.40 JHF 114 or above
  • R81 JHF 42 or above
  • R81.10 JHF 9 or above
  • Specific VPN client (E84.70 on Windows, currently a specific build for macOS)

You can see the details here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

See also this video by @Peter_Elmer 

29 Replies
JustTesting
Participant

This is great news! I've been looking for a way to use Azure MFA, but the Windows NPS RADIUS had some caveats where each additional tunnel with secondary connect re-prompted for MFA.

I am curious how this will behave with secondary connect in my environment, where I have SMB firewalls that won't support the new SAML authentication method. The video says at the 5:20 mark that the identity awareness session can be shared with other gateways post-authentication, but does that apply to authentication itself?

0 Kudos
PhoneBoy
Admin
Admin

That’s a good question.
@AndreiR do you know?

0 Kudos
AndreiR
Employee
Employee

@PhoneBoy  I don't know for sure. Better check with gateway team.

0 Kudos
PhoneBoy
Admin
Admin

We checked this and confirmed that this will only work where the gateway has exactly the same authentication factor/factors as the realm on the primary gateway.
This is by design. 

0 Kudos
JustTesting
Participant

Understood, thank you for looking into it!

0 Kudos
lullejd
Contributor

Hi,

 

Has anyone managed to make this work? Although gateway is upgraded to R80.40 with JHF114 there is still no option on the gateway properties VPN Clients > SAML Portal Settings as stated in the Release notes.

 

Also on R81, is it yet available?

 

Thanks

 

Senior Information Security Engineer
0 Kudos
Anat_Bar-Anan
Employee
Employee

Hi,

thanks for your question.

To be able to configure SAML for VPN RA, you'll need to also upgrade your MGMT to the JHF.

As for R81 - feature is planned to be available in next R81 JHF - currently scheduled for end of July. 

0 Kudos
lullejd
Contributor

I have management with R81 latest jumbo hotfix and Gateway R80.40 take 141. I think the management is the problem then. will have to wait for the new JHF of R81

Senior Information Security Engineer
0 Kudos
Anat_Bar-Anan
Employee
Employee

updating that next R81 JHF scheduled to mid-end of August

0 Kudos
meeruji
Employee
Employee

Currently as per sk172909 for SAML Authentication Configuration you require the following: 

  1. Check Point Security Gateway running R80.40 Jumbo Hotfix Accumulator Take 114 or higher.
  2. Check Point Security Management running R80.40 Jumbo Hotfix Accumulator Take 114 or higher.
  3. Endpoint Security Client for Windows (starting from version E84.70 build 986102705), or  macOS Endpoint Security Client version that can be downloaded here: (Endpoint Security VPN).
  4. The latest Smartconsole Build for R80.40 Build 423 or higher. Without this the portal page won't be visible. Refer to sk165473 for more details. 
  5. If your MGMT server is on R81 or R81.10 the Portal Page will not be visible. Both the Gateway and Mgmt Server need to be on R80.40. Integration seems to be only for R80.40 Gateways, Cluster's and VSX currently. 
0 Kudos
Paul_Hagyard
Collaborator

This is much nicer than using the Microsoft NPS AzureAD plugin for MFA!

With reference to the PDF in the SK (SAML for Remote Access VPN, 6 June 2021), using UPN rather than email for LDAP matching (pg 12, Multiple Logon Option) is likely to be more successful. Organisations often have external users requiring access, and the UPN for such users will be the required firstname.surname@org.domain but their email address in AD is more often an external domain. In such a scenario uses cannot logon unless the lookup type is set to UPN.

0 Kudos
Paul_Hagyard
Collaborator

I will review the client documentation and likely raise a SR, but is there any known way with Endpoint Security standalone to not perform a CRL check on the gateway VPN certificate?

At present we have got this working with the gateway using a default SmartCenter ICA issued VPN certificate. The SmartCenter CA certificate is loaded into the client trusted root certificate store. Everything works fine, but the client complains about being unable to reach the CRL. The SmartCenter uses an internal domain name, so the CA is not resolvable (and is not accessible from the Internet anyway).

0 Kudos
PhoneBoy
Admin
Admin

Without validating the CRL there is no way for the client to know if the remote certificate should be trusted as it could have been revoked.
Even if it is possible (don’t believe it is) it’s not recommended to disable this check.

0 Kudos
Paul_Hagyard
Collaborator

Thanks, although it's only the new browser component for SAML doing the CRL check. For non-SAML VPN connections the Endpoint Security client does not complain about being unable to perform a CRL check on the same certificate (e.g. retrieving the site details/policy via HTTPS) - so presumably it is not checking beyond the certificate's CA trust.

Sounds like the easiest option is an external CA cert.

0 Kudos
PhoneBoy
Admin
Admin

That...could be a bug and might be worth a TAC case.

0 Kudos
Paul_Hagyard
Collaborator

Hi,

For anyone implementing this with Azure AD and retaining local AD group matching via LDAP for Identity Awareness role-based access, we found it was necessary to modify $FWDIR/conf/identity_awareness_custom_settings.C on the SmartCenter server(see sk147417) and uncomment the line:

#\,

to be simply

\,

Otherwise Identity Awareness fails to match AD user DNs in the format "DN=surname\,firstname@domain" and role-based access does not work. A policy install is required to push the behaviour change to the gateway.

Cheers,

Paul

0 Kudos
Heath_H
Contributor

Any updates for this support in R81 (my lab is on R81 for testing purposes) and all the manual steps and specific version requirements make this very difficult for me to test on my production gateways.

 

Given that it’s been several months since this was first dropped, any updates on some of the limitations (specifically, Identity Sharing - I need to enforce Access Roles on gateways other than my VPN gateways).

 

And the SK makes a note about SDL doesn’t support SAML, which I completely understand, but does that mean that we can’t use SDL without SAML and still use SAML for user triggered VPN connections?

 

Finally, what happens if the client isn’t at a version that supports SAML?  Do they fallback to another supported mechanism (RADIUS) or do they just completely fail to authenticate?

0 Kudos
PhoneBoy
Admin
Admin

As far as I know, Remote Access SAML will be added to the R81/R81.10 JHF in the coming weeks.
@Royi_Priov can you speak to the Identity Sharing implications here as the release notes for this mention a planning session with pre-sales?

0 Kudos
Paul_Hagyard
Collaborator

In regards to role-based access, if you have on-prem AD DCs then just continue using traditional IA for roles (ADQ / Identity Collector). We're matching UPN format SAML logins against ADQ for role-based access, so the same AD roles can be used on any gateway.

0 Kudos
Tim_Tielens
Contributor

Can you elaborate on that, how did you set this up ?
I'm testing SAML auth for MAB but the SNX connection won't launch for some strange reason.
I've created a LDAP group and added the External Users Profile (generic*) in there.
Authentication works, MFA works,  but I would rather use our local ldap groups if I could match SAML email to local UPN.

0 Kudos
PhoneBoy
Admin
Admin

As of R81.10 JHF 9, Remote Access VPN + SAML Auth is supported.
At this moment, it is not currently integrated into the R81 JHF, but is planned.
The original post has been updated with this information.

0 Kudos
PhoneBoy
Admin
Admin

And now R81 JHF 42 has been released which includes support for SAML Authentication for Remote Access.
Original post has been updated.

0 Kudos
Heath_H
Contributor

Great - I just put that ongoing take on my lab to test it out.  But one question that isn't covered in the docs.

I already have a SAML IdP configured for the SSL VPN.  Do I need to create a new IdP object for the Remote Access VPN, or is there a way to use the same IdP object for both blades?  It's all the same back-end IdP (Okta, in my case).

I'm assuming that they need to be separate because the EntityID value is very different (not just the GUID value, but the actual path).

If so, are there any plans to enable using a single IdP object for both blades in a future update?

0 Kudos
PhoneBoy
Admin
Admin

I believe you'll have to create the IdP object multiple times, but you should be able to refer to the same IdP for both.
The reason for that is that the different services (Mobile Access versus Remote Access) have different return URLs. 

0 Kudos
Heath_H
Contributor

Per the SK:

 

But when creating an Identity Provider in R81 (JHF 42), I have to pick the service for the IdP, and when setting up the IdP for the VPN Client -> Authentication, it will only show an IdP that is defined for Remote Access.

So that comment in the SK is confusing.

0 Kudos
PhoneBoy
Admin
Admin

Right, you'll have to define that IdP twice (one for Remote Access, one for Mobile Access).

0 Kudos
Heath_H
Contributor

Initial testing of SAML for Remote Access VPN was positive, but a few notes for those doing the testing:

1) Read through the release notes, there are critical steps about manual edits using GUIDBedit and a script that has to be run on the management server.  I believe the script updates some policy validation settings that otherwise cause the policy to fail validation with a complaint about not being able to have multiple login options if one of them is an Identity Provider.

2) The embedded browser does not support FIDO2/WebAuthN if you are using Okta as your SAML provider.  This is likely something that Okta has to address because they don't support either with native Safari on Mac, either.  This limits the usefulness of this over native RADIUS auth if you were looking to get FIDO2/WebAuthN support for more modern MFA factors.

3) The current VPN client version is E85.30, but the recommended is still E84.30.  The solution requires E84.70 at a minimum.  So depending on how you handle client upgrades, this may be a challenge.

 

So, @PhoneBoy , @Paul_Hagyard  a few questions:

1) When do you expect the manual steps involving GUIDBedit and the script will no longer be required? 

2) Any plans to support other browsers for the SAML flow?  Chrome, Firefox, Edge.?  I ask because the embedded browser isn't fully supported by Okta (see above) and some users prefer other browsers (as well as corporate standards.  I also assume that by IE, you mean the system browser (Edge, now) and not the literal IE (11) which is deprecated.

UPDATED:  So, after testing this, I can state that by IE, they mean the literal IE (10 or 11).  So if you have removed IE from Windows in exchange for Edge Chromium (because even Microsoft is pushing for users to move from IE11 to Edge Chromium), then the SAML flows will NOT work.  The embedded browser does not appear to support WebAuthN (at least not with Okta), so support for U2F or biometrics is not going to be possible.

0 Kudos
PhoneBoy
Admin
Admin

Keep in mind these features were added effectively post-release, so the number of changes we could do in the actual JHF was limited.
I suspect these steps won't be required in R81.20, where this feature is expected to be integrated.

As for using "literal" IE, even though it is deprecated for most end user usage, I believe many apps still use this component in the OS.
Not sure what the technical reason is for using it over, say, the end user's preferred external browser. 

0 Kudos
Heath_H
Contributor

Completely understand.  I am just trying to provide feedback in the hopes the the final product will actually be usable in a production environment.  And with IE11 being removed from Win10 by a number of enterprises, it would be in the best interest of Check Point and it's customers if you supported other options.

Hopefully the developers will figure out how to use the default browser as defined by the user, that or ensure proper support for key security protocols in the embedded browser and testing it with the top SAML providers in the market (MS, Okta, Ping, etc.) to be sure that it is fully supported.  I'd actually prefer that the client have an embedded browser that works the same across platforms and fully support necessary security protocols and APIs.  I would have thought that they would use the Chromium/WebKit engine as it is cross-platform and just strip out unnecessary features that could represent security issues.

0 Kudos