I have a Microsoft SQL Server 2014. The mail system is configured via DBMail and there is one stored proc in main web app (having its own database) which executes msdb's sysmail_update_account_sp by selecting the appropriate profile using msdb.dbo.sysmail_account.
The problem I am facing is the web application has a SQL login and I want to switch context and execute sysmail_update_account_sp.
EXEC AS USER = @UserName
SET @AccountNr = ( SELECT TOP 1 account_id FROM msdb.dbo.sysmail_account WHERE name = @DatabaseName ORDER BY account_id )
IF @AccountNr > 0
EXECUTE msdb.dbo.sysmail_update_account_sp
@account_id = @AccountNr
, @email_address = @ParamSMTPFrom
, @account_name = @DatabaseName
, @display_name = @DatabaseName
, @replyto_address = @ParamSMTPFrom
, @description = @EmailAccountDescription
, @mailserver_name = @ParamWebAppSmtpServer
--[ , [ @mailserver_type = ] 'server_type' ] 'optional only SMTP supported'
, @port = @ParamWebAppSMTPPort
, @username = @ParamWebAppSMTPUser
, @password = @ParamWebAppSMTPPwd
, @use_default_credentials = 0 -- we will always have nor domain credientials @DefaultCredentials
--use account name and password
--not databse credentials
, @enable_ssl = @SSL -- bit 1 for use ssl
REVERT
Error occurring is:
Cannot execute as the database principal because the principal "SERVERNAME\dbMailUser" does not exist, this type of principal cannot be impersonated, or you do not have permission
Things I checked:
- SERVERNAME\dbMailUser has DatabaseMailUserRole permission in msdb currently.
- If I add the executing stored proc user (from web app) as sysadmin,I don't have to switch or anything. But I want to limit the permission to it's minimum.
How can I execute as a different user (SQL or Windows Login) by switching context properly? The current SQL login is a database owner.
The requirement is the login should be able to configure DBMail from a stored procedure and able to send mails (the DatabaseMailUserRole), without it being in the sysadmin role.
Am I in the right direction, regarding my understanding of how DBMail configuration works?
EXECUTE ASat all using this approach. I believe the issue is the need for a counter signature. I have updated my answer by adding info starting with "One difference...". Please let me know how that works. If not, then it might just be that one remaining step is to create a User inmsdbfrom the[MrDoStuff]Login. But let's try just this next piece by itself first. – Solomon Rutzky Nov 10 '15 at 17:18sysadminrole, then great. Glad it is working for you :). – Solomon Rutzky Nov 12 '15 at 16:07sysadminfixed server role, correct? If yes, then I will update my answer to include that detail. Thanks. – Solomon Rutzky Nov 11 '16 at 15:12sysadminserver role did not defeat the purpose of creating the Certificate in any way. There is no way to connect as the Certificate-based Login or Impersonate it viaEXECUTE AS. It is just a container for permissions. The permissions still needs to be assigned to a module so that the module can inherit the permission(s). This is still very secure, much more than Impersonation. It just means you don't need the Certificate created inmsdb, and no need to counter sign, as the Login should be able to execute across database boundaries. – Solomon Rutzky Nov 11 '16 at 15:21msdbso that the other proc can be counter-signed, then this is still a far better (i.e. more secure) approach than Impersonation. Nobody will ever be able to hijack the Certificate-based Login / User or even your stored procedure to use those permissions in a way that you did not specifically intend. – Solomon Rutzky Nov 11 '16 at 15:53sysadminand you said "yes". If you are now saying that it is the actual Login that the app uses, that is different. Also, if the question is now about permissions needed for Attachments, that is a new question (related to this one, but different) as Database Mail runs asynchronously via Service Broker, so a separate process needs to be accounted for. – Solomon Rutzky Nov 11 '16 at 16:09