Estou coletando dados de desempenho por meio do WMI e gostaria de evitar a necessidade de usar uma conta no grupo Administradores para essa finalidade. A máquina de destino está executando o Windows Server 2003 com o SP / updates mais recente.
Eu fiz o que acredito ser a configuração apropriada para permitir que nosso usuário acesse o WMI (semelhante ao descrito aqui: link ).
Aqui estão os passos específicos que foram seguidos:
Eu consigo me conectar remotamente por meio do WMI Explorer, mas quando realizo essa consulta:
Select CommandLine, ProcessId FROM Win32_Process
Eu recebo um resultado válido, mas cada linha tem uma linha de comando vazia. Se eu adicionar o usuário ao grupo Administradores e executar novamente a consulta, a coluna Linha de Comando conterá os dados esperados.
Parece que há uma permissão que estou perdendo em algum lugar, mas não estou tendo muita sorte em rastreá-lo.
Muito obrigado antecipadamente.
A concessão do direito de usuário 'depurar programas' na diretiva de segurança local permite acesso às informações de CommandLine / ExecutablePath. E, embora ainda seja melhor do que usar uma conta de administrador (local), ela ainda representa um risco de segurança. É por isso que postei uma pergunta de acompanhamento para ver se ela pode ser realizada com privilégios mais baixos aqui:
Quais são as permissões mínimas para o WMI? acesso aos processos CommandLine?
Eu não acredito que isso seja um problema de permissões, mas talvez uma sutileza de sua estrutura de consulta, e vou explicar por meio do código que criei para executar apenas essa operação (para poder armazenar em cache posteriormente as linhas de comando ).
No código do meu aplicativo CacheMyWork (que você pode navegar aqui ), a consulta específica que Eu emito - e que definitivamente retorna os resultados da CommandLine - é
SELECT CommandLine FROM Win32_Process WHERE ProcessId =
Eu não usei o WMI Explorer por um tempo, mas talvez ele retorne o CommandLine para um único processo, mas não para o array inteiro de uma só vez? Não sei.
Eu tive este aplicativo disponível por três anos, e embora eu não me lembre no momento da última vez que testei enquanto estava sendo um usuário não-administrador, tenho 99% de certeza de que ele deve funcionar cenário porque milhares o baixaram e ninguém ainda relatou que não estava reiniciando aplicativos em cache após a reinicialização. [Sim, eu sei o que acontece com as pessoas que ASSUME, mas isso não me impediu de ser um asseverador imprudente aqui.]
É um pouco embaraçoso mudar minha opinião sobre isso tão completamente, mas seu comentário subsequente à minha primeira tentativa faz com que a teoria das permissões pareça muito mais convincente de repente.
O Windows atualmente possui permissões que são designadas de maneira diferente dependendo se o processo de solicitação é remoto ou local, e isso fede ao tipo de comportamento que vi quando um objeto é ACL para que o INTERACTIVE seja permitido mas REMOTE não é. Quando você faz logon via RDP, seu token de acesso incluirá o SID INTERATIVO; Quando você executa uma consulta remota (que usa RPC, que geralmente vem em pipes nomeados ou TCP / IP), seu token de acesso não inclui INTERACTIVE mas em vez disso REMOTE. Além disso, tenho visto casos em que duas tentativas de acesso ou sessões de logon diferentes acabam de alguma forma "reunindo" seus direitos de acesso combinados, portanto, seu caso de "quando eu estou conectado, a consulta remota do WMI também é bem-sucedida" faz sentido. Eu teria que reler o Windows Internals para entender se as sessões, WinStations ou tokens de acesso estão sendo compartilhados, mas certamente o que você relata é consistente com algumas experiências que tive.
Não há uma boa razão para o atributo CommandLine ser ACL diferente do atributo ProcessID, mas parece que é isso que está acontecendo. Gostaria de saber se isso era algo que você poderia alterar por meio de configurações profundamente incorporadas ou se ele é simplesmente codificado no sistema operacional Windows.
Voltei pelas etapas de alteração de permissões descritas na pergunta original e havia dois lugares em que a diferença local / remota parecia aparecer:
Eu focalizaria suas investigações nessas áreas e em qualquer outro lugar você perceberia essas permissões diferenciais locais / remotas (INTERATIVAS / REMOTAS). Embora nenhum deles aponte definitivamente para o atributo CommandLine que você está seguindo, é quase certo em minha mente (sim, ainda mais certo que a minha resposta anterior) que diferenças como essas explicarão o comportamento que você está vendo e fechará O intervalo entre "remoto" e "local" permitiria os resultados que você procura. [Vamos apenas esperar que a Microsoft não codifique coisas para que - não importa o que você configure - você não possa expor o atributo CommandLine para consultas remotas. Não seria a primeira vez que um design hard-coded de visão curta frustrava nosso uso do sistema operacional ...]
Ah, desculpe, essa é uma pergunta antiga, mas acho que isso funcionaria se alguém tivesse um problema semelhante:
Por favor, experimente o seguinte:
Em vez de "Usuários do Monitor de Desempenho", teste SUA etapa 1 com "Usuários de LOG de Desempenho" e permita somente "Métodos de Execução" e "Ativação Remota" para o grupo "Usuários de Log de Desempenho". E aplique os direitos a "este e subordinar namespaces". E não se esqueça de adicionar seu usuário ao novo grupo ...
eu tive um problema semelhante (mas outro WMI-Class) e ele trabalhou com o grupo "Performance LOG Users" mas não com "Performance Monitor Users" ...
Espero que isso funcione para você também ...
p.s. no win08 ou superior, se você acha que pode deixar seus passos 2 ou 3. Mas eu não sei se eles são necessários para o win03.
Tags permissions security wmi