I have deployed some reports and my users wish to do away with the logon prompt when getting to the reports manager homepage.
I have an account which is local to the server and I want to run all of the SSRS site under the context of that account. This account is a "browser" in the reports site.
Prior to 2008, when SSRS site was still listed in IIS you could disable anonymous authentication and provide an account. All requests to the reports site would go in under that account which was configured with readonly access. It worked quite well this way. The only downside was that it made publishing new reports or doing updates a bit more difficult.
How do I accomplish this same thing using reporting services configuration tool? The service account and the execution account don't provide this functionality when I configured them.
Individually setting up users for access to the reports site is a maintenance sinkhole and my server is on someone else's domain so I don't have access to info like usernames and being able to create groups.
Also, I tried the "anonymous access for 2012 reporting services" steps and while this takes care of the logon prompt issue for me it also makes it to where users can delete data sources and reports entirely.
If you are using Windows authentication then you will need two accounts on the local server to satisfy your needs. One would be a "ReportUser" account and one would be a "ReportAdmin" account.
If you can provision or use two existing windows accounts for those roles then use SSRS manager to set the "ReportUser" as a browser user and "ReportAdmin" as an admin user in SSRS manager. Always deploy using the "ReportAdmin" user. The "ReportAdmin" could be the admin account for that box. You could deploy with that account.
Since you did not link the article you used to configure anon access I have no idea how your "ReportUser" is connecting.
This particular customer wanted no login prompts at all and agreed to pay support costs for re-deploying any reports which their workers may delete by accident.
To comply with their request I used the steps outlined in the "Anonymous access for 2012 reporting services" article referenced above.
Generally I would set up two accounts in the exact manner as Irb described. This is actually the first time that someone has not wanted that setup 0.o
Related
My company just finish set up a reporting services server 2017.
The service run under a domain name.
At the same server, an IIS has been setup to run a web application in ASP.NET which will server the report from a report viewer. The IIS is currently running with default App Pool.
GOAL : We want client to be able to access the report from the web application without having to fill in the username and password from anywhere be it on intranet or internet.
Before this, we have ssrs 2008 with similar setup but for authentication we go with anonymous authentication, which is what we want, they can view report from anywhere.
But from microsoft site, they stated that authentication isn't supported anymore in the latest version, and we have tried doing it which results in error 401: Unauthorized.
Currently, I'm trying to do a kerberos authentication,
Things that I have done :
SPN for reporting services account.
Delegation for reporting services account.
Web application web.config I've added authentication mode="Windows" identity impersonate="true"
On IIS, I've enabled windows authentication and impersonate.
But when I try to request a report from the web application, I still got the prompt for username and password, when I fill in my domain and password, I still got the same error 401: Unauthorized.
Am I doing something wrong? Is Kerberos really suitable for my GOAL?
Thanks in advance.
EDIT : Sorry, If I am posting in the wrong section. I don't know where is the correct section for this question.
When you are planning to deploy the reporting service on the internet its batter to use the custom authentication instead of the windows authentication. Creating a custom authentication extension requires custom code and expertise in ASP.NET security.
If you do not want to code a custom authentication extension, you can use Microsoft Active Directory groups and accounts, but you should greatly reduce the scope of a report server deployment. The following guidelines describe how to support this scenario:
Create a low-privileged domain user account with read-only permissions. The account must have access to the computer hosting the report server. Provide a custom Web form so that users can log on using the low-privileged domain account.
Create role assignments that map the user account to specific items in the report server folder hierarchy. You can limit access to read-only operations by choosing as the role assignment the Browser predefined role.
Configure reports to use stored credentials to get data for the report. This approach is useful if you want to query the external data source using an account that is different from the account that allows access to the report server.
you could refer to the below links for more detail:
https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2005/bb283249(v=sql.90)?redirectedfrom=MSDN#configuring-authentication-for-extranet-and-internet-access
https://learn.microsoft.com/en-us/sql/reporting-services/security/authentication-with-the-report-server?view=sql-server-ver15
https://forums.asp.net/t/2095478.aspx?401+Unauthorized+SSRS+authentication+from+NET+IIS
https://forums.asp.net/t/1273411.aspx?Setting+up+Reporting+Services+with+IIS+Access+Denied+Error
We recently had to change a domain admin password due to a security issue. As a result, on our prod web server, we're seeing a large number of Event ID 4625 errors showing up in our security log associated with an IIS App Pool. We're on Windows 2012 R2/IIS 8.5; ASP.NET 2.0 & 4.0 are installed on the system.
The interesting piece is that the App Pool in question never used the domain admin account as its Identity. It has always used the out of the box ApplicationPoolIdentity. I should also note that the server was logged off using that affected user well prior to the password change & a new account is now used to administer the server.
The server itself though was in fact built using the affected domain admin account. All roles/features were added while logged in as the aforementioned account. With this in mind, no services are running as the account, ie World Wide Web Publishing Service/IIS Admin service. They're running as Local System & always have.
No functionality has been compromised, everything is operating normally on the web server. The issue is that our tech services team is receiving constant notifications from their account monitoring software regarding the bad logon attempts & it is impeding their operations. Full disclosure... We haven't had an opportunity to reboot the server yet since its production, we will be doing that tonight.
The problem seems to be relegated to the root of the site, the \wwwroot folder. Segregating only the root app to its own app pool/turning off the pool is not an option since it services file system requests. We've tried explicitly setting the identity on the affected app pool to use Local Service as well as a regular domain user. The issue persists regardless:
So naturally, our hope is that the reboot takes care of it... Perhaps the old password is stuck in a kerberos cache, but it's just strange since this app pool never used the ID as its identity, that it continues to show up.
We had a virtual directory that was using the ID in order to reach out to a CIFS share on the network. Once we changed that, the error ceased.
I have created and deployed an SSRS report 2008, which I am able to access from the same machine using the URL. But I am not able to access the URL from another machine in the same network. Please suggest me what i have to do to access SSRS reports via URL from another machine in Local Area Network.
The ability to access an SSRS report is generally dependent on Windows authentication, which is controlled under the report manager's security tab. You can add or remove groups of users through the security interface. This would explain why some users can access it and others cannot. Also, when granting access, you must be sure the user has the Browser role enabled.
If it is a permissions issue, then SSRS should return a permissions error when you attempt to access it from the other terminal.
Therefore, you need to ensure that all intended users are in an appropriate user group and granted the appropriate permissions.
You can run the report by accessing report manager from your browser. Report manager url is the one we set up while installing and configuring ssrs.
I'm trying to set up SSRS 2008 on my desktop machine for development purposes.
The following is working fine:
Report deployment on local server
Previewing the report in BIDS
Access to htpp://localhost/Reports panel
But when I point the ASP.NET Reportviewer to the Report URL, I get the following error:
The permissions granted to user 'NT-AUTHORITY\NETWORKSERVICE' are insufficient for performing this operation. (rsAccessDenied)
How can I get around this error? Is there any dialog where I can grant SSRS access rights to certain forms authentication roles? I've googled quite a bit on this, but what I have found so far was either outdated or quite confusing.
Edit: Several users of my web app are going to have access to the same database, so I need the UserID build-in field (User!UserID) to reflect the user's Forms authentication ID. I guess the only way to achieve this is making SSRS work with forms auth?
You web application is running as Network Service so that is the user you are trying to connect to Report Server as. You have several options. One, you can grant Network Service permission to execute the report you are trying to run. Two you can have your web application impersonate a windows user and give the correct users permission to the report. Three you can impersonate impersonate a different user when connecting to RS. I believe to do the last one you will have to write some extension code for the viewer to tell it how to impersonate before connecting, but for the other two there would be no code change.
You could also look into using Report Server in Forms auth mode if your web site is not an internal site, but this is more complicated.
EDIT for 2nd Question:
Yes, you will need each user to be unique when they access RS so you will need to use Forms Auth or windows auth or write your own custom authentication extension.
My supervisor at the office tells me that he saw a demonstration with a pre-release version of Microsoft "Geneva" (now Windows Identity Foundation) where a developer did the following:
He set up some sort of ASP.net web application where a user could log in using a customized log-on system. Behind the scenes, the web application logs the user in as a user in an Active Directory.
The user logs in.
Once the user is logged in, the the ASP.net web application thread runs as the logged in user for the duration of the user's session and can access resources on the network (such as running SQL queries on tables whose access is controlled Active Directory)
Steps 2) and 3) are exactly the same as using the "Integrated Windows Authentication" setting in the "Directory Security" tab of the web site settings in IIS. Step 1) is different because we are using a custom log-on system as opposed to the Kerberos authentication.
We want to set up one of our applications to operate exactly as described in 1), 2), and 3). However, all the documentation that I've seen regarding Windows Identify Foundation is about Cardspace and Federated Security. We have zero interest in using either of these technologies right now.
We just want to be able to log users in to Active Directory Accounts behind the scenes.
Yes, we've tried the ActiveDirectoryMembershipProvider with Forms Authentication, but it's a complete kludge to actually access resources on the network requiring impersonation on every page!
UPDATE Jan 7, 2010. Okay, I've been working at this for a while, and everything I've managed to come up falls short of what I want to achieve. Perhaps the functionality I want is not in the release version of WIF.
Here's where I'm at now. I've found some documentation on MSDN that indicates that there are three different identities used in ASP.net: the identity specified by HttpContext.Current.User, the identity specified by Thread.CurrentPrincipal, and finally the identity specified by WindowsIdentity.GetCurrent. link
In one example of where I want to use the process I'm looking to design, I want to perform a SQL query as the logged in user. In my debugger, I see that I easily set the HttpContext and Thread users to the logged in user. However, when I connect to the SQL server using Windows Authentication, it always always always connects as the WindowsIdentity.GetCurrent user and that user is always always always the identity of the ASP.net process unless I'm using Windows Authentication with impersonation. I absolutely cannot use Windows Authentication with my application because my users must log in by playing a magic flute song and Windows Authentication has no support for logging in with magic flute songs.
To clarify, there is no trouble with obtaining a WindowsIdentity representing the logged in user (who logged in with a magic flute song). The problem is that I cannot use that WindowsIdentity to perform SQL queries for my user.
WIF allows you to configure it so a claims based identity maps to an AD account, the claim may either be a federated identity claim, or delivered via an information card. c2WTS performs this function.
Even when it does map because of delegation you're always going to have to delegate if you want to use the AD identity IIS is impersonating - that's just how it works, unless you setup Kerberos delegation for IIS
You can achieve the same using Identity Impersonation in ASP.net. Also you need to enable windows integrated authentication for you web app. This will solve the purpose. If the logged in user does not have the required rights to access resources you will get security exceptions which you will have to handle.