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

SAML SSO asking for Authentication Method

I am setting up a second Checkpoint Client VPN solution using SAML SSO authentication on a new Gateway. We have the existing solution working perfectly on the old gateway. When a user tries to connect, they are passed through to the SAML provider where authentication is performed, and away they go. 
I have copied all the same settings and have set up a new Identity Provider for the new VPN, however when connecting it is asking for an authentication method despite it being set to use SSO, as per the attached picture. On the existing (working) one this option simply never comes up. 
Can anyone point me in the right direction as to what might be causing this. 
The gateways VPN Clients Authentication is set to use the identity provider (GCP_SSO_WOF) and the Gateway is, paired to the applicable SAML Identity provider, with the service set to Remote Access VPN. 

I figure I have missed something, somewhere, but this is doing my head in. I am following the identical setup to the previous gateway and am getting a different result!  Thanks
 

0 Kudos
1 Solution

Accepted Solutions
nzmatto1
Contributor

To follow this up and close it off, though we were well above the minimum required version and patches required for this to work, something somewhere must have messed up deep inside the bowels of the firewalls. We tried a reboot, that achieved nothing. We had another permissions issue which we resolved but that also had no impact, final as we were almost ready to put these boxes into production we applied the latest available patches, and after then the option suddenly started working. 
So the root cause is unknown, however somehow the patch process resolved the issue. I'm guessing somewhere some file was re-written and that fixed it. Although we spent way too long troubleshooting this I am happy that it never impacted production workloads so will not be investigating further. 
If anyone comes across this thread, experiencing similar, I recommend going ahead and applying the newest available patches early on in your troubleshooting. 
Thanks Matt

View solution in original post

12 Replies
the_rock
Legend
Legend

Im pretty sure you are missing the right setting on gateway object in dashboard, under vpn clients or something, cant recall exact setting now, but can check in the lab tomorrow. There should be an option for authentication, just make sure its same as other working gateway.

Andy

0 Kudos
nzmatto1
Contributor

I am wanting only to permit the VPN Client, using only Check Point Mobile for Windows. 
Under VPN Clients I have desktops checked with only Checkpoint Mobile for windows, nothing else (though I have tested all of these). For Authentication I have disabled to older client compatibility, and under Multiple Auth have added my Identity Provider as the first option and username/password as the second. This second option will be removed as soon as I get SSO going. 
Under Dynamic ID Settings I have the Use Global settings checked. 
The SAML Portal settings only have my URL and certificate set. 
Office mode is set, and the ip ranges have been defined and policy permitted. 
The Mobile Access section does not use SSO as we do not use it. 
 
In the shared mobile access policy I have set all the permissions the same. 
The firewalls do have outbound internet access. 

0 Kudos
the_rock
Legend
Legend

This is what I was referring to.

Andy

 

Screenshot_1.png

0 Kudos
nzmatto1
Contributor

We're not enabling the older clients which don't support multiple logon, however I have tested that. There is one surprise I've just noticed and that has me scratching my head. When I tested the above, SSO/SAML was not available in the drop down box for Authentication methods. This might be normal though as that's for really old clients which wouldn't support SSO anyway as far as I am aware. 
Thanks Matt

0 Kudos
nzmatto1
Contributor

To follow this up and close it off, though we were well above the minimum required version and patches required for this to work, something somewhere must have messed up deep inside the bowels of the firewalls. We tried a reboot, that achieved nothing. We had another permissions issue which we resolved but that also had no impact, final as we were almost ready to put these boxes into production we applied the latest available patches, and after then the option suddenly started working. 
So the root cause is unknown, however somehow the patch process resolved the issue. I'm guessing somewhere some file was re-written and that fixed it. Although we spent way too long troubleshooting this I am happy that it never impacted production workloads so will not be investigating further. 
If anyone comes across this thread, experiencing similar, I recommend going ahead and applying the newest available patches early on in your troubleshooting. 
Thanks Matt

PhoneBoy
Admin
Admin

What version/JHF of gateway/management are you doing this on?
Unless it’s all R81.20, you’ll probably need the script (among other things) from here: https://support.checkpoint.com/results/sk/sk172909

0 Kudos
nzmatto1
Contributor

Yeah, the magic script. I have run that and made the required database changes. I'm on R81.10 at the moment. I also have an existing SAML SSO solution which is working perfectly from the same manager. 
I have noted that the Metadata file provided to me from the SAML provider for this gateway is identical to the file provided by them for the previous gateway. I have asked about this and asked them to check if perhaps somehow they have provided me with a duplicate copy of the old file instead of a new one. At their far end both gateways are talking to the same SAML service, so it is quite possible this is correct. 
Overnight last night I worked through as many different options as I could try and nothing has changed the behavior. The existing one works fine, though it now attempts to connect to the new gateway, fails and so connects to the existing gateway. That's weird given I've disabled MEP, but I guess this is because both gateways participate in the remote access community.  
I have deployed similar for another client with 4 gateways and that has worked fine across all the gateways which are all in the same community, so I don't think that's an issue. 
Thanks Matt
 

nzmatto1
Contributor

The file from the provider is definitely correct, so that rules that one out too. 
I note R81.20 has a few fixes for SSO and I wonder if that would help, but our manager is a cloud based installation and R81.20 is not yet available to it. R81.10 Take 109 is the latest on the Available Updates page. I will upgrade to that on Friday, unless R81.20 magically becomes available. 
Does anyone happen to know when this might become available to cloud installations?

0 Kudos
the_rock
Legend
Legend

If you meant Smart-1 cloud mgmt server, R81.20 had been available for at least 6 months now. But, only CP can install it, not you.

Andy

0 Kudos
nzmatto1
Contributor

I don't think it's the Smart-1 cloud management server (but I don't know). It was just an Amazon AMI I selected in order to build a new manager in AWS. 

0 Kudos
the_rock
Legend
Legend

Definitely not S1C, for sure. Honestly, at this point, I would consult with TAC and see if this can be fixed via remote session.

Andy

0 Kudos
SenpaiNoticed_U
Employee
Employee

Per SK172909

  1. make sure that you Mgmt server and gateways are correct version plus jumbo.
  2. Verify that the script has been run on the environment if required.
  3. Verify that the Gateway has the Authentication available. Gateway object >> vpn client >> authentication
  4. verify that the client is on the SAML supported version or higher, anything E86.00 or higher will work. 

If the issue persists, please open a Support Ticket with TAC.


SK172909 also has a section for initial configuration troubleshooting steps that resolves most first time issues.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events