Re: Non-administrator advantages / disadvantages

["Eric C. Lukens" <eric.lukens () UNI EDU>]

I find the risks of mildly out-of-date software are still far less than
letting the users have admin rights. So just because it takes you a few
days to deploy the Java update, doesn't mean that you should give admin
rights to end-users so they can have it *today*. Ideally you should get
critical updates out within 24 hours, but the lack of admin rights is
still more important. If it takes you months to package updates, then
you should hand out admin rights to give the users a chance to keep
their systems up-to-date.

In my previous stint in desktop support at a college at UNI, I found the
trick to not handing out admin rights was to make sure nothing ever
automatically popped up on the screen asking for them. Once I did that,
the number of calls dropped dramatically. You'd still get people asking
about installing new software and the occasional settings change, but it
became manageable.

This means doing the following:

1) Set UAC on Vista and above to silently fail on your end-user's user
GPO. The specific setting is "User Account Control: Behavior of the
elevation prompt for stand users" and should be set to "No prompt." The
"User Account Control: Detect application installations and prompt for
elevation" should then be set to disabled. Leave the settings for
administrators to whatever you find appropriate. Help-desk staff will
need to know to use run as or login as an admin to install/update things.

2) Disable update checking in all applications when packaging them or
deploying them. This seems highly counter-intuitive, but as long as you
keep up on the notifications yourself and are responsible for installing
the updates via GP, SCCM, or whatever else you use, it doesn't really
matter since the end-users can't install the update anyway. Usually
every application has this setting, though getting it into the package
can be difficult. Some applications need to be repackaged, so
investments into repackaging software is required to do this right.

3) Disable access to control panel applets that have no settings the
users can change.

4) As much as possible, utilize software that does have its own update
mechanisms that don't require admin rights. Firefox now has this. If you
allow it, Chrome runs from the user's profile, self-updates, and always
has up-to-date Flash.

5) Concurrent-software licenses. If possible and if you have concurrent
licensing and license managers, install software everywhere you expect
it might be needed. While unnecessary software is a risk, I had to
balance it against handing out admin rights.

6) Methods for quick deployment. If you have software packaged and a
user requests it, make sure you can quickly get it installed on the
system. SCCM makes this easy. GP isn't too bad as you tell them to
"reboot and it will be installed."

Lastly, you still need management backing that certain things are not
worth your efforts. For example, I had a user want the power settings on
the monitor to never sleep so they could have their slideshow of family
pictures for ambiance in their office. You need management to back you
up that things not necessary for the person's job are not going to
happen or are at least subject to your discretion on implementation. If
the philosophy in your institution is that IT will honor every whimsical
request even if not related to their job duties, then you just as well
hand out the admin rights.

Of course, you will have a significant number of users that will rate
your performance as terrible for blocking their ability to install
whatever they want. However, in my experience, when pressed most of the
time you'd find the software had nothing to do with their job
responsibilities. If the software was related to their job
responsibilities, I generally requested a few days to test it (if I
wasn't familiar with it) and would hand the install task over to a
trusted student employee. If the software was to be deployed to more
than 5 machines or so, I'd package it.

Lastly, if the job duties of a person really require constant changing
of settings or installation of software, then you should give the user a
*second* account with local admin rights to install the software--bonus
points if it only works via run-as and can't interactively log on. In
those cases, you should set UAC to prompt as usual.

The app store in Windows 8 might make some of this problem go away for
the "modern" apps. You can per-approve applications and then the users
can install them themselves.

-Eric

-------- Original Message --------
Subject: Re: [SECURITY] Non-administrator advantages / disadvantages
From: Shalla, Kevin <kshalla () UIC EDU>
To: SECURITY () LISTSERV EDUCAUSE EDU
Date: 11/30/2012 3:48 PM

> A few have admin rights now, and there’s a stampede by others to also
> get it, so we’re considering granting it to many others. 
>
>  
>
> Kevin
>
>  
>
> *From:*The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Steven Alexander
> *Sent:* Tuesday, November 27, 2012 3:00 PM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU
> *Subject:* Re: [SECURITY] Non-administrator advantages / disadvantages
>
>  
>
> Kevin,
>
>  
>
> Most users don’t require anything above basic user privilege to do their
> jobs.  If you give them administrator rights, you are giving up control
> of their machines.  The users can install any software, bypass group
> policy and possibly gain domain admin rights (if a domain admin logs in
> to their machine).  They will also be much more vulnerable to malware. 
> Most malware requires administrator privilege for full functionality
> because admin rights are needed to install device drivers, put a network
> card into promiscuous mode or install a new service. 
>
>  
>
> Prohibited software can span a pretty wide range: games, P2P software,
> unlicensed/pirated software, personally owned software.  You need to
> worry about performance/compatibility problems, security issues,
> copyright. 
>
>  
>
> What’s the context behind your question?  Do your users have admin
> rights now?  Are you considering granting or taking away admin rights
> for everyone or just some users?
>
>  
>
> Regards,
>
>  
>
> Steven Alexander Jr.
>
> Online Education Systems Manager
>
> Merced College
>
> 3600 M Street
>
> Merced, CA 95348-2898
>
> (209) 384-6191
>
> alexander.s () mccd edu <mailto:alexander.s () mccd edu>
>
>  
>
> *From:*The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] *On Behalf Of *Shalla, Kevin
> *Sent:* Tuesday, November 27, 2012 12:24 PM
> *To:* SECURITY () LISTSERV EDUCAUSE EDU <mailto:SECURITY () LISTSERV EDUCAUSE EDU>
> *Subject:* [SECURITY] Non-administrator advantages / disadvantages
>
>  
>
> I’m trying to highlight the advantages and disadvantages of prohibiting
> administrator access for users of Windows computers.  Can you provide
> feedback on what I have below?  By the way, what’s an example of
> software that is generally prohibited?  Is BitTorrent an example?  Is it
> common?
>
>  
>
> Advantages
>
> Most malware stays on one user profile, so other users on same machine
> are unaffected.  Deleting the profile can remove the malware. Prohibited
> (by policy) software doesn’t get installed.  Combinations of software
> known to be problematic are not installed (like multiple active versions
> of antivirus).
>
>  
>
> Disadvantages
>
> User cannot install or update some software immediately – have to wait
> for desktop support.
>
>  
>
> Kevin Shalla
>
>  
>
>
>   ­­  

-- 
Eric C. Lukens
IT Security Policy and Risk Assessment Analyst
ITS-Network Services
Curris Business Building 15
University of Northern Iowa
Cedar Falls, IA 50614-0121
(319) 273-7434
http://www.uni.edu/elukens/

If you see an attachment called smime.p7s, you may disregard it. It is
an S/MIME digital signature file to validate the authenticity of this
email message.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature