A couple of questions...
Are you running 6.8.x or 7?
Since you didn't specify, let's assume you are running 6.8.x.
If a kiosk is logged on, will they have some sites that they will always be allowed to go to? (A whitelist of sites that you don't care who can go to)
And if they go beyond the proscribed sites, then it prompts for a domain user/password?
Yes, you can do that.
In general, on 6.8, it involves creating a custom action with a 407 code returned for all but the whitelisted sites, and apply that block/407 action to the profile that the kiosk's autologon user ID maps to.
With 7, it's a matter of editing the rules in a different way, but answer the initial questions to validate my assumptions, and we can guide you with more details.
I'm actually the single sign-on administrator and not the Web Gateway administrator so I had to find the answers. It is version 7.
Except for Blocked Categories, the current proxy settings let the users go to any site including social networking, etc. So the expectation is that the reporting will identify who went where. But since the workstation auto logs in to hospital.SSO then iexplore.exe runs as hospital.SSO and all traffic is tied to hospital.SSO. The user logs into the single sign-on GINA with their valid domain account so they are authenticated against the domain.
The only time the proxy login appears is if the workstation is logged in with a non-domain account.
What are the options under version 7?
Our Web Gateway admin is pretty busy and if it's something I can do at the workstation level then I'll give it a try. Otherwise I'll just relay the instruction to him.
There is a method in the products rule library called Try-Auth. That means that in case somebody is not willing to authenticate, he could simply hit escape and will not be authenticated. NTLM would prompt for credentials then. Actually the question contains a paradox - not authenticating certain users, would require to have authenticated them to know their name in order not to authenticate them
As you noted, we can create excludes based on IPs which is easy as this a piece of data that exists. The initially described method of try auth simply means
- Ask user who he is
- If he tells, proceed with proper settings for the respective user
- If he prefers to stay anonymous (no authentication) grant access, but use a stricter Policy Set (more Categories Blocked, full driven AV, etc.)
Does that sound ok?
Did you ever figure out how to do this in V7. We have a similar issue with our SSO roll out.
I never took this any further. Exclusion by IP is a maintenance nightmare for 30,000+ workstations.
But I didn't see the response from Michael Schneider. I would have to try it out. Is sounds feasible since each location has 1-3 generic userids in use for their shared SSO workstations. If it would cause the authentication prompt to appear then that would work. I've moved onto to a new team so I'll see if the SSO team wants to try it out.