How to stop domain users from installing any software?

Hi everyone, I was wondering which policies, etc I could setup to stop any installations from occurring in a server 2003 domain environment? I have 2003 RC2 and XP Pro clients.

I guess the quick easy way is to make everyone guests, but this also blocks them from other things that they might need to do/access. I've seen a lot of ideas but they do not fully block everything. I know there probably isn't a fix all but would like to get as close as possible.

Thank you all,

From serverfault Chris

• The answer is to stop them from being administrators. If you are unwilling to do this, then there will always be a way for them to get around anything that you put in place.

  Chris : They are only domain users, no local admin or domain admin rights, they are still able to install software.

  MarkM : Domain users are limited users unless they are made local admins or power users on their computers or are part of the Domain Admins group. There is something you are missing if they can install software.

  Chris : I checked the groups and user profiles and they are only part of the domain users group, is there another spot where I am not looking? thanks for the reply

  tony roth : what groups\users are in the local administrators group on the workstations?

  Bart Silverstrim : Even plain non-admin users can install some software, depending on the access rights the software needs. A simple game could be completely encapsulated in a subdir of the home directory; if it doesn't need to touch the system dir or access protected parts of the registry, policies won't stop them.

  Chris : @tony roth, just ourdomain/Domain Admins and Administrators. Users do not have password to local admin. We only have one user on all workstations, administrator. No custom groups locally.

  tony roth : Like Bart says if an app doesn't follow the rules stuff can happen! Applocker is the best solution at this point!

  Chris : I understand, too bad I can't use it in my environment.

  Jim B : Installing software has little to do with being admin

  MarkM : @Jim B - Care to elaborate? A use cannot install software afaik unless they are in the Admin group, or there has been a group set up custom that has permission to the appropriate branches of the registry and application installation directory.

  Jim B : @mark you are operating under the assumption that the software you are installing requires registry access (to register DLLS et al). Directory access is controlled by the directory owner so directory access is wherever the user installing the software wants to create it. As an example you can install many clr based apps without registering anything, (so long as .net exists) and once java is installed it also usually requires no "install". In addition most of the .exe files from pstools don't require an install and neither does any malware I can think of.

  MarkM : Most of those examples would be considered running an application as opposed to installing one.
  From MarkM

• Remove local admin rights, remove local power user, spend hours debugging crappy and ill-architected software with access problems using sysinternals software to manually work around access issues.

  Set up software shares for home directories, profiles, etc. and redirect select subdirs (like my docs) to a network share. Then use something like Faronics Deep Freeze to "reset" the computer back to a pristine state after each restart.

  I think they also have software that can whitelist executables, but it will be a pain to set up and maintain if you have a large number of systems with diverse needs to attend to.

  Get systems without CD drives and use a portable USB drive for installation of software.

  Get HR to support policies that make it crystal clear what's allowed and what isn't on systems, that they're company property and that there's no expectation of privacy on them.

  Use filtering software to monitor web use and you can block out downloads if need be.

  How draconian do you want to get?

  You could also use images of your systems and periodically re-image your computers to a clean state. Still takes maintenance though, as an image a month out of date needs a month of patch-tuesdays installed, plus users still need their own data accounted for on the server or if they're managing to "accidentally" save things locally you're going to hear grumbling.

  You'll need to examine your policies and balance usability with how much of a PITA you're going to make it for employees to get their work done and how miserable you want to make your employees feel, if the employer expects a lot from the employees and at the same time won't give them any sense of empowerment or freedom at all...employees that feel a foot on the back and eyes over their shoulders have wonderfully creative ways of making your life more miserable and they won't feel bad in the least for it if they feel justified.

  Chris : thanks for the reply btw, unfortunately we are lax in our company. But I hate when people install any apps. If they need something installed it needs to go through us. The re imaging is a good idea, but like you said if they save anything local there then they will be pissed. Someone mentioned that being just domain users that it will stop installation, am i missing something? I only have them as domain users, no local admin or domain admin privileges.

  Bart Silverstrim : Local docs and such are an issue until user training takes over. Drill into them that documents can and will be lost if they don't save to the network; they'll lose them at some point anyway when the hard disk fails. THEN MAKE SURE YOUR NETWORK SHARES ARE SAFE with backups that are working. Otherwise, you tell them to save to XYZ so they'll be "safe" then you lose everything? They'll never trust you again.

  Bart Silverstrim : And no, you're not missing something. It entirely depends on the program design and privileges needed to run. Otherwise you wouldn't have issues with malware sneaking into your systems; they're programs running quite easily with user privileges (or initially running with user privileges to get a foothold on the system).

  Bart Silverstrim : The only way around it is to whitelist allowed exe files. A war of attrition can be waged using a Deep Freeze-like product, because users grow tired of reinstalling their pet programs each time they reboot. It's also a good training tool for users to save files where they're supposed to lest they lose them each reboot, but that's more of a BOFH perspective.

  Chris : We have a script that backs up there desktop/mydocs etc, so that part isn't a problem. So I think I'm going to test out some re imaging software like you said, thanks for the idea.

  tony roth : we just end up killing the lusers, its the cheapest solution to these types of problems. Truthfully you'd get fired for doing that around here!

  Chris : lol, I wish I could that!

  tony roth : I know of a fortune 50 firm that within a certain department almost everybodys an admin on servers (thousands of servers)! Jezzus, of course to be truthful this is a department that needs to be real agile and anything that slows them down gets frowned upon!
  From Bart Silverstrim

• They will always be able to "install" software that doesn't require admin access. A lot of software doesn't need to write to the Program Files folder or make any system wide changes. Especially simple apps that are just EXEs or "portable apps." Afterall, you allow them to run EXE files, right?

  If they are truly non-admins and do not have write or modify rights to Program Files or Windows then I bet they're just running simple apps. There's a group policy setting that lets you whitelist which EXEs are allowed, but I would be very careful with playing with that as it can make all your machines inoperable.

  Chris : I understand, I tried playing around with blocking exe's, but it gets a little crazy. Thanks for the reply.

  DrZaiusApeLord : No problem. I've noticed is that some installers will check for admin rights and if they don't have it, will then install themselves in the local profile. As as admin that's always bothered me. This is typical of ad-supported 'freeware.' I've always just ignored it or uninstalled it next time I worked on their computer.
  From DrZaiusApeLord

• Your first step will be to get buy-in from the business to actually allow you to do such a thing. Even in giant corporate secure environemnts I've seen execs unwilling to set up appication whitelists. After that you should look into software restriction policies.

  This allows you to allow or block software based on:

  Hash, Certificate, Path and Internet Zone.

  Where Software restriction does not apply is:

  Drivers or other kernel mode software.

  • Any program run by the SYSTEM account.

  • Macros inside of Microsoft Office 2000 or Office XP documents.

  • Programs written for the common language runtime.

  For CLR lockdown you should use CASPOL.

  The depoyment steps would be to set up a test machine and start locking down the policies. Admin rights have no effect on this type of restriction (unless you choose to see the link for details). Once you have locked down both regualr and CLR based software the only real source of worry is java.

  From Jim B