Identity Collector is now GA

[PhoneBoy]

Check Point Identity Collector is a Windows-based application which collects information about identities and their associated IP addresses, and sends it to the Check Point Firewalls for identity enforcement. The identities are collected from the following servers:

• Microsoft Active Directory Domain Controllers.
• Cisco Identity Services Engine (ISE) Servers, versions 2.0, 2.1 and 2.2 - see sk108235.

Identity Collector Key Benefits over Standard AD Query

• Reduces the load on the Security Gateway - the agent is doing the queries instead of the Security Gateway.
• Reduces the load on the DCs - the native Windows API used consumes less resources.
• The Identity Collector requires no administrator or administrator-like permissions. Only permission required is read-only access to the domain security logs.
• One Identity Collector can serve multiple gateways, even from different CMA.

Identity Collector will be part of R80.10 GA. It can also be utilized on R77.30 and R77.20 with a hotfix that can be obtained through the TAC.

For more details: Identity Collector Technical Overview

[Raj_Khatri]

Thanks Dameon for the update.  We have been using the AD Query Agent for the past 2 years which was in EA.  Do you know if the R77.20/R77.30 standalone hotfix will be integrated into a newer jumbo take?

[PhoneBoy]

Not sure what the plan is with respect to integrating with the Jumbo Hotfix. I believe it can be applied on top of current jumbo hotfixes, but check with the TAC to confirm.

[Quinn_Yost]

About time!   I presume the hotfix is the same as required for vSec enforcer?

[Brian_Deutmeyer]

Good luck integrating IDC HF with vSEC HF... I was told it couldn't be done on 77.20... Both are integrated in 80.10...

[Magnus_Holmberg]

been using it for years now and working great, would love to see it integrated to general HFA for R77.30.

[Doeschi]

Hi Phoneboy,

thanks for the info, we've been discussing the collector on the CPX in Milan with Peter Elmer. We're acutally waiting for an additional feature for the last few years. As we'd like to replace the Client Auth Rules with Identity Based Rules (IA), we miss the opportunity to use/force strong authentication.

Ideas that came into my mind when we learned about the Identity Collector:

• Make a web-based portal on the Indentity Collector quite similar to the one on the Firewall Module for Client Auth, so the user can use SecurID Tokens to authenticate.
• The Identity Collector itself does note the quality of authentication of each identity (simple/plain auth learned from the AD, strong auth for those who used the portal on the Identity Collector). This information must be shared between all Identity Collectors.
• The Firewall Module will learn the quality of the authentication along to the identity
• In the firewall policy one can select per rule which quality of authentication is needed. (IA with plain auth/IA with strong auth)

Let me know, what you guys think about that. For me, this will be a great addition to a new great solution from Check Point.

Regards

Roger

[Magnus_Holmberg]

Hi,

the web-based portal is something we have asked R&D for the last 2 years we have been using the clients, not for strong auth but to make it easier for the linux/MAC guys. Currently they need to login to diffrente webpages depending in what country they are in.
And if we would have it on the IC server instead, then we could share the identity across the board on all CMA.
So thats something that would help very much.

Second part of agent is to understand the redundancy you get as there is really no HA, cluster etc.
Would be nice if you could get the Agents to atleast see eachother if they are up or not.

Agreeing with the strong auth as a BYOD senario would be easier to achive if the rules could demand strong auth based on 2 factor or similar on the webportal.

Regards,
Magnus

[Tzvi_Katz]

Hi Magnus,

1. For Web based portal - Why not not log to a specific PDP portal and configure Identity Sharing to share info with the enforcing gateways?

2. For Cross CMA identity Sharing - We are not about to add everything but the kitchen sink to the identity collector just to overcome the cross CMA issues but to address them in the gateway level. There is an RFE being worked to provide PDP to PDP identity sharing over REST to overcome the SIC limitations.

3. Identity agents HA - We will add to the subsequent release a view of last reported time from each client. Our best practice guideline is to use an Active-Active formation - have two agents report the same information to the PDP's.

4. Our vision for authentication enforcement is to have as part of the access role to enable to choose the selected realm and identity source, but this is something in the longer term roadmap.

