SAML Support for Remote Access VPN

[PhoneBoy]

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)

[Heath_H]

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?

[PhoneBoy]

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. 

[Heath_H]

Per the SK:

• R80.40 Jumbo Hotfix Take 119 or higher is needed if the same Identity Provider is to be used for multiple blades (Mobile Access, Remote Access, Identity Awareness).

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.

[PhoneBoy]

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

[Heath_H]

Per sk172909, it has this statement:

• R80.40 Jumbo Hotfix Take 119 or higher is needed if the same Identity Provider is to be used for multiple blades (Mobile Access, Remote Access, Identity Awareness).

But that doesn't appear to apply to the R81 release yet, correct?

[PhoneBoy]

The first release to have Remote Access SAML functionality was R80.40 via the JHF.
Looks like this issue was addressed shortly after that.
It took a few months before the functionality appeared in R81 and R81.10 where I assume they addressed this limitation prior to releasing it into the JHF stream.

At least that's how I interpret the situation.

[JT_Ohio]

is there a way to just have the gateway stop the reauthentication process at the end of the remote VPN timeout.  This is where our experience starts to get squirrely. Depending on the token/session timeout a user could receive different challenges.   If we could have the gateway stop the re-authentication at the end of the VPN connection time would solve this. (Background information about my questions is below) 

We are using Microsoft as our IDP, there appears to be a mix of how folks are being prompted for their passwords and their MFA challenge.  We utilize a hybrid AD environment which has Azure joined workstations, the session token time outs can change depending on when someone logins, locks their workstations or utilize their Microsoft MFA in another solution, like our cloud ESG.  These particular interactions will change the session and token time outs, which we believe will confuse some of our users.  We are engaging our gateway support firm to help understand if there are additional configurations available that can make the experience consistent? So far there does not seem to be anything available.

One thing we have noticed is that folks that utilize their 2factor with the MS authentication app or receive a phone call will be challenged again.  When the VPN client time out is reached these folks would receive another password prompt or another MFA prompt. The password challenge is not the concern, as it just waits for input on the workstation.  The concern is with the MFA challenge, as the user may just approve an MFA request out of the blue which could be a security issue or just confuse them and increase Helpdesk calls.

Thanks!

[Anat_Bar-Anan]

@JT_Ohio - you mean cancelling the reauthentication altogether? this will cause the remote client to disconnect and require it to connect again.

[JT_Ohio]

@Anat_Bar-Anan - Yes, if there is a way to cancel the re-authenticate altogether. Yes we do not want the client to start re-auth process.  Our time out is rather long so this would not interfere with a users workday experience.  Please let me know if there is a way to do this on this on the gateway or VPN client.

[Heath_H]

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.

[PhoneBoy]

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. 

[Heath_H]

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.

[leonfranken]

I fully agree with you! Just tested this and without support for WebAuthN/FIDO2 this will be useless for many of our customers. Besides the lack of support of these techniques, using an old IE engine also causes a misformed IDP login page UI (background image is not loaded) in our setup. Hopefully development finds a way to move to default browser.

[AndreiR]

In order to use such default browsers as Chrome, FF or Edge you can set the "idp_browser_mode" parameter in trac.defaults to "default_browser" and restart TracSrvWrapper service. If you need to modify this parameter centrally for all users, you have two options:

1. Prepare custom installer with  help of VPN Configuration Utility
2. Modify trac_client_1.ttm on gateway and add following parameter

:idp_browser_mode (
    :gateway (
        :default (default_browser)
    )
)

Save file and install policy. Do not forget to backup trac_client_1.ttm before any changes.

[Heath_H]

@AndreiR - Thank you for that setting.  I just tested changing the setting in Trac.defaults on Mac (E85.30 Build 986200317) and can confirm that it opens the page in my default browser (Chrome) which supports WebAuthN with Okta.  I still haven't tried it in the trac.client_1.ttm file, which would be a lot easier as it's how we configure MEP for our clients today.

Are there other settings in trac_client_1.ttm that you can point us to?

[leonfranken]

Hi @Heath_H 

Good to hear that your tests are successful!

