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?
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.
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.
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)
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.
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."
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)
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.
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
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.:
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.
Virtual PC or VMWare may be a solution, depending on the situation.
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