6

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?

Kyle Noland
  • 1,039
  • 3
  • 19
  • 21

10 Answers10

8

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.

Rob Moir
  • 31,664
  • 6
  • 58
  • 86
  • 3
    Process Explorer is just a replacement to Task Manager. The monitoring tool is Process Monitor. – user1686 Jun 03 '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 03 '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. – Rob Moir Jun 03 '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 03 '09 at 18:48
3

You might pick up some useful tips from the other thread on this subject: Legacy apps requiring administrator privileges on XP

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

Community
  • 1
Maximus Minimus
  • 8,937
  • 1
  • 22
  • 36
2

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)

user1686
  • 8,717
  • 25
  • 38
  • 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 03 '09 at 15:21
  • That I agree with. – user1686 Jun 03 '09 at 15:29
  • 1
    I would have to find a user who knows what they're doing first. – Kyle Noland Jun 03 '09 at 15:53
2

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.

Mark H
  • 21
  • 1
1

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

squillman
  • 37,618
  • 10
  • 90
  • 145
  • I like your enthusiasm, but I think this type of policy is a quick way to start losing clients. – Kyle Noland Jun 03 '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 03 '09 at 16:50
  • Works well for power users/developers in a corporate environment. – Brian Knoblauch Jun 03 '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 03 '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 03 '09 at 17:47
0

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)

mrTomahawk
  • 1,119
  • 1
  • 10
  • 17
0

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.

Kevin Kuphal
  • 9,064
  • 1
  • 34
  • 41
0

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.

Ian Boyd
  • 5,131
  • 14
  • 57
  • 79
0

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

Scott
  • 1,173
  • 3
  • 13
  • 25
-2

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

JFV
  • 751
  • 1
  • 7
  • 15
  • 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 – Rob Moir Jun 03 '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 03 '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 03 '09 at 17:21