Showing results for 
Search instead for 
Did you mean: 
Create a Post

Best Practices for Identity Collector Architecture

Is there a "best practices" doc available that gives coverage of proper IDC architecture, specifically in VSX environment with multiple VS running IDA? Should IDC agents be configured with each IDA enabled VS as a gateway (IDC agent side)? Should only VS0 run IDA and share out the database to each VS? I'm having a difficult time finding the best way to implement this IDC on VSX in regard to reliability first, redundancy second, and performance third.



11 Replies

Re: Best Practices for Identity Collector Architecture

I've been waiting for an IDC best practices document since it was in EA.   Someday...

0 Kudos

Re: Best Practices for Identity Collector Architecture

You'd think Identity Collector would be mentioned here: Best Practices - Identity Awareness Large Scale Deployment 

I submitted some feedback in the above SK.

Hopefully this is something we can address in the near future.

0 Kudos

Re: Best Practices for Identity Collector Architecture

6 months later, no sign of IDC in the SK: Best Practices - Identity Awareness Large Scale Deployment

Do we have any thoughts on when the SK may be updated?



Re: Best Practices for Identity Collector Architecture


sk88520 covers Identity Collector as well. Essentially IDC should be treated as any other identity source, one (or more) PDP should be defined and the rest of the enforcement points should get the information using identity sharing. 

Re: Best Practices for Identity Collector Architecture

Is there any limitations with the # of IA collectors and sharing across gateways?

We have a rollout at my company where 9 of the 10 clusters have local AD servers.    Our windows team had concerns with AD load and hence why we went with IA collectors verse AD Query.

In order to be as redundant as possible, we attempted the following:

  • Each of the 9 sites have 2 local IA collectors connected to its local AD servers only 
  • Each of the 9 sites shares (or attempts to) with the other locations
  • The 10th site has no AD servers locally so it connects to one of our datacenter's IA collectors (both IA servers).
  • The 10th site accepts shares from other gateways but does not share themselves
    • Since its collecting from the same IA as the DataCenter GW, that DC GW is already sharing.

What we are getting is a whole mix of users that seem to collect fine locally but simply do not share across all other GWs.


2 locations run clustered 13500 appliances

6 locations are 4800 clustered appliances

1 location (the one with no AD servers) is a 5800 cluster.


When looking that the "best practices' docs for IA, it doesn't seem clear to me on what method would be best for reduced load, efficiency and most importantly....redundancy.


  • Has anyone had similar issues with this type of rollout?  
    • What did you do to get it to work?
  • What are the # of redundant IA collectors you can deploy to one gateway?
    • Can you do more than 2?
  • What is less on resource load and bandwidth:   
    • Deploying 2 (or more )IA collectors in 2 different DCs (redundancy) that collect logs from EVERY AD server across the enterprise; have every GW collect from these IA servers and do not share identities
    • Deploying 2 (or more )IA collectors in 2 different DCs (redundancy) that collect logs from EVERY AD server across the enterprise; have only the DC GWs connect to the IA collectors and share identities with all other GWs
      • In this event, would I need to deny sharing between the DCs since they are collecting the same logs?
      • Is there any issue with the remote GWs since they would see the same sharing info from both DC GWs?




0 Kudos

Re: Best Practices for Identity Collector Architecture

Additional info:
Management server: R80.20 JHF take 47
GW: All are R80.10 JHF take 189
0 Kudos

Re: Best Practices for Identity Collector Architecture

I too would like to get better understanding of IA in general and IDC use cases in particular.

It does not look like we can use IDC for Identity Logging, which still relies on the high privilege account with AD query.

Would be nice to remove AD Account Units from the picture and rely on IDCs for that as well. 

0 Kudos

Re: Best Practices for Identity Collector Architecture

There are 2 problems with Identity Sharing:

1. Identity Sharing via VPN can cause IPSec Replay Attacks by clusters standby member

2. Identity Sharing between gateways managed by different domains of a MDM is a pain


That's why if only IDC is involved, I tend to configure each gateway to receive the events individually.

But with other identity sources like TSagent, RemoteAccess this is not possible, as they are not shared then.



0 Kudos

Re: Best Practices for Identity Collector Architecture


Luckly, neither of the 2 problems you have defined would affect us. I ended up changing the topology last night for 2 clusters (2 separate data centers) connected to the same IDCs (one in each DC) and then sharing with the other gateways.

Looks ok so far but will need to test further as old user sessions start to age out.

I was thinking of having each GW just all connect to the same 2 IDCs but I know that a terminal agent for citrix is in our future and i might have to use the user agents for our MAC OS clients here.

Captive portal is something we wanted to avoid since we already have one for forcepoint in play today.
0 Kudos

Re: Best Practices for Identity Collector Architecture

Quick update:

The IA collectors at 2 DCs and then sharing to other gateways has been working great!    We gotten a few access roles deployed and so far its working as we imagined.

For the MAC issue, this is really due to MAC OS.     With any MAC OSX joined to AD, the MAC is not 'site aware' and therefore we were getting auths sent to DCs that we were 1) not monitoring with the collector and 2) really didn't want them going randomly cross site.

The temp fix was to set a prefered AD server in the Active Directory config on the MAC.   That has consistantly gotten the login but have to sometimes 'force' the update with "kinit" via terminal.

Long term (outside of using the machine agent from Checkpoint), we have been testing NOMAD with the MACs.   NOMAD is site aware and our initial testing gets the MAC as close to windows in regards to AD.


One item did come up that caught us offguard:   2 of DCs we are collecting from stopped connecting.   Its for a sister company of ours and think something changes on a config or patch.    Regardless, my question is:   how do you monitor this type of event on the Identity Collector itself?  

I've seen post on custom querries to the gateways to detect when they stop getting feeds from the collector itself.   I've also seen the updated SK (sk108235) on the monitoring capabilities via SNMP to R80.20 gateways for the collector status.


I simply can't find in any searches or admin guides on how to monitor issues on the IA collector itself in regards to its "identity sources" status. 

Does anyone know how to detect such an event?

Lastly, during my search, I see that there is a newer collector out (sk134312).   We are currently running 80.72.0000  and I'd like to plan to upgrade it......but can't seem to find any docs on how to upgrade 🙂     Plenty on install but nothing on upgrading a existing collector.

  • Do you export the config, delete the agent and reinstall?
    • Any changes needed to resynch with the gateways, its identity sources, etc?
  • Does it support a direct upgrade when running the new MSI package?
    • Does the configs stay in a 'in place' upgrade? 



0 Kudos

Re: Best Practices for Identity Collector Architecture

Anyone have any advise or reference documentation on how to upgrade an existing IA Collector MSI?

I still can't find any notes on checkmates or within support center.    


Thanks in advance 🙂 

0 Kudos