Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I know we all struggle to strike a balance between keeping our user's workstations locked down but still usable. I have a real problem with one client whose users are constantly installing toolbars, games, malware etc. I really want to be able to take away their local administrative rights (and so does management). The problem is they rely on a handful of poorly written applications that require local administrator rights to run properly. Before anybody suggests it, it is not possible to get rid of these applications.

I realize I can create custom shortcuts to these applications using the runas command and saving the local administrator credentials. The problem with this solution is:

  • I have to manually supply the local administrator credentials for each user.
  • Some of the programs rely on data in the local user profile and do not function properly if "tricked" into thinking they are running under the ComputerName\Administrator profile.

What I would love is to install some application or apply a Group Policy that allows me to specify applications that should be allowed to elevate the local profile's permissions. Is there a solution like this available?

How does everyone else handle locking down workstations and still supporting legacy/poorly written software?

share|improve this question
    
I think you should look here magicermine.com and here boxedapp.com –  MastAvalons Jan 27 '12 at 21:22
add comment

10 Answers

up vote 8 down vote accepted

It's rare that a software package actually needs admin rights, but rather it's writing to an area of the registry or hard disk that admins normally have access to and other users do not. That might sound like nit-picking but its fundamental to nailing this issue.

You can use the process monitor edit: thanks grawity tools from Microsoft to monitor what the applications are doing, and allocate rights to those areas to the users. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

You can then use Group Policies to apply security ACLs to both files and folders and parts of the registry. A common cause of this problem is the program writing to either/or it's installation folder in c:\program files, or its global settings on the machine registry under HKey Local Machine.

share|improve this answer
3  
Process Explorer is just a replacement to Task Manager. The monitoring tool is Process Monitor. –  grawity Jun 3 '09 at 15:17
    
I hate to ask a question in an answer, but if you do finding it having errors writing to the registry, how do you allow certain registry areas? –  Jacob Jun 3 '09 at 15:22
    
Thanks Grawity. You're right. Stupid typing fingers here! Jacob, you can control permissions in the registry via a similar mechanism to permissions on disk: ACLs that can be controlled via GPOs. –  RobM Jun 3 '09 at 15:27
2  
@Jacob: You can grant users permission to write to the registry on a per-key basis - just like NTFS folders. –  Ian Boyd Jun 3 '09 at 18:48
add comment

You might pick up some useful tips from the other thread on this subject: http://serverfault.com/questions/18435/legacy-apps-requiring-administrator-privileges-on-xp

You should then be able to set the necessary file system and registry permissions using a GPO.

share|improve this answer
add comment

I find Process Monitor and Microsoft Application Compatibility Toolkit useful when trying to get stuplegacy applications work. There's also LUA Buglight, but I haven't tried it.

As for locking down, I would give local admin rights to those users who know what they are doing, and are not going to "accidentially" destroy things. (this is only my opinion)

share|improve this answer
    
I certainly agree w/ using tools like Process Monitor, the ACT, and LUA Buglight (which is nice-- I've used it), but I don't agree w/ giving users local admin, ever. Not even sysadmins should be logged-on and doing day-to-day activities with a local admin account. You should always have to explicitly logon as an administrator, either thru RunAs or other alternative credential mechanisms, or by an out-right logoff/logonn, when you want to perform administrative tasks. –  Evan Anderson Jun 3 '09 at 15:21
    
That I agree with. –  grawity Jun 3 '09 at 15:29
1  
I would have to find a user who knows what they're doing first. –  Kyle Noland Jun 3 '09 at 15:53
add comment

We deveoped two good methods for supporting users without Admin rights:

1. Create a group with "[user]-adm" accounts and create them for power users that might need access. Then make the accounts active for a couple of hours when they call needing the rights. They can right-click and use "RUN AS" to install with elevated rights.

2. We created a scheduled task that loaded a batch file on startup. If a user opened a shortcut on his desktop, it ran the batch file (already running in memory to avoid open-txt passwords) and added him to the local-admin group. An email is automatically sent to the helpdesk, and a timer starts that only keeps it active for 1 hour. The helpdesk ticket tracks usage, so any abuse is logged. That one worked pretty well, but the first option above is more supportable.

share|improve this answer
add comment

I very much disagree with never giving local-admin access. I would waste a colossal amount of time if I employed that practice. However, it is difficult to gauge trust for local admin the larger your organization gets. Consider employing a "Scorched Earth" policy for granting local admin with a signed form to accompany the granting thereof. Said policy would be "if you break it you're on your own, we'll spend a few minutes looking at it and then it's a wipe and reload."

share|improve this answer
    
I like your enthusiasm, but I think this type of policy is a quick way to start losing clients. –  Kyle Noland Jun 3 '09 at 15:55
1  
In my experience, quite the contrary. Users are very happy that they can do what they need to and seldom need their machines regenned. It does help that we have a process that lets us kick off a full ground-up regen with only about 2-3 minutes of a tech's time. –  squillman Jun 3 '09 at 16:50
    
Works well for power users/developers in a corporate environment. –  Brian Knoblauch Jun 3 '09 at 17:17
1  
I like your enthusiasm also, but I highly disagree with your opinion. Once you put such a system and policy in place and enforce it you, then you can then start approaching each issue individually and taking the right steps to maintain the security of your systems. Maintaining such a system sounds hard politically, and it is at first. But if you hold your guns and educated yourself more about how to do the right things, it gets easier over time. –  mrTomahawk Jun 3 '09 at 17:21
    
That's cool, and I understand your stance. I knew I would get some kickback for this one which is fine. –  squillman Jun 3 '09 at 17:47
add comment

I don't think you really know how the application works if really think that these applications need an Administrator in order to work. Product vendors will tell you this because its an easy cop out, but really its almost always not true. I work in a DOD environment and we never given any one administrative rights to their system, because there are always ways around it. I usually end up using Process Monitor which many people have mentioned, but you should also look at reading Aaron Margosis' "Non-Admin" WebLog, it's dedicated to how to overcome these issues and to always use a least privileged account. I also recommend listening to the Least User Access (LUA) podcast from Microsoft Technet Radio, as they touched this topic with Aaron Margosis. Aaron appears to a have a new tool called LUA Buglight 2.0 which is supposed to help in the process of overcoming the application requirements, but honestly I've never used it.

Least User Access (LUA)

share|improve this answer
add comment

You might also consider VMware's ThinApp (formerly Thinstall)

http://www.thinstall.com/

Not sure if this can work around this particular issue but it may be able to.

share|improve this answer
add comment

Virtual PC or VMWare may be a solution, depending on the situation.

share|improve this answer
add comment

The majority of applications that fail to run as standard user fail because of file or registry access that they're being denied.

On Windows XP you can ACL the various folder and registry locations that the program needs access to, so that the standard user can access them.

i.e. Give Everyone full control to

c:\Program Files\World of Warcraft
HLKM\Software\Green Planet\Project Quantum

If they're trying to register a COM object, or a file extension, you can ensure it's registered once, and then also give full control to that hive branch. e.g.:

HKLM\Software\Classes\GreenPlanet.ProjectQuantum.1
HKLM\Software\Classes\CLSID\{9785B48F-520D-4179-8DEE-A4C7DDEBAB4F}


If your people are running Windows Vista, they have a greater chance of successfully running as standard user. Microsoft bent over backwards to make apps run as standard user, when they would have failed on Windows XP.

Its file and registry virtualization is quite useful and working around applications that think they need to write to machine-wide locations.


The real answer is to fix the application. There is almost no application on earth that needs to write to machine-common locations. These applications should be fixed by the authors.

If you did manage to find the one or two apps on earth that have a ligitimate reason to write to common locations, and you don't want your users to be running as administrators, then you ACL the locations to they have access to them.

share|improve this answer
    
typically the application needs only modify or read access, I would shy from giving "Full Control" whenever possible –  mrTomahawk Jun 3 '09 at 20:44
    
Agreed, mrTomahawk. But generally i first try to make it work, then walk backwards. –  Ian Boyd Oct 30 '09 at 15:44
add comment

Is it possible to run the apps in a Terminal Session? This way you can give 'local admin' rights on the TS, but not on the actual local computer.

-JFV

share|improve this answer
    
Downside of giving local admin access rights on TS are two-fold here: 1) Apps that are "bad tempered" enough to need local admin will probably react to terminal servers with the same enthusiasm and emotional stability that I react to reality TV shows with (that is to say, not very much at all really). 2) Local Admin access on a TS means that if one user does something dumb or unlucky, they can ruin the service for everyone. However, this does lead me to wonder about virtualisation, if needs be. Each user's PC could run a Virtual PC image that can easily be replaced in the event of a problem –  RobM Jun 3 '09 at 17:01
    
I would definetly never do this. You are not only now requiring the additional costs associated with a dedicated TS, but you've also now pushed the security issue off onto a server instead of addressing it head on. –  mrTomahawk Jun 3 '09 at 17:16
1  
The reverse would be a better solution. All the controlled apps on the TS and the stuff that requires local admin be the only local apps. –  Brian Knoblauch Jun 3 '09 at 17:21
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.