Restrições de software do Windows 2003 GPO

Estamos executando um farm do Terminal Server em um domínio do Windows 2003 e encontrei um problema com as configurações de GPO de restrições de software que estão sendo aplicadas aos nossos servidores TS. Aqui estão os detalhes de nossa configuração e o problema:

Todos os nossos servidores (controladores de domínio e servidores de terminal) estão executando o Windows Server 2003 SP2 e o domínio e a floresta estão no nível do Windows 2003. Nossos servidores TS estão em uma UO em que temos GPOs específicos vinculados e a herança é bloqueada; portanto, apenas os GPOs específicos do TS são aplicados a esses servidores TS. Nossos usuários são todos remotos e não têm estações de trabalho associadas ao nosso domínio, portanto, não usamos o processamento da política de loopback. Adotamos uma abordagem de "lista de permissões" para permitir que os usuários executem aplicativos; portanto, somente os aplicativos que aprovamos e adicionamos como regras de caminho ou hash podem ser executados. Temos o nível de segurança em restrições de software definido como Não permitido e a aplicação está definida como "Todos os arquivos de software, exceto as bibliotecas".

O que descobri é que, se eu der um atalho a um aplicativo, ele poderá iniciá-lo, mesmo que não esteja na lista Regras Adicionais de aplicativos "na lista de permissões". Se eu der a um usuário uma cópia do executável principal do aplicativo e ele tentar iniciá-lo, eles receberão a mensagem "este programa foi restringido ...". Parece que as Restrições de Software estão realmente funcionando, exceto quando o usuário inicia um aplicativo usando um atalho, em vez de iniciar o aplicativo a partir do próprio executável principal, o que parece contradizer o objetivo de usar Restrições de Software.

Minhas perguntas são: Alguém mais viu esse comportamento? Alguém mais pode reproduzir esse comportamento? Estou faltando alguma coisa no meu entendimento das Restrições de Software? É provável que eu tenha algo mal configurado nas Restrições de Software?

EDITAR

Para esclarecer um pouco o problema:

Nenhum GPO de nível superior está sendo imposto. A execução de gpresults mostra que, de fato, apenas os GPOs no nível TS estão sendo aplicados e, de fato, posso ver minhas Restictions de Software sendo aplicadas. Nenhum curinga de caminho está em uso. Estou testando com um aplicativo que está em "C: \ Arquivos de Programas \ Aplicativo \ executable.exe" e o executável do aplicativo não está em nenhuma regra de caminho ou hash. Se o usuário iniciar o aplicativo principal executável diretamente da pasta do aplicativo, as Restrições de Software serão aplicadas. Se eu der ao usuário um atalho que aponte para o aplicativo executável em "C: \ Arquivos de Programas \ Aplicativo \ executable.exe", eles poderão iniciar o programa.

EDITAR

Além disso, os arquivos LNK são listados nos Tipos de arquivo designados, portanto devem ser tratados como executáveis, o que significa que estão vinculados pelas mesmas configurações e regras de restrições de software.

Então, finalmente encontrei a resposta. Nas nossas regras de Restrições de Software, existe uma regra de caminho como tal:

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

Isso permite que qualquer executável dentro do diretório Arquivos de Programas e seus diretórios filhos sejam executados sem ônus. Esse caminho é adicionado por padrão quando você configura Restrições de Software. A remoção dessa regra de caminho faz com que todo o programa seja negado, mesmo que seu executável seja explicitamente adicionado como um caminho irrestrito.

O que suscita a pergunta: se 99% de todos os programas estão instalados no diretório Arquivos de Programas, mas eu quero restringir determinados programas, como posso fazer isso com Restrições de Software?

Igualmente importante é a pergunta: exatamente qual é a utilidade das restrições de software, exceto para os programas ou executáveis ​​não localizados em arquivos de programas?

Eu verificaria as ACLs no atalho que você foi criado para os usuários. De acordo com as práticas recomendadas de Políticas de restrição de software: Política de segurança; Serviços de Segurança ,

Os usuários podem tentar burlar as políticas de restrição de software renomeando ou movendo arquivos não permitidos ou substituindo arquivos irrestritos. Como resultado, é recomendável usar as ACLs (listas de controle de acesso) para negar aos usuários o acesso necessário para executar essas tarefas.

Você pode tentar remover o LNK como um tipo de arquivo designado. Mesmo sendo tratados como executáveis, não deveriam ser. Dessa forma, as restrições de software devem ser aplicadas ao executável direcionado pelo arquivo LNK, e não ao próprio arquivo LNK.

Eu experimentei o que você está falando - é muito chato. Tenho certeza de que, por padrão, seus usuários têm permissão para executar aplicativos instalados nos Arquivos de Programa.

Você já tentou restringir o acesso a aplicativos com Permissões NTFS e lista branca dessa maneira?

Os usuários poderiam ter atalhos para o que quisessem e isso não os ajudaria, uma vez que não poderiam acessar o programa.

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