4.3 Identity Collector

What Identity Collector Is

Identity Collector is a Windows service, installed separately from the Security Management server, that aggregates identity information from multiple sources and pushes the consolidated mappings to one or more Security Gateways. It is the recommended design whenever a deployment has more than one gateway, more than one identity source, or needs to centralize AD query load.

Identity Collector solves two problems that per-gateway AD Query creates:

1. Duplicate load on AD. With N gateways each running AD Query, every DC is queried N times. Identity Collector queries once and fans out.
2. Source breadth. AD Query alone cannot identify RADIUS-authenticated VPN users, Syslog-fed identities, or endpoints running Identity Agent. Identity Collector ingests all of these and produces one coherent feed.

Sources Identity Collector Aggregates

Identity Collector can ingest from:

• Active Directory (the same AD Query mechanism, run once centrally).
• RADIUS accounting records, typically from a VPN concentrator or remote-access server, where the accounting start/stop messages include username and framed IP.
• Syslog messages from third-party systems that emit login events in a parseable format.
• Identity Agents installed on endpoints, which report the logged-in user directly.
• Tara OTP and other supported identity providers.

Each source is configured as a "feed" inside Identity Collector. The service normalizes the entries (canonicalizing user names, resolving domains, deduplicating overlapping entries) and pushes the resulting mapping set to every gateway it is configured to serve.

Architecture

Identity Collector runs on a Windows server (it can be co-located with the Security Management server or installed on its own box). The deployment pieces are:

• Identity Collector service. The aggregation engine that pulls from configured feeds.
• Identity Collector configuration tool. The Windows UI used to add feeds, gateways, and credentials.
• Gateway-side configuration. On each gateway, Identity Awareness is enabled with Identity Collector selected as the source, and the collector's address and shared secret are configured.

The gateways receive mapping updates over an encrypted, authenticated channel. Enforcement still happens on the gateway — Identity Collector only feeds the cache. This is important: the collector is not in the data path and does not see the user traffic; it only ships identity metadata.

When to Use Identity Collector

The recommendation is straightforward:

• More than one gateway sharing the same identity domain → Identity Collector.
• Multiple identity sources (AD plus RADIUS, AD plus Syslog) → Identity Collector.
• Multi-domain forests where mappings need to be unified → Identity Collector.
• Any deployment that wants to keep DC query load off the gateways → Identity Collector.

For a single-gateway, single-domain, Windows-only environment, per-gateway AD Query is acceptable and simpler. The exam usually treats "use Identity Collector when you have multiple gateways or non-AD sources" as the rule of thumb.

Operational Behavior and Failure Modes

Mappings pushed by Identity Collector age out according to the TTL configured in the collector. If the collector service stops or loses network connectivity to the gateways:

• Existing cached mappings on the gateways remain valid until their TTL expires.
• New mappings stop arriving, so unidentified IPs gradually accumulate.
• If Captive Portal is configured as a fallback, unidentified users can still authenticate interactively, keeping policy working.
• Once the collector is restored, it resumes pushing and the gateways' caches refill.

For high availability, Identity Collector can be deployed in a redundant pair; gateways can be configured with multiple collectors and will fail over to the next reachable one.

Configuration in SmartConsole

On each gateway that should receive from the collector:

1. Enable Identity Awareness.
2. Select Identity Collector as the identity source.
3. Add the collector's IP address and the shared secret configured on the collector side.
4. Install policy.

On the collector side, add the gateway as a destination and configure the feeds. The collector validates the connection and starts pushing mappings. In SmartView logs the "User" column populates once mappings arrive.

CLI Verification

On the gateway, pdp monitor shows the identity cache and indicates which entries came from Identity Collector. pdp monitor show sources (or equivalent pdp subcommands, depending on R82 version) reports per-source counters — useful to confirm the collector feed is active and delivering mappings, not just that the cache is populated.

High Availability and Sizing

For mission-critical deployments, Identity Collector should be installed as a redundant pair. The two collectors do not actively load-share; one is primary and the other stands by. Gateways are configured with the addresses of both, and fail over to the secondary if the primary stops responding. There is no shared state between the pair — each collector independently pulls from configured feeds, so on failover the new primary simply resumes pushing its own current view of the mappings.

Sizing guidance is conservative: a single Identity Collector instance handles tens of thousands of mappings comfortably when feeds are healthy, but heavy AD forests with very high Kerberos churn or noisy Syslog sources can drive CPU up. In practice the bottleneck is rarely the collector itself; it is the upstream feed (DC query latency, Syslog rate). Monitoring the collector's queue depth and source counters is the standard operational check.

Exam Traps

• Identity Collector is not in the traffic path. It only ships metadata. The gateway still enforces identity and still holds the cache.
• Identity Collector does not replace Identity Awareness — it is a source that feeds the blade. The blade must still be enabled on the gateway.
• If the collector fails, the gateway does not immediately drop existing mappings; they age out per TTL.
• Identity Collector can aggregate Identity Agent feeds, AD Query, RADIUS, and Syslog — it is a true aggregator, not just an AD wrapper.
• A redundant Identity Collector pair does not share state; the standby rebuilds its view from its own feeds on failover.