I have a new 2008 Reporting Services server and report. The data source for the report is set to use Windows Integrated Security. When I try to run it I get
The report server has encountered a configuration error. Logon failed for the unattended execution account. (rsServerConfigurationError)
Using the account specified in the Execution Account in RS Config Manager I can log into the server and SQL Mgmt Studio although I don't have any rights to the database I'm reporting on. Any idea why I would get this error? What's it trying to log into?
It sounds like the report server is trying to use the Unattended Execution Account to connect to the database specified in the report data source.
If the account specified does not have permissions to read data from that database then you can change your data source connection, e.g. choose "Credentials Not Required" and then add a username and password for the data source to the connection string. This is not ideal however, because the username and password will be visible to anyone with permission to edit the data source.
Ideally you need to either have permissions to the source database granted to the Unattended Execution Account or change your data source to use a different connection method, e.g. use Stored Credentials and specify an account with permissions to the source database (if you don't actually need the features enabled by setting an Unattended Execution Account, then you can remove it entirely).
More information: http://msdn.microsoft.com/en-us/library/ms156302(v=sql.100).aspx
Related
For version 14.0.600.689 I've setup unattended account, data source based on parameter and Credentials option "Do not use credentials". It works fine.
Than on another server we've upgraded to latest 14.0.600.744. And same configuration gives an error:
Login failed for user ''.
Cannot create a connection to data source 'MainDataSource'. (rsErrorOpeningConnection)
When we setup secured credential for report inside it works.
Did something changed in logic of using unattended execution account?
Do I have any other way to setup one credential for expression based data source for many reports?
So looks like this is a bug, between 14.0.600.689 and 14.0.600.744.
But I found a workaround, in newer version when you add in the end of dynamic connection string an option of "Integrated Security=true" it will use unattended execution account, otherwise it wraps with User ID empty and give that SqlConnection error.
While in older version, it will use unattended execution account always with an option "Do not use credentials".
I am trying to connect to Datasource but getting this error:
An error occurred during local report processing.
An error has occurred during report processing.
Cannot create a connection to data source 'PO'.
You have specified integrated security or credentials in the connection string for the data source, but the data source is configured to use a different credential type. To use the values in the connection string, you must configure the unattended report processing account for the report server.
Any idea how to resolve this?
Thanks
Aruna
Looks like it forgot your password,
If it is an embedded data source > Right click on the Data source then go to properties > credentials.
If it is a shared data source go to the shared data sources, right click on the shared data source and hit Open, once in there click on credentials and enter the credentials again.
I was having this same issue. For me, the problem was that I was using a DNS alias as the server name in the connection string. Once I changed that to the actual machine name my connection was solid.
I guess this issue occurred in Visual Studio when you connected to data source but were not able to create a report using that data source. What credential did you use when creating database. Windows authentication or username and password. Right click on data source in VS and select credential as same as your server/db in properties. Mine is windows auth for my server/db and selected the same for data source. so now I am able to create reports.
I deployed my report to the report server. This report has some DB connection which uses Windows Authentication.
When I run the report from the same server works fine, but when I try this from a remote sever I errors saying EXECUTE permission denied on the stored procedure.
The EXECUTE permission was denied on the object 'sp_xxx', database
'DB', schema 'dbo'.
I did further analysis and found that when the report try to connect to the DB is uses NT AUTHORITY\ANONYMOUS LOGON login.
And the report server is running under NT Authority\NetworkServices.
p.s: Also the remote server and the report server is in the same domain.
What am I doing wrong which is not passing my Windows authentication?
Please help...
If you have access to the server you should define a ReportUser user that has access to ssrs and mssql since you are using windows auth. When you deploy, the dataset credentials should be set to the same user above. This would be akin to going into ssrs and setting the configuration of the dataset of the report to a known user account with sufficient privileges to run the report and query the database.
I'll try to walk you through, I hope I haven't forgot something
Can you connect to your server remotely using management studio and your admin credentials? (Check TCP/IP is enabled under SQL Server configuration manager)
Have you assigned enough permissions to the security role? have you assigned the user to the role?(check this out - Grant execute permission for a user on all stored procedures in database?)
Can you successfully connect with your data source? (Check username and password are working)
Do you think it is possible to create a SQL server ODBC Connection for an active directory user who doesn't log in into the windows.
Ideally this type of users will be used in the batch process. So, Another person logs in and creates a batch process and runs it with another user.
Note: I dont want to create a SQL server authentication. Instead would like to use active directory.
Thanks.
You can't save alternate windows authentication credentials into an ODBC connection for SQL Server. You can only save credentials into the ODBC setting if you use SQL Server authentication.
There are other options though.
You can create a windows authentication ODBC connection to SQL server even if the account you create the connection with doesn't have database access. You just have to untick the "Connect to SQL Server to obtain default settings for the additional configuration options" and you can't use the "Test connection" feature. You just have to create the connection on faith.
With that connection, it will only work if your batch process or application is running as a different account to the logged-in user. Services that run as system accounts do this sort of thing. If you create an application that can be run as a service then you can change the account it runs under.
You can also run as another account manually. Using explorer you can [shift] + right-click on an application and choose "Run As different user" and then enter the other account credentials. Then when the process or application uses the ODBC connection, it will be the correct credentials and work.
There's also "ShellRunAs" https://technet.microsoft.com/en-us/sysinternals/shellrunas.aspx
I am working on an application which bulk-loads data into a SQL Server 2008 database. It writes a CSV file to a network share then calls a stored procedure which contains a BULK INSERT command.
I'm migrating the application to what amounts to a completely new network. In this new world bulk insertion fails with this error:
Msg 4861, Level 16, State 1, Line 1
Cannot bulk load because the file "\\myserver\share\subfolder\filename" could not be opened. Operating system error code 5(failed to retrieve text for this error. Reason: 15105).
I connect to the database using Windows Authentication, using the same account which wrote the file. The file, and the folder in which it resides, grant read and modify rights both to my user account and the database server's domain service account. That service account apparently has constrained delegation permitted, which is mentioned on MSDN. Still no good. If I connect using a SQL Server account then bulk insertion succeeds, but we are trying to stick exclusively to Windows Authentication.
Does anybody have a handle on what needs to be done to make this work? How exactly does SQL Server go about accessing data on network shares, hopping between its service account and that of the connected user? I know that I can bulk insert in a similar situation in our current infrastructure, but it is so crufty with age that it would be hard to track down what has been done to enable this in the past.
Recently we had this issue for a number of our Devs. I've come up with a number of ways to allow testing of bulk inserts.
Our preference was to use a SQL service account. We set the SQL server and SQL agent to run as a service account and then allowed the devs to trigger agent jobs. The service account was granted permission to the UNC shares and this all functioned correctly. Note that the service account will always been fine running these agent jobs (assuming UNC permissions are set). It's the Devs trying to test that will come across these issues.
Another method is to create a share on the SQL server itself and point the bulk insert path at the local directory. These errors seem to only occur when accessing UNC paths. Regardless of whether the UNC path has the correct permissions to allow you access. For example we create C:\test\ as a folder on the SQL server itself and permission it to allow a dev to drop test files there. These are then called via the bulk insert command.
A command may need to be run against master to allow a SQL login group permission to bulk insert. This is as below.
GRANT ADMINISTER BULK OPERATIONS TO "domain\usergroup"
Adam Saxton's blog (about Kerberos and bulk inserts from a share) should be read: http://blogs.msdn.com/b/psssql/archive/2012/09/07/bulk-insert-and-kerberos.aspx. Adam offers two approaches:
Enable constrained delegation for the machine (as opposed to the sqlservr.exe startup) account, or use a SQL Server login. Adam mentions two other approaches (which he does not recommend).
An aside, the latter half of the OP's message "(failed to retrieve text for this error. Reason: 15105)" may be related to a SQL Server startup account lacking rights documented within SQL Server's "Configure Windows Service Accounts and Permissions" topic, such as SeAssignPrimaryTokenPrivilege.
Did you ever resolve this issue? I recently had a similar problem and discovered that the best way to resolve it was to use a SQL login.
Initially, having read the notes here I thought if I just granted read permissions to the Windows account with which I was connecting to the SQL Server that would be okay, but even when I granted read access to Everyone, I still couldn't read in the file.
I believe the reason is something to do with SQL Server impersonating the windows user and attempting to access the UNC share, which is delegation and which is not allowed unless explicitly enabled. There are some notes here which may help. This is the constrained delegation of which you speak and I couldn't get it to work either!
Bottom Line: I just used a SQL Login and made sure the SQL Server Process account had read permissions on the share (by granting read to Everyone in my case) and it worked.
In order to bulk insert with AD users, the SQL service it self has to be running as a domain user and has to have the AD permission to be able to delegate authentication. Same if you wanted to run linked servers with ad users. Here is the link for AD and linked servers, but the permission are the same.
Linked Servers and Active Directory
The server must have an SPN registered by the domain administrator.
The account under which SQL Server is running must be trusted for delegation.
The server must be using TCP/IP or named pipes network connectivity.