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.

[Peter_Elmer]

Hello @MtxMan ,

I confirm: you need to have an object of type 'LDAP Account Unit' on your management server. 

I am happy to help - feel free asking local Check Point peers to contact our EMEA Overlay Presales Team I am part of.

greetings

pelmer

[MtxMan]

Hi @Peter_Elmer 

apologize i did not realized if you reply my question on last Tuesday. 

If AD Query no longer available, what is your suggestion if i need LDAP account as a authentication methods for user?

[Peter_Elmer]

Hello @MtxMan ,

the LDAP Account Unit is an object living independent from AD Query or ID Collector. 

best regards

peter 

[RS_Daniel]

Hello @MtxMan ,

If you had AD query enabled before, LDAP account unit should be already created on smartconsole. It is atuomatically created when you do the Identity Awareness wizard (for AD query). 

If LDAP accoun unit was deleted for some reason, just disable/enable Identity Awareness again, do the wizar for AD query, publish, disable AD query and enable Identity Collector. those are the steps we follow always we implement a new gateway and MOB/remote access work as expected. HTH

Regards

[CheckPointerXL]

Hello Peter,

i watched your great videos.

Anyway, for the migration plan is not clear to me if an identity session will be lost after we disable AD Query and if a user doesn't perform a new login.

If so, i think the migration could be potentially dangerous during business hours.

For example people connected to captive portal should lost their access i guess, it is right? 

Thank you

[Peter_Elmer]

Hello @CheckPointerXL ,

certainly you want to perform the migration in a maintenance window. Using the Captive Portal is a good idea to have a dedicated identity source available.

You may want to ask a local Check Point office for an offer of a Professional Services to help you during the migration.

best regards

peter 

[tropicanaslim]

Hi Danny,

im sorry, i still didnt understand about this statement : verify if a PDP enabled firewall gateway (cluster) is required (headquarters!)

let me translate to my customer requirement, if my customer has 6200 HA + management and then i need to buy CloudGuard Network for PDP?

Thankyou!

[Jonathan]

Hi,

Went through the entire thread and I'm still a bit confused 😕

We have two domains, we use ADQuery, we use MobileAccess for users to connect to the office VPN, and we use the TerminalServer Agents.

1. I want to make the change granularly. Can I set the ADQuery to serve only one domain, and the Collector to serve the other one simultaneously (meaning both option will be ticked in Smatconsole Gateway settings)?

2. If I understand correctly, disabling the ADQuery in the gateway settings won't affect the MobileAccess VPN users, since this mechanism uses the LDAP Account Unit object?

3. Is there anything we need to change to take care in the TerminalServer agent side or is it not relevant?

Thanks

[Peter_Elmer]

Hello @Jonathan ,

I recommend you connect with a local Sales Engineer from your area and review the project step-by-step. 

The complexity of actions taken in sequences is high and over email or community dialog I might overlook something. Therefore we have the global presales organization so you have a local colleague to brainstorm with.

In principle, AD Query and ID Collector work independent of each other. They share the common object LDAP Account Unit. Section 6 in the sk179544 is outlining, what is happening when both ID Sources are active. Mobile VPN users can work as long as the LDAP Account Unit object is configured according to your needs.

Terminal Servers present a dedicated ID Source and work according to their configuration. It is important to understand the LDAP Account Unit object settings are used here as well to authorize users once they are authenticated.

Again, best you call a local colleague to review the project step-by-step.

best regards

peter

[MarcP]

Hi Peter,

Thanks for all of the information provided, this is very helpful. I have a follow up question for you:

After having completed a migration from AD Query to Identity Collector, within the LDAP account unit definition, do we still require to have all of the Environment's Domain Controllers defined here? It seems to me that we should only require one or two DC's here as this will only query AD for users/groups and not for login details. Can you please confirm?

[Wolfgang]

@MarcP yes, you‘re right. You need only one for browsing through the ActiveDirectory, all others are for redundancy. But be aware if you use the LDAP account unit for authentication (maybe for remote access as an example) there should be more then one defined for redundancy.

[MarcP]

Perfect! Thank you Wolfgang!

[Peter_Elmer]

Hello @MarcP ,

as mentioned by @Wolfgang , multiple Active Directory Servers contain the same information and hence you may just need one. But all depends on the way the directory services is build. 

You may want to have a dialog with the relevant admin team here making sure not to miss any branch or organizational unit. You may want to ask the directory services admin team about Global Catalog (see section 9 in sk179544).

best regards

pelmer

[MarcP]

Yes, absolutely, a conversation with the AD admins is definitely worth having to ensure we have all bases covered.

Thanks Peter.

[CheckPointerXL]

i recently faced a problem where IDC joined 3 AD (all redundant) but LDAP Account unit had ony one of them... customer told me that few user randomly was not able to surf, and on pdp i saw that user was not recognized.... i fixed by alligning IDC and LDAP AU ADs

[CheckPointerXL]

Hi all,

it is confirmed that IDC does not recognize log off events?

Just to summarize, it collects same log events like AD Query, is this correct? :

from sk180227:

Version of Domain Controller	Event logs
Windows Server 2003	672, 673, 674
Windows Server 2008 and higher	4624, 4769, 4768, 4770

4624

528,540

Low

An account was successfully logged on.

4769

673

Low

A Kerberos service ticket was requested.

4768

672,676

Low

A Kerberos authentication ticket (TGT) was requested.

4770

674

Low

A Kerberos service ticket was renewed.

PS

Solved on my self:

Identity Collector is based on security events which are logged on the Domain Controller servers (events 4624, 4768, 4769 and 4770).  (sk86441)