All our public machines are auto-login to an unprivileged account (on the
computer and the domain)
By auto-login, do you mean that the user begins in a (hopefully new) desktop session? I
was proposing that the user begin at the login screen, having to first select the
"Guest" account. I presume this would work fine for Windows or Mac for local
login; I'm not sure about domain authentication. Our specific environment, due to
regulatory reasons, doesn't actually allow for any sort of public access.
Most public systems dump any file changes on reboot; we also like that since
we've seen webstealer trojans running in user space.
Alternatively, you could wipe the user space on logout. I'm told that both
Windows and Mac can be configured this way; no additional software required.
Presumably this could provide faster turn-around for users.
The issue comes with explaining how to REALLY exit the browser. Close the
windows? Well, yah, unless they minimized one or are using one of the Macs.
Yes; exactly. I agree with you that a reboot is preferable to trying (possibly
unsuccessfully) to get the browser restarted. The reason I was favoring a
logout approach was that it felt more intuitive. If I want to secure a machine,
I would either lock it or log out. I wouldn't expect a reboot would be needed,
even under a guest account. Logging out of a service/system when your done is
generally a best practice. Restarting a service/system isn't necessarily.
Regards,
John
On 4/7/2010 1:02 PM, Cary, Kim wrote:
Right. All our public machines are auto-login to an unprivileged account (on
the computer and the domain). The idea of using a desktop background is a good
one, and most of our labs/public computers will also do that. Most public
systems dump any file changes on reboot; we also like that since we've seen
webstealer trojans running in user space.
The issue comes with explaining how to REALLY exit the browser. Close the
windows? Well, yah, unless they minimized one or are using one of the Macs.
Reboot is more sure AND has the benefit of dumping the sandbox created by deep
freeze.
We'll explain that one of the reasons we're asking them to do this is to 'log
out'.
On Apr 7, 2010, at 8:03 AM, John King wrote:
I'm certainly not an expert when it comes to labs, but I'm of the opinion that users
shouldn't share a system login session. Would enforcing LDAP/AD authentication for lab
machines and providing "Guest" account access on public kiosks be a viable
alternative? Any changes made to the file system could be rolled back at logout. Kiosks
could force logout after a certain period of inactivity. I think users are likely to
understand the need to log-out (after having initially logged-in), more so than having to
close the browser or restart the machine.
Also, customizing the machine's default background may not be a bad place to put a "close your
browser" or "restart/logout when done" message.
Regards,
John
On 4/6/2010 5:10 PM, Cary, Kim wrote:
As we're closing in on putting our portal behind CAS, I'd like to re-visit this
subject with the list:
What do you do to remind your users to exit their browser on public
computers?
We're thinking of printing some table tents for the labs& public access
areas, or maybe laminated stickers that could go on table tops.
However, aside from those things, I'd appreciate pointers to any of your online
docs where you explain to your users what the issue is and how to handle it.
BTW, I'm leaning towards a 'reboot when done' recommendation for public access
and lab machines -- simplest effective way to close everything and many areas
use 'deep freeze' which will reset the config on boot.
--
John N. King
Web Developer
Computing& Information Technology
SUNY Geneseo
South Hall 124A2
585-245-5577
[email protected]
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
John N. King
Web Developer
Computing & Information Technology
SUNY Geneseo
South Hall 124A2
585-245-5577
[email protected]
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
