Executando o pacote SSIS do trabalho do SQL Agent pertencente a um usuário de domínio não sysadmin

Eu tenho dois pacotes SSIS que são executados agendados da noite para o dia (via SQL Server Agent) como parte de uma implantação maior do SSIS, sem problemas. Tudo está usando autenticação do Windows, e o trabalho agendado pertence a um administrador de sistemas (bem, eu) e é executado como a Conta de Serviço do SQL Server Agent.

Portanto, os dados essencialmente passam da source system ~> transit db ~> staging ~> NDSnoite para o dia.

Os dois pacotes do SSIS com os quais me preocupo, lidam com as peças transit db ~> staginge staging ~> NDS, respectivamente, para um conjunto específico de dados.

Um usuário de domínio (não sysadmin) faz algo no source systeme que envia os dados interessantes para o transit db, então eu preciso de uma maneira de buscar esses dados atualizados durante o horário de trabalho para atualizar o NDS: foi decidido que a maneira mais simples de acionar essa pessoa esse ETL estava clicando em um botão em uma pasta de trabalho do Excel habilitada para macro, que se conecta ao SQL Server via ODBC (usando a Autenticação do Windows) e executa um procedimento armazenado.

O procedimento armazenado fica assim:

create procedure dbo.UpdateMaterialInventory
as
begin
    execute msdb.dbo.UpdateMaterialInventory;
end

O procedimento armazenado "irmã" no [msdb] se parece com o seguinte:

create procedure dbo.UpdateMaterialInventory
with execute as 'SqlAgentProxy'
as
begin
    execute msdb.dbo.sp_start_job N'NDS-ManualMaterialInventory';
end

Este usuário [SqlAgentProxy] é um usuário do Windows que criei em [msdb] fora do logon do usuário do domínio, ao qual concedeu executepermissão para este UpdateMaterialInventoryprocedimento. Isso evita ter de conceder ao usuário executepermissão de domínio msdb.dbo.sp_start_job, o que seria excessivo.

O trabalho do SQL Agent NDS-ManualMaterialInventorypertence ao usuário do domínio e possui 2 etapas, cada uma do tipo [Pacote do SQL Server Integration Services], configurada para Executar como SSISProxy .

SSISProxyé um proxy do SQL Server Agent que é mapeado para o subsistema [Pacote de Serviços de Integração do SQL Server], usando o nome da credencial SSISProxyCredentials. O logon do usuário do domínio foi adicionado aos principais da conta Proxy .

Eles SSISProxyCredentialsforam criados com a identidade do mesmo usuário do domínio que está executando o SSIS ETL inteiro durante a noite e sua senha foi verificada quatro vezes.

Agora, se eu executar isso:

execute as login=N'DOMAIN\thatperson'
exec NDS.dbo.UpdateMaterialInventory;
go

Eu recebo esta saída:

Job 'NDS-ManualMaterialInventory' started successfully.

No entanto, o histórico do trabalho está contando uma história muito menos animadora:

The job failed.  The Job was invoked by User DOMAIN\thatperson.
The last step to run was step 1 (Extract).

E o passo 1 detalha:

Executed as user: {domain user that runs SSIS ETL overnight}.
Microsoft (R) SQL Server Execute Package Utility  Version 12.0.4100.1 for 64-bit
Copyright (C) Microsoft Corporation. All rights reserved.
Started:  2:18:50 PM  Failed to execute IS server package because of error 0x80131904.
Server: {server name}, Package path: \SSISDB\Foo\Bar\foobar.dtsx, Environment reference Id: NULL.
Description: Login failed for user '{domain user that runs SSIS ETL overnight}'.
Source: .Net SqlClient Data Provider 
Started:  2:18:50 PM  Finished: 2:18:51 PM  Elapsed:  0.094 seconds.
The package execution failed.
The step failed.

O trabalho falha e nada é registrado em qualquer lugar.

Se eu alterar o proprietário da tarefa para ser eu mesmo e alterar a execução das etapas como a Conta de Serviço do SQL Server Agent, a tarefa será executada, bem-sucedida e registrará 1.067 linhas em [Metadados]. [Dbo]. [Sysssislog].

Parece que há algo errado sobre como os proxy / credenciais são configurados. Qual parte estou fazendo de errado?

O problema parece mais complexo do que é. Como você está usando o SQL 2014, provavelmente está sendo mordido pelos novos recursos de segurança introduzidos em 2012.

A única coisa que realmente importa é:

Server: {server name}, Package path: \SSISDB\Foo\Bar\foobar.dtsx, Environment reference Id: NULL.   
Description: Login failed for user '{domain user that runs SSIS ETL overnight}'.

O logon do usuário proxy provavelmente não tem acesso ao catálogo SSISDB (mesmo que ele possa ter acesso ao SQL Server).
Você precisa mapear o logon para um usuário do SSISDB e configurar o acesso às pastas / projetos do SSISDB no Integration Services.

Dê uma olhada nesta postagem no blog do MSDN Dicas de controle de acesso ao catálogo SSIS e permissões do catálogo SSIS do SQL 2012

Depois que o pacote estiver sendo carregado, você poderá encontrar outros problemas de contexto de segurança, mas deverá obter um log melhor nos próprios serviços de integração.