Q1: why would I want to have an Unattended Execution Account?
Q2: if I don't use an Unattended Execution Account, which account is used to run the reports?
Q3: if i get the following error message when running a report:
"The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationError) Log on failed. Ensure the user name and password are correct. (rsLogonFailed) Logon failure: unknown user name or bad password".
I understand that the Unattended Execution Account user name and/or password is wrong. But, where is that user name and password used? I mean, should the Unattended Execution Account be added in SQL Server or is the user name and password stored in the report? Even if a change the user name and password in SSRS Configuration Tool, the report doesn't run. So, the old account information seem to be stored somewhere?
I've been googling around but I don't get the big picture.
Thanks!
The MSDN article has pretty detailed information about this.
From that the answers to your questions are:
Q1: You should set the Unattended Execution Account if you don't want to set credentials for data sources and want the data source to work even when users are not able to enter their credentials (subscriptions or other scheduled executions.)
From the linked MSDN article:
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.
Most SSRS installations do not need the Unattended Execution Account. They use the "Credentials stored securely in the report server" option in the data sources.
Q2: I'm not sure what "run the reports" means, but the SSRS Service account is always responsible for the rendering and delivery of the reports, whether an Unattended Exec Account is set or not. The connections to the data sources will use the credentials specified in the data source. Unattended Exec Account will only be used if the data source is set to "Credentials are not required."
Q3: This account may not be used at all, but SSRS still checks the credentials with the domain. If none of your data sources are set to "Credentials are not required" then I recommend you remove the account from the SSRS configuration.
Your questions are probably answered by this MSDN article. For Q1 "Why?":
Send connection requests over the network for reports that use database authentication...
Retrieve external image files that are used in report...
On question 2: the Unattended Execution Account doesn't determine who runs the report. It just determines the above two things. The report is executed by the Report Server, and that process is running under its own account you configured.
On question 3: see the "How Account Information is Stored" section in the linked question. I'm not sure why a change in the Config Tool wouldn't be immediately effective, you may have to debug that seperately (try to restart things once or twice, etc). If you can't figure that one out be sure to start a new SO question with the details on your situation.
Related
I've got an ssrs report server setup and the data sources are set to use the user's windows login. However when I try to setup a subscription it says it can't because the credentials aren't stored in the data source. Is there no way to have a subscription that uses a generic account but when run interactively it uses Windows username
I use a database account for running all of the reports. You'll have to set this up in each database. Then I have report folder permissions associated to Active Directory groups. I also use a domain service account for deploying the reports and setting up the subscriptions. That way if a member of the BI team leaves the company and their account is deactivated the subscription will still run.
Data Source Example:
SQL Server 2016 reporting. The SSRS service runs as an account that has read access in the database I'd like to run reports from.
I'd like to create a server level data source object that would use the Windows service account to connect, instead of storing the credentials in the data source itself. Is there a way to do so?
The "Without any credentials" option doesn't work, I've tried.
I want to display SSRS reports with integrated mode in share point.
But when I set report server url in Share point then getting below error
The permissions granted to user 'XXXX' are insufficient for performing this operation. ---> Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: The permissions granted to user 'XXXX' are insufficient for performing this operation.
I am using windows credential user and have admin permission.
For connecting SSRS with Share point, you have to follow steps in share point
1. Create Service account for SSRS
2. Set Shared database setting in SSRS application
Then you have to pass the Share point URL into the VS project of SSRS under Deploy setting.
Quite a common ommision in SSRS setup is the provision of the SSRS Execution Account. might be worth confirming you have this setup.
Technet - SSRS Execution Account
I have old classic ASP application (not asp.net) that I need to configure to use Microsoft SQL Server 2008.
It works well with following config string:
SERVER=myServer;DRIVER=SQL SERVER;DATABASE=myDatabase;UID=sa;PWD=somepass
But I need to use integrated security. But got error in any types of declaration that I tried. Something like that and a lot of variations don't work:
SERVER=myServer;DRIVER=SQL SERVER;DATABASE=myDatabase;Integrated Security=SSPI;
So my question is: how connection string should look like for Classic ASP integrated security. Or maybe additional web server configuration is needed?
Note that this will hit SQL based on the authentication of your asp application pool assuming your using anonymous authentication.
I see you have added a comment noting IIS 5, setting a site to use windows auth on ISS5 is possible by going to the properties of your site, selecting the "Directory Security" tab, then clicking the "Edit" button on the "Anonymous access and authentication control" section. Disable anonymous authentication and tick the "Integrated Windows Security" option.
(NOTE: the webserver will need to be able to authenticate the credentials, so you may run into NTLM and kerberos issues depending on your domain configuration - tread carefully!)
This should execute the asp files as the authenticated user, in which case your connection strings would then be able to use trusted connections.
You have a few choices here depending on which providers you have available to you.
For instance, with the SQL Native Client 9.0 OLE DB provider you could use:
Provider=SQLNCLI;Server=myServerAddress;Database=myDataBase;Trusted_Connection=yes;
Native Client 10 is slightly different:
Provider=SQLNCLI10;Server=myServerAddress;Database=myDataBase;Trusted_Connection=yes;
I prefer the SQLOLEDB provider (ive had trouble with SQL SERVER driver and VARCHAR(MAX) in the past):
Provider=SQLOLEDB;Data Source=Your_Server_Name;Initial Catalog=myDataBase;Integrated Security=SSPI;
NOTE: suddenly changing the authentication may break other stuff - i'd certainly just recommend adding a SQL credential on the SQL server and use that in your connection strings instead.
Its a pity you haven't replied to my inquiry in a comment to your question so I will have to give a wider answer. (Although HeavenCore has actually given you the correct connection string to use, the SQLOLEDB one).
When using anonymous access
When you run a Classic ASP website under anonymous access the security token that the thread executing the acript belongs to the IIS anonymous user. This user by default on IIS5.1 is a local machine user. As a result unless the SQL server is also running on the same box you can't use this user to grant access to a SQL Server.
You would need to create a new user in your domain to act as the anonymous account. Then you would change the anonymous user for your application to this new account. In SQL server you can then grant appropriate database access to this account.
If I recall correctly you can set the anonymous user account by opening the site properties. In the Directory Security tab, click Edit.. under Authentication and access control. In the authentication methods dialog that appears you can change the anonymous account to one that is a member of the domain.
When using windows integrated access
If you running classic ASP without anonymous access but instead are authenticating connections using window integrated security then each script will run using the security token of the authenticated user. Hence when SSPI is used in the SQL connection the user associated with the connection the request has arrived on is used.
To give these users access the SQL DB you would need to create appropriate AD Group(s) and grant these Group(s) access to the DB. Then assign the users to these Group(s).
The downside to this approach is that it gets limited benefit from connection caching however considering the rest of your configuration that may not be too much of a concern.
I have a problem about the credential in reporting service..
When I choose option windows authentication for a report in SQL Server Reporting Services, only the administrator can view the report. The other users can't view the report. But when I set credential stored securely in the report server and enter the username and password, all users can view the report but some data of the report is not showing.
For your information, I have created the user in SQL Server and I have set the role and user mapping.
What should i do?
Based off of what you are saying I would guess that you have not added the users windows credentials to the proper group on the reporting server. The admin would have access as by default that role is already given permission in the proper groups.
Here is an article from Microsoft that explains this process.
http://msdn.microsoft.com/en-us/library/aa274425%28SQL.80%29.aspx
This is a good article on setting up role based security.
http://odetocode.com/articles/215.aspx
If I understand your question properly, you want to use your end-users' windows credentials from end-to-end with your reports. You do not want to specify a specify set of windows or SQL credentials to connect to your data source, you want to use the end users' credentials instead.
In order to accomplish this, you will need to grant the end-users rights to access your reports in SSRS as well as granting them rights to run the needed SQL on the underlying database.
Finally, if your SSRS instance is not running on the same server as your database, you may run into security delegation issues. You can read more about this topic by visiting http://support.microsoft.com/default.aspx?scid=kb;en-us;810572