Home / server / Questions / 112717
Accepted
joeqwerty
Asked: 2010-02-15 06:14:06 +0800 CST

Windows 2003 GPO Software Restrictions

  • 772

We're running a Terminal Server farm in a Windows 2003 Domain, and I found a problem with the Software Restrictions GPO settings that are being applied to our TS servers. Here are the details of our configuration and the problem:

All of our servers (Domain Controllers and Terminal Servers) are running Windows Server 2003 SP2 and both the domain and forest are at Windows 2003 level. Our TS servers are in an OU where we have specific GPO's linked and have inheritance blocked, so only the TS specific GPO's are applied to these TS servers. Our users are all remote and do not have workstations joined to our domain, so we don't use loopback policy processing. We take a "whitelist" approach to allowing users to run applications, so only applications that we approve and add as path or hash rules are able to run. We have the Security Level in Software Restrictions set to Disallowed and Enforcement is set to "All software files except libraries".

What I've found is that if I give a user a shortcut to an application, they're able to launch the application even if it's not in the Additional Rules list of "whitelisted" applications. If I give a user a copy of the main executable for the application and they attempt to launch it, they get the expected "this program has been restricted..." message. It appears that the Software Restrictions are indeed working, except for when the user launches an application using a shortcut as opposed to launching the application from the main executable itself, which seems to contradict the purpose of using Software Restrictions.

My questions are: Has anyone else seen this behavior? Can anyone else reproduce this behavior? Am I missing something in my understanding of Software Restrictions? Is it likely that I have something misconfigured in Software Restrictions?

EDIT

To clarify the problem a little bit:

No higher level GPO's are being enforced. Running gpresults shows that in fact, only the TS level GPO's are being applied and I can indeed see my Software Restictions being applied. No path wildcards are in use. I'm testing with an application that is at "C:\Program Files\Application\executable.exe" and the application executable is not in any path or hash rule. If the user launches the main application executable directly from the application's folder, the Software Restrictions are enforced. If I give the user a shortcut that points to the application executable at "C:\Program Files\Application\executable.exe" then they are able to launch the program.

EDIT

Also, LNK files are listed in the Designated File Types, so they should be treated as executable, which should mean that they are bound by the same Software Restrictions settings and rules.

windows windows-server-2003 group-policy

4 Answers

  1. Best Answer

    So I finally found the answer. In our Software Restrictions rules there is a path rule as such:

    %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

    This allows any executable inside of the Program Files directory and it's child directories to run unencumbered. This path is added by default when you configure Software Restrictions. Removing this path rule causes all programd to be denied, even if their executable is explicitly added as an unrestricted path.

    Which begs the question: If 99% of all programs are installed to the Program Files directory, but I want to restrict certain programs, how can I achieve this with Software Restrictions?

    Equally important is the question, exactly what good are Software Restrictions except for those programs or executables not located in Program Files?

    • 5

  2. I would check the ACL's on the shortcut that you have been created for the Users. As per the Software Restriction Policies Best Practices: Security Policy; Security Services,

    Users might try to circumvent software restriction policies by renaming or moving disallowed files or by overwriting unrestricted files. As a result, it is recommended that you use access control lists (ACLs) to deny users the access necessary to perform these tasks

    • 0

  3. You may want to try removing LNK as a designated file type. Even though they are being treated as executables, they shouldn't be. This way the software restrictions should be getting applied to the executable targetted by the LNK file, and not the LNK file itself.

    • 0

  4. I've experienced what you are speaking of -- it's very annoying. I'm pretty sure by default your users are allowed to run apps that are installed in Program Files.

    Have you tried restricting access to applications with NTFS Permissions and white listing that way?

    Then users could have shortcuts to whatever they wanted and it wouldn't help them since they wouldn't be able to access the program.

    Ref: http://www.virtualizationadmin.com/articles-tutorials/terminal-services/security/locking-down-windows-terminal-services.html

    • 0