Como você bloqueia estações de trabalho e ainda suporta aplicativos legados que exigem direitos de administrador local?

5

Eu sei que todos nós lutamos para encontrar um equilíbrio entre manter as estações de trabalho dos usuários trancadas, mas ainda utilizáveis. Eu tenho um problema real com um cliente cujos usuários estão constantemente instalando barras de ferramentas, jogos, malware, etc. Eu realmente quero ser capaz de tirar seus direitos administrativos locais (e também o gerenciamento). O problema é que eles contam com um punhado de aplicativos mal escritos que exigem direitos de administrador local para serem executados corretamente. Antes de qualquer um sugerir, não é possível se livrar dessas aplicações.

Eu percebo que posso criar atalhos personalizados para esses aplicativos usando o comando runas e salvando as credenciais do administrador local. O problema com esta solução é:

  • Eu tenho que fornecer manualmente as credenciais do administrador local para cada usuário.
  • Alguns dos programas dependem de dados no perfil de usuário local e não funcionam corretamente se forem "induzidos" a pensar que estão sendo executados no perfil ComputerName \ Administrator.

O que eu adoraria é instalar algum aplicativo ou aplicar uma Política de Grupo que me permita especificar aplicativos que devem ter permissão para elevar as permissões do perfil local. Existe uma solução como esta disponível?

Como todo mundo lida com o bloqueio de estações de trabalho e ainda suporta software legado / mal escrito?

    
por Kyle Noland 03.06.2009 / 17:06

10 respostas

8

É raro que um pacote de software realmente precise de direitos de administrador, mas esteja gravando em uma área do registro ou do disco rígido que os administradores normalmente têm acesso e outros usuários não. Isso pode soar como nit-picking, mas é fundamental para pregar esta questão.

Você pode usar as ferramentas de edição do monitor edição: thanks grawity da Microsoft para monitorar o que os aplicativos estão fazendo e alocar direitos para essas áreas aos usuários. link

Em seguida, você pode usar diretivas de grupo para aplicar as ACLs de segurança a arquivos, pastas e partes do Registro. Uma causa comum desse problema é a gravação do programa em / ou sua pasta de instalação em c: \ arquivos de programas ou suas configurações globais no registro da máquina em HKey Local Machine.

    
por 03.06.2009 / 17:15
3

Você pode encontrar algumas dicas úteis do outro tópico sobre este assunto: Aplicativos legados que exigem privilégios de administrador no XP

Em seguida, você poderá definir as permissões necessárias do sistema de arquivos e do Registro usando um GPO.

    
por 03.06.2009 / 19:12
2

Eu localizo Monitor de processos e Microsoft Kit de Ferramentas de Compatibilidade de Aplicativos útil ao tentar fazer com que os aplicativos legados estúpidos funcionem. Há também LUA Buglight , mas ainda não tentei.

Quanto ao bloqueio, daria direitos de administrador local para os usuários que sabem o que estão fazendo e não vão "acidentalmente" destruir as coisas. (esta é apenas a minha opinião)

    
por 03.06.2009 / 17:14
2

Desenvolvemos dois bons métodos para oferecer suporte a usuários sem direitos de administrador:

1 . Crie um grupo com contas "[user] -adm" e crie-as para usuários avançados que possam precisar de acesso. Em seguida, faça as contas ativas por algumas horas quando elas precisarem dos direitos. Eles podem clicar com o botão direito do mouse e usar " EXECUTAR COMO " para instalar com direitos elevados.

2 . Criamos uma tarefa agendada que carregou um arquivo de lote na inicialização. Se um usuário abrisse um atalho em sua área de trabalho, ele executaria o arquivo de lote (já em execução na memória para evitar senhas de texto aberto) e o adicionaria ao grupo de administração local. Um e-mail é automaticamente enviado para o helpdesk, e um temporizador é iniciado, mantendo-o ativo por apenas 1 hora.  O ticket do helpdesk rastreia o uso, portanto, qualquer abuso é registrado. Esse funcionou muito bem, mas a primeira opção acima é mais suportável.

    
por 18.12.2011 / 03:26
1