Regards,

Tzvi Katz - Identity Awareness and Access Clients R&D GM

[Magnus_Holmberg]

Hi Tzvi,

1, 2: Sharing between gateways is about step number 2 or 3 that R&D always ask us to turn off.
Yes we have done sharing within CMA before between GW.
When we ask R&D about sharing between CMA they say ok its possible but hard to do and not recommended with the amount of users/objects we have.

If you can cross share between domains with high number of users we would love to do that.
Second part why we would like it in the IC is that then we could possible have it from multiple domains as we recently was bought by another ISP and it will take years before all is integrated fully.

3: Sure but one comment i know we and other customers have had is the issue on seeing if it stops or not, it has been solved with monitoring on server side ofc.
But it would be nice to get a logentry saying: "lost identity collector" or similar. in the log.

4: Sure thing.

But we will submit and RFC and then you guys can check if multiple customers wants the same to be added.
Just because checkpoint want you to do in a specific way its not always the way that the customers wants to have it.We see it as a great benefit if we can get all IA from one source and connect the citrix, portal etc to the agent as well.

/Magnus

[Brian_Deutmeyer]

In regards to sharing between CMAs, I just set up a PDP for each CMA and had the IDC send identities to each PDP.  Those PDPs can then share the identities with all the gateways in each respective domain.

So if you have 2 domains, each domain will have its own PDP and the IDC will send the same identities to both PDPs to be shared.

[Tzvi_Katz]

Hi Roger,

Please find the answer I had provided Magnus om the same thread.

Essentially there is no need for a portal on the Identity Collector for that, but to enhance the gateway/management side.

Currently the Identity Awareness captive portal do support SecurID as a matter of fact.

As I had answered Roger we have a product vision to extend the authentication scheme to a unified one (see remote access client multi login options) to all of Check Point components are enforce the login option as part of the access role.

[Doeschi]

Hi Tzvi,

First, thank you for the answer. Well, using the Identity Awareness Captive Portal doesn't solve the problem sharing the Identity over Cross CMA as well as handling multiple domains. Thus, it'll reduce the load on the gateways, if there's a possibility to "outsource" that feature to a system like the IC.

To my opinion, Magnus and I share the same idea of having 1 system (with possible HA solution) to collect the identities as well as the "used" authentication method and share it with all gateways independently of their Management Systems / Domains. Along with extending the IA access role with the auth scheme as you already "visioned", the solution would be perfect and a great benefit for all IA users.

Regards

Roger

[Dor_Marcovitch]

can we use the identity collector to aggregate identities from the terminal server's MUH agent for multiple gateways?

[Doeschi]

Hi Dor,

This is a good idea and goes along the ideas we raised a year ago. It would be great, if the identity collector would be the "single point of contact" regarding identities used for authorization within Check Point products. To achieve this, the identity collector should be capable to collect the identities from the AD and the ISE (as it works now) but also from the IA Agents and the MUH agents. And, it should also make a difference of people with weak authentication (like username / password on windows logon) and people with priviledged access that has to use strong authentication (2-factor auth) and mark the identities accordingly. Then on the security gateway the firewall admin can decide per rule, if no auth, weak auth or strong auth is needed to match the rule.

Regards

Roger

[PhoneBoy]

As far as I know, not currently, though it sounds like a good idea.

Tzvi Katz‌, maybe something to consider?

[Tzvi_Katz]

Hi Dameon, 

The identity collector purpose is to collect identities from external sources. The PDP should be the source of the logic. 

So what Roger had essentially requested is to add to an access role the capability to specify the identity source or the realm used for authentication. 

[Doeschi]

Hi Tzvi,

As the PDP is a part of a single management domain, this isn't a wise chose for the "brain", as there are always issues by synchronising the knowledge about the idnetities between the different PDPs. In my opinion, to offload that knowledge to the IDC makes it easier for everything, since nothing has to be shared anymore, all PDPs can always ask the IDC independently.

I understand that this would be a major design change of how to threat the identities, but the gain would be immense.

Tzvi Katz schrieb:

So what Roger had essentially requested is to add to an access role the capability to specify the identity source or the realm used for authentication. 

And no, you didn't really get the point...

[Tzvi_Katz]

Hi Dor, 

The PDP can perform the identity sharing of MUH sessions, no need for the IDC to own such capability. 

[Dor_Marcovitch]

why not consolidating the "collection role" of identities from external resources to one entity (IDC) instead of using identity sharing between all the FWs ?

then you can also change the update channel of identities from the FW to the IDC.. than you will get some kind of a Star topology for the identity sharing process and if you add the ability to have 2 different servers as the IDC you get even

 more redundancy (IDC installed on a VM server which can be redundant on multiple physical servers on multiple datacenters) 

[Doeschi]

Not to mention the offload of the https sessions from the IA Agents to the IDC instead to the already busy firewalls in a large scale deployment. Thus identity sharing with the need of that ridiculous hide-nat configuration could be fully replaced by IDC... and even cross-CMA.

[Magnus-Holmberg]

One of the biggest reason for IDC was to offload the GW of heavy loads when u do have alot of identity's.
The reason why we got involved in the R&D project for the AD query agent was just because of the GW cant handle all the requests when u have a large number of users and identitys/groups.

Adding sharing between GW increases the load of the GW but it also need to do something that it wasn´t really designed for. the GW should handle alot of traffic and run that thru alot of security features.
I believe this request is similar to why Check Point prefer to have the MGMT on a seperate box from the GW. 

I also think this match good with the M releases to be able to develop feature faster and release it without rebuilding or adding complexity to the GW code that is the most sensitive and need the most testing before releases.
Then u can add features and still only use one way to communicate to the GW for updating identitys and groups.

Checkpoint customers are used to need to split up the environment on several boxes, like MGMT, LOG, EVENT and GW.

[Tzvi_Katz]

As a concept the PDP is the one who should share the information to to rest of the enforcement points (PEP) who perform the heavy lifting of "handle alot of traffic and run that thru alot of security features.". In case your environment is loaded in a manner no gateway can be nominated as a PDP, this is the time to use a dedicated one. 

The IDC collect and partially parse login events, the PDP in his turn perform the user LDAP resolution, collect the user groups association and performs the access role calculation, all of this information is not available for the IDC and not designed to. 

[Maxim_Mogorean]

Would be of much use if the Collector had a possibility to filter Windows Logon Event by their Type. For example to exclude events of connection to shared folder, scheduled task or service startup.

By the way, does Checkpoint has this in plans for the Collector?

[Dor_Marcovitch]

it can be really useful it is a pain with all vendor they only look on "its an authentication event" and do not care about the type, it causes a lot of pain at customers when a user performs an RDP session with a different user, the mapping for the local computer is changed to the remote user he used to login although from the "type" of the authentication log one can understand it is being used for RDP session. regarding the SMB it is something that is needs to stay but maybe if you can somehow exclude some of the settings. remember a user is doing windows logon event maybe 1-2 time a day. all other security events are the one that keeps the user-ip mapping "alive"/"updated" unless you extend the time period of the mapping which can cause a security issues on some point of views.

[Royi_Priov]

Hi Maxim,

Filtering login events by type - I guess you are referring to the logon types of event 4624?

By default, we are dropping event 4624 type 10 (see here) from association database in IDC as it is for RDP.

However, other scenarios such as the mentioned SMB don't have proper evidence on the AD, but on the endpoint machine only. I personally think that forwarding events from all client PCs to the AD is not a reasonable solution for customers to avoid this scenario.

Thanks,

Royi Priov.

[Maxim_Mogorean]

Hi Royi,

Yes 4624. Having the possibility to exclude type 3 would make the mapping of a user to an IP address non-flapping in cases when multiple users are logged in to the same PC (User PC, not Terminal Server). Thus active user's mapping would not flap to an inactive one.

[Royi_Priov]

Hi Maxim,

Dropping type 3 is possible.

However, please make sure that the scenario you are describing indeed produce event 4624 type 3 on your AD.

As far as I remember on my environments I didn't get type 3 but type 2.

If you are getting type 3 and wants to add this possibility, you are welcome to contact your local office and process an RFE.

Thanks,

Royi Priov