Identity Collector integration design guidelines

[Peter_Elmer]

I created a series of training videos posted at sk179544 documenting integration guidelines for the Identity Collector in on-premises Active Directory services. 

The material is helpful to customers migrating away from AD Query due to Microsoft hardening DCOM services (see KB5004442 and sk176148). The changes rolled out by Microsoft as default from 14-June-2022 require Check Point Security Gateways using AD Query running software indicated in sk176148 or later.

The videos posted in sk179544 help achieving a more detailed understanding of identity based security and deploying a better identity centric security solution. The material enables engineers designing a security solution based on users and machines (instead of IP addresses) and making better use of resources, achieving a higher grade of resilience and scale when integrating to directory services.

You find material allowing to achieve a basic understanding of Identity Awareness in 10 minutes and acquiring detailed knowledge about AD Query and the Identity Collector. Senior engineers find guidelines given when observing the current identity security driven environment is not working as expected. 

Enjoy and I am happy getting feedback to improve the material.

greetings

pelmer

[Thomas_Eichelbu]

Hello Peter, 

very good job!
but there is one thing which comes to my mind:

it the last days we configured IA for some customers we had the following challenges:

+ often we use an FQDN like "identity.company.local" to let the IA Agent connect to.
therefor we import certificates into the Browser Authentication part in the Dashboard. Even when Browser Authentication is not really required for IA Agents right ? But this seems  the only plausible location to import a certificate for "identity.company.local" for me, right?

+ when there are multiple certificates imported on a system, MOB/IA/UserCheck, sometimes the IA Agent connects to different portals by random? mostly the IA Agents shows a fingerprint from the external portals, MOB mostly.
is this an error made by me, or a generell problem?
a customer reported this to me, after policy install some IA Agent disconnect and show the certificate of the MOB blade.

+ Last night we changed a certificate for "identity.company.local" on a medium size customer,  he was concern that hundres of users might have to manually approve the new fingerprint. we managed this with the "Distributed Configuration Tool". After a reboot or the restart of the IA Agent service the new fingerprint was loaded succesfully. 
still the question remains, what to do in large scale enviroments? we cannot expect that all user always reboot their clients, if they wake up after hibernate or something the will be prompted to approve the new fingerprint manually. A nightmare for all heldesk workers. How to overcome this?

perhaps you can also deep dive into this, since IA is a userexperience product, a smooth integration into the Windows ecosystem is a must!

best regards!

[Peter_Elmer]

Hello @Thomas_Eichelbu ,

you may want to connect to a local Check Point presales colleague to dialog about your environment in detail.

The Identity Agent connects to the multi-portal infrastructure on the gateway. This infrastructure is using controlled by the 'Browser Based Authentication Settings' but even other functions such as Gaia Web UI and Mobile Access Blade are using it. You therefore need to take a look at these settings as well. Look at the browsers certificate details to understand if the cert you see is the self-signed of Gaia UI or an imported associated with another portal. You may want to use a certificate signed by an Enterprise CA - or any other CA that you know your clients are trusting (see details here in the admin guide).

If you need further help a local Check Point colleague can organize a web meeting and we can discuss further details.

best regards

peter 

[Sorin_Gogean]

Hello,

Nice sessions Peter, thank you for that 😉.

When you have time, can you do some regarding ISE/pxGrid, as that is also used as an Identity Source in some companies .

(also some explaining the Groups and Roles, would help some, monitoring, redundancy/HA, etc...)

We implemented the IA in our environment, and challenges that we faced were related to ISE, and Groups/Roles definitions.

Ty,

[Peter_Elmer]

Hello @Sorin_Gogean ,

thanks for the feedback. 

In 2019 I documented Cisco ISE integration on this post here. I have run an Identity Based webinar for partners that is recorded here. 

The challenges you experienced are maybe best reviewed asking a Check Point colleague local to your region for help, The matching of Access Role objects are specific to environments and I can't make a general statement from here, sorry. 

best regards

peter 

[LazarusG]

Hi

Can I clarify the use-case of identity collector?

Is it correct that we can continue to use AD query so long as we have a correct major and minor OS version as per SK176148?

But it is recommended to migrate to Identity collector as its a better identity source collector that doesnt rely on WMI and can use accounts with more appropriate permissions?

Finally, If you choose to implement identity collector is it correct that this will require a phasing out/decommissioning of AD query (because they should not co-exist)?

Thanks

[Peter_Elmer]

Hello @LazarusG 

sorry for the late response - I was off for vacation.

Certainly you can continue using AD Query for learning login events, however the Identity Collector presents the recommended method for integrating to on-premises Active Directory services as explained in sk179544 - specially video #4. 

In video #5 you can see the details of the status when AD Query and ID Collector are enabled. I recommend disabling AD Query once you verified ID Collector integration is working as expected.

best regards

peter