Just tested by changing trac_client_1.ttm but without success. I am using VSX R81.10 (no jumbo) with Harmony Endpoint E85.40.
I will dive in further tonight.

Leon

[Heath_H]

I'm testing on R81.  I tried going to R81.10, and it didn't go well so I reverted to R81, which was much more stable for me.

I'll try testing via the trac_client_1.ttm file as well and see if I can get it working or not and report back.

heath

[leonfranken]

I can get it working only when changing trac.defaults on client, just like you.

I've changed:

idp_browser_mode STRING embedded GW_USER 1

to:

idp_browser_mode STRING default_browser GW_USER 1

[Heath_H]

Any word from CP devs on if/when we will be able to configure that setting via the trac_client_1.ttm file on the server/gateway?  Asking users to manually edit that file is a non-starter in a corporate environment, and I haven't seen documentation on editing it in the DMG/installer file like you can do with the Windows client (build a custom MSI).

[AndreiR]

Hi @Heath_H ,

Please follow item #2 from my comment (https://community.checkpoint.com/t5/Remote-Access-VPN/SAML-Support-for-Remote-Access-VPN/m-p/132996/.... Do not forget to save trac_client_1.ttm and install policy.

VPN client will receive idp_browser_mode parameter upon next connection to your gateway. The setting will have effect starting the second connection.

[leonfranken]

Hi AndreiR,

That is exactly what I did.

I performed the following steps:

• changed OBSCURE_FILE in trac.defaults to 0 in order to make trac.config readable
• added the property to trac_client_1.ttm on the gateway and did a policy install
• reconnected the client and successfully verified that the idp_browser_mode property was added to the trac.config and set to default_browser

result: client keeps on using the embedded browser

Additional steps taken:

• modified idp_browser_mode proaperty in trac.defaults from embedded to default_browser

result: client uses default browser

Seems like the client ignores the property from the gateway at all.

Versions used:
Gateway: R81.10 (VSX)
Client: Harmony Endpoint E85.40

UPDATE: I have the exact same behavior when using standalone VPN client: Check Point Mobile for Windows E86.00.
UPDATE 2: Same goes for Endpoint Security VPN E86.00
UPDATE 3: Also tested a freshly installed non-VSX gateway but without success

Leon

[AndreiR]

Hi @leonfranken ,

There might be a bug in SAML implementation. I will assign engineer to double-check it.

[leonfranken]

Hi @AndreiR 

Thanks for your update, just let me know if I can assist with anything.

Leon

[leonfranken]

Hi @AndreiR 

Do you have an update regarding this issue?

Thanks,
Leon

[MrAleksen]

In case anyone else finds this thread and are wondering about the state of this issue, I got this response from Check Point Support: 

"I got confirmation from R&D Team that changing idp_browser_mode via the trac_client_1.ttm file is not yet supported and there is no centrally managed way to introduce this parameter change. This option is set be implemented in 2023."

[PhoneBoy · Accepted solution]

idp_browser_mode is supported on Windows from E87.30 client version.
See: https://support.checkpoint.com/results/sk/sk180726 

[mssmith_sloco]

We have SAML working in our lab on R81.10 . We have tested both MAC and Windows, works great. Are there any plans for using SAML auth for Mobile?

[PhoneBoy]

For mobile clients, we are generally wrappers for the built-in VPN functionality provided by the OS.
Which may prevent us from implementing this functionality on mobile devices.

[mssmith_sloco]

Thanks @PhoneBoy  . We had Cisco Any Connect prior and utilized SAML with Azure MFA.  Loosing this functionality is difficult..We will look at other options.. Thanks! 

[Anat_Bar-Anan]

adding to @PhoneBoy, a solution we've suggested to customers involves MDM compliance checks and capsule VPN (for Android) or Capsule Connect (for iOS). if you'd like to read about it - please refer to sk98201(MDM Cooperative Enforcement for Mobile clients), and if you're working with MS Intune, you can also have a look at sk170415 (Capsule Connect iOS MDM CE in Intune) , and sk170320 (Capsule VPN setup in Intune MDM)