/build/static/layout/Breadcrumb_cap_w.png

Opinion question about local administrators

Quick question to see what everyone thinks about this.

I know in the past people have told me that if we allow everyone to be local administrator on their machine it's a recipe for disaster.

My question is, what is the difference between making everyone local admin and setting every program on the machine to run as administrator?

Would one option be considered better or worse than the other?

In my head they seem like they would be similar, but the local admin would have a bit more ability.

Setting the programs to run as admin would mean they couldn't install things without our knowledge, right?

 

Thanks.


0 Comments   [ + ] Show comments

Answers (4)

Posted by: SMal.tmcc 10 years ago
Red Belt
4

Less admin's = less virus's and malware

In the classroom we allow everyone to be admins for teaching purposes, but those machines are frozen with Faronic's Deepfreeze.


Comments:
  • Makes sense. - AFCUjstrick 10 years ago
    • What we noticed with staff machines, If they are not an admin they can only infect their profile area usually, not the system32 or program files area and a lot less root kit problems also.

      What is the reason you do you need users or even programs to run as admin's? - SMal.tmcc 10 years ago
      • All of our users are local admins now.
        I've been trying to figure a way to get out of that and the running programs as administrator was an interesting idea I stumbled on. - AFCUjstrick 10 years ago
      • We have a list of users that need to be admin, but they sign an agreement with us. It states they are on their own to maintain their box. We provide an image to them and they have to install any other software. The only help we provide is to migrate their profile and reimage. If AV detects a virus it cannot remove we reimage without permission and they can no longer be admins. A lot of software I found just needs extra rights to certain area normally off limits to a domain user.
        As an example a lot of teachers use testbank software and have to upload new testbanks on a regular basis. I just give the domain users all rights to the testbank\data area and it works without them being admins. This is where a test env is important, so you can find the minimal rights needed for a user to do their job - SMal.tmcc 10 years ago
  • We do have a bit of a test environment. But not nearly as extensive as it should be. I guess my main goal is to prevent users from installing their own software/toolbars/mouse pointers/updates. - AFCUjstrick 10 years ago
    • It should be created as a company policy first about users and being an admin and then all you do is enforce it. Out of 700 staff we have 30-40 admins, those are usually laptops that are off campus so they need to be able to do updates on their own. - SMal.tmcc 10 years ago
      • I see. - AFCUjstrick 10 years ago
      • Everyone thinks they need to be an admin! You will find it hardest changing that mind set.
        To help quell that we need it now attitude on being an admin we have remotely on many occasions made a user a temp admin to install some type software and then remove those rights immediately after (for example go-2-meeting, webex). Just use computer management and under action connect to their computer add that user to the admin group, let the install happen and then remove them all remotely. We even will use TVNC or Ultra VNC to monitor sometimes. - SMal.tmcc 10 years ago
  • Good advice. THanks. - AFCUjstrick 10 years ago
    • The one Credit Union I have helped a couple of years ago, we implemented deepfreeze and all files are now saved to the network period. All updates are done at night when IT staff wake and thaw the machines, they even disabled USB ports with RTV!

      If someone needed additional software they had to get it approved then they would schedule a remote install when and if it did.

      Staff bitched for a 2 months and then realized it got them no place but watched and labeled so they conformed. - SMal.tmcc 10 years ago
      • Bad part is not sure the upper management in this department has the "stomach" for the 2 month period. - AFCUjstrick 10 years ago
      • You're my hero, Steve. I'm going to print this conversation out and show it to my director to aide in my quest to enforce non-admin users. All great points! - nheyne 10 years ago
Posted by: jegolf 10 years ago
Red Belt
3

When I started my current job we had the same problem. Many users with local Admin rights. There were many reasons why this was the case:

- no central management system for applications and Windows updates

- legacy applications that needed elevated rights to run

- IT laziness (it happens)

- important people are convinced that THEY should be able to control THEIR machines (we all know that the machines are, in fact, the property of the employer)

So us Desktop folks decided it was time for a change. This takes some planning and support from upper management - and sticking to your guns. So we:

- Implemented Kace. Now we control application installs, updates, patches, etc.

- Determened which legacy applications required elevated rights, did some research, found out why exactly, and elevated user rights to the directories and registry keys necessary. Some of this took some deep digging and trail and error. Not necessarily for the light hearted!

- Stopped being AS lazy as we were

- Convinced the important people that while they won't have local Admin rights they are still quite important

Once we eliminated any justified reason a user could have for Admin rights we removed them. Low and behold - support calls for malware dropped drastically. Random toolbars and weather tracker installs dropped drastically. Users are happy. IT is happy.


