Move from Identity Awareness AD Query to ID Collector now

[Danny]

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.

[D_W]

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?

[skandshus]

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

[MikeB]

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

[Chris_Atkinson]

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).

[Paul_Hagyard]

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.

[Peter_Elmer]

Hello @Paul_Hagyard 

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

greetings

pelmer

[AviG]

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.

[Paul_Hagyard]

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.

[Peter_Elmer · Accepted solution]

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. 

[JuPo]

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

[JuPo]

You can ignore my second question.

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

[Peter_Elmer]

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

[skandshus]

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..

[Peter_Elmer]

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

[Paul_Hagyard]

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.

[FGA_Sys_And_Net]

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?

[skandshus]

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..

[Scottc98]

Whats the workaround for bridge mode only deployments?  (https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...)

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?

[Peter_Elmer]

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 

[Linus]

Hello @Peter_Elmer 

so with those hotfixes applied AD Query will still work even after the full changes from Microsoft are deployed in March 2023 ?

[Peter_Elmer]

Hello @Linus ,

please watch sk176148 for updates - here R&D will document the details that will be relevant by the time the HFs are released. 

best regards

peter 

[skandshus]

This is confusing. earlier you stated that the SK was updated to reflect, but now you say we should watch for updates.

Can we get a confirmation that it WILL work with the microsoft Dcom implementation or not?

when i look at the SK it only shows it was created with a certain date, but no edit/recreation date stamp. so im unsure if you have actually done anything in that sk or not 🙂

Date Created

01-nov.-2021

[Peter_Elmer]

Hello @skandshus 

here is what I am referring to - extract from sk176148:

To apply the Microsoft hardening and continue using AD Query and Identity Logging, you must install a hotfix. The hotfix is included in:

• Jumbo Hotfix Accumulator for R81 starting from Take 60
• Jumbo Hotfix Accumulator for R80.20 starting from Take 208

Check Point is working to integrate the solution into Jumbo Hotfix Accumulators for other versions. This article will be updated when more details are available.

best regards

peter

[Peter_Elmer]

I posted a series of training videos in this context about ID Collector and Identity Awareness at sk179544 and referenced in this post.

[MtxMan]

Hi @Danny 

Thanks for you sharing. But i have some initial question :

1. currently i have customer still on AD Query, and i just offer them shift to ID Collector. but my question is, with ID Collector can i still use AD users for authentication on Mobile Access? because i dont get specific information about that.
2. you said "Identity Collector and AD Query should not be used together as they collect from the same identity source.", because im still worried about my first question, so i will try both to collect identity to proven to the customer. Do you have an idea?
3. In your pdf, i quote some information : "Check Point also authenticates users against external stores, such as RADIUS, SecurID, LDAP and TACACS", beside that is there any identity source i can used for authentication on Mobile Access?

Thanks!

[Peter_Elmer]

Hello @MtxMan ,

in regards to using ID Collector in addition to AD Query you may want reviewing this video stored at sk179544. Here you see CLI commands allowing you monitoring the identity sessions. I suggest getting familiar monitoring ID sessions in your environments to get a better understanding, which event is leading to which change in the ID session table. 

In the context of users connecting to the HTTPS Portal on the gateway (Mobile Access Blade) you may want to explore options documented in the admin guide here. The option 'username and password' allows integration to directory services defined in the LDAP Account Unit object. The LDAP Account Unit object is holding information instructing the gateway raising queries in LDAP or LDAPs against one or more Active Directory logon servers. The gateway will take the username and password entered by the user authenticating on the HTTPS portal and raise a query against the AD Server if this user is a) known, b) having the right password and c) understanding the groups she or he belongs to.

I admit that this is a complex configuration and I yet had no time creating step-by-step configuration videos, but have this on my list.

best regards

pelmer

[MtxMan]

Hi @Peter_Elmer 

Thank you for replying with resourceful information.

No problem for me if it's a complex configuration as long as we can confirm that ID Collector can used as querying AD information for Mobile Access. Thanks!

[Peter_Elmer]

Hello @MtxMan ,

the ID Collector is listening to login events reported by an MS AD Server via Security Events API. If a user logs on to the MAB portal there is no login event to MS AD Server. The ID Collector is working in conjunction with the LDAP Account Unit you need to have on your management server. 

When using AD Query you execute a configuration to create the object LDAP Account Unit. This is the key object here: this object holds instructions the gateway needs to authenticate the user logging on to the MAB Portal. 

You can always contact a Check Point Sales Engineer local to you asking for project specific help - feel free reaching out to the colleagues - we are all here to help.

greetings

peter 

[MtxMan]

Hi @Peter_Elmer 

well noted, it's mean we need "LDAP Account Unit" to authenticate user via MAB portal right? so based on your information, i think using AD Query is the best choice right now for my use case.

Thank you Peter, maybe if i have an issue in the future i will asked the local team via distributors or throw a question over here. 😁