none
Reportviewer - how to pass windows authentication to it

    Question

  • Hi,

    How do you pass the windows security credentials used in an asp.net website to the reportviewer control?

    I have a website set up with windows integrated security and when I just call the reportviewer control using the following code I get an access denied error.

    ReportViewer.ProcessingMode = Microsoft.Reporting.WebForms.ProcessingMode.Remote
    ReportViewer.ServerReport.ReportServerUrl =

     

    New Uri("http://server/reportserver")ReportViewer.ServerReport.ReportPath = "/reports/report1"

    My config file is set to...

    <

    authentication mode="Windows"/>
    <
    identity impersonate="false"/>

    Even changing the impersonate to "true" doesnt help.

    So does anyone know how to programmatically set the reportviewer security credentials so that it picks up the windows based username & password....
    e.g.

    ReportViewer.ServerReport.ReportServerCredentials = ??

    • Edited by niallhannon Thursday, December 17, 2009 12:30 PM formatting
    Thursday, December 17, 2009 12:29 PM

Answers

  • Hi niallhannon,

    From your description, it seems you are going to pass the client's credential from the custom web application to the SQL Server Reporting Services. 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, you 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.

     

    Local Server

    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:

                  

    <system.web>

        <authentication mode="Windows"/>

        <identity impersonate="true"/>

        <authorization>

            <deny users="?"/>

            <allow users="*"/>

        </authorization>

     </system.web>

     

    Remote Server

    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:

    http://www.odetocode.com/Articles/216.aspx

     

    If there is anything unclear, please feel free to ask.

     

    Thanks,

    Jin Chen


    Jin Chen - MSFT
    Tuesday, December 22, 2009 9:04 AM
  • Hi niallhannon,

    In this case, if you are going to pass the client's credential to the report server, you should need to configure the Kerberos delegation.

    Thanks,
    Jin Chen
    Jin Chen - MSFT
    Tuesday, December 22, 2009 9:06 AM

All replies

  • Hi niallhannon,

    From your description, it seems you are going to pass the client's credential from the custom web application to the SQL Server Reporting Services. 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, you 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.

     

    Local Server

    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:

                  

    <system.web>

        <authentication mode="Windows"/>

        <identity impersonate="true"/>

        <authorization>

            <deny users="?"/>

            <allow users="*"/>

        </authorization>

     </system.web>

     

    Remote Server

    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:

    http://www.odetocode.com/Articles/216.aspx

     

    If there is anything unclear, please feel free to ask.

     

    Thanks,

    Jin Chen


    Jin Chen - MSFT
    Tuesday, December 22, 2009 9:04 AM
  • Hi niallhannon,

    In this case, if you are going to pass the client's credential to the report server, you should need to configure the Kerberos delegation.

    Thanks,
    Jin Chen
    Jin Chen - MSFT
    Tuesday, December 22, 2009 9:06 AM