Issues with module signing and SSIS catalog internal procedures I'm trying to set up a stored procedure to execute an SSIS package. I want to allow a user to execute only this stored procedure, so I need it to run as a different user.

I found this article which detailed creating a certificate and signing the module so that a privileged login could execute it.

When I try to run any command impersonating the login, I receive the following error:


  Cannot execute as the server principal because the principal "CrossDbCertLogin" does not exist, this type of principal cannot be impersonated, or you do not have permission.


Here's a script to reproduce the problem:

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


Eventually I add the certificate to the stored procedure, but it seems the impersonation isn't even functioning so I'm trying to get that working first.

What am I doing wrong?

EDIT: A little more info on my procedure.

When I change it to "EXECUTE AS OWNER" (in the same form as the example I followed), I receive the following errors.


  Msg 27123, Level 16, State 1, Procedure create_execution, Line 39
  The operation cannot be started by an account that uses SQL Server Authentication. Start the operation with an account that uses Windows Authentication.
  
  Msg 27123, Level 16, State 1, Procedure set_execution_parameter_value, Line 34
  The operation cannot be started by an account that uses SQL Server Authentication. Start the operation with an account that uses Windows Authentication.
  
  Msg 27123, Level 16, State 1, Procedure start_execution, Line 32
  The operation cannot be started by an account that uses SQL Server Authentication. Start the operation with an account that uses Windows Authentication.


Inside my procedure I call three internal SSIS Catalog Procedures: Create_Execution, Set_Execution_Parameter_Value, and Start_Execution.

When I change the procedure to execute as the SQL Agent Service account, I get the following error:


  Msg 15199, Level 16, State 1, Procedure prepare_execution, Line 34
  The current security context cannot be reverted. Please switch to the original database where 'Execute As' was called and try it again.


EDIT2: I ended up using a SQLCLR SProc to call my original proc, which solved all the issues.
In Vedran's code which you reference, he also signs the stored procedure in the other database.  I do not see in your code that you have taken that final step.

Erland Sommarskog has an extensive discussion at http://www.sommarskog.se/grantperm.html of this problem.  This includes a discussion of, in his words, "the Problematic EXECUTE AS".

In the following link, which is for starting SQL Agent jobs, you can see yet another approach to delegating rights to a login which has no particular rights.  See: Allow non-sysadmin, non-owner of a SQL Server Agent job to execute it

If that appeals to you, you can create your own stored procedure to allow your user to start the SSIS process.

10/20/2014 Edit: "Cannot execute as the server principal because ..."

First of all, if you are a sysadmin, then the problem is not your rights, but the context you are trying to run.  (I believe that you are a sysadmin.)  So it could be something like:


If the server principle you want to use is a Windows Group it cannot be impersonated.
Have you recently restored a system database (e.g. msdb) from another server? Then the account you see in msdb may not match an account on the current server. (You might see the same name in database_principals, but the sid could be different.) If so, try using exec sp_change_users_login 'AutoFix','principalname'.
If the owner of a database (in master.sys.databases)is not the same sid as the 
database's dbo user, then it cannot be impersonated.  (This is unlikely in msdb since sa is the normal owner of msdb.)  
If the login was dropped, even if the user remains in the database, you may not be able to impersonate the account.


And there are likely other flavors as well.