I am having trouble calling an SSRS report server over SSL. I cannot figure out whether the issue is with my code or the configuration of either my web site or the SSRS site (both are under my control).
Below is some background. I am providing as much information as I can, because I don't know where the problem is. Some of it may not be relevant.
Web site (ASP.NET 4.0) and SSRS (2008 R2) are running on same server.
Everything works fine when both are running using http/port 80
Error returned by the SSRS url is "The remote server returned an error: (401) Unauthorized."
Certificate is fine, just created and installed it.
Certificate specified under https binding in IIS, and under SSL info for SSRS.
Web site uses anonymous authentication.
Application Pool Identity of web site is same domain user as SSRS service account. This same user is assigned to the "Browser" role in SSRS.
I have tried opening the HTTPS URL both with and without specify port 443
SSRS URL uses same sub domain as web site and both match the certificate
In my code, before calling GetResponse, I set Credentials to CredentialCache.DefaultCredentials. Also tried DefaultNetworkCredentials and leaving that line of code completely out.
Even though SSRS is running on the same server as the web site, I cannot "see" the SSRS site in IIS (seems weird and a mystery I haven't been able to solve). I do not see more than one version of IIS installed.
Nothing in SSRS logs (nothing, no indication that SSRS ever even got the request)
My intuition says this is a configuration setting somewhere, rather than a code issue, but I cannot figure it out. I've read a little about impersonation and wondering if that is what I need. I'd rather not bypass certificate validation unless that is the proper approach in circumstances such as this. If this is the problem, I want to do it properly.
Related
I have migrated our company web apps from Windows Server 2003 to Windows Server 2008 R2. The are all .Net 2.0 classic web apps. They all seem to work fine, except when accessing any resource with a path starting with /Reports/...
In one app the physical path on disk is c:\Websites\app_name\WebService\Reports... In this reports folder PDF files are dynamically generated and written to disk. They can be accessed via a URL such as this:
http://domain_name/Reports/xxxx.pdf
where /Reports is a virtual directory mapping to the physical path above. This worked fine on 2003 server & IIS6 but on IIS7.5 & 2008 R2 I keep getting the following error:
The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /Reports/xxxx.pdf
I have another web app that generates the reports dynamically and streams them directly to the client browser for saving to the local disk, rather than being written to disk on the server. Similar to the above example, the page that generates the report is found under path as follows:
/Reports/Viewer.aspx
In this case there is no virtual directory being used. The URL referenced in the browser is:
http://another_domain_name//Reports/Viewer.aspx
Once again I get the same error message as above... HTTP 404 - The resource cannot be found.
I have tried all the permission settings under the sun to try and get it working but to no avail. I've use built in accounts, created new accounts with permissions from very minimal right up to full admin rights. I've also played with the new AppPool Identities with no success. It doesn't seem to matter what permissions I set specifically on the directories, or the accounts configured for the app pool or basic settings on each website itself.
Once thing I have discovered though, is that whilst the browser is getting the HTTP 404 error, there is no record of this request appearing in the IIS log files for each website!! This is really confusing me, as I would definitely expect to see a failed 404 log entry on the requested resource.
Something else to note, I'm running SQL Server 2008 Enterprise on this machine with Reporting services installed and enabled. It's a stretch, but could there be some contention over the /Reports path in my websites vs something else running on the machine? I'm using different bindings/host headers for each individual domain and website running on the server.
Check Reports folder conflict. And remember, Google is faster than SO.
IIS gives 404 errors for more than just File Not Found these days - so it doesn't give away too much to attackers. Have a look at the event log (application), and also try accessing it from the server itself.
The other thing to check is that your IIS app pools are correctly configured - especially with the correct pipeline mode and .NET framework version.
At a command prompt, type:
netsh http show urlacl
See if there are any bindings with /reports/ --maybe a left over from a SQL Server Reporting Services install?
v/r
BK
My host is having issues getting my MVC3 app to work on their server, so I though I'd check it out myself. Until now I've been too busy developing under the built in server to worry about IIS, but today I tried my first deployment to the host with no joy. Then I tried one to my local IIS, with no joy. Then I tried telling VS to use IIS for debugging, to maybe resolve some local issues, with no joy.
What steps and configuration are required to use local IIS 7.5 to debug an MVC3 application?
EDIT: Going through a browser, after clearing up a permission problem for my Windows user on Temp ASP.NET Files, I now site with a I get a HTTP Error 403 (Forbidden), but the occassional basic auth login dialogue. Here I have tried a Forms auth user, my normal Windows user, and my Windows admin user, all to no avail.
When I try and debug under VS, I get a 500, internal error.
THE PLOT THICKENS: When I enable directory browsing on the site, I get a proper directory listing for the site root url. This suggests the the MVC3 routing is not working, but why not?
If you're getting a directory listing that means there's not a default file set (for IIS6). It usually means the request wasn't routed to IIS to deal with. thing are slightly different with II7 & it's integrated pipeline.
Simon
I have an ASP.NET application that's trying to copy a file to a remote share that's on a server on another domain ("REMOTEDOMAIN"):
File.Copy(#"c:\Test.txt", #"\\REMOTEMACHINE\Share");
When we get to the File.Copy method, I'm getting "Login failure: Unknown user name or password" when trying to connect to the share through the local IIS install. This is despite the share itself having "Everyone" read/write permissions (temporarily, at least). The Security log on the remote server logs the same error, so I know the process is at least trying to get to the right place.
I sort of understand why, as the website's application pool is attempting to authenticate with an account on LOCALDOMAIN and not REMOTEDOMAIN.
However, the weird thing is, the entire process works fine when I test through the ASP.NET Development Server instead of IIS, despite the fact that both the Development Server and the IIS Application Pool are using the same credentials.
Any thoughts on how to further diagnose this? Unfortunately the test site has to remain on LOCALDOMAIN and the files still have to be copied to REMOTEDOMAIN; I can't move one site to the other or vice versa.
Everyone does not include Anonymous, so the user still needs to be in the domain of the REMOTEDOMAIN (http://support.microsoft.com/kb/278259). You could get this working by allowing "Guest", but it would be a security nightmare of course so it is not much of a help.
The solution would be to impersonate Asp.Net user: http://support.microsoft.com/kb/306158
One hack that you should know is that if the IIS is not in the remote domain, you can go around this problem, by setting up local (non-domain) users on both machines and setting the same password for both of them.
despite the fact that both the Development Server and the IIS Application Pool
are using the same credentials.
Are you absolutely sure about this? If you are talking about the Visual Studio dev server, it runs on your account. And typically Asp.Net runs as "Network Service"
Today we tried to put an ASP.NET application I helped to develop on yet another production machine. But this time we got a very weird error.
First of all, from all the ASP.NET pages, only Login.aspx was working. The rest just show a blank screen when they should have redirected to Login.aspx. The HTTP response is 200, but no content.
Even worse - when I try to enter the address of some inexistent ASPX page, I also get HTTP 200! Or, when I enter gibberish in some existing ASPX page code (which should have been accessible without login) I also get HTTP 200.
If I enter the name of some inexistent resource (like asdasd.jpg), I get the expected 404.
The redirect to login page is written manually in Global.asax. That's because the application has to use some alternate methods of authentication as well, so I can't just use Forms Authentication. I would suspect that Global.asax is failing, if not for the working Login page.
Noteworthy facts are also that this machine is both a Domain Controller and has SharePoint installed on it. Although the website in question is listed in SharePoint's exception list.
I would check the following:
Is the application within a virtual application or its own site and not just a virtual directory?
Does the application have it's own App Pool? If it does not then is the app pool shared by apps in a different .net version.
Is the .net version of the application the correct one? 1.1 or 2.0?
Do the files in the file system have the correct permissions to be accessed via IIS?
Have you performed an IIS Reset?
Create a stand alone test.aspx page within your folder that just displays the date/time and check it works.
Make this single test.aspx page perform an exception (eg. divide by zero) and see what the outcome is.
More information required.
What Op Sys?
What mode IIS running under?
What version of .Net?
What version of SharePoint?
(Why are you using your DC as a web host?)
Does it work on the other production machines you've deployed to?
If so what is different between this machine and the working ones?
Did you deploy the same way?
Are you sure your hitting the right machine?
Are you sure your hitting the right web site?
What ISAPI components are installed globally and for the web site?
Is .aspx mapped to the ASP.Net ISAPI filter?
Do you have any HTTP Modules or HTTP Handlers configured?
Can you change the global aspx to write out some messages so you can be sure the piece of code you interested in is reaching?
Anything coming up on the IIS log or the event logs?
Addition:
What version of .Net?
By the sounds of it the .jpg request is being dealt with by IIS directly which is why you get the 404, but the .aspx request is being dealt with by something else which except for you login page, is always returning 200.
Assuming .aspx is wired correctly to .Net the the order of processing is based on ISAPI filters (high to low then global before site), then the ASP.Net ISAPI Extension (sorry I said this was a filter earlier but it's actually an extension). Then we get into the ASP.Net pipeline based on your .Net configs, and calls the HTTP Application (which includes your global.asax code), any HTTP Modules followed finally by a HTTP Handler. Your ASP.Net web forms are just fancy HTTP Handlers.
However, the request can be responded to and terminated from any point.
Since your code works on other machines though, I'm tempted to point a finger at SharePoint if it isn't installed on the working machines. Is this SharePoint 2007? That is also an ASP.Net application (I don't think 2003 was).
I have code running in an ascx within PageLayout within SharePoint 2007 that accesses files on a remote server i.e. File.Create("\servername\sharename\folder\file.txt"). The code runs within a SharePoint web application that has CAS trust set to Full in the web.config. The File.Create throws the following exception:-
System.UnauthorizedAccessException
Access to the path '\\servername\sharename\folder\file.txt' is denied.
The share is shared to Everyone with Full Control and the NTFS permissions are set to Everyone with Full Control. The web application app pool is running under a domain account also with explicit permissions to access that resource (not that this should be needed).
I ran Process Monitor on the remote machine and no hits were being recorded on the server. This leads me to believe that it is an issue with the SharePoint Code Access Security settings. Like I've said above, the trust in the web.config is set to Full.
Is it possible that CAS is still blocking the remote access? Can anyone think of any other area to review?
Update
A bit more information...
I've tried making the app pool acct domain admin and the problem still occurs. When using the same method to access a drive on the local machine it works fine. Running the same code in SnippetCompiler outside of sharepoint using the app pool account works fine.
Hope this helps, let me know if you can think of any more avenues of investigation or tests I can try.
Update
Im not sure if this would affect the issue but the local server is running Windows Server 2003 and the remote server is running Windows 2000.
Update
I've just tried running the code through a web part and it works fine. The file structure I use in the project that is failing is as follows:-
wss
- VirtualDirectories
- SharePointWebApp
- ...sp web app files
- .
- .
- PageLayoutControls
- control.ascx
- .
- .
Then in IIS I have the following structure:-
IIS
- Websites
- SharePointWebApp (pointing to \wss\VirtualDirectories\SharePointWebApp)
- PageLayoutControls (virtual directory pointing to \wss\VirtualDirectories\PageLayoutControls)
Then within the PageLayouts I reference the controls using the following:-
<%# Register TagPrefix="TEST" TagName="MyControl" Src="~/PageLayoutControls/control.ascx" %>
<asp:Content ContentPlaceholderID="PlaceHolderMain" runat="server">
<TEST:MyControl id="myControl" runat="server"/>
</asp:Content>Let me know if you need more info.
Update
The mystery deepens...
When I access the sharepoint site from Internet Explorer (6 or 7) on the SharePoint web front end server I do NOT get the exception.
When I access the sharepoint site from Mozilla Firefox from the SP web front end server I DO get the exception.
When I access the sharepoint site remotely from ANY browser I get the exception.
Also, it makes no difference what user I use to log on to the site, as long as they have permissions to access the sharepoint site.
Any thoughts?
Update
Hmm, I've now found that if I access the sharepoint site remotely and the sharepoint site tries to do a File.Create() locally (i.e. File.Create("C:\temp\abc.txt")) then it works. If I access the sharepoint site from the sharepoint box and do a File.Create() remotely (i.e. File.Create("\ServerName\ShareName\FolderName\file.txt")) then it works.
It only fails when I access the sharepoint site remotely and have the sharepoint site try to do a File.Create() remotely as well. Kind of a double hop problem. This makes me think it may be an NTLM / Kerberos issue.
Currently, we are running using NTLM authentication.
Has anyone else experienced this sort of issue?
Update
Yep, I'm pretty sure this is an NTLM issue not allowing a double hop. I just changed the authentication on the sharepoint site to use Basic Authentication and its worked. Changed it back to Integrated Authentication and it failed.
Now to decide whether to move the farm to use Kerberos or find another way around the issue. :-/
Update
Just giving SPSecurity.RunWithElevatedPrivileges a shot now. One thing though, is RunWithElevatedPrivileges meant to be used in this context? Previously, I've only used it to get access to lists and libraries within SharePoint rather than accessing a file access the network.
Any thoughts?
Update
Yep, SPSecurity.RunWithElevatedPrivileges resolves the issue. :-)
I wonder if this is the double-hop issue and that your code is trying to access the resource as the impersonated user, but that fails because NTLM will not impersonate to another server (Kerberos would).
Have you tried SPSecurity.RunWithElevatedPrivileges? That would remove the impersonation (RevertToSelf) and then maybe the application pool owner can just act as himself (herself?) whereas maybe it couldn't before.
Just a thought and should be pretty easy to try out.