topic Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW! in Firewall and Security Management

Move from Identity Awareness AD Query to ID Collector now

Danny — Tue, 15 Feb 2022 12:37:01 GMT

Microsoft further hardens Windows and enforces it's DCOM security feature in response to CVE-2021-26414. On June 14, 2022, Microsoft will go into the second stage of hardering DCOM, and the mentioned change may interfere with your current AD Query implementation. More details about this can be found in sk176148.

While Check Point R&D is apparently working to overcome this issue, now it is a good time to consider moving from AD Query to Identity Collector implementation.

This has been discussed before. I'll focus on Check Point Best Practices and Solutions.

(PDF) Identity Awareness: Reference Architecture & Best Practices
- recommends ID Collector because of security (requires low privileged account only, while AD query requires a high privileged account)
- recommends ID Collector because it's better suited for low, medium and large scale deployments (the use case for AD query is small deployments only)
- recommends ID Collector because it's low resource use (AD query has high resource use)
- recommends ID Collector because it's realtime identity assurance
- recommends ID Collector for company's headquarters together with a dedicated PDP enabled firewall that shares to a PEP enabled perimeter firewall (reminder: AD query is only recommended for small deployments, so it's not intended for headquarters)
  - Reference architecture for external perimeter (PDP Broker > Getting Started)
  - Reference architecture for external perimeter using Maestro (Design Guideline)
(sk108235) ID Collector - Technical Overview
(Admin Guide)
- ID Collector
- Configuration
- Installation
- Optimization
(sk176148) Check Point response to CVE-2021-26414 recommends Identity Collector as the identity source instead of AD Query.

Ready to go?

verify your current AD Query configuration
- Tools: SmartConsole
verify the types and numbers of identities in your network
- Tools: SmartConsole, cpview, SmartEvent
verify where to install the ID Collector
- dedicated Windows server or directly on your AD
verify the required redundancy, create multiple ID Collectors
verify if a PDP enabled firewall gateway (cluster) is required (headquarters!)
- don't worry, you don't need to buy new CP appliances, just create a pair of vHosts within your VMware ESXi infrastructure and buy 4x 1 CloudGuard Network virtual core for VMware ESXi (2x vCores * 2x vHost)

Reminder: Identity Collector and AD Query should not be used together as they collect from the same identity source. AD Query and Identity Collector conflict and should not be used as the identity connector for the same gateway. Events may arrive out of sync and the same event may be observed multiple times, leading to unpredictable results.

Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW!

D_W — Mon, 14 Feb 2022 22:03:39 GMT

Thank you for the reminder! We're already thinking about switching to the ID collector architecture since months.
Atm we use AD Query on all of our sites. Some are smaller (10-200 users), some are bigger (200-2000 users) and most of them have a local DC.
According your post only solution is now to install ID collector on each site - bigger/more important sites will become a redundancy IDCollector. Question for me here - is it a good option to also roll out the identity agent? We never used it before but sometimes have issues when users very quickly change their work space. Any recommendations for this?

Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW!

skandshus — Mon, 14 Feb 2022 22:42:59 GMT

Nice.. a feature we bought into “ad query” is eol.. but we can buy a VMware core license if we need psp 🙂

Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW!

MikeB — Tue, 15 Feb 2022 00:23:36 GMT

thanks for the information! What options does Check Point recommend for Quantum Spark (Gaia Embedded) that do not require purchasing additional licenses??

Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW!

Chris_Atkinson — Tue, 15 Feb 2022 01:34:57 GMT

This ("Quantum Spark" working with Identity Collector) should be address with the upcoming R81.X alignment, stay tuned for the EA (or enquire with your local SE).

Re: Move from Identity Awareness AD Query to ID Collector now

Peter_Elmer — Tue, 15 Feb 2022 13:31:57 GMT

Some more background:

latest security needs have driven Microsoft to harden the WMI protocol used by AD Query
I strongly encourage reading carefully the KB5004442 and sk176148
ID Collector only requires an Active Directory user account with Event Log Reader rights (see sk108235)
AD Query (sk60301) requires Domain Administrator privileges (see sk93983 for using a non-domain admin account)

These are the most important reasons why now is a good time to move from AD Query to Identity Collector. In addition Check Point introduced Identity Conciliation (sk146835) since R80.40. Customers should upgrade to the recommended software release and GA Jumbo HF (see sk95746 for details) in order to benefit from Identity Conciliation allowing the PDP and PEP processes making a precise decision how to handle login events learned from different identity sources that are related to the same IP address.

In the context of a migration project customers should review Identity Session Sharing (sk149255) and plan the project in details.

Check Point Partners may want to review background about Identity Awareness documented in this CheckMates webinar.

Re: Move from Identity Awareness AD Query to ID Collector now

JuPo — Thu, 24 Feb 2022 16:20:20 GMT

Hi @Peter_Elmer,

