Home page logo

educause logo Educause Security Discussion mailing list archives

Re: Non-administrator advantages / disadvantages
From: Eric Lukens <eric.lukens () UNI EDU>
Date: Mon, 3 Dec 2012 03:14:13 +0000

Since I gave my list of ways to make limited-user rights work better, I’ll
also give a list of ways to reduce risk when giving end-users admin rights.

1) Regularly review the list of administrator accounts on the machine, this
can be scripted or done via various software programs/administration tools.

2) Have users use a limited account for day-to-day activities and use the
admin account as a run-as account to install software. This reduces the
likelihood of the user accidentally doing something they didn’t intend to

3) Do not let the local admin accounts have access to domain/network-based
resources like file shares to reduce the likelihood of using the account
for day-to-day activities. Exception, if the software they need to run as
an admin is a legacy app that requires admin rights, then some network
resources may need to be accessible.

4) Consider a software restriction policy (administered via group
policy/sccm or via your Endpoint Protection products). There are lots of
ways to use these, but one option is to limit software to the Program Files
and Windows folders. For your admin users, you can create a special folder
where they can copy program installers that is also permitted (perhaps a
special folder on their desktop). This reduces the risk of malware
substantially while still giving the users admin rights--and might not be a
bad idea for regular users. However, this is an intensive task to get
going. Further, some applications that auto-update aren’t going to work
well with this method, though you can also allow applications based on the
certificates that signed the installers, so you could approve Adobe and
Oracle for regular browser plugin updates. Since a software restriction
policy can use hash rules, path rules, and certificate rules, it is fairly
comprehensive, but admittedly a significant undertaking, but certainly
doable. We have departments using software restriction policies with great

5) Reputation-based file restrictions. This is another area where Windows 8
makes some improvements, as all Win 8 machines have a reputation-based tool
that can be configured to not allow applications that aren’t yet well-known
to Microsoft. Such tools also exist in various A/V programs. Policies can
be configured to prevent even admin users from launching unknown apps. A
sophisticated admin user might be able to bypass the policy to get the
software running, but average users are going to be prevented. I’ve
encountered some issues with bleeding-edge updates of open-source
applications being block by reputation-services, but they usually are
corrected within hours of release.

6) Use group policy and other tools to enforce settings that you view as
non-negotiable so that admin users can’t change them. Avoid using logon
scripts, registry edits, and changes to the default user profile to push
settings unless there is no other way to set them (or if the setting has no
security implications). Group policy will enforce settings regularly and
revert changes made if the user works around a setting.

7) Monitor installed software to make sure your users aren’t installing
software they aren’t licensed to use.

8) Consider preventing even the admin end users from launching regedit and
perhaps revoke their ability to kill processes. These aren’t fool proof and
can cause some compatibility issues with installers that use the user’s
privileges to kill processes and merge registry changes with regedit,
though such installers are far less common now. Sophisticated users will be
able to work around these restrictions.

9) Configure your A/V to not allow end-users to disable it, or require a
password to disable it that is only provided if necessary.

I’m sure there are more risk mitigations for local admin rights, but these
are the ones I came up with off the top of my head that I have used or


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

 *From:* randy <marchany () vt edu>
*Sent:* December 2, 2012 7:21 PM
*To:* SECURITY () listserv educause edu
*Subject:* Re: [SECURITY] Non-administrator advantages / disadvantages

What are we trying to prevent by restricting user from having admin privs?
If it's to keep people from downloading evil malware, I hate to tell you
this but the primary method of malware delivery is by web drive-bys where a
user simply visits a legit www site and the malware is loaded via an
infected ad. User downloads are probably a small % of the infection. So
here are some questions I believe need to be answered before one implements
an arbitrary security solution.

0. IMHO, restricting user privs arbitrarily is a response to an old attack
vector.  Similar to account lockouts, this was the ONLY defense about 5-10
years ago when there weren't additional controls. Make sure you're
addressing the right problem.
1. do you have stats that show the types of infections and their vectors at
your site? In other words, do your stats show that users with privs are the
primary cause of infection? If so, then it makes sense to restrict user
2. Use your stats to support your security decisions. If your stats show
that web drivebys are your primary source of infection then restricting
user privs won't make you any more secure.
3. How long does it take for a user to have software that they need for
their job installed on their machine? 2-4 hours? 2-4 days? 2-4 weeks? In
the SANS classes I've taught, I ask this question and the answers I get
back actually range from hours to weeks. I was shocked that it takes more
than a day to have software installed on a work machine. I'm not talking
about an aquarium screen saver. I'm talking about business software.
4. If you don't have a responsive software install process, your users will
bypass your security by simply installing the software they need on their
personal machine, copy the data to the machine and do their work. Now, your
chances of data exposure increase and you have a worse problem than the one
you were trying to solve.

So, I believe it's extremely important that you collect the appropriate
security stats before making a security decision.

Just my .02.

-Randy Marchany
VA Tech IT Security Office

On Fri, Nov 30, 2012 at 4:45 PM, Shalla, Kevin <kshalla () uic edu> wrote:

 This is a disadvantage from the user’s perspective.  They want to do what
they want to do when they want to do it.  I have to provide support and
demonstrate value added.  It’s difficult to argue this: “I know you’re the
administrator of your own computer at home, and it works for you, and
nothing gets in your way, but here at work, we have to slow you down
because it’s for your own good, and the good of the university.”  We’ve
been short of staffing, but still striving towards automating software
updates, but so far the only thing we’ve mastered is through group policy,
which isn’t very reliable.  Further, Adobe and Java are frequently telling
users to update, yet when they try, they are thwarted.  Thus, we have users
questioning our value, and saying “Give me the keys, you guys are too slow”.

** **


** **

*From:* The EDUCAUSE Security Constituent Group Listserv [mailto:
*Sent:* Tuesday, November 27, 2012 2:31 PM
*Subject:* Re: [SECURITY] Non-administrator advantages / disadvantages****

** **


User cannot install or update some software immediately – have to wait for
desktop support.****

** **

This is a disadvantage :-?****

** **

*From:* The EDUCAUSE Security Constituent Group Listserv [
Behalf Of *Shalla, Kevin
*Sent:* Tuesday, November 27, 2012 3:24 PM
*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?****

** **


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

** **


User cannot install or update some software immediately – have to wait for
desktop support.****

** **

Kevin Shalla****

** **

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]