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 exécuté en tant que le compte de service de l'Agent SQL Server.
Ainsi, les données vont essentiellement source system ~> transit db ~> staging ~> NDS pendant la nuit.
Les deux packages SSIS qui m'intéressent, gèrent le transit db ~> staging et staging ~> NDS parties, respectivement, pour un ensemble spécifique de données.
Un utilisateur de domaine (non administrateur système) fait quelque chose dans le source system et 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 déclencher cet ETL était de cliquer sur un bouton dans une macro- activé le classeur Excel, 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 de domaine, auquel j'ai accordé execute l'autorisation pour cette procédure UpdateMaterialInventory. Cela évite d'avoir à accorder à l'utilisateur du domaine execute l'autorisation de msdb.dbo.sp_start_job, ce qui serait excessif.
Le travail de l'Agent SQL NDS-ManualMaterialInventory appartient à l'utilisateur du domaine et comporte 2 étapes, chacune de type [Package SQL Server Integration Services], configurée sur Exécuter en tant queSSISProxy.
SSISProxy est un proxy de l'Agent SQL Server mappé au sous-système [SQL Server Integration Services Package], à 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.
Le SSISProxyCredentials a été créé avec le Identity 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 en moi-même et que je modifie les étapes 'exécuter en tant que pour être 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.