I have configured SSRS on Server1.
Server2 is linked to Server1 in sys.servers.
All queries/reports link runs fine if I run Server1 objects
I want to run report on a Server2 objects
Try 1
I created a Shared Data Source to Server2, built query in a Shared Dataset.
SELECT Field1 FROM Table1
a) Preview - Runs fine
b) Server1/Reports throws this error:
An error has occurred during report processing. (rsProcessingAborted)
The execution failed for the shared data set 'table1'.
(rsDataSetExecutionError) Query execution failed for dataset
'DataSet1'. (rsErrorExecutingCommand) For more information about this
error navigate to the report server on the local server machine, or
enable remote errors
Try 2 I tried to use Server1, and link from there. So when creating a Dataset I used Server1 as a source and built this query
SELECT Field1 FROM Server2.master.dbo.Table1
a) preview runs fine
b) Server1/Reports throws same error as above
NOTE: changing above query to OPENQUERY yields same thing
If I look at logs it says:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
it can connect to Server1 datasource (since SSRS is installed on Server1), but can't connect to Server2. How can I grant that user access to Server2?
How I can fix above issue, so that report runs fine from Server1/Reports too
NOTE: I use SQL Server 2017
You are using Windows Authentication for the Report Server and again in the shared datasource. That means that the logged-in user token is passed to a second hop, Server2. To allow this, you will have to enable Active Directory Delegation.
Contact your network administrators and ask them to configure (at least constrained) delegation on Server1 to allow delegated connections to Server2 (at least to the SQL Server Service).
Related
I migrated from SQL Server 2008 to 2019. On the old server there is set up a job, which calls a dtsx file. It needs database access, file system access because it saves tmp files to disk, and internet conneciton to send this file.
The connection string is defined followings:
<DTS:ConnectionManager
DTS:ConnectionString="Provider=SQLOLEDB.1;Password=p#ssword;Persist Security Info=True;User ID=MyUser;Initial Catalog=MyDB;Data Source=SQLServer\Instance;" />
If I run it using the Execute Package Utility it works. If I run it through the SQLServer Job, I get the error that the user is not granted to access the file system. The owner of the job is the same I am logged in and run the package using the Utility.
In the history i see:
The job failed. The Job was invoked by User Domain\RightUser.....
where RightUser is the Owner (and same as before, the same user run the package using the utility)
but the second row of the error:
Executed as user: NT Service\SQLAgent$AnotherUser.
And I have no idea where this AnotherUser comes from.
Whats wrong?
Furthermore, I don't really like the hardcoded password in the connection string, If the job run in its owner context, should it work changing the connection string to Integrated Security=True;, right?
This is a very common problem with running SSIS packages. That other user is SQL Agent, which in reality runs the package (this is the default user running the steps in jobs). Job owner has got nothing to do with running the SSIS packages. SQL Agent user name is set during the SQL Server installation. If it's omitted, the installer creates automatically a username like you described.
To the second question, yes you are right. If the user, who executes the package, has the correct permissions to the SQL Server described in the connection string, the userid and password are unnecessary. But in your case, the package is run by the SQL Agent with NT Service -level username, so it might be impossible to add that username to the SQL Server. You should set up a proper username for running the SSIS package and set it as a proxy account to the SQL Server, like described here: https://community.spiceworks.com/how_to/129293-configure-an-ssis-package-to-execute-as-a-proxy-account
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)
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
Does SQL Server has an external log file or internal table for attempted connections, or is that kind of info put somewhere in the Windows Event Log?
You can enable connection logging. For SQL Server 2008, you can enable Login Auditing. In SQL Server Management Studio, open SQL Server Properties > Security > Login Auditing select "Both failed and successful logins".
Make sure to restart the SQL Server service.
Once you've done that, connection attempts should be logged into SQL's error log. The physical logs location can be determined here.
Another way to check on connection attempts is to look at the server's event log. On my Windows 2008 R2 Enterprise machine I opened the server manager (right-click on Computer and select Manage. Then choose Diagnostics -> Event Viewer -> Windows Logs -> Applcation.
You can filter the log to isolate the MSSQLSERVER events.
I found a number that looked like this
Login failed for user 'bogus'. The user is not associated with a trusted SQL Server connection. [CLIENT: 10.12.3.126]
If you'd like to track only failed logins, you can use the SQL Server Audit feature (available in SQL Server 2008 and above). You will need to add the SQL server instance you want to audit, and check the failed login operation to audit.
Note: tracking failed logins via SQL Server Audit has its disadvantages. For example - it doesn't provide the names of client applications used.
If you want to audit a client application name along with each failed login, you can use an Extended Events session.
To get you started, I recommend reading this article: http://www.sqlshack.com/using-extended-events-review-sql-server-failed-logins/
I am trying to create a linked server in SQL 2008 to an Advantage v7 database server. I've successfully created the linked server in SQL 2008 using the commands below and the connection tests out fine. Also, the Advantage DB I'm connecting to does not have a data dictionary.
SQL to create the Linked Server
EXEC master.dbo.sp_addlinkedserver
#server = N'ADVANTAGE', #srvproduct=N'Advantage',
#provider=N'Advantage.OLEDB',
#datasrc=N'\\asc1\questtest$\spaulrun'
/* For security reasons the linked server remote logins password is changed with ######## */
EXEC master.dbo.sp_addlinkedsrvlogin
#rmtsrvname=N'ADVANTAGE',
#useself=N'False',
#locallogin=NULL,#rmtuser=NULL,#rmtpassword=NULL
When I run the following query:
select * from
openquery(ADVANTAGE,'select * from members')
I get this error:
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "Advantage.OLEDB" for linked server "ADVANTAGE" reported an error. Access denied.
Msg 7350, Level 16, State 2, Line 1
Cannot get the column information from OLE DB provider "Advantage.OLEDB" for linked server "ADVANTAGE".
I've verified that this is not an NT File permissions issue. Also, just before the error messages are displayed, I can see all of the column names on the screen for just a second. So I'm getting at least some table information back from Advantage. I just don't know why I'm getting the Access denied message.
Any help is greatly appreciated!
This sounds familiar, but I don't remember the exact error message I got.
Try going to the Advantage OLE DB Provider in the Linked Server setup and right click and choose properties and set "Allow Inprocess".
If I remember correctly, in Management Studio Express i went to
Server Objects -> Linked Servers -> Providers -> Advantage OLE DB Provider (Right Click->Properties or Double Click)
Set "Allow Inprocess"