LDAP based VPN restrictions

[kamilazat]

Hi everyone!

I'm working on implementing Identity Awareness-based restrictions for Remote Access clients in my lab environment. Here's the setup: I have two separate gateways, which we'll call GW1 and GW2, and two distinct LDAP groups that belong to the same domain controller, referred to as ldap1 and ldap2. Users access the network using Endpoint Security VPN clients. 

I’m trying to make sure that users from ldap1 can only connect to GW1, while users from ldap2 can only connect to GW2. When configuring these restrictions, either all users can connect to any gateway, or none of them can connect anywhere.

Does anyone have suggestions on how to effectively achieve this?

[Duane_Toler]

You can't really prevent a gateway's authentication with AD groups.  However, you can use Access Roles to control traffic for users via a gateway.

Create two LDAP groups, one for each group, LDAP_Group_1, LDAP_Group_2 and configure the LDAP items (CN, OU, etc.).

Create two access roles:  Role_1, and Role_2.  In each role, add the LDAP_Group_X as the group of users  respectively.  Use the Access Roles as the Source column in the rules.  You do NOT need to have the VPN community in the "VPN" column, if you're using access roles (which is why they're awesome!).  Set the Install On gateway for each Access Role.  You can re-use that access role elsewhere and do Drop rules if you want to be obsessive-compulsive about it.

The access roles mappings are also conveyed to other gateways, if you're doing Identity Awareness and sharing.

In Identity Awareness, you don't need AD Query for this exercise, either; only enable "Remote Access" as a source.  The RA login maps the user to the role.

[kamilazat]

Thank you for your explanation!

OK so I created two access roles and the groups ldap1 and ldap2 (they are exactly seen as CN=ldap1, CN=Users etc.). I also added gateways in the Networks tab in the access role settings respectively (GW1 to ldap1 access role and GW2 to ldap2).

Then I created rules like this:

src: ldap1_access_role    dest: GW1    any any Accept    install on GW1

src: ldap2_access_role    dest: GW2    any any Accept    install on GW2

I wanted to assume that the traffic from ldap2 to GW1 would be dropped by the cleanup rule but I still can connect using credentials from both groups. I don't want to utilize IP addresses here because the users should be able to use the VPN client from any machine as long as they enter correct credentials. I really wonder what I'm missing here...

[Duane_Toler]

In the access role, don't add anything other than the LDAP user groups, because this is VPN client users.  Are you trying to prevent users from connecting to GW1 and GW2 directly (SSH, webUI, ping, etc.)?  Or do you want to prevent the user from passing traffic through a gateway to hosts on the internal network? 

[kamilazat]

I removed everything other than the LDAP user groups. I am trying to prevent ldap grous from connecting to specific gateways via VPN using Endpoint Security. Right now I have LDAP groups with names 'ldap1' and 'ldap2' and each of these groups has 1 user for testing. At the same time I have two gateways, namely GW1 and GW2.

I want the LDAP group 'ldap1' to only be able to connect to GW1 via VPN.

And I want the LDAP group 'ldap2' to only be able to connect to GW2 via VPN. 

Whatever I tried so far, I either end up with any group being able to any GW, or nobody being able to connect anywhere. I set up AD object to use Check Point password. On the VPN client, I enter the IP address of the gateway and connect using the user credentials as set up on the AD. Maybe I'm testing it the wrong way?

[Duane_Toler]

For gateways in the same management domain, you can't prevent them from authenticating, only passing traffic.  To prevent authentications, you'll need to have an additional authentication tier, such as RADIUS, which can filter the incoming request with the authorized users.

However, there's debate about the correctness of using multiple Remote Access communities.  This would allow you to do what you want.  I have a customer who has multiple RA communities defined and it seems to work for them (R81.10 management at the time, and R81.10 gateways).  I can't find official documentation stating that it works, but you can configure it in SmartConsole and try it.

If you have R81.10 management AND R81.10 gateways or higher, you can try this:

Go to your object list, select VPN communities, right-click on the existing RA community (this is the only way it works; don't click "New" button or right-click anywhere else; you must right-click on the existing community).  In the fly-out menu, you then have an New option and can configure a new RA community.

Create two RA communities (or re-use the existing one and rename it), RA_1 and RA_2.

In RA_1, add gw1 as gateway and LDAP_Group_1 as the participating users.

In RA_2, add gw2 as gateway and LDAP_Group_2 as the participating users.

You still want to use access roles in your policy to control traffic through the gateways.  Don't use "GW1" or "GW2" as "destination" column; this will never match what you want.  Be sure to test this as heavy as you can; don't assume the first test is a satisfactory match.  Test this many MANY times!

There's no guarantee this will work, however.  If your management, and your gateways, are less than R81.10, then this is almost certain to fail.

Good luck!

[kamilazat]

You made my eyes tear up when reading about two RA communities! Unfortunately it didn't work on my R81.20 setup. I wonder if we can manipulate it from SmartDashboard or any other config files somehow. And how did you even manage to create two RA communities in the first place?

[Duane_Toler]

Right-click on the *existing* RA community and you get a "New community" option.  It only appears in that specific way.  The option doesn't appear with any other method.  However, it's not guaranteed to work.  I've only seen a customer do it once, too.  I personally haven't tried it yet.  It'd be quite useful, for situations like yours, if it does work.

Until then, you'll just have to control things with access roles in the policy.

[kamilazat]

I guess it was "fixed" with one of the updates. On JHF Take 41 it doesn't work. So, back to square one.

Maybe we can ping someone who has experience in this. Wonder if anybody comes to your mind 🙂

[Duane_Toler]

I checked that one customer's policy and, while they still do have multiple RA communities defined and in their policy, they have the rules for the additional RA communities disabled.  They've also renamed the original RA community.

Their current configuration works in this manner.   R81.10 gateways with a recent JHF, and Smart-1 Cloud R81.20 with semi-recent cloud-side JHF (the S1C tenant has mgmt API 1.9, not 1.9.1, so i know it's not JHF 53).  Their prior configuration was the same gateways but Smart-1 225 appliance with R81.10.

Name-sanitized, here's one of their RA communities:

{
  "community": "MY_GEN_VPN",
  "type": "vpn-community-remote-access",
  "gateways": [
    "MYFW"
  ],
  "user_groups": [
    "MY_VPN_GEN",
    "MY_VPN_INS",
    "MY_VPN_PWR",
    "MY_VPN_AUD",
    "MY_VPN_RSA"
  ]
}

 
Here's their other one:

{
  "community": "MY_CON_VPN",
  "type": "vpn-community-remote-access",
  "gateways": [
    "MYFW"
  ],
  "user_groups": [
    "MY_VPN_Consultants"
  ]
}

Looks like their user-groups, and ...surprisingly.. the majority of user accounts are local-defined users (yeah i know...).  I doubt that matters here.  Some users are defined via RADIUS to their RSA Authentication Manager server (where they then do MFA through a policy on the server).