VPN authentication when moving to Smart-1 Cloud central management

[Andrew-OCD]

Dear Checkmates,

We are in the process of migrating all the Quantum Spark 1570 devices from local policy to a central management using the Quantum Smart-1 Cloud.

Each gateway will still have it's own specific policy.

Each gateway also has some VPN users that will be allowed remote access to the internal environments on the site. 

When I configure the "RemoteAccess" object on the central platform it only allows me to setup a single authentication mechanism and so now anybody who has valid credentials can login to any of the gateways. They are unable to access anything because we use the AD-Group that they are a member of to control which destinations they can access.

Does anybody know a way that I can restrict the authentication in the same way, so that only members of the same AD-Group associated with the site can authenticate to the site's gateway?

We are running R81.10.08 on the Sparks.

Thanks

Andrew

[PhoneBoy]

Don't believe this is possible.

[Andrew-OCD]

I was afraid that might be the case.

Now the difficulty is to persuade the customer that the previous functionality, when the devices were local and could have different authentication for each individual gateway, is no longer possible now that they have gone for a centralised management approach.

I wonder if there is another way to achieve the same functionality?

1.) Each gateway needs to be able to authenticate differently using seperate AD-Groups

2.) Each gateway will have access policies based on the AD-Groups to limit access

Anybody with any suggestions, they would be greatly appreciated.

Andrew

[Martin_Raska]

Hi Andrew,

I am thinking the same. it's not possible due to you have only one Remote Access community. One or multiple AD groups for ALL GWs.

[PhoneBoy]

Each gateway can enforce a unique policy as per your second point.
However, the authentication settings apply to all Remote Access gateways under the same management.
What might be a better approach is to enable Secondary Connect: https://support.checkpoint.com/results/sk/sk65312
The idea being, it really doesn't matter which of the gateways the users connect to, they will be connected transparently to the correct gateway that provides the allowed access.
However, if they connect to the incorrect one, they will be prompted to authenticate with the one that does when needed.