Users can only browse when we allow unauthenticated access from the Squid proxy's IP address. We temporarily changed the workstation to explicitly use the Check Point security gateway's proxy interface, navigated to https://fwcp1.lair.co.za/connect, authenticated and thereafter changed the proxy settings back to using Squid. Reviewing log entries shows the security gateway correctly identifying the IP of the workstation behind the Squid proxy but the IP is not associated with the authenticated user for that IP:

Re: Identity Awareness not matching users behind proxy

In my experience using caching proxies these days causes more issues than it solves. Website contents have become so dynamic that caching website contents brings you much less than in the early days of the internet with static websites.

Re: Identity Awareness not matching users behind proxy

We are based in South Africa and subsequently suffer from 160ms latency to Europe and 270ms latency to the USA. Using caching proxies when deploying Linux systems massively reduces deployment times so we wish to continue using them.

PS: User LAN and WiFi traffic wouldn't be channeled through the caching proxies, which in turn direct their requests via the security gateway's proxy.

Re: Identity Awareness not matching users behind proxy

We actually already use FreeRADIUS to authenticate support staff to AD using security group memberships, to return relevant authorisation tokens.

Samba 4.7 and later supports Security Event logging natively (Setting up Audit Logging - SambaWiki), so we could drop our custom patches to send logon/logoff time summaries to the HR department. Legacy laws in South Africa require archaic sign in/out records for the government's worker compensation fund, with hefty penalties on non-compliance...

Anyway, debugging ADQuery a while back showed me how the Security Event logs are processed by SQL-esque queries, so I believe I can write a fairly simple event log Samba event log processor. Just need to investigate whether or not Web API Identity Awareness associations are cleared at policy install, the way ADQuery associations are. If not a boot script could tell the processor to search back for the last hour's events, the same way ADQuery does.

This is getting really off topic but I see great value in implementing WPA2-Enterprise (802.1x) for AD based WiFi authentication using RADIUS, which could then inform Identity Awareness when users connect to WiFi networks instead of replying on captive portal authentication every day.

Re: Identity Awareness not matching users behind proxy

We had another problem whereby application policies were not granting accessing to users when directing traffic via the security gateway proxy service, whilst they worked perfectly when sending requests directly. This most probably has to do with pre-defined applications being set with fixed port associations:

I'll log a feature request for HTTP_proxy and HTTPS_proxy service ports to track the security gateway's custom proxy port setting.

XFF unfortunately still doesn't work when we leave the Check Point security gateway on the default 8080 port assignment and update Squid to forward requests there.

Re: Identity Awareness not matching users behind proxy

This is locked down by the global policy on the MDS environment. I could clone the policy, change the proxy port and assign it to the relevant domain but it may be preferable to have the proxy port automatically track the associated security gateway's proxy port setting: