How to actually configure Identity Collectors and Identity Sharing

[AkiYa]

Hi guys,

I need to understand if my current setup is correct since we are experiencing random issues with the Identity Awareness access roles rules.

Short question:
I have two Identity Collectors configured to collect logins from several servers in three domains; The gateways are configured to receive data from their specific domain query pool, however some users (ie. the admins) need to connect across different sites under different domains.
In this case, is the Identity Sharing needed?
If yes, what is the correct configuration to be done? ("get identities from other gateways" and "share local identities with other gateways"?

I've read the documentation but I can't still understand whether my configuration is correct or not, also because the complexity of my infrastructure.

I'll try to explain it:

SITES: there are different sites where the two main offices are running two separated domains (trusted), and site to site VPNs across each sites.

DOMAIN CONTROLLERS: there are several DC distributed across the sites (but not all the office have one), managed by DFS: as a result, users could authenticate to a DC which is not necessarily the closest one.

GATEWAYS: each site has a checkpoint gateway.

AUTHENTICATION METHODS: each gateway is configured on the Identity Collectors, but we also need to collect data from Identity Agents and Remote Access (where enabled)

What I don't understand is whether the Identity Sharing is needed in this situation, since I'm expecting the gateways to get all the IP/user association from wherever the user logged in; But then if a user logged from "Site A-Domain A" and needs to connect to a server on "Site B-Domain B", I want the rule on the Gateway B to allow the connection.

Also is not clear if I should configure the Identity Broker....
And by the way in the documentation is not clear whether the "sharing id" parameter is the same in case of a cluster or each gateway should have its (I guess not or it will be really complicated to configure).

[PhoneBoy]

What this diagram doesn't tell us is:

1. Version/JHF of gateways
2. If the gateways are managed the same manager (if not, Identity Broker is probably needed)
3. The precise connection between IDC, AD, and gateways (the diagram should make this clear)

In general, Identity Collector should be "as close to the Identity Source as possible."
Identity Sharing is likely needed here, though that will become clear once you answer the above questions.

[AkiYa]

Hi @PhoneBoy ,

1. All the gateways are on R81.20 - JHF 84
2. Yes, they are all managed by the central Management, located at Site A
3. Not sure if you have seen the attachment "SCHEMA.png", anyway I'll explain it better:

- there are two main "headquarters" defined by the domain. Let's say "alpha.local" and "beta.local".
The domains are trusted and people will connect via Remote Access to their gateways; They need to access resources located across all the infrastructure
(of course I'm talking about people connected from the office, I know that Remote Access role wins over everything else)

- Some branch offices have an internal Domain Controller, which is a replica of the main at the HQ.
DFS is configured so that "alpha.local" or "beta.local" answer to all the related domain controller, technically the closest one but not always...

- there are two IDC, one at the "alpha.local" HQ and one on cloud (Azure) which is connected via s2s VPN to the Alpha HQ.
All the DC (both domains) are configured on each IDC; The domains and related DC are defined by query pools

- each gateway is configured to collect data from both the IDC

Just to be clear here are the problems:
- sometimes a user logged in from a office on domain X, can' t access resources on the office of domain Y, even though an Access Role is configured to allow the connection.

- on the IDC I see mixed results for a user/IP, in particular I don't understand why I see records from months ago (this could explain the missed match of the rules)

Thanks
 

[PhoneBoy · Accepted solution]

In general:

• Each IDC should be pulling ONLY from the NEAREST AD server
• Each gateway should pull identities ONLY from the nearest IDC instance
• Identity Sharing should happen between the relevant gateways

Your diagram doesn't even show gateways and your description suggests you've got multiple IDCs pulling the same AD server.
This is not best practice and will be problematic.
Additionally, an IDC instance at each site that has an AD server is likely a good idea.

[AkiYa]

I' ve attached a new schema, I hope it's more clear but I don't get the point of showing the gateways (all the sites have a checkpoint gateway except for Azure).

Some more infos:

- all the gateways are managed from a SMS at the central "Alpha" HQ (Site A)

- there are several domain controllers, they are all connected to the IDC to collect data; "Alpha" sites use a query pool for their Alpha domain, "Beta" sites use a query pool for Beta domain.

- there is also that IDC on Azure, I' ve added it for redundancy purpose but if I understand well is not even useful unless all the gateways have a direct VPN to Azure.
It' s more important to have an IDC on site Beta, correct?

- I don't know if it's important but site B and B1 are connected through a MPLS connection; the same for A and A3

Now, what do you exactly mean for "nearest AD server"?
Since the IDC is installed on site A, should it be configured to connect to Site A domain controller only? (and Site B for the domain "Beta.local")?

What about gateways pulling identities from the nearest IDC?
At this point I would just remove the IDC on Azure, they will use the "nearest" in any case; Unless I configure another IDC on Site B, at that point:
Sites B and B1 will use IDC at Site B; Sites A, A1, A2 and A3 will use IDC at Site A, correct?

Can you please explain better "Identity Sharing should happen between the relevant gateways"?
My first idea was that the sharing should happen only between the gateways A and B, exchanging identities from the respective query pools, but then I thought that everyone had to collect data from everywhere... and I understand it's probably wrong.

I could try to configure an IDC on each site with a DC, but if not strictly necessary I would avoid because of the resources needed.

Thank you!

[PhoneBoy]

The reason the location of the various gateways are important is because of latency between the various components matters (AD/IDC/Gateway).

Any site that has a Domain Controller and a Check Point gateway should have it's own Identity Collector instance.
That means adding IDC instances to: A1, A3, and B.
Each IDC instance should ONLY be pulling identities from the local DC and nowhere else.
The gateways at each site should be configured to do LDAP queries to the local DC (or nearest in the case of A2 and B1).
That would be the most ideal and scalable configuration.

If you don't want an IDC installed at the smaller sites (I assume these are the A1/2/3 sites), then the IDC at Site A should be querying the DCs at A1 and A3 and you should have an IDC at Site B querying it's local DC.

Either way, all gateways (at A1, A2, A3, A, B, and B1) should be sharing identities with each other and set up to query via LDAP the groups from the nearest DC.

[AkiYa]

sorry @PhoneBoy ,

there is still a thing that I don't get: you wrote

"The gateways at each site should be configured to do LDAP queries to the local DC"

and

"all gateways (at A1, A2, A3, A, B, and B1) should be sharing identities with each other and set up to query via LDAP the groups from the nearest DC."

maybe it's a typo, or I miss something, but are you talking about AD query?
Isnt' the IDC purpose to get rid of AD query?
If you meant "IDC" it would make sense to me, can you please confirm?

Thank you very much, now I'm going to start modifying the configuration.

[PhoneBoy · Accepted solution]

With the exception of SAML-based identity sources, all methods require two stages to fully acquire the users identity:

• The usernames (which you are using Identity Collector for)
• The groups the user is in (which is done through an LDAP query from the gateway)

Therefore, any gateway that is receiving information from Identity Collector must also perform an LDAP group lookup (via pdpd).
The calculated Access Role is what is shared to other gateways.

See: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_IdentityAwareness_AdminGuide...