 |
 |
We try to follow a few basic rules for administering our users accounts, with exceptions where need be. By default any new user in our system is granted only User-level access to Windows workstations (2k and XP) and their accounts are volatile (i.e. they are removed from the PC when the user logs off). We make profiles volatile by default because our staff and students move between so many workstations (~1,500 users and ~850 desktops/laptops). Students accounts have additional restrictions placed on them via Local Group Policies. When good cause can be shown we will grant some users Administrator-level access to workstations and/or make thier profiles non-volatile. These changes are almost always made to work with legacy software (Administrator-level access) or because the user wants to have many settings changed from the defaults (non-volatile accounts). It would be nice to not-allow any end users Admin-level access, but their are just too many legacy applications and/or hardware that were designed to work with Administrator/System access. This is especially true of a lot of the medical software and lab equipment. To handle user data we implement folder re-direction for the "My Documents", "Desktop" and "Favorites" to respective folders in the person's network home directory. We also change the default permissions on the local workstations so that User-level accounts can only write to 'C:\Temp' and no where else on the local HDD (outside of their profile that is). All actual data is saved on file servers which connect to our SAN environment. Laptops are handled differently, mainly because the user is not always connected to our network and they may be half-a-world away on business. We only have two accounts on laptops, both of which are Administrator-level accounts. One account is for our IT staff and the other is for all others to use. To handle most updates we do the following: - Windows (and other M$ products) updates are pushed out from our WSUS server to both laptops and workstations - Updates for many "common" programs (Java, Acrobat Reader, Microsoft Office, Quicktime, etc) our pushed out to our desktop using Novell ZenWorks. Laptops must be updated manually on an as-needed basis. - Third-party software that is not common across all our workstations, or large groups, is installed/updated manually on both laptops and desktops. This includes things like Adobe and Macromedia products or Matlab, Endnote, etc. Well I guess that's enough rambling for now. -- Stephen Bogdanski Network Support College of Veterinary Medicine Michigan State University >>> On 11/19/2007 at 3:00 PM, <[log in to unmask]> 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. > > /rich