Eu discordo muito de nunca dar acesso ao administrador local. Eu gastaria uma quantia colossal de tempo se empregasse essa prática. No entanto, é difícil avaliar a confiança do administrador local quanto maior for sua organização. Considere o uso de uma política de "Terra Escaldada" para conceder ao administrador local um formulário assinado para acompanhar a concessão do mesmo. Essa política seria "se você quebrar você por conta própria, passaremos alguns minutos olhando para ela e, em seguida, será uma limpeza e recarga".

    
por 03.06.2009 / 17:31
0

Eu não acho que você realmente saiba como o aplicativo funciona se realmente achar que esses aplicativos precisam de um administrador para funcionar. Os vendedores de produtos irão dizer-lhe isto porque é fácil, mas na verdade nem sempre é verdade. Eu trabalho em um ambiente DOD e nunca concedemos nenhum direito administrativo ao sistema deles, porque sempre há maneiras de contornar isso. Eu geralmente acabo usando o Processo Monito que muitas pessoas mencionaram, mas você também deve olhar lendo Aaron Margosis 'Weblog não-administrador ", ele é dedicado a como superar esses problemas e sempre usar uma conta com menos privilégios . Também recomendo escutar o podcast de acesso de menor usuário (LUA) do Microsoft Technet Radio , conforme eles tocaram tópico com Aaron Margosis. Aaron parece ter uma nova ferramenta chamada LUA Buglight 2.0 que supostamente ajuda no processo de superação dos requisitos do aplicativo, mas honestamente eu nunca usei isso.

Acesso de menor usuário (LUA)

    
por 03.06.2009 / 19:15
0

Você também pode considerar o ThinApp da VMware (antigo Thinstall)

link

Não tenho certeza se isso pode contornar esse problema específico, mas pode ser possível.

    
por 03.06.2009 / 19:15
0

O Virtual PC ou o VMWare podem ser uma solução, dependendo da situação.

    
por 03.06.2009 / 20:53
0

A maioria dos aplicativos que não são executados como usuário padrão falham devido ao acesso arquivo ou Registro que estão sendo negados.

No Windows XP, é possível ACL os vários locais de pasta e registro que o programa precisa acessar, para que o usuário padrão possa acessá-los.

i.e. Conceder todos controlo total a

c:\Program Files\World of Warcraft
HLKM\Software\Green Planet\Project Quantum

Se eles estiverem tentando registrar um objeto COM ou uma extensão de arquivo, você pode garantir que ele seja registrado uma vez e, depois, também dar controle total a essa ramificação da seção. por exemplo:

HKLM\Software\Classes\GreenPlanet.ProjectQuantum.1
HKLM\Software\Classes\CLSID\{9785B48F-520D-4179-8DEE-A4C7DDEBAB4F}

Se seus funcionários estiverem executando o Windows Vista, eles terão mais chances de serem executados com êxito como usuários padrão. Microsoft se inclinou para trás para fazer aplicativos rodarem como usuário padrão, quando eles teriam falhado no Windows XP.

Sua virtualização de arquivos e registros é bastante útil e trabalha em torno de aplicativos que acham que precisam gravar em locais de toda a máquina.

A verdadeira resposta é consertar o aplicativo. Quase não há aplicações no mundo que precisem gravar em locais comuns às máquinas. Estas aplicações devem ser corrigidas pelos autores.

Se você conseguiu encontrar um ou dois aplicativos no mundo que têm um motivo mínimo para escrever em locais comuns e não quer que seus usuários estejam em execução como administradores, ACL os locais a que eles têm acesso para eles.

    
por 03.06.2009 / 20:39
-2

É possível executar os aplicativos em uma sessão de terminal? Dessa forma, você pode conceder direitos de 'administrador local' no TS, mas não no computador local real.

-JFV

    
por 03.06.2009 / 17:34