Comments:
  • It would be fantastic to have a push like that around here. - AFCUjstrick 10 years ago
    • Since you are CU you should be able to push security as a priority since you are a prime target hackers love to get on the inside of. As a college we are also a prime target to hack, many systems to turn into zombies to use as their minions. Also lots of Private Info that helps identity thief's. - SMal.tmcc 10 years ago
  • exactly, when you have smaller staff and bigger demands this becomes important. You need workable tools, the willingness to solve install problems without giving away the farm, and all IT staff sticking to your guns.

    We also found it helped convincing important staff you are taking the burden of not infecting their computer with virus's off them and onto your department. - SMal.tmcc 10 years ago
    • Luckily we don't have much virus problems, but I worry that we have them and don't even know it. - AFCUjstrick 10 years ago
Posted by: alex.woo@clsa.com 10 years ago
White Belt
1

IMHO - getting rid of local admin rights is the most effective way to prevent malware attack and reduce PC troubles.  Some applications are so stubborn that they appear to require local admin rights to run (properly) but in most of the cases that I have seen, it is purely due to a bad application design which writes something to Windows restricted folder or registry which a normal user does not have access to. If you know which folders or registry paths that application is trying to write, you can grant modify permissions to that user alone which is a much better way than giving native local admin rights. In some unavoidable situations IT developers require admin access on their development PCs to perform testing and installations. They way I tackle that is to give them a separate account (e.g. _dev) which is blocked for interactive login and also blocked by the proxy to access the Internet. This can reduce the attack surface yet they can use this separate login to perform their work.


Comments:
  • The really bad part is that it would take a disaster of some kind to change the thinking of those in power. "If there isn't a problem why change?" is what they'll say. - AFCUjstrick 10 years ago
    • That is so true most of the time. Security measures and changes are only taken seriously and put into effect after an incident happens. And it can be hard to prove sometimes what has been prevented by taking proper measures in the first place. - jegolf 10 years ago
      • Of course the redeeming factor of all this is it wouldn't cost us any money to implement. We've already got the K1000 and use it extensively everyday. It's just the mental and emotional cost of the intial work and backlash. - AFCUjstrick 10 years ago
Posted by: jaybee96 10 years ago
Red Belt
1

Getting rid of Local Admin rights is the best step forward to have a more secure desktop.

Looking at some of the large attacks by the NSA / Brittish Int.  against some telco's in Europe where the "local admin rights" were used  was big news couple of weeks ago.

But then raises the question how you should manage Applications that need higher privileges ?  or how to keep track of the usage of these privileges?

According to Gartner, taking away the Administrative Privileges would reduce 90% of the sucurity vulnerabilities , so that is a good start right?

UAC only will not help either, because it will still require higher privileges , it is only an extra hurdle for the enduser to decide if an application / function should be executed.

We sometimes use shims ( ACT) to resolve security / compatibility issues, but this is very hard to maintain, what if application changes , environment changes etc..  it takes much more time to test and to develop a good shim and in most cases , you do not have the time to play around with that during a migration.

Conclusion:

Step 1: Keep it simple and get rid of ALL Adminstrator rights and replace that with Standard User accounts.

Step 2: Implement a good Privilege Management tool like Avecto's privilege Guard ( www.avecto.com) I'd prefer their Policy Based control because it's works within your AD Group Policies , lightweight, works  immidiately and is fully configurable with reporting options.

Let me know if you need some reference sites.

ps. only tool I know who can do this kind of control is Avecto, please let me know if there is any product like that.

 

 

 

 


Comments:
  • I agree it needs to happen, I just wonder the actual differences between admin accounts and running programs as admin. I guess as long as Windows isn't run as an administrator then all the same restrictions should be true as far as ability to install/change things on the machine. - AFCUjstrick 10 years ago
    • partly true, if you are an admin , then basically all doors are open. (without a warning) if you grant an application Admin Privileges (runas) but that is actually another user running the application ( other registry, other mappings if .., etc..)

      So a solution like Privilege Guard would still use the "Standard User" account but it will extend it's privileges to a pre-configured level / time.

      Jeroen - jaybee96 10 years ago
    • If I'm not mistaken - right-clicking an executable, going to Properties, and checking off "Run this program as an administrator" is all tied in to UAC. If UAC is enabled this will automatically elevate the rights to an admin level without having to grant permission (for users with Admin rights). So if you are logged in with standard user rights this won't actually elevate you to an admin so to say.

      In a nutshell - UAC sandboxes Admins only. Amiright? We disable UAC so I never have to worry about it... - jegolf 10 years ago
      • We have UAC disabled on all of our machines as well. I found in the registry where you can put the path to the exe and RUNASADMIN and it sets the checkbox you're talking about automatically for all users on the machine. That's pretty much my plan. Find the apps that need to run as admin and set them there then start removing local admin from users. - AFCUjstrick 10 years ago
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