Integrated Security on Reporting Services XML Datasource - reporting-services

I am working on setting up my report server to use a web service as an XML datasource. I seem to be having authentication issues between the web service and the report with I choose to use Integrated security. Here's what I have:
1) I have a website w/ an exposed service. This website is configured to run ONLY on Integrated Security. This means that we have all other modes turned off AND Enabled anonymous access turned off under directory security.
2) Within the Web.config of the website, I have the authentication mode set to Windows.
3) I have the report datasource set to being an XML data source. I have the correct URL to the service and have it set to Windows Integrated Security. Since I am making a hop from the Browser to the Reporting Server to the Web Service, I wonder if I am having an issue w/ Kerberos, but I am not sure.
When I try to access the service, I get a 401 error.
Here are the IIS logs that I am generating:
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 0
2011-01-07 14:52:12 W3SVC IP_ADDY POST /URL.asmx - 80 - IP_ADDY - 401 1 5
Has anyone worked out this issue before? Thanks!

It does sound like you are experiencing the "double hop" issue. Is it possible to create an account on your web service that the reporting server uses explicitly instead of passing through the users credentials?

There's a simpler solution if you dont want to muck around with Kerberos... although the user experience is less desirable.
On the Data Source...If you check the "Credentials supplied by the user running the report" and the "Use as Windows credentials when connecting to the data source" then the user will be promoted to log in when they run the report. Since the credentials are being supplied to the SSRS server it's only a single hop from SSRS to the webservice... thus avoiding the double-hop NTLM authentication problem.
It's less user-friendly, though, since you have to log in to run the report.

Related

SQL Server Reporting Services - cannot authenticate through URL on the same machine as SSRS server

I am accessing SSRS reports (SQL Server 2016) through URL to embed them in my application in an iFrame. When I access SSRS reports remotely, i.e from different computer I can authenticate and display the reports.
In my iFrame source I put:
http://example.com:4000/path_to_ReportServer/report_name
And that works fine when I deploy my app to stage server. All the SSRS reports load with no problem at all.
However I develop on the same PC as my SSRS report server resides, and when I am on it I have to change all the links in iFrames to:
http://computername:4000/path_to_ReportServer/report_name
edit: originally I wrote here that I use localhost, but actual I meant computer name.
If I try to run my app from VS on my dev machine and I do not change the domain to computer name I wont be able to authenticate at all. It just keeps asking me for the same credentials over and over again.
I've checked the ReportServerService log, and I see this as a last line when I try to log in:
library!DefaultDomain!3bd0!11/21/2016-12:52:36:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: Invalid PBI Configuration, Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: The report server has encountered a configuration error. ;
I looked for this problem extensively, and I only find MS configuration tutorial but no one having similar issue to mine.
I have checked the usual culprits like firewall or port conflicts (but if I had any of those I would not be able to access the SSRS from any other PC, yet I can and the link doesn't work only on local machine.)
I am very new to SSRS in general so please kindly be patient with me. Thanks!
A few things you can try:
In SSRS Configuration and ensure that the Report Service and Report Management endpoints are valid (Copy the url in the hyperlink and make sure it opens on your local host.)
In SSRS Configuration and ensure that the Report Service Database has been properly deployed.
Remove any custom modules/assemblies you have applied to the default behavior from the ssrs web config (Custom Security).
I think you have applied changes to ssrs's web config in order to have it load assemblies for your custom security, custom datasourse/dataset, custom render format and fat fingered the config somehow.
You're probably running into a same-origin-policy error, which wikipedia states as under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.
The fix is to implement the X-Frame-Options metatag, like so:
X-Frame-Options: ALLOW-FROM https://example.com/

SSRS Permission settings in Report Service

I am running Report Service Manager - Web portal for accessing the Reports. For Development and Testing purpose, Report service is running from my computer.
Whenever Testing Team tries to access the web from their end, report service is asking an Initial Authentication of my computer account. ( Windows Authentication ). How to skip this authentication mode ? This is an Internal Application, i want Report service to run on any computer without asking any authentications.
If you are all on the same domain, simply add "DomainName\All Users" with the appropriate role to the portal. The testers may also need to add your site as a trusted site in their browsers. "All Users" is exactly as it sounds - any user account on that domain will have the access you grant.
Alternatively, if you need to disable security entirely (bad idea), you'll have to configure a new security extension - it's relatively simple to do, especially with all the samples you can find online (google "SSRS custom authentication" or "SSRS anonymous authentication"), but if you've never done anything like this before, you may struggle if you run into any unexpected issues.
See here for one example on how to enable anonymous access:
http://blogs.msdn.com/b/jameswu/archive/2008/07/15/anonymous-access-in-sql-rs-2008.aspx

pass windows credential from IIS to SSRS

I have deployed a couple of reports in SSRS2012, the report uses the user's windows token to do some verification. When testing the report in VS I successfully read the windows token but when I deploy to SSRS token is empty.
I did configure all data sources to use windows authentication and to impersonate the user.
any ideas?
Thanks
I'm a little unclear on the specifics here, but I'm thinking the problem is with the authentication method you're using in IIS.
Check out this other question:
Why does Windows/Integrated Authentication in IIS not pass user credentials to SSRS and SQL?
The versions are a bit different (SSRS 2005) but I think the issues here are the same. I won't get into it too much, because the answer in that link explains it better than I could, but essentially, it works from Visual Studio because your Windows Token is the one making all the requests. When you deploy to IIS, however, without explicitly configuring Windows Authentication and Identity Impersonation, the requests are being executed as the App Pool User, not the user using your web app. I hope this helps!

SSRS Report Rendering Hangs With Stored Credentials For XML data source type

In SSRS Report Server (SQL Server 2008 R2), I have a shared data source with data source type of XML. I have a report that uses a shared data set based off of the shared data source. The XML endpoint is living in an IIS-hosted Windows authentication app, and my development server is on a domain.
In Report Server, if I set the shared data source Connect Using option to Windows integrated security, the report renders quickly and as expected.
If I set Connect Using option to Credentials stored securely in the report server (with either domain or local account as configured account), the report rendering hangs indefinitely. There is no error. The "Loading... cancel" popup never goes away. The last line in the Report Server log file says:
library!ReportServer_0-6!19a4!11/22/2011-10:59:27:: i INFO: RenderForNewSession('/Test1/MyReportThatHangs')
Since Report Server caching does not work with "Connect Using" = "Windows integrated security", I'd really like to use "Credentials stored securely in the report server". Is it possible that option is not supported with the XML data source type?
The problem was SSRS was trying to load BCMLogon.dll which it didn't have permission to.
For full thread, see here: http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/928cd523-9eeb-49ce-a145-e0885c76adba
I guess I didn't wait long enough to get the error this guy did:
http://completedevelopment.blogspot.com/2009/01/network-provider-issues-and-sql-server.html
Renaming c:\windows\system32\BCMLogon.dll to BCMLogon-RENAMED.dll
fixed the problem (I'm working off of a Dell laptop). I can't believe
I didn't try that before... Anyhow, I still think it's odd that
there was a System.Data.SqlClient.SqlException: Timeout expired
exception when checking "Impersonate the authenticated user after a
connection has been made to the data source" with an XML data source
(unless SqlDataClient has some mode where it can load XML from urls).
Also, it seems that reporting services isn't properly notifying
clients that the HTTP request failed and instead leaves the client
hanging (but perhaps http.sys does not allow a response that after 15
minutes).

Impersonation in IIS 7.0

I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.
In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.
Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.
These are the settings that I'm using on both IIS 6.0 and 7.0:
<authentication mode="Windows">
<identity impersonate="true">
What changed from 6.0 to 7.0?
There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).
Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:
Internal Server Error. This is HTTP
Error 500.19: The requested page
cannot be accessed because the related
configuration data for the page is
invalid.
Here is the workaround that is proposed:
Workaround:
1) If your application does not rely
on impersonating the requesting user
in the BeginRequest and
AuthenticateRequest stages (the only
stages where impersonation is not
possible in Integrated mode), ignore
this error by adding the following to
your application’s web.config:
<validation validateIntegratedModeConfiguration="false"
/>
2) If your application does rely on
impersonation in BeginRequest and
AuthenticateRequest, or you are not
sure, move to classic mode.
I hoped that was useful to understand how IIS 7.0 now works.
Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.
Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.
I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!
#Esteban - Clarified my not very useful in helping you answer.
Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.
I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.
If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.