My website is redirecting to 404 error page when the page actually does exist. My website is set up so that it uses windows authentication. If the user does not have access, he/she is redirected to a page that tells them they have no access. If the user does have access then it takes them to another page. My website is set up on a 2008 server with IIS 7. The default document is Default.aspx, windows authentication is enabled and the rest is disabled, my website was working before I put in the security. I have also tried this with Anonymous Authentication. I also put to allow all users for now until I get this to work. I added in tracing to see what it was doing since we cannot debug on the server, so then I see that it is not getting the users' ID. So I do not know what I am missing. I cannot figure out why since this works perfectly on my local machine but not on the local server. I have researched this and I cannot come across anything else I can do. Also, this works when I run it on my local machine and I am using VS 2013.
To get the User's ID, I have used the following code:
un = HttpContext.Current.Request.LogonUserIdentity.Name.ToUpper();
un = User.Identity.Name;
un = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
It crashes on the following line due to the user ID being 0.
I have searched YouTube videos that walk through setting up Windows Authentication and I even have it working on another application perfectly fine! This is frustrating and would really appreciate any help I can get. Please let me know if further details are needed.
The error I get is a 404 error
Error Summary
HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Detailed Error Information
Module IIS Web Core
Notification MapRequestHandler
Handler StaticFile
Error Code 0x80070002
Requested URL http://MyApp.com:80/Default.aspx
Physical Path D:\Sites\MyApp\Default
Logon Method Negotiate
Logon User XXX\bds
Related
I have a curious problem with a legacy ASP.NET web application using Windows Authentication. A particular page is crashing, and an inspection of the page and the site logs indicates the page is crashing because the request is not properly authenticated - no Windows identity is being requested by IIS or supplied by IE 11.
The page has a curious path; it took a few minutes to decode how it was originally assembled. The initial request is not for a specific page, but is merely a folder-only URL that is routed to Default.aspx. The handler checks the query string and redirects to specific pages accordingly.
The initial request to the site is authenticated, as evidenced by the IIS site logs. The page to which the request is redirected (Response.Redirect) does not authenticate. The absence of the Windows authentication challenge leaves the site with no automatic identity to the targeted page, leading to the page crash (code depending on the identity fails). The sequence goes this way:
Original URL: /sitename/folder/?parameter1=value¶meter2=value
IIS issues the authentication challenge, and the authenticated user is shown in the logs - eg, domain\user
The request is then handled by folder/Default.aspx (default page as defined in IIS)
Default.aspx.cs inspects the query string, and routes the request to (eg) OtherPage.aspx via Response.Redirect.
OtherPage.aspx is requested, and the request is logged - with no authentication, and no challenge
OtherPage.aspx.cs crashes (no user credential)
I am trying to theorize how or why ASP.NET is even permitting the unauthenticated file request. I have tried to reproduce the behavior in a test environment, and have been unable to do so. I have suspected that "Automatic logon in Intranet zone" might have been disabled, or that stored local credentials may be present but somehow causing a conflict, but neither of those scenarios panned out. The former did result in a failed authentication attempt and a proper 401 response from the server (the target page was not fired in a test environment).
Further research into this question has led to a solution if not a 100% dissection of the cause.
The users experiencing the problem were accessing the target site via a link in an email message. The link, for some unknown reason, inhibited the credential exchange between IE and IIS until the site URL was placed in the "Local Intranet" sites list of IE. This allowed the "Automatic logon in Intranet sites only" option to apply which, in turn, allowed the authentication to work.
The reason this is not a "100% dissection" is because these users were accessing the site previously, wherein authentication worked when the site was accessed conventionally. Exactly how the email message link inhibited the authentication exchange is not known. At the moment, I theorize that some security setting inhibits authentication when originating from an email link unless the specific site URL is explicitly qualified as a trusted or Intranet site.
Thanks for your consideration.
I've viewed a few of the other IIS reverse proxy with windows authentication posts on here and they don't seem to be what I'm trying to do. Hopefully someone will be able to help or spot what I'm not doing or doing wrong.
I've got a server which has a website running on port 80 which I need to present a number of other web applications on. I cannot create new hostnames so I created a virtual directory in the site which pointed to my web apps, however the root site is using .net2.0 app pool which must stay as .net2.0 whereas my ASP.NET MVC apps all need 4.0 app pools. As per the web.config inheritance problem this is not working and I cannot change the web.config in the root to ignore propagation to child web.configs - with me so far? ;-)
To cut a long story short I've now got a virtual directory in my port 80 site which is acting as a reverse proxy to another site on port 81 and this is working fine for anonymous connections. I've tested it with a simple HTML page and I can access it and the url re-writing is working on links in the HTML page, all good so far.
Now I need to enable windows authentication on the port 81 site, so I followed the instructions similar to what is in these links on MSDN site to configure SPN's for the domain account I'm using (DOMAIN\testaccount) and other IIS config's:-
link 1
link 2
The problem is that all I get now is the good old error message:-
Access is denied. Description: An error occurred while accessing the
resources required to serve this request. The server may not be
configured for access to the requested URL.
Error message 401.2.: Unauthorized: Logon failed due to server
configuration. Verify that you have permission to view this directory
or page based on the credentials you supplied and the authentication
methods enabled on the Web server. Contact the Web server's
administrator for additional assistance.
-------------------------------------------------------------------------------- Version Information: Microsoft .NET Framework Version:4.0.30319;
ASP.NET Version:4.0.30319.34280
I've tried creating a test aspx page which just outputs the server variables to the response but even this is not working.
I can't find anything else to try, initially I thought I'd have to get Kerberos sorted to pass the details from virtual directory to site on port 81 but the MSDN posts say this is not needed, just the SPN's.
Anyone any ideas?
This turned out to be something very simple and me being dumb for not checking! :-)
I spent days trying to figure out why this wasn't working, not sure why I didn't try earlier but I changed the application pool it was running under to use .net2.0 and then my test aspx page worked!?!
Turns out in IIS manager if you click on the root server node itself that under 'ISAPI and CGI restrictions' feature settings that the .net4.0 DLL's were set to 'Not Allowed' but the .net2.0 DLL's were 'Allowed'! I just enabled the .net4.0 changed the application pool back and then voila it works.
We have a MVC4 application running on a windows server 2008 with iis 7.5. everything was running fine until out SSO team installed siteminder for single sign on.
Now the application after the SSO redirect is giving a 403 forbidden error. Any Suggestions?
Here's what is happening.
1. access the site.
2. Site redirects to SSO page
3. after entering the credentials (everything is validated as the siteminder trace and logs is showing no errors)
4. application redirects the original entered url and we see a 403.
we currently have no implementation that uses the SSO user coz we were waiting for the SSO to be setup and our current authentication in web config is set to "None"
application was all good before the siteminder and the url was accessible.
Verified everything but not sure what is the issue.
1. Application pool is set to 4.0
2. TestConnection is ok for authorization and authentication
3. No errors in siteminder logs (the SM cookie is set correctly)
4. We do not have SSL
5. this is the only site running on the server
6. IIS_IUSRS is given access to the sites root folder
Not sure if there is anything we can do in the sites web config. though as i have mentioned before it was all ok before site minder. Now Even if we disable the siteminder the application just return 403 forbidden.
please help!!
well we finally reached out to some people with extensive siteminder experience and they suggested to use the "classic" app pool instead of "Integrated" which solved our issue.
I've written a web application for internal use at work (not for the wider internet) that makes use of Windows authentication - ASP.NET interrogating Windows for the current set of credentials. An authentication method called from the Page_PreInit of protected pages throws a 401 error if the username is not found in an AD group I've set up.
I implemented Earlz' CustomErrorsFixer from Throwing an HttpException always sends back HTTP 500 error? as I too was only getting 500s back. Now my custom error pages are working, which is great.
Developing locally in Visual Studio development server, I've found that if I do not have access, I just go straight to the 401 error page. However! When I publish the site to an IIS server, if the user doesn't have access they get a Windows username/password prompt (the ugly, small one in XP). This is actually quite handy because it gives people who are logged onto a different domain a chance to enter the correct credentials.
At this stage, when the password prompt comes up, if the user hits Cancel or Escape, they go to the custom 401 page, which tells them how to go about requesting access. IF however they try to enter a username and password, which defaults to the wrong domain and are therefore incorrect credentials, they are shown the default IIS 401 page, which I'm very keen to avoid. Third scenario - if they enter CORRECT credentials, they are asked 3 times, and then shown the custom error page.
So, users see the custom 401 page if they are "authenticated", and the standard IIS one if they are not.
However, I've been finding that most people when prompted with a username/password box just enter the username/password without domain - which ends up being incorrect and therefore sending them to the non-custom IIS 401 page. Does anyone know how I can solve this? It's extremely annoying, because people need to see the custom 401 page in order to see which group they need to request access to!
In case it matters, the browser we all use is IE8 on XP or IE9 on Windows 7. Please let me know if I should post any code up.
IIS7 intercepts the 401 along with a few other HTTP status code by default.
Try this:
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</configuration>
I am having an issue adding a Web Service Reference to the CRM Deployment Service at http:///MSCRMServices/2007/CrmDeploymentService.asmx
When I first attempt to connect it says Connecting to and prompts for credentials. After entering my credentials, it will continue to prompting for credentials indefinately.
When I attempt to navigate to the service in IE, I get prompted for credentials and after submitting them a few times, I get a 401 error.
When I attempt to navigate to the service in Firefox or Opera, the basic authentication dialog pops up and I enter credentials. The service description page correctly appears.
Is there something preventing IE/VS from submitting the credentials correctly? In each place, I am using the same domain/user credentials. I have tried it from IE on both a computer on the domain and a computer not on the domain and get the same results.
Not sure if this will help, but I vaguely remember something like this happening to us at work, and someone fixed it by disabling IPV6. Like I said my memory is hazy so I don't know if this is the exact problem that we were having too. I just remember that the solution was to disable IPV6 on the server.