web-dev-qa-db-fra.com

Problèmes avec la signature du module et le catalogue SSIS Procédures internes

J'essaie de mettre en place une procédure stockée pour exécuter un package SSIS. Je souhaite permettre à un utilisateur d'exécuter uniquement cette procédure stockée, alors j'en ai besoin pour exécuter en tant qu'utilisateur différent.

J'ai trouvé cet article qui crée un certificat détaillé et la signature du module de sorte qu'un login privilégié puisse l'exécuter.

Lorsque j'essaie d'exécuter une commande imprenable le login, je reçois l'erreur suivante:

Impossible d'exécuter en tant que directeur du serveur, car le principal "crossdbcertlogin" n'existe pas, ce type de directeur ne peut pas être impersonné, ou vous n'avez pas la permission.

Voici un script pour reproduire le problème:

create certificate CrossDatabaseCert
ENCRYPTION BY PASSWORD = 'passA'
WITH SUBJECT = 'Certificate for Cross-Database Database Impersonation'
GO


CREATE Login CrossDbCertLogin FROM CERTIFICATE CrossDatabaseCert
GO

backup certificate CrossDatabaseCErt to file='C:\temp\CrossDatabaseCert.CER'
WITH PRIVATE KEY
(
    FILE = 'C:\temp\CrossDatabaseCert.PVK',
    DECRYPTION BY PASSWORD = 'passA',
    ENCRYPTION BY PASSWORD = 'passB'
)
go

use msdb
create certificate CrossDatabaseCert from file='C:\temp\CrossDatabaseCert.CER'
WITH PRIVATE KEY
(    FILE = 'C:\temp\CrossDatabaseCert.PVK',
    DECRYPTION BY PASSWORD = 'passB',
    ENCRYPTION BY PASSWORD = 'passA'
)
Go

EXECUTE AS LOGIN=N'CrossDbCertLogin';
SELECT 1

Finalement, j'ajoute le certificat à la procédure stockée, mais il semble que l'impersonnation ne fonctionne même pas, alors j'essaie de l'obtenir d'abord.

Qu'est-ce que je fais mal?

Edit: Un peu plus d'informations sur ma procédure.

Lorsque je le change à "exécuter comme propriétaire" (dans le même formulaire que l'exemple que j'ai suivi), je reçois les erreurs suivantes.

MSG 27123, Niveau 16, State 1, Procédure Create_Execution, ligne 39 L'opération ne peut pas être démarrée par un compte utilisant l'authentification SQL Server. Démarrez l'opération avec un compte qui utilise l'authentification Windows.

MSG 27123, niveau 16, état 1, procédure Set_Execution_Parameter_Value, ligne 34 L'opération ne peut pas être démarrée par un compte qui utilise l'authentification SQL Server. Démarrez l'opération avec un compte qui utilise l'authentification Windows.

Msg 27123, niveau 16, état 1, procédure start_execution, ligne 32 L'opération ne peut pas être démarrée par un compte utilisant l'authentification SQL Server. Démarrez l'opération avec un compte qui utilise l'authentification Windows.

Dans ma procédure, j'appelle trois procédures de catalogue SSIS internes: Create_Execution, Set_Execution_Parameter_Value, et Start_Execution.

Lorsque je modifie la procédure pour exécuter en tant que compte SQL Agent Service, je reçois l'erreur suivante:

MSG 15199, niveau 16, état 1, procédure PREPARY_EXECUTION, ligne 34 Le contexte de sécurité actuel ne peut pas être retourné. Veuillez passer à la base de données d'origine où "exécuter comme" a été appelée et l'essayer à nouveau.

EDIT2: J'ai fini par utiliser une SPROC SQLCLR pour appeler mon procédé original, qui a résolu toutes les problèmes.

sql-serverstored-proceduressecuritypermissionssql-server-2014
2
Mansfield

Dans le code de Védran que vous faites référence, il signe également la procédure stockée dans l'autre base de données. Je ne vois pas dans votre code que vous avez pris cette dernière étape.

Erland Sommarskog possède une vaste discussion à http://www.sommarskog.se/grantperm.html de ce problème. Cela inclut une discussion de, dans ses mots, "l'exécution problématique comme".

Dans le lien suivant, qui est pour commencer les travaux d'agent SQL, vous pouvez voir Encore un autre Approche de délégation des droits à un identifiant qui n'a aucun droit particulier. Voir: Autoriser non-sysadmin, non-propriétaire d'un travail d'agent SQL Server à l'exécuter

Si cela vous intéresse, vous pouvez créer votre propre procédure stockée pour permettre à votre utilisateur de démarrer le processus SSIS.

10/20/2014 Modifier: "Impossible d'exécuter en tant que directeur du serveur parce que ..."

Tout d'abord, si vous êtes un sysadmin, alors le problème n'est pas vos droits, mais le contexte que vous essayez de courir. (Je crois que vous êtes un sysadmin.) Donc, cela pourrait être quelque chose comme:

  1. Si le principe du serveur que vous souhaitez utiliser est un Windows Group Cela ne peut pas être impersonné.
  2. Avez-vous récemment restauré une base de données système (E.G. msdb) d'un autre serveur? Ensuite, le compte que vous voyez dans msdb peut ne pas correspondre à un compte sur le serveur actuel. (Vous pourriez voir le même nom dans database_principals, mais le sid pourrait être différent.) Si tel est le cas, essayez d'utiliser exec sp_change_users_login 'AutoFix','principalname'.
  3. Si le propriétaire d'une base de données (en master.sys.databases) n'est pas le même sid comme l'utilisateur dbo de la base de données, il ne peut pas être impersonné. (Ceci est peu probable dans msdb depuis sa est le propriétaire normal de msdb.)
  4. Si la connexion a été supprimée, même si l'utilisateur reste dans la base de données, vous ne pourrez peut-être pas pouvoir imiter le compte.

Et il y a probablement d'autres saveurs aussi.

3
RLF