SQL Server – Cross-Database Impersonation Fail for Service Account

impersonationpermissionssql server

I would like to enable an application that dumps a big ol' heap of data into a Staging area to be able to kickoff the stored procedure that transforms & loads the data into the Production area. If possible, I'd like to not grant the application any access to the production area. Unfortunately, EXECUTE AS seems to be failing me. For reference, the DBs in question are running on 2008 R2, but I'm recreating the behavior on my 2016 localhost. As well, the service account in question is a domain credential, but I've recreated the behavior with a SQL Auth credential for portability.

The Setup

use [master]
create database Prod;
create database Stage;
create login ServiceAccount with password='Password1234';
go
use Prod
create table tbl1 ( i int );
insert tbl1 select 1;
go
use Stage
create user ServiceAccount for login ServiceAccount; 
go
create proc spLoadStageToProd as
begin
    insert Prod.dbo.tbl1(i)
    select checksum(newid())%100; -- random number
end;
go
grant execute on spLoadStageToProd to ServiceAccount;
go

The Testing

From the Stage database, exec spLoadStageToProd; succeeds. Predictably, exec as login = 'ServiceAccount'; exec spLoadStageToProd; fails with the error…

Msg 229, Level 14, State 5, Procedure spLoadStageToProd, Line 1 [Batch Start Line 21]
The EXECUTE permission was denied on the object 'spLoadStageToProd', database 'Stage', schema 'dbo'.

Okay, so I'll try execute as owner so that the proc has the permissions it needs to do the work but the (developer who has the password for) ServiceAccount doesn't get to muck about in my Production area.

alter proc spLoadStageToProd
with execute as owner
as
begin
    insert Prod.dbo.tbl1(i)
    select checksum(newid())%100; -- random number
end;
go

Shoot! Well now a simple test from Staging of exec spLoadStageToProd; returns the error:

Msg 916, Level 14, State 1, Procedure spLoadStageToProd, Line 5 [Batch Start Line 35]
The server principal "DOMAIN\peter" is not able to access the database "Prod" under the current security context.

"DOMAIN\peter" is of course me: the doof with sysadmin server role…

Well that's weird enough… I tried alter authorization on object::spLoadStageToProd to dbo; but the same error (Msg 916) pops up. What's more… exec as login = 'ServiceAccount'; exec spLoadStageToProd; now returns…

Msg 229, Level 14, State 5, Procedure spLoadStageToProd, Line 1 [Batch Start Line 37]
The EXECUTE permission was denied on the object 'spLoadStageToProd', database 'Stage', schema 'dbo'.

Screw it! alter authorization on object::spLoadStageToProd to sa;…

Msg 15151, Level 16, State 1, Line 41
Cannot find the user 'sa', because it does not exist or you do not have permission.

…

…sad.

So… clearly I'm misunderstanding something fundamental. I tried enabling cross-db ownership chaining just in case that was the sticky wicket but no luck. After fruitless googling and a quick scan of these two dba.se questions, I'm pretty stuck. Where am I going wrong?

How do I get this SProc to run on elevated cross-database permissions regardless of who calls it?

The project that precipitated this question is an iterative deprecation so I think cert-signing may end up being a rather large administrative overhead as time goes on.

If it is possible to use this stored proc as a wrapper to execute restricted actions agnostic of who calls it, that's the end-goal.

I am confident that the SProc cannot be improperly modified, so anything that executes from inside it may be highly permissioned – in the hopes that I don't need to administer perms for the ServiceAccount one-by-one.

Courtesy Cleanup Script

revert;
use [master]
go
drop database Prod,Stage;
drop login ServiceAccount;
go

Best Answer

