Identity Awareness not matching users behind proxy

[David_Herselman]

We configured security policy layers to detect users behind proxies:

Some systems use an explicit caching Squid proxy which is configured to send requests to the Check Point security gateway's proxy interface:

acl local-servers dst 10.0.0.0/8 100.64.0.0/10 172.16.0.0/12 192.168.0.0/16

always_direct allow local-servers
always_direct deny all
never_direct deny local-servers
never_direct allow all
cache_peer 100.127.254.1 parent 3128 0 no-query no-digest

Check Point security gateway is configured accordingly:

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:

[Danny]

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.

[David_Herselman]

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.

[PhoneBoy]

Did you enable XFF on the gateway as well?

[David_Herselman]

It is indeed:

network group object:

[PhoneBoy]

In my right in understanding that the authentication is occurring only with Captive Portal and not with, say, Identity Collector or ADQuery?

I'd also check with a tcpdump the proxy is actually sending the XFF header.

I suspect a TAC case is probably in order also.

[David_Herselman]

Correct, we run Samba AD and still need to write our own ADQuery 'equivalent' to feed authentication events to Identity Awareness using the Identity Web API. We were however pleasantly surprised to discover that captive portal and Kerberos authentication events survive policy installs, unlike AD Query Identity Awareness association events on classic Windows AD environments.

XFF is definitely working, as evident on the sample log entry in the original post where the record contains 'Proxied Source IP 192.168.5.12'.

I'll log a case with TAC, wanted to make sure I wasn't missing something first...

[PhoneBoy]

Wonder if you can hook up Samba to RADIUS Accounting?

I know you can hook up Samba to a RADIUS server for VPN authentication: VPN Single SignOn with Samba AD - SambaWiki 

Not sure if that's easier than writing an IDA API connector, but another avenue to consider.

[David_Herselman]

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.

Time, time, time...

[David_Herselman]

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.

[PhoneBoy]

Can't you just add the custom services?

Or are you saying that doesn't appear to work?

[David_Herselman]

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:

[PhoneBoy]

Tracking the gateways explicit proxy port would definitely be an RFE.