Raghunandan44
asked on
Problem When running sql reports
Hi ,
I have just Installed Sql Server reporting services on my machine . When i try to run a small sample app .
I get an errpr as No reporting server found at the http://localhost/reportserver .
When i tried to browse to that through the IE i get an HTTP404 page Cannot be found error.
Did i miss something please help me here
Thanks
raghu
I have just Installed Sql Server reporting services on my machine . When i try to run a small sample app .
I get an errpr as No reporting server found at the http://localhost/reportserver .
When i tried to browse to that through the IE i get an HTTP404 page Cannot be found error.
Did i miss something please help me here
Thanks
raghu
What's the full error you receive?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Have you checked that your IIS is running and configured correctly?
Exactly simon kirk, that's what I was saying with the ASP.Net account. Permission related possibly.
ASKER
what kind of permissions sholud i give to the aspnet account inorder for reports to run.
Thnaks all for the replies they were very helpfun in learning about this stuff
Thanks
Raghu
Thnaks all for the replies they were very helpfun in learning about this stuff
Thanks
Raghu
Here this is from an article by Scott Allen:
http://odetocode.com/Articles/216.aspx
Credentials and ASP.NET
Determing what DefaultCredentials represents in an ASP.NET environment is more difficult. 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 take 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>
WIth impersonation the ASP.NET page will execute with the security context of the client, and web service calls to the same machinewill also be made with the security context of the client (using DefaultCredentials). You will still need to configure role-based security for each user to give each user authorization to perform actions.
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.
Finally, you can pass credentials from ASP.NET to the reporting server using the NetworkCredential class shown earlier in the article. All the same caveats apply in regards to storing a username and password in code or in an XML config file.
Once you’ve avoided all of the access denied messages, it’s time to configure role-base security.
http://odetocode.com/Articles/216.aspx
Credentials and ASP.NET
Determing what DefaultCredentials represents in an ASP.NET environment is more difficult. 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 take 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>
WIth impersonation the ASP.NET page will execute with the security context of the client, and web service calls to the same machinewill also be made with the security context of the client (using DefaultCredentials). You will still need to configure role-based security for each user to give each user authorization to perform actions.
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.
Finally, you can pass credentials from ASP.NET to the reporting server using the NetworkCredential class shown earlier in the article. All the same caveats apply in regards to storing a username and password in code or in an XML config file.
Once you’ve avoided all of the access denied messages, it’s time to configure role-base security.
It kind of helps if you understand the implications of the security model you choose--I would also read up on the Microsoft .NET security models:
http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnnetsec/html/secnetch06.asp
If you post the exact connection error message you receive, we would also be able to provide more accurate answers.....
Brett
http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnnetsec/html/secnetch06.asp
If you post the exact connection error message you receive, we would also be able to provide more accurate answers.....
Brett
ASKER
The Exact Message That i get When i try to run the application is
"A connection Could Not be Made to the Report Server http://localhost/reportserver "
Thanks
raghu
"A connection Could Not be Made to the Report Server http://localhost/reportserver "
Thanks
raghu
Did you install IIS after you installed the .Net framework?
Go back to the way it was originally and try this:
Open up a command prompt, I am guessing your running framework 1.1:
Navigate to:C:\WINDOWS\Microsoft.NE T\Framewor k\v1.1.432 2
Enter this
aspnet_regiis -i
Go back to the way it was originally and try this:
Open up a command prompt, I am guessing your running framework 1.1:
Navigate to:C:\WINDOWS\Microsoft.NE
Enter this
aspnet_regiis -i
ASKER
Thanks for all your help guys !!
I gave up and reinstalled the whole reporting services . that worked.
Thanks
raghu
I gave up and reinstalled the whole reporting services . that worked.
Thanks
raghu
ASKER
thanks
raghu