Exécution du package SSIS à partir du travail de l'Agent SQL appartenant à un utilisateur de domaine non administrateur système

J'ai deux packages SSIS qui s'exécutent pendant la nuit (via l'Agent SQL Server) dans le cadre d'un déploiement SSIS plus important, sans aucun problème. Tout utilise l'authentification Windows et le travail planifié appartient à un administrateur système (enfin, moi) et s'exécute en tant que compte de service de l'agent SQL Server.

Ainsi, les données vont essentiellement du source system ~> transit db ~> staging ~> NDSjour au lendemain.

Les deux packages SSIS qui m'intéressent, traitent respectivement les parties transit db ~> staginget staging ~> NDSpour un ensemble spécifique de données.

Un utilisateur de domaine (non administrateur système) fait quelque chose dans source systemet qui pousse les données intéressantes dans le transit db, j'ai donc besoin d'un moyen de récupérer ces données mises à jour pendant les heures de travail pour mettre à jour le NDS: il a été décidé que le moyen le plus simple pour cette personne de se déclencher cet ETL, était en cliquant sur un bouton dans un classeur Excel à macro, qui se connecte à SQL Server via ODBC (à l'aide de l'authentification Windows) et exécute une procédure stockée.

La procédure stockée ressemble à ceci:

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

La procédure stockée "sœur" dans [msdb] ressemble à ceci:

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

Cet utilisateur [SqlAgentProxy] est un utilisateur Windows que j'ai créé dans [msdb] à partir de la connexion de l'utilisateur du domaine, auquel j'ai accordé l' executeautorisation pour cette UpdateMaterialInventoryprocédure. Cela évite d'avoir à accorder à l'utilisateur du domaine une executeautorisation msdb.dbo.sp_start_job, ce qui serait excessif.

Le travail de l'Agent SQL NDS-ManualMaterialInventoryappartient à l'utilisateur du domaine et comporte 2 étapes, chacune de type [Package SQL Server Integration Services], configurée pour s'exécuter en tant que SSISProxy .

SSISProxyest un proxy de l'Agent SQL Server qui est mappé au sous-système [Package des services d'intégration SQL Server], à l'aide du nom d'informations d'identification SSISProxyCredentials. La connexion de l'utilisateur du domaine a été ajoutée aux principaux du compte proxy .

Ils SSISProxyCredentialsont été créés avec l' identité du même utilisateur de domaine qui exécute l'intégralité de SSIS ETL pendant la nuit, et son mot de passe a été quadruple-vérifié.

Maintenant, si je lance ceci:

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

J'obtiens cette sortie:

Job 'NDS-ManualMaterialInventory' started successfully.

Cependant, l'histoire de l'emploi raconte une histoire beaucoup moins encourageante:

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

Et les détails de l'étape 1:

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.

Le travail échoue et rien n'est enregistré nulle part.

Si je change le propriétaire du travail pour être moi-même et que le déroulement des étapes soit le compte de service de l'Agent SQL Server, le travail s'exécute, réussit et enregistre 1 067 lignes dans [Métadonnées]. [Dbo]. [Sysssislog].

Il semble que la configuration du proxy / des informations d'identification ne soit pas correcte. Quelle partie je fais mal?

Le problème semble plus complexe qu'il ne l'est. Étant donné que vous utilisez SQL 2014, vous êtes probablement mordu par les nouvelles fonctionnalités de sécurité introduites en 2012.

La seule chose qui compte vraiment est:

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}'.

La connexion de votre utilisateur proxy n'a probablement pas accès au catalogue SSISDB (même s'il peut avoir accès à SQL Server).
Vous devez mapper la connexion à un utilisateur SSISDB et configurer l'accès aux dossiers / projets SSISDB dans Integration Services.

Veuillez consulter cet article de blog MSDN Conseils de contrôle d'accès au catalogue SSIS et autorisations du catalogue SSIS SQL 2012

Une fois que le package est réellement chargé, vous pouvez rencontrer d'autres problèmes de contexte de sécurité, mais vous devriez obtenir une meilleure journalisation des services d'intégration eux-mêmes.