October 23, 2009 at 2:35 pm
Books Online recommends not using the Reporting Services Execution Account as the login to connect to data sources. However, it is much more convenient to define a data source this way, since you do not have to enter the user name and password when you setup a data source. I was wondering if anyone is aware of any security problems or other serious problems from doing this?
From SQL Server 2008 Books Online
“The unattended report processing account is used primarily to connect to external servers, and not as a login to database servers. If you want to use the account credentials to log in to a database, you must specify credentials in the connection string. You can specify Integrated Security=SSPI if the database server supports Windows integrated security and the account used for unattended report processing has permission to read the database. Otherwise, you must enter the user name and password in the connection string, where it appears in clear text to any user who has permission to edit data source connection properties.
Although you are not prevented from using the unattended report processing account to retrieve data after the connection is made, doing so is not recommended. The account is supposed to be used for very specific functions. If you use it to retrieve data, you undermine the purpose for which it is intended.”
October 27, 2009 at 10:15 am
bump
October 27, 2009 at 12:17 pm
Hi Michael,
I have to agree with Microsoft because SSRS usually randomly reject normal T-SQL code and to resolve most problems it generally throws strange execution context errors which may not be valid if you are using one account for both tasks.
In security context the Datasource account could be DBO or less but SSRS in most implementations require admin permissions.
Kind regards,
Gift Peddie
October 28, 2009 at 9:50 am
Gift Peddie (10/27/2009)
Hi Michael,I have to agree with Microsoft because SSRS usually randomly reject normal T-SQL code and to resolve most problems it generally throws strange execution context errors which may not be valid if you are using one account for both tasks.
In security context the Datasource account could be DBO or less but SSRS in most implementations require admin permissions.
I'm not sure I understand what you mean. SSRS is not running under the execution account; it is running under the service account. I am only using the exection account for data sources and for it's usual purpose of connectiing to file shares, etc. The execution account only has the necessary permissions in data source databases; usually only permissions to execute specific stored procedures.
I have never experienced any problem with using the execution account to connect to data sources.
October 28, 2009 at 10:36 am
Michael Valentine Jones (10/28/2009)
Gift Peddie (10/27/2009)
Hi Michael,I have to agree with Microsoft because SSRS usually randomly reject normal T-SQL code and to resolve most problems it generally throws strange execution context errors which may not be valid if you are using one account for both tasks.
In security context the Datasource account could be DBO or less but SSRS in most implementations require admin permissions.
I'm not sure I understand what you mean. SSRS is not running under the execution account; it is running under the service account. I am only using the exection account for data sources and for it's usual purpose of connecting to file shares, etc. The execution account only has the necessary permissions in data source databases; usually only permissions to execute specific stored procedures.
I have never experienced any problem with using the execution account to connect to data sources.
We are not talking about the same thing my bad you are looking to expand uses of the subscription account while I am talking about the standard datasource account. So you may have to run some test in a test box.
http://technet.microsoft.com/en-us/library/ms156302.aspx
Kind regards,
Gift Peddie
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply