Print

Print


On Nov 19, 2007, at 3:00 PM, Richard Wiggins wrote:

> I'm curious how folks manage access to Administrator accounts.  One  
> piece of advice is to create a general user account and use it at  
> all times except when you need to install a program or make another  
> system change.  That way it's harder for spyware or other malware to  
> break in.
> My question is whether those of you who manage fleets of machines  
> give your end users access to the Administrator account, even if you  
> encourage users to follow the above advice.
> You may have noticed that ACNS will be updating the SSL VPN to  
> support Mac's new Leopard operating system.  Whenever the SSL VPN is  
> updated, users need to upgrade the Java client installed on their  
> computers, and this requires admin access.  (See http://servicestatus.msu.edu/status_detail.php?id=1995)
> Obviously you'd want to avoid the scenario where your user is on the  
> road and needs to update the client but they don't have  
> Administrator access.
> There are other examples.  Once I was using a loaner laptop and  
> could not connect to a Wi-Fi network on the road because it was not  
> an encrypted network, and Windows demands Administrator access to  
> connect anyhow.
> During last Friday's wireless test folks needed to be sure they had  
> a Java VM installed, and to install a speed test applet.
> Or maybe you need to upgrade software for some reason while on the  
> road.
> OK, enough examples -- I look forward to hearing how you handle this.

In unixville, we have traditionally used sudo to accomplish this.   
Taken from: http://www.courtesan.com/sudo/intro.html
... "The ability to restrict what commands a user may run on a per- 
host basis."

Solaris provides a really rich RBAC environment which can be used to  
provide specific resources to users based on which roles you want them  
to have. An interesting (though dated) article on it is here:
http://www.samag.com/documents/s=7667/sam0213c/0213c.htm

This really isn't probably what you're after Rich, but I figured I'd  
provide a *nix perspective anyways ;)

./mk
-- 
Matt Kolb  <[log in to unmask]>
Academic Computing & Network Services
Michigan State University