there are few auth cache options on MWG:
both of them do auth backend caching only, the user still get 407 and have to provide credentials (interactively or transparent/SSO).
I'm looking for a rule set to maintain a list of IPs with corresponding usernames and groups, so the user will be excempted from auth prompt for some time (say 30 min, configurable). This function is called "auth surrogates" by other vendors. It should be also possible to output a list of all entries (IP->user/groups) in the auth cache or search in this list (by IP or user).
I'm aware of shortcomings of this approach especially for RDP/VPN users.
Please provide steps to configure such auth caching.
the "Authentication Server" is exactly doing this.
Unforutnately we have no way to output the list of active sessions with IP addresses, their associated usernames and session lengths. This information is held in memory only.
Thank you André,
I've check the Auth Server ruleset. What is the best way to integrate it in the "explicit proxy auth" ruleset? Just put it inside of "Authenticate With User Database" rule set? How to use it with "Kerberos + NTLM Fallback" rule set?
What are the benefits of using Auth Server ruleset comparing with just putting the IP, Username and Groups in PDStorage?
A suggestion: would the "Re-validate Session Under Ideal Conditions" rule inside of the Auth Server ruleset benefit by restricting it to interactive user-agents (i.e. browsers)?
you can not really combine "explicit proxy auth" and "authentication server". Authentication server is used for transparent environment, where no "407" exists (as this is a proxy status message, in transparent environments the browser does not know about the proxy).
In the transparent setup the browser receives a 302 to an internal web site, which sends back a 401 and requests "web site authentication", rather than proxy authentication. So the browser thinks he logs in to a web site.
Since we don't want to do this redirect back and forth for every request, the "session" (IP address) is stored.
For explicit proxy authentication we don't cache. Every new TCP connection gets a 407 returned to the browser for authentication, to make sure the user is really authorized. While this certainly puts some load to the DC we have not seen this causing problems.
So basically, as you mentioned PD Storage:
If using explicit proxy auth: Use "explicit proxy auth" rule set and use PD Storage for cache. Please respect the "Global" and "User" PD Storage: The "User" PD Storage is bound to IP address unless authenticated, then it binds to the username. So its not possible to make a "User" PD Storage entry after authentication but read it before authentication.
If using transparent proxy use the authentication server.
thank you for your detailed answer. It's interesting that there are no 407 in the logs, just 302 only. But there is a 407 response present on the wire:
# curl -x 192.168.1.1:9090 example.com -IL HTTP/1.1 302 authenticationrequired Date: Thu, 16 Sep 2021 08:47:02 GMT Location: http://192.168.1.1:9090/mwg-internal/de5fs23hu73ds/plugin?target=Auth&reason=Auth&ClientID=2514953479&ttl=30&url=aHR0cDovL2V4YW1wbGUuY29tLw,,&rnd=1631782022.1199388769 Content-Type: text/html Cache-Control: no-cache X-Frame-Options: deny Proxy-Connection: Keep-Alive HTTP/1.1 407 authenticationrequired Date: Thu, 16 Sep 2021 08:47:02 GMT Content-Type: text/html Cache-Control: no-cache X-Frame-Options: deny Proxy-Connection: Keep-Alive Proxy-Authenticate: Basic realm="McAfee Web Gateway"
yes, the original GET request to example.com is replied with a 302 because it is redirected to the authentication server.
I think curl follows the redirect. The request to the authentication server is probably not logged, since it is an internal request.