March 22, 2016 at 3:38 am
I have a Dotnet application developed using VS2012 (VB.NET) developed on my workstation. The application connects to a SQL Server database (on a virtual Windows 2008R2 64-bit machine, SQL Server 2008R2). Part of the application is a Reporting Services (SSRS) report, which was developed remotely on the SQL Server using VS2008, and is hosted there. I have no issues running and viewing the report using Report Manager. The report works fine and I get the expected results from the underlying dataset. So am I sure the report is configured correctly and uses the correct authentication details to access data from the database.
I’ve deployed the application on another virtual server (Windows 2012, 64-bit), running IIS 8.0.9. The application uses windows authentication. The application works absolutely fine both when I browse to it from within IIS and from a browser on my PC, except when I’m trying to navigate to the report. Here all I see is a (javascript?) control (please see attached image).
There is no error thrown by the application, but I've attached a logfile from SSRS, which says Login failed for user 'NT AUTHORITY\SYSTEM'. Following this, I've gone into Report Manager and added 'NT AUTHORITY\SYSTEM' as a user, giving it all roles. I then stopped and re-started the Report Server Service.
Still no change. I've attached the logfile from SSRS in case it can shed some light into what's going on. I'd be grateful for any suggestions.
March 22, 2016 at 6:07 am
This appears to be an error connecting the report manager to the report server database.
Log on to the the server hosting reporting services and open Reporting Services Configuration Manager application.
Connect to your instance, then got to the Database settings (third one down). Click the change credentials button then follow the Wizard. Even if you are still using the Service account under credentials follow the wizard completely through as it will grant the required access and roles to the account.
(N.b. the Change Database wizard will also reassign the credentials but also allow you to check / specify the reportserver database along the way, use this if you aren't sure the database exists)
Then try the report again. HTH
March 22, 2016 at 6:30 am
Spiff (3/22/2016)
This appears to be an error connecting the report manager to the report server database.Log on to the the server hosting reporting services and open Reporting Services Configuration Manager application.
Connect to your instance, then got to the Database settings (third one down). Click the change credentials button then follow the Wizard. Even if you are still using the Service account under credentials follow the wizard completely through as it will grant the required access and roles to the account.
(N.b. the Change Database wizard will also reassign the credentials but also allow you to check / specify the reportserver database along the way, use this if you aren't sure the database exists)
Then try the report again. HTH
Hello and thanks for the reply.
I have done as you suggest and gone through the process of 'changing credentials', even though I' still using the Service Account as before. Everything went through as expected and I've attached an image of the results.
I've also stopped and re-started the Report Server Service.
When I navigate to the report from either the application or from the IIS server, the result is still as I explained in my OP. I've attached the latest log file.
Any ideas?
March 22, 2016 at 9:02 am
Hmmm. I'm not seeing the report server connection error in your log file. Have you checked the Data Source for the report?
March 22, 2016 at 9:13 am
Spiff (3/22/2016)
Hmmm. I'm not seeing the report server connection error in your log file. Have you checked the Data Source for the report?
If I open up SSRS Config Manager, and go to Report Manager URL, and open up the 'Reports' virtual directory, I can test the authentication details of the datasource. I get a 'Connection created successfully' message for the username and password I'm using to connect to my database.
I can also 'preview' the report itself and it returns the expected results from the underlying query. I take this to mean that there's nothing wrong with the report or the credentials I'm using in the datasource of the report.
I'm completely stumped.
March 22, 2016 at 9:25 am
This could be a double-hop issue since you are using IIS to connect and you say you are using windows auth on the server.
March 22, 2016 at 9:35 am
Try saving the windows credentials in the Data Source on the report server.
March 22, 2016 at 9:54 am
Have tried that already, with the same result.
As an experiment I'm going to temporarily disable the Windows Firewall on both servers and test to see what result that might have. This will have to wait until tomorrow though.
Thanks for your suggestions.
March 30, 2016 at 2:54 am
So have set delegation rights for the IIS server following suggestions on this blog:
https://sqlbadboy.wordpress.com/2013/10/11/the-kerberos-double-hop-problem/
Still the same situation. I've attached an SSRS log file in case someone spots a problem.
March 30, 2016 at 3:16 am
Have you changed the SSRS authentication method to Negotiate in the rsreportserver.config?
<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
</AuthenticationTypes>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
March 30, 2016 at 3:28 am
Spiff (3/30/2016)
Have you changed the SSRS authentication method to Negotiate in the rsreportserver.config?<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
</AuthenticationTypes>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
Thanks for the quick response:
Copy and pasted straight from the config file:
<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
<RSWindowsNTLM/>
</AuthenticationTypes>
<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
March 30, 2016 at 3:29 am
Thanks for the quick response:
Copy and pasted straight from the config file:
<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
<RSWindowsNTLM/>
</AuthenticationTypes>
<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
March 30, 2016 at 3:34 am
Thanks for the quick response:
Copy and pasted straight from the config file:
<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
<RSWindowsNTLM/>
</AuthenticationTypes>
<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
March 30, 2016 at 3:38 am
Thanks for the quick response:
Copy and pasted straight from the config file:
<Authentication>
<AuthenticationTypes>
<RSWindowsNegotiate/>
<RSWindowsNTLM/>
</AuthenticationTypes>
<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
<EnableAuthPersistence>true</EnableAuthPersistence>
</Authentication>
March 30, 2016 at 3:39 am
Sorry - not sure what happened there!
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply