Temos um código herdado que ainda usa chamadas xp_cmdshell. Quando migramos para o SQL Server 2008, criamos um procedimento armazenado que usava o código conforme o seguinte padrão:
EXECUTE AS 'DOMAIN\ID2'
EXEC master..xp_cmdshell @command
REVERT
Quando passo WHOAMI como comando, o que mostra não é o 'DOMAIN\ID2', mas sim o ID da conta de serviço sob a qual o SQL Server está sendo executado (ou seja, 'DOMAIN\ID1'). Não deveria estar retornando 'DOMAIN\ID2', pois supostamente está sendo executado em um contexto de segurança diferente? Em caso afirmativo, alguma ideia de por que não mudaria o contexto? Este processo foi criado por outro desenvolvedor que já se foi há muito tempo e não estou realmente familiarizado com segurança e representação como provavelmente deveria estar.
Não seria bom encontrar uma ferramenta que permitisse representar para o Windows um usuário sem saber a senha ? Cada estagiário poderia se passar pelo CFO e sacar milhões do banco... As possibilidades!
Não,
EXECUTE AS
está alterando o contexto de segurança exclusivamente no que diz respeito aos objetos de acesso do SQL Server (tabelas, procedures etc). De forma alguma será (nem mesmo pode, no caso) ser capaz de alterar o contexto real de execução do NT para o processo ou para os processos iniciados pelo SQL Server.Atualizar
Obviamente, esqueci de adicionar a informação útil real: existe uma maneira de
xp_cmdshell
usar uma credencial específica, desde que você crie essa credencial no SQL Server:A principal diferença é que você está fornecendo a senha explicitamente aqui para o SQL Server. Agora o SQL Server usará esse 'proxy' de credencial sempre que for chamado
xp_cmdshell
de um contexto de login SQL ou de um contexto EXECUTE AS.Você também pode associar uma credencial a um login para acesso 'genérico' a recursos fora do SQL Server (por exemplo, acessar um compartilhamento de rede):