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?


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.


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.

  • Do you have any GPOs in higher level OUs or at the domain level that are Enforced? I'd also check for paths that have wildcards or that might otherwise allow execution from the path the shortcut is in. – Chris S Feb 14 '10 at 16:03
  • @Chris S: See my edit. – joeqwerty Feb 14 '10 at 17:05
  • have you done a "gpresult /z /user dom\user" and looked at the results carefully? – tony roth Mar 24 '10 at 20:50
  • Yes. I'm not seeing anything that gives me any insight as to the cause. Thanks for the suggestion. – joeqwerty Mar 26 '10 at 15:20
  • @joeqwerty, What's joeqwerty supposed to mean? – Pacerier Jun 26 '15 at 8:53

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


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?

| improve this answer | |

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

| improve this answer | |
  • The users don't have access to perform the actions, so I don't think this applies. Thanks. – joeqwerty Mar 26 '10 at 15:21

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.

| improve this answer | |
  • Hmm... I didn't think to try that. I'll give it a whirl and let you know if it works. – joeqwerty Mar 26 '10 at 15:22

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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.