I85PREP
⌘ K
CCSA R82 study materials
CCSA R82 study resources

Identity Awareness Behind a Proxy

CCSA R82 · Put your knowledge to work in context.

All case studies

Identity Awareness Behind a Proxy

An R82 Security Gateway enforces Identity Awareness using AD Query plus Identity Agent on 800 workstations. Users in 10.20.0.0/16 reach the internet through an explicit HTTP/HTTPS proxy at 10.20.0.250; the gateway sees only the proxy IP as the source for all web traffic. The rule base has an Access Role 'Finance' permitted to a SaaS application, and a rule blocking social media for everyone else. Finance users report they are blocked from the SaaS app, and the logs show source=10.20.0.250 with no identity. The proxy supports X-Forwarded-For but it is not enabled. AD Query is healthy and shows users logged in.

1. Explain why Identity Awareness cannot resolve users in this topology and identify the two viable remedies.

Read the worked answer

AD Query and Identity Agent map IP address to user. When all traffic is proxied, the gateway sees the proxy's IP (10.20.0.250) as the source, so the identity lookup returns either no user or the proxy machine account. The real client IP is hidden inside the HTTP header.

Two remedies:

  1. Identity Agent on the proxy / Identity Collector: install Identity Agent on the proxy or use Identity Collector so the proxy's own identity mapping is populated per user session. This requires the proxy to report user identity to the gateway.
  2. X-Forwarded-For parsing: enable XFF on the proxy and configure the gateway to trust the proxy as an identity source (Identity Awareness blade supports XFF for HTTP/HTTPS when the proxy is defined as a trusted source). The gateway then extracts the client IP from the header and resolves identity from that IP.

Without either, the Access Role 'Finance' can never match because there is no user identity attached to the connection.

2. Assuming XFF is enabled, what must be true about the proxy object and the rule base for the Finance rule to match, and how would you test it?

Read the worked answer

Requirements:

  • The proxy must be defined as a trusted proxy / identity source in the Identity Awareness configuration; otherwise XFF headers are ignored to prevent spoofing.
  • The proxy must insert XFF on the client-to-proxy leg and forward it to the gateway, and the gateway must be the first hop after the proxy (no additional NAT that rewrites the client IP again).
  • The Finance Access Role must be based on the AD group, and the user must be a member; the rule must be above the social-media block rule.

Test:

  • From a Finance workstation, hit the SaaS app; check the log - the source should show the client IP (or the resolved user), not 10.20.0.250.
  • Use pep show pdp all / pdp diagnostics to confirm the user is resolved.
  • Temporarily add a log rule above the block rule to see the matched identity; if identity is still the proxy, XFF is not being accepted.