Como permitir que usuários não administradores executem um script VBS que exija privilégios mais altos?

Question

Eu tenho um script vbs que precisa ser fornecido aos usuários finais, mas requer mais direitos do que eles têm em suas estações de trabalho bloqueadas - especificamente atualizando alguns valores do Registro HKLM e parando / iniciando um serviço do Windows. Existe uma maneira que eu possa fornecer-lhes a capacidade de executar o script para que ele funcione? por exemplo. Executar Como uma conta de usuário diferente, sem exigir que os usuários tenham uma conta diferente para fazer login como?

O script não faz parte de um processo de login. É permitir que os usuários que estão testando um produto de software apontem suas máquinas em um "ambiente" diferente, para que possam alternar entre os ambientes Test e Live.

ATUALIZAÇÃO: Eu estou bem, se a única solução significa fazer algo fora da VBS, apenas ter algumas opções seria bom.

    

Answer 1

Não sem criptografar a senha e incluí-la no script VBS.

Existem outras opções, como o script remoto, mas essas configurações podem estar desativadas dependendo se você faz parte de um domínio.

O script faz parte de um processo de login?

editar:

The script isn't part of a login process. It's to allow users who are testing a software product to point their machines at a different 'environment', so they can switch between Test and Live environments.

UPDATE: I'm ok if the only solution means doing something outside VBS, just having some options would be good.

Sem mais detalhes, a melhor solução que posso recomendar é criar uma conta de usuário separada e modificar as ACLs das chaves do Registro para permitir explicitamente que essa conta modifique essas chaves. Em seguida, execute o script nessa conta. Tente isso.

    

Answer 2

Uma maneira de fazer isso seria usar o NSSM ou uma ferramenta semelhante para executar o script como um serviço do sistema. Você pode configurar a segurança no serviço para permitir que o usuário inicie e, talvez, escreva um script que faça isso para eles.

    

Answer 3

Um pouco de resposta centrada em programação, mas eu escreveria um pequeno aplicativo Windows .NET e um aplicativo cliente que pudesse se comunicar de forma segura por WCF / remoting . O serviço apenas escutaria as solicitações do cliente e, se o cliente fosse autorizado, executaria o script. O serviço estaria sendo executado como uma conta com as permissões corretas.

EDITAR

Em uma estratégia semelhante, você pode configurar o script como uma tarefa agendada que está configurada para ser executada como um usuário com permissões para fazer o que você precisa. Em seguida, conceda aos usuários permissão para executar a tarefa agendada. Para fazer isso, você precisa entrar em %SYSTEMROOT%\System32\Tasks e definir as permissões de NTFS no arquivo de tarefa apropriado.

    

Answer 4

Se você puder configurar uma tarefa agendada e tiver acesso ao comando "schtasks" para executar a tarefa, poderá configurá-la para ser executada como qualquer usuário ou até mesmo direitos de acesso ao sistema, sem expor senhas ou permitir acesso elevado direitos para qualquer comando, exceto o que você configurou. Como é um pouco mais complicado, aqui está um link para minha resposta de outra pergunta / problema similar: superuser.com/a/903881/229612

    

Answer 5

Para conceder permissões para executar scripts no computador local

1. No Internet Explorer, abra% windir% \ system32 (por exemplo, C: \ WINDOWS \ System32).
2. No painel Detalhes, clique com o botão direito do mouse em cmd.exe e clique em Propriedades.
3. Na caixa de diálogo Propriedades do cmd.exe, na guia Segurança, clique em Adicionar.
4. Na caixa de diálogo Selecionar usuários, computadores ou grupos, no menu Enter os nomes dos objetos a serem selecionados,
5. digite o nome do usuário para quem você deseja conceder permissões e em seguida, clique em OK.

Na caixa de diálogo Propriedades do cmd.exe, na guia Segurança, na caixa Permissões para administradores, marque a caixa de seleção Permitir para Ler & Execute e clique em OK.