I'm working on a recently created server that was built to house a migrated version of SSRS, from SSRS 05 to 08.
Previously, we had no issues with connectivity from the IIS server to the SSRS server via the report viewer control and we did not supply credentials at that time. Now, when we try to use the viewer we get back; "The request failed with HTTP status 401: Unauthorized."
Obviously that is a new issue that we have never had before even though we never used credentials in the first place. So that is my first question... The new server is sitting in the same "place" as the old one. IP, Domain, Subnet is the same. Users have been set up the same, and the SSRS configuration appears to be the same. What could be the difference that is causing the error?
Also, i've been doing some testing, and I realized that I can access that server and get the reports in that environment by pointing my dev environment running in visual studio 2008 to that server without using credentials. I'm assuming by not setting the report viewer objects serverreport.reportservercredentials to something and leaving that property as a null value that it is using something else? possibly my windows user credentials? to access the reporting server. (That would be my second question.)
And finally. I decided to bite the bullet and implement credentials on the report viewer. When i create the credentials for the local user on the ssrs server that was created for this purpose, and is also listed in the report manager as a browser, i get the request failed error. My third question is; Is there something that I'm not thinking of for this type of implementation?
Please let me know if there are any questions or things that i need to clarify with in my post.
I ended up going down a different route.
There were two issues... first. the application on the web server was running as a local user. And the old SSRS server was set up to accept anonymous users.
To remedy this, I had our net work guys create a new domain account. I then changed the app pool identity for the application to use that domain account, and gave it list and write permissions on the temp folder and added it to the correct groups in windows.
I then gave that domain user browse ability on the reporting server.
this worked for 2.0+ apps... now i just need to figgure out what folders the user needs access to for the 1.1 apps.
(ps... i also found that the domain user actually works when i pass credentials via the report viewer control in .net.)
Related
I have an mvc4 site running on an win2k8 iis 7.5.
It uses built in security for authentication.
The users on log in are presented with a grid showing their jobs at the top of the page is the email address of the current user that allows them access to the log off menu.
Very very occasionally users report that they see grids from other users. The screen shots I have been sent show the email address not of the user reporting the issue.
I am stuck as to the cause of this issue.
Versions of the same site are in use on other servers and there have been no reports of this issue occurring elsewhere.
IIS is set not to cache pages etc I am unsure as how to trace the cause of this / stop it happening. It is from reports a very occasionally event - however it should not be happening.
Does anyone have any ideas / suggestions.
Since the AspNet Identity is an authentication technology based on the client cookies, there is a possibility, in that case, there is another user opening the webpage without closing the preceding browser session. In the words, the preceding client session is still preserved in the browser.
I suggest you consider setting up the session timeout.
How to set session timeout in web.config
I have a C# .net core web app published to Azure and I'm having trouble downloading a report from SSRS (URL based report - hit the URL, SSRS generates the report, app downloads it to memory and serves it to the user for download). It's a multi-layer application with multiple different people managing these different layers. Also, nobody else has ever used SSRS in this way, all our previous SSRS reports have been scheduled reports, so none of us know exactly how this works. But it does, "It works on my machine."
These are the pieces:
Web app deployed on Azure
Azure SQL Database
SSRS is running on-prem
I don't control any of these, just the code. If I open the report on the SSRS site, it pulls the data in from the database just fine. If I run the app from my computer, it goes out to SSRS and runs the report, which pulls the data from the database and generates the report and feeds it back to me no problem. After publishing to Azure, I no longer get a valid file back (unreadable content, file is only 3KB when it should be about 20KB). But I do get a file back, so I assume that means SSRS permissions are fine. And since SSRS can access the database and generate the report if I run it directly in the SSRS interface, I assume the connection to the database from SSRS is fine. We don't know which layer to look into to troubleshoot this.
Here are a few things I've tried to see if I could reproduce when I'm running on my machine and their results:
Remove access to SSRS for my account - no file is downloaded and I get a 500 error
Changed database creds to be incorrect - no file is downloaded and I get a 500 error
Removed WebClient.Credentials = DefaultCredentials from the C# app - no file is downloaded and I get a 500 error
I can't reproduce downloading the report with "unreadable content" when running on my machine. I don't know who to tell they need to look into something deeper. At this point, everyone tells me that "It should work." I've included my method that handles the report download to see if there's anything there that can be changed.
public FileStreamResult GetReport(string reportAddress)
{
var net = new WebClient();
net.Credentials = CredentialCache.DefaultCredentials; //I feel like this could be related, as it's likely different when running on Azure but SSRS still gives me a file instead of a 500 error like when we removed SSRS access for my account to test while running on my machine
var data = net.DownloadData(reportAddress);
var content = new MemoryStream(data);
var contentType = "APPLICATION/octet-stream";
return new FileStreamResult(content, contentType);
}
Any idea on where to look?
Method execution:
return GetReport("http://server/ReportServer/?/ReportsRoot/ProjectFolder/ReportName&Param1=P1Value&rs:Command=Render&rs:format=wordopenxml");
As stated in remarks from documentation of CredentialCache.DefaultCredentials:
The DefaultCredentials property applies only to NTLM, negotiate, and Kerberos-based authentication.
DefaultCredentials represents the system credentials for the current security context in which the application is running. For a client-side application, these are usually the Windows credentials (user name, password, and domain) of the user running the application. For ASP.NET applications, the default credentials are the user credentials of the logged-in user, or the user being impersonated.
When running on your machine, that I assume is in the same domain of SSRS, DefaultCredentials are passing your domain user authentication, because the app is running under your authentication/authorization context, and your code is passing that authentication information in the request, making everything work.
When running on Azure, obviously the code has a local user, not your domain user, breaking the auth chain.
I'd suggest you to investigate ways to use your domain user (or even better an ad hoc user for your app) to create non-default credentials and pass them to the request, it should work.
Maybe investigate the possibility to federate your AD Domain with your Azure subscription (not an expert, but should be possible to join Azure AD whit on premise one).
I am attempting to create a new web api for my company and am running into an issue with permissions.
First, the api is hosted on one server and it needs to access a database on another server. The app pool is using ApplicationPoolIdentity as it's identity.
When I run the api from Visual Studio, it is able to access the database on the other server. Incidently, I made sure that my login doesn't have access to that server. Instead I am forcing the api to use a connection string from the web.config file that contains a username and password. I am able to pull back information just fine.
When I put the api into IIS on my machine, I get the error 'Login failed for user Domain\username' any time I try to get information to return from the API. Is there any reason that Visual Studio would allow this to work, but IIS keeps trying to login to the database server with my machine account instead of using the connection string in the web.config file? I am trying to figure out how to get around this issue.
I found the issue. It seems that my connection string was being modified in three different places in the program. At one point one of my team members had it coded to pull the machine as the user instead of using my connection string. Once I updated and removed redundant code I was able to make the connection between machines without having to use a domain account.
My company is planning to upgrade all our users to windows 7, and with it upgrading all the user browsers to chrome.
We have several intranet sites using asp.net mvc and mvc webapi. I have set my intranet to the trusted domain setting, and I can confirm that when viewing a page in chrome the User.Identity.Name property is correctly set to my information.
However, when I try to do any action that requires sql server connectivity it fails instantly, complaining about Anonymous login which is disabled.
This is problematic, as we would like to get our users off IE.
After some digging it seems the best way to handle this is talking with our IT department to deploy software policies to enable kerberos delegation in the registry based on this information here:
http://www.chromium.org/administrators/policy-list-3#AuthNegotiateDelegateWhitelist
After adding this key to my registry i was able to "hop" to SQL Server without issues. I hope this helps others as this issue was driving me nuts.
I have written and deployed a custom security extension for SSRS 2008r2 and it works beautifully apart from when trying to deploy reports from within BIDS 2008/Visual Studio.
The architecture for the security extension handles logins via multiple authorities and I manage this by creating a user session in LogonUser(), persisting this in a database and then loading the session in the client proxy class for the RS web service using a UID passed by cookie from the service, then rewriting the authentication ticket to contain the session UID plus user roles for the current user. These values can then be used in the custom authorization extension to manage user permissions on SSRS actions and objects.
The problem I have run into is that it does not work when deploying reports from BIDS. Its accesses the service directly and therefore the service proxy class is not required. I have tried handling the post-authentication event on the HTTP context but alas the session cookie is not persisted by the RS service so I cannot access the session values.
So what am I missing? Is there another method for controlling user roles & permissions that does not require hard coding usernames anywhere? Like I said, logins can be made using multiple authorities so managing permissions via just a username is not possible (and the thought of it makes me cringe).
One possible solution I thought of is writing an extension or plugin for BIDS that essentially acts as a proxy for the web service which would allow me more control over the login process, but I have no idea if this is possible (google is no help...)
Any help would be gratefully accepted!
Are you using the IAuthenticationExtension interface? The following link provides a sound example of access control if that is what you require.
http://blogs.msdn.com/b/jameswu/archive/2008/07/15/anonymous-access-in-sql-rs-2008.aspx
I would imagine that the nt username can be tracked here and then lookups made against active directory groups etc. The main headache I can see here would be enabling the correct trust policy in the ssrs policy configuration.
Well I gave up on finding an elegant solution so I have gone down the road of least resistance and followed what I gather is the SSRS guideline of having a 'master' account, which I will specify is to be used for report deployment and subscriptions. This account will need to be hard coded in or pulled from a settings file I'm not sure if there is any other way. Cheers.
Update: I have gone down this road and it works fine. If a user is logged in through the web front end they can deploy reports there, but if they want to deploy from the development environment (BIDS) they need to log in using the master account when it the login dialog shows. I have restricted the deploying account to only this specific use.