cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question

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.

Thanks,

Josh

9 Replies
Quinn_Yost
Nickel

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

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
Matt_Taber
Nickel

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?

Thanks

Employee+
Employee+

Re: Best Practices for Identity Collector Architecture

Hello, 

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.

Notes:

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.

Questions:

  • 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
Vladimir
Pearl

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

Norbert,

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