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