in you presentation from the CheckMates webinar you say that "All Logon Servers inside a fully trusted domain are sharing login events". Is this really true? I discussed this with our AD experts and they don`t share this opinion (in terms of event logs). Could you please give us more details on how to understand this?

My other question is regarding DCOM security feature and the Identity Collector communication with DC. What is the difference in communication (and event log reading) between AD query and Identity Collector. As mention in the documentation, both methods use DCOM/RPC and read event logs (security logs) from the DC. How comes that AD query is affected by the DCOM hardening and Identity collector is not?

And my last question is - why is the Identity session conciliation mechanism kind of a "secret" 😁? From the sk146835 and the IDA documentation we know, that there is a Confidence, but it is not clear what confidence has which identity source. There are few examples in the SK which are totally insufficient to understand this correctly. As an example -> Kerberos vs Identity collector. Which has higher confidence?

Thank you

Juraj

Re: Move from Identity Awareness AD Query to ID Collector now

JuPo — Thu, 24 Feb 2022 16:35:46 GMT

You can ignore my second question.

AD query uses WMI.
Identity collector uses Windows Event Log API.

Re: Move from Identity Awareness AD Query to ID Collector now

Peter_Elmer — Thu, 24 Feb 2022 18:56:18 GMT

Hello @JuPo,

thanks for your feedback.

Prior to creating the material in 2019 I worked with several large enterprise customers investigating their IDA integration. I interviewed AD admin teams and back then, it was a consistent pattern that AD Servers have been configured to share login events inside trusted AD domain structures. I consulted with R&D and created the ppt material.

Certainly this may be different today and different in your environment.

Back then it was a common issue, that multiple gateways learned login events twice (or more often):

from AD servers using the PDP process configured to learn login events from a 'close by' AD Server
via ID Sharing form PDP to PEP (back then ID sharing was enabled by default)

In detail:

Back then I observed AD servers shared login events among themselves and PDP instances learning login events from an AD Server 'close by'. Once a login event is learned by the PDP instance it generates an ID Session.

Back then, each gateway was most often configured for PDP and PEP. When PDP and PEP are running on the same gateways, each ID Session is immediately propagated to the PEP instance. The PEP instance enforces the security based on the ID Session. ID Session can - and should be - shared with PEP instances running on other (remote) gateways. The PDP work is 'kind of heavy lifting' and you want to 'save resources where you can'. Hence an ID Session sharing architecture is key to the success of any identity based network (see sk170756 and sk175587.

Let's say for example gw1 has learned a login event from a 'close by AD Server. Gw1 is configured to share ID sessions with gw2. PEPgw2 learns a login event from PDPgw1 via ID Sharing but on the same gw2 a PDP is running and this PDP process learns the same login event from a 'close by' AD server: the same event is learned twice. Back then, there was not ID Conciliation functionality to control this sequence of events and as a result the gateway PEP instances was instructed from multiple PDP instances to add/remove/add ID sessions for the same login event.

Back in the days prior creating the ppt you are referring too, I observed time delays of the login event propagation. I observed with AD Query latency: I observed the AD server is 'quicker' writing the Event log message and publishing it via Microsoft API 'event log' than publishing it via WMI infrastructure that is using the IIS web instance. I observed it takes 'more time' for a PDP to learn 'alice has logged on' using AD Query than using ID Collector.

The ID Session Conciliation functionality is documented to introduce 'now the gateway can handle multiple login events coming from multiple sources related to the same IP address'. This wasn't possible before release R80.40. The default capabilities are shaped after consulting with many customers and investigating many different scenarios.

The ID Session Conciliation allows PDP and PEP instances managing multiple login events from multiple sources related to the same source IP Address. You can use the pdp conciliation command to modify it. In case your scenario is not achieved by the current settings you consult with Check Point support as indicated in sk146835 in order to have your gateways configured to achieve what you need.

I am myself not changing the defaults - other then by the CLI commands. I respect TAC and R&D guiding relevant configuration changes. They are complex and each scenario should be consulted with TAC.

Certainly I am happy to learn details about your environment and you can organize a meeting to discuss contacting your local Check Point contact. My calendar is open to all colleagues and they know, they can book a meeting according free slots.

best regards

pelmer

Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW!

Paul_Hagyard — Thu, 24 Feb 2022 20:36:51 GMT

The R81.20 EA announcement (https://community.checkpoint.com/t5/Product-Announcements/R81-20-EA-Program-Production/ba-p/135926) says "Identity Collector is now supported with Quantum Spark Appliances." but provides no further clarification. Can the new R81.20-aligned Identity Collector agent be used with older management and gateway versions (R80.40/R81)? What SMB devices will be supported? We have many customers with SMB boxes that only support R77.20.x, not R80.20.x.

Re: Move from Identity Awareness AD Query to ID Collector now

skandshus — Thu, 24 Feb 2022 21:31:21 GMT

I am still totally confused. And checkpoint guide/sk does not help much.. I’m seeing the DCOM issue on my server 2022.. how am I supposed to authenticate my remote access users (vpn) with their ad credentials? Can anybody share some insights and maybe a print screen on an example of a policy allowing this?? I got identity collector working.. picking up info from active directory and sending to gateway.. but I am REALLY confused on how this is supposed to work if I remove the ldap/ad query from the gateway, because that Will result in having 0 options in adsing users ti my access role, because I ain’t have a “directory” to search for users in smart console..

Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW!

Peter_Elmer — Fri, 25 Feb 2022 07:54:47 GMT

Hello @Paul_Hagyard

I will forward your question to the relevant R&D team.

greetings

pelmer

Re: Move from Identity Awareness AD Query to ID Collector now

Peter_Elmer — Fri, 25 Feb 2022 08:44:21 GMT

Hello @skandshus ,

you may want to call your local Check Point contact in order to get direct help on your project. Here some indications:

Follow instructions given by Microsoft here. Note the time allowing customer using the less secure method of DCOM has been moved to 14-March-2023
Monitor sk176148 to get informed about the progress Check Point R&D documents for creating a solution allowing AD Query to support the more secure of DCOM

Now about remote access users authenticating and authorizing against an on-premises Active Directory

Create a diagram allowing you to see the communication path and all network components securing the traffic from VPN Client computer towards application. It is imperative identifying all components 'along the way authentication traffic uses' in order to troubleshoot the environment.
Review Remote Access Guide and Management Admin Guide sections about LDAP integration
I created step-by-step videos for SAML based authentication for VPN Clients (sorry, I haven't videos for on-prem AD) but you can see the configuration of an authentication realm.
The authentication realm is holding the descriptions of the systems (AD Servers) representing the authentication and authorization infrastructure - you don't remove any LDAP related configuration from the gateway!!
You add ID Collector to the gateway allowing it to learn the login event of the user towards the AD server. This event an only occur if the VPN client has established connectivity

I acknowledge that this is complex and encourage you to work with a local Check Point representative on this project.

-pelmer

Re: Move from Identity Awareness AD Query to ID Collector now

FGA_Sys_And_Net — Fri, 25 Feb 2022 09:14:17 GMT

Hello,

We have migrated to Identity Collector to retrieve IPs/Users associations. It works correctly.
However, it seems that other features use the DCOM interface of the DCs:

LDAP Account Unit
- CRL retrieval
- User Management
- Active Directory Query (migrated to IDC)

This is used to identify VPN users and rules based on Access Role.

What can be done?

Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW!

AviG — Sun, 27 Feb 2022 07:49:47 GMT

Since Management Server R81.20, the ID Collector can be configured for (centrally managed) 1500/1600/1800 GWs. It is supposed on those GWs since R80.20.35.

As for a fix for AD Query which will support the new "Hardened" mode, we are working to add a fix into R81.10, R80.20.35 and R77.20.87 releases over the coming weeks.

Re: Move from Identity Awareness AD Query to ID Collector now

Paul_Hagyard — Sun, 27 Feb 2022 22:20:50 GMT

The DCOM security hardening will affect AD Query because it uses WMI to collect events from the Windows security event log. VPN RAS authentication will use whatever authentication mechanism is specified for the gateway (e.g. RADIUS, LDAP etc). I'm not aware of DCOM hardening in any way affecting LDAP. Alternately, if you have an Azure AD deployment you can use SAML integration and achieve MFA.

Re: Identity Awareness > AD Query EOL Q2/2022 > Switch to ID Collector NOW!

Paul_Hagyard — Sun, 27 Feb 2022 22:23:35 GMT

With R81 the current recommended version it would be reasonable to expect that issues with AD Query would be fixed in that first. While it's reasonable to expect customers to upgrade (e.g. from R80.40) to the recommended version for a new fix, expecting them to upgrade to a version that is not the recommended release isn't.

Re: Move from Identity Awareness AD Query to ID Collector now

skandshus — Tue, 01 Mar 2022 21:56:45 GMT

CORRECT!
I also see the DCOM error when using LDAP Integration for authenticating users on the remote access blade using their active directory identity.. so thats a "no go" apparantly..

Re: Move from Identity Awareness AD Query to ID Collector now

Scottc98 — Thu, 24 Mar 2022 22:53:30 GMT

Whats the workaround for bridge mode only deployments? (https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk101371&partition=Advanced&product=Quantum)

Seems like AD query is the only supported method today. Anyone know if IA collector or any other methods are possible today or in near future releases?

Re: Move from Identity Awareness AD Query to ID Collector now

Peter_Elmer — Fri, 25 Mar 2022 14:40:56 GMT

Hello @Scottc98 ,

note that sk176148 was updated to reflect the new dates given by Microsoft. In addition Hotfixes for R81 and R80.20 have been released allowing to continue the use of AD Query even with the Microsoft hardening activated. HFs for other releases are work in progress as documented in the sk.

For your customers environment you may want to contact your local Check Point Sales Engineering reference and look at the overall design to explore options.

best regards

pelmer