The permissions granted to user 'NT AUTHORITY\NETWORK SERVICE' are insufficient for performing this operation. (rsAccessDenied)
I've successfully installed MS SQL Server 2008 Express with reporting services on a Windows Server 2003 SP2.
If I go to http://srvreporting/ReportServer (I've added the address to the (Intranet Locale) all is right and I see the page. The same thing happens when I go to http://srvreporting/Reports.
In Reporting Services Configuration Manager I've set:
Service account: Local System
Database: Connection with a particular user with all rights on db
Execution account: Nothing specified
I've a service published on IIS 6 that opens up a web page , using the ReportViewer .NET class (on web.config I've set <authentication mode="Windows">, set some report parameters values and does the call to url. So my service receive an URL from an application and do the call to reporting services page.
In IIS i've enabled the anonymous access with an user in group Administrators and also Windows Identity.
When my service opens the page i've the above error: The permissions granted to user 'NT AUTHORITY\NETWORK SERVICE' are insufficient for performing this operation. (rsAccessDenied).
I've executed all this from server machine and no client has been used. I'll try the clients soon. I don't understand why the NETWORK SERVICE user is used. If in reports I add NETWORK SERVICE rights to use reports all work fine but i don't want to do this.
P.S.: In local policies i've set the users to authenticate as themselves.
Anyone knows wich is the problem?
Why it uses the NT AUTHORITY\NETWORK SERVICE user? I've executed all this operation from the server machine
Hi Montanari F,
From your description, you are using MicrosoftReportViewer control to display a server report in a custom web application. Now, we encounter the error “The permissions granted to user 'NT AUTHORITY\NETWORK SERVICE' are insufficient for performing this operation. (rsAccessDenied)” while viewing reports. You want to know why the user user 'NT AUTHORITY\NETWORK SERVICE' is used and how to solve the issue. If I have misunderstood, please do not hesitate to let me know.
By default, every call to Reporting Services must be an authenticated call. To provide credentials to authenticate, we must use the Credentials property of the web service proxy class. The credential could be DefaultCredentials that represent the credentials for the current security context of the process or credentials for an account that exists on the report server using the NetworkCredential class. In this case, you use the NetworkCredential for an account that exists on the Report Server.
To avoid use of Network username and password, we can use the DefaultCredentials.
ReportViewer.ServerReport.ReportServerCredentials = System.Net.CredentialCache.DefaultCredentials;
For a client-side application, like a Windows Form application or a console mode program, the DefaultCredentials will be the credentials of the user executing the program.
For ASP.NET environment, in a default installation, with no impersonation in place, DefaultCredentials will be the credentials for the ASP.NET process. The ASP.NET process runs as the ASPNET account (in IIS 5.0), or the NETWORK SERVICE account (in IIS 6.0). At this point we need to break down the scenario into local reporting server versus remote reporting server environments.
If the web application is on the same server as the Reporting Services web service, the call will authenticate using DefaultCredentials, but you are probably seeing the “permissions are insufficient” exception. One solution to this problem is adding the ASPNET or NETWORK SERVICE account into a role in Reporting Services, but takes care before making this decision. If you were to place the ASPNET account into the System Administrators role, for example, anyone with access to your web application is now a Reporting Services administrator.
Alternatively, you can use impersonation in ASP.NET. You can enable impersonation for the application, for a subdirectory of pages, or for individual pages, using the identity element in web.config (see more resources for additional information). When using impersonation, it is important to deny access to anonymous users, as shown below:
When a web application makes web service calls to a remote report server, there are additional complications. If you are using impersonation, there is a one-hop limit with NTLM authentication. The client’s credentials make one hop from the client machine to the web server, and ASP.NET can use these credentials to impersonate the client on the same machine only. For ASP.NET to use the credentials on another remote machine would require the credentials to make a second hop, which does not happen - the call will go to the remote machine with the credentials of the ASP.NET process instead. Since the ASP.NET process runs under a local machine account by default, the remote server will not authenticate the credentials and the call will fail with an access denied message.
There are a number of solutions in this scenario.
First, you can look at enabling Kerberos delegation, which is beyond the scope of this article, but you can read about delegation in the article How to Configure an ASP.NET Application for a Delegation Scenario. Using delegation would allow you to have the client’s credentials make the additional hop to reach the report server, which in turn gives you more granular control over authorizations by placing users and groups into roles instead of process accounts.
Another option is to run the ASP.NET process under an account with permissions to the report server. For example, the ASP.NET process could run under a domain account. For details, see the article: ASP.NET Process Identity. A similar strategy would be to synchronize the ASPNET / NETWORK SERVICE accounts on both the application server and the reporting server by matching thier passwords and configuring ASP.NET to use the password. Using these options you’ll need to add the ASP.NET process account into a role on the report server. Unfortunately, anyone with access to your web application will now be in this role, so your application will become responsible for more granular authorization checks.
For a more detailed description, please see the article that is offered by Scott:
If there is anything unclear, please feel free to ask.
Jin Chen - MSFT