Security – How to lock down workstations and still support legacy applications that require local administrator rights

group-policylockdownpermissionsSecurity

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?

Best Answer

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.