我们正在Windows 2003域中运行terminal服务器场，并发现正在应用于我们的TS服务器的软件限制GPO设置有问题。 以下是我们的configuration和问题的详细信息：
我们所有的服务器（域控制器和terminal服务器）都运行Windows Server 2003 SP2，域和林都在Windows 2003级别。 我们的TS服务器位于一个OU中，我们有特定的GPO链接并阻止了inheritance，所以只有TS特定的GPO被应用到这些TS服务器。 我们的用户都是远程的，没有工作站join到我们的域，所以我们不使用环回策略处理。 我们采取“白名单”的方式允许用户运行应用程序，因此只有我们批准和添加的path或散列规则才能运行。 我们将“软件限制”中的“安全级别”设置为“不允许”，并将“强制”设置为“除库以外的所有软件文件”。
我发现，如果我向用户提供应用程序的快捷方式，即使它不在“白名单”应用程序的“附加规则”列表中，也可以启动该应用程序。 如果我向用户提供应用程序的主要可执行文件的副本，并尝试启动它，则会得到预期的“此程序已被限制…”消息。 软件限制似乎确实有效，除了用户使用快捷方式启动应用程序，而不是从主可执行文件本身启动应用程序时，这似乎与使用软件限制的目的相矛盾。
我的问题是：有没有其他人看到这种行为？ 任何人都可以重现这种行为？ 我在理解软件限制方面错过了什么？ 是否有可能在软件限制中configuration错误？
编辑
为了澄清这个问题，
没有更高级别的GPO正在执行。 运行gpresults显示，实际上只有TS级别的GPO正在被应用，我确实可以看到我的软件关键词正在被应用。 没有path通配符正在使用中。 我正在使用位于“C：\ Program Files \ Application \ executable.exe”中的应用程序进行testing，并且应用程序可执行文件不在任何path或散列规则中。 如果用户直接从应用程序的文件夹启动主应用程序可执行文件，则强制执行软件限制。 如果我给用户一个指向“C：\ Program Files \ Application \ executable.exe”应用程序可执行文件的快捷方式，那么他们就可以启动该程序。
编辑
另外，LNK文件在指定的文件types中列出，因此它们应该被视为可执行文件，这意味着它们受到相同的软件限制设置和规则的约束。
所以我终于find了答案。 在我们的软件限制规则中有一条path规则：
％HKEY_LOCAL_MACHINE \ SOFTWARE \微软\的Windows \ CurrentVersion \ ProgramFilesDir的％
这允许程序文件目录内的任何可执行文件，并且它的子目录运行不受阻碍。 当您configuration软件限制时，此path默认添加。 删除此path规则会导致所有编程被拒绝，即使他们的可执行文件明确添加为一个不受限制的path。
这引出了一个问题：如果所有程序的99％安装到Program Files目录，但是我想限制某些程序，那么我怎样才能通过软件限制来实现？
这个问题同样重要，除了程序文件中没有的程序或可执行文件外，软件限制究竟有什么用处？
我会检查已经为用户创build的快捷方式的ACL。 根据软件限制策略最佳实践：安全策略; 安全服务 ，
用户可能会尝试通过重命名或移动不允许的文件或覆盖不受限制的文件来规避软件限制策略。 因此，build议您使用访问控制列表（ACL）来拒绝用户执行这些任务所需的访问权限
您可能想要尝试删除LNK作为指定的文件types。 即使他们被当作可执行文件，他们也不应该这样做。 这样软件限制应该被应用到由LNK文件指定的可执行文件，而不是LNK文件本身。
我已经经历了你在说什么 – 这是非常烦人的。 我很确定，默认情况下，您的用户可以运行安装在Program Files中的应用程序。
你有没有尝试限制访问与NTFS权限和白名单这样的应用程序？
然后，用户可以有任何他们想要的捷径，它不会帮助他们，因为他们无法访问该程序。
参考： http : //www.virtualizationadmin.com/articles-tutorials/terminal-services/security/locking-down-windows-terminal-services.html