Correct: Impersonation / EXECUTE AS, by default, is quarantined to the initial database. In order to get around this you need to do either set the initial database to TRUSTWORTHY ON (not a great option, so should be viewed as a last resort), or create a Certificate that can be in both the initial DB and the destination DB that can be used to link the desired permissions (and then you don't need Impersonation at all).

I have several examples of doing this across various answers here on DBA.StackExchange. Try these first:

Stored procedure security with execute as, cross database queries, and module signing (this one goes through, step by step, showing how Impersonation, Cross-DB Ownership Chaining, and TRUSTWORTHY work, and then how module signing eliminates the need for all three of those options).
Permissions in triggers when using cross database certificates

Now, given the new information added to the question regarding:

The project that precipitated this question is an iterative deprecation so I think cert-signing may end up being a rather large administrative overhead as time goes on.

and:

If it is possible to use this stored proc as a wrapper to execute restricted actions agnostic of who calls it, that's the end-goal. ... I am confident that the SProc cannot be improperly modified, so anything that executes from inside it may be highly permissioned - in the hopes that I don't need to administer perms for the ServiceAccount one-by-one.

the direction to take can be narrowed down. Usually the goal is to be as granular as possible with the permissions, so it sometimes takes some extra steps to get to a least-privileged setup. But that doesn't mean that you can't take fewer steps to be less granular when the situation calls for it.

One of the (several) wonderful aspects of module signing is that you are effectively giving permissions to the code, not to people. So you can control the who can make use of the permissions by properly setting permissions on whatever code (i.e. Stored Procedures, Functions, Triggers, etc) is being signed.

Assuming you want both Server/Instance -level and Database-level permissions, even if you don't end up using most of what will be allowed, you can do the following:

Create a Certificate in [master].
Create a Login from that Certificate.
Add the Certificate-based Login to the sysadmin Fixed Server Role.
Switch to the Stage DB
Re-create the same Certificate in this DB (either by backing it up to a file on disk OR by extracting both the Certificate and the Private Key to variables or a local temporary table as shown in my other answers).
Sign the Stored Procedure with this Certificate via ADD SIGNATURE.

That's it! The Stored Procedure, regardless of who executes it, can do anything it was coded to do. And if that code changes, you will need to do the ADD SIGNATURE again. But the Certificate-based Login cannot be Impersonated, so nobody can use it to get "sa" privileges. And, if you use "encrypt by password" when creating the Certificate and do not give that password to anyone, then nobody will be able to sign other modules with it.

In this setup, the only on-going administration would be re-signing the Stored Procedure if you keep changing it.

Also, regarding your final attempt (i.e. alter authorization on object::spLoadStageToProd to sa;): that doesn't work because "sa" is a Login (Instance / Server -level), not a User (Database-level). So you can only grant permissions on database-level items to principals found in sys.database_principals.

Related Solutions

Sql-server – Access denied when disabling agent job, despite SqlAgentOperator membership

Please check to see if there is a DENY on the sp_update_job procedure. This may be a direct DENY to your login or it may be a DENY on some group that has your login as a member. DENY always trumps a grant.

If so, then removing your login from the group or having an administrator REVOKE the DENY should solve the problem.

Response prompted by reading Piers7 request. Time has passed, of course.

Execute Permission Denied on Object sp_start_job in SQL Server

I don't like the TRUSTWORTHY option because it significantly increases your exposure to a variety of things. As Remus explains in this answer, it essentially elevates any db_owner to sysadmin. Some other things worth reading are a series on TRUSTWORTHY by Sebastian Meine, the BOL topic, and a KB article (even though the assembly portions may not be relevant to you in this scenario):

(And there are tons of other posts out there cautioning against the blind use of this property - just because it works and it is easy doesn't mean it's the right thing to do - in fact that should make you question it even more.) So I would suggest a different approach (and there are still others, such as signing with a certificate, but this has always worked for me):

Create the procedure in msdb.

Create a user for this user's login in msdb:

USE msdb;
GO
CREATE USER floobarama FROM LOGIN floobarama;

Grant the user execute privileges on the stored procedure:
```
GRANT EXECUTE ON [dbo].[RunJob] TO floobarama;
```

Test it - either by calling the procedure from another database:

USE tempdb;
GO
EXECUTE AS LOGIN = N'floobarama';
GO
EXEC msdb.dbo.RunJob @job_name = N'whatever';
GO
REVERT;

Or an easier test, in case you don't want to run any job now and don't want to wait until this user executes it to find out whether they have sufficient access to msdb:

USE msdb;
GO
CREATE PROCEDURE dbo.whatever
WITH EXECUTE AS N'sysadminaccount'
AS
BEGIN
  SET NOCOUNT ON;
  SELECT [I am really...] = SUSER_SNAME();
END
GO
GRANT EXECUTE ON dbo.whatever TO floobarama;

USE tempdb;
GO
EXECUTE AS LOGIN = N'floobarama';
GO
EXEC msdb.dbo.whatever;
GO
REVERT;

Result should be:

I am really...
---------------
sysadminaccount

Validate that this doesn't expose anything else in msdb to this user:
```
USE tempdb;
GO
EXECUTE AS LOGIN = N'floobarama';
GO
SELECT job_id FROM msdb.dbo.sysjobs;
GO
REVERT;
```
Result should be...

Msg 229, Level 14, State 5, Line 21
The SELECT permission was denied on the object 'sysjobs', database 'msdb', schema 'dbo'.

...since creating a user in a database doesn't give them automatic rights to anything in that database; you need to explicitly do so either for that user, or for a role or group they are in (including public).