Main Nav

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

 

Comments

>Disadvantages

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

 

This is a disadvantage :-?

 

Kevin was probably referring to offsite users unable to perform a necessary (admin) task?

I think Microsoft has a good summary of LUA: http://technet.microsoft.com/en-us/library/bb456992.aspx

Windows 7 has also tried to help the least privilege principle with UAC..

--

Jason Gates

Southern Adventist University

 

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

 

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”.

 

Kevin

 

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

 

Message from christopher.webber@ucr.edu

I think the larger picture needs to be looked at:

- Who are your clients? 
- What is your actual goal?
- What do your users need?

Frequently we get all huffy puffy about not being able to install software etc, but is that really a service to the "business?" My bet is you will need to find a balance. If you are managing a clerical worker that has a very distinct job, sure, lock it down (just make sure Freecell gets installed). If you are dealing with say a Resident Director or someone in Student Affairs, it may be a job requirement that they are able to play video games or can install software. It all depends. 

The typical BOFH attitude of CONTROL EVERYTHING ALL THE TIME needs to end. This is exactly why BYOD is winning, because even executives are tired of the stupid crap IT puts them through.

</rant>

-- cwebber

Christopher Webber - Systems Administrator 
Bioinformatics Core - Institute for Integrative Genome Biology
University of California, Riverside

Twitter: @cwebber
Tel: 951.867.7108
http://cwebber.ucr.edu


On Nov 30, 2012, at 13:48 , "Shalla, Kevin" <kshalla@UIC.EDU>
 wrote:

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
 
Message from 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 ---
I will agree with Kevin here. My wife is a high-level administrator here, and often has to act very quickly on tricky personnel issues. When someone sends her a pdf related (say) to an emergency dismissal and her Acrobat insists on an update NOW, the last thing she needs is to submit a support ticket and wait a couple of days before she can read the file. This kind of thing happens more often than we might think (well, maybe not the emergency dismissal), but the notion that IT support student workers' time is more valuable than the Vice President's time, so we need to hold up their work to minimize IT support costs needs to be discussed with all parties involved.
And yes, there may be tools that will make such updates automatic, or make remote updating trivial, but actually implementing those tools still seems a long way off.
Just my 2c worth.

Geoff

Geoffrey S. Nathan
Faculty Liaison and IT Policy Coordinator, C&IT
and Professor, Linguistics Program
http://blogs.wayne.edu/proftech/
+1 (313) 577-1259 (C&IT)


Message from j-braden@tamu.edu







Chuck Braden <j-braden@tamu.edu> wrote:
I see both sides of this issue. However, i am not sure what poses the bigger risk. 
In this age, users ( especially higher ed users that should be able to understand the 'EDUCATION' part) can't just be passive participants -they have to have some basic awareness of how to maintain the tools they need to perform their job just like anyone else. Organizations should have a continual training program in place that raises awareness about the most basic resposibilities that accompany use. That being good email/password practices, routine software updates, installation of properly licensed software that is necessary to perform a business function, and holding these individuals accountable when they it get it wrong. 

Do all faculty/staff need admin access? No probably not. Some might require it due to the accessability/availability of support staff, while other institutions might be able to rely on wsus and group-policies, which should reset any changes in local policies that potentially were altered by the local admin account anyway.

Most malware can still infect limited accounts now. Yes, the impact is less and cleanup is usually less involved. But not providing admin is no longer the benefit it used to.

I see some value in not having a user logged in as admin at all times, which also aligns with least privilege guidelines. However, i recognize the issue with having a limited account for general access and an admin account for software updates ( and the less than ideal unique password selection that could be a side effect).

 As for myself, my general limited id is the only one that is defined in active directory so i can't effectively accomplish my job ( no drive maping to server storage), when logged in as admin. While i acknowledge that has some drawbacks with the managment of the password expiration of the local account from active directory, as the group policy is setting the global password expiration and complexity/length for all accounts on the workstation, the admin account is not likely to be ignored. 

And as i understand it, there now are tools to manage passwords on local workstation accouts now, but i dont have any personal experience with them.


For my needs/use, i believe my implementation provides the benefits of both environments. But, ymmv.




Geoffrey Steven Nathan <geoffnathan@WAYNE.EDU> wrote:
On 12/1/2012 7:45 AM, Geoffrey Steven Nathan wrote:
I will agree with Kevin here. My wife is a high-level administrator here, and often has to act very quickly on tricky personnel issues. When someone sends her a pdf related (say) to an emergency dismissal and her Acrobat insists on an update NOW, the last thing she needs is to submit a support ticket and wait a couple of days before she can read the file. This kind of thing happens more often than we might think (well, maybe not the emergency dismissal), but the notion that IT support student workers' time is more valuable than the Vice President's time, so we need to hold up their work to minimize IT support costs needs to be discussed with all parties involved.

But unfortunately that is the epitome of targeted spear phishing... getting an "administrator" to open a malicious attachment, and/or OK an "update".

Jeff
Message from hhoffman@ip-solutions.net

Situations like this are a perfect use for services like Box where the display of the documents are inside of the browser, the sharing of folders documents have defined ACLs and the ability to share depends firstly on correct authentication.
My $0.02.

Cheers,
Harry

Jeff Kell <jeff-kell@UTC.EDU> wrote:

On 12/1/2012 7:45 AM, Geoffrey Steven Nathan wrote:
I will agree with Kevin here. My wife is a high-level administrator here, and often has to act very quickly on tricky personnel issues. When someone sends her a pdf related (say) to an emergency dismissal and her Acrobat insists on an update NOW, the last thing she needs is to submit a support ticket and wait a couple of days before she can read the file. This kind of thing happens more often than we might think (well, maybe not the emergency dismissal), but the notion that IT support student workers' time is more valuable than the Vice President's time, so we need to hold up their work to minimize IT support costs needs to be discussed with all parties involved.

But unfortunately that is the epitome of targeted spear phishing... getting an "administrator" to open a malicious attachment, and/or OK an "update".

Jeff
Eric, I would add remote assistance to your list. It also makes IT more efficient by eliminating travel time. -Eric Eric Case, CISSP ecase (at) email (dot) arizona (dot) edu College of Architecture and Landscape Architecture http://www.linkedin.com/in/ericcase (520) 344-CISO (2476)
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 privs.
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



Message from eric.lukens@uni.edu

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 do.
 
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 success.
 
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 suggested.
 
-Eric
 
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/
 
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 privs.
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



Randy,

 

Without administrator rights, the impact of malware is limited: they can’t, for instance, install a device driver, retrieve cached domain passwords or sniff the network.  Some malware do have privilege escalation exploits packaged in, but these are generally not zero-day exploits.  The Cool and Blackhole exploit kits, for instance, attempt escalation using the TrueType font vulnerability that was found in Duqu about a year ago.

 

I don’t think the important question is whether most infections come from drive-by downloads or from users installing unauthorized software.  Rather, we need to consider, in our environments, what the difference is between malware running with administrator privileges versus basic user privileges. 

 

Regards,

 

Steven Alexander Jr.

Online Education Systems Manager

Merced College

alexander.s@mccd.edu

 

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of randy
Sent: Sunday, December 02, 2012 5: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 privs.
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


Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.