Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a php website running under IIS 7.5. The site is secured by Windows authentication and that works fine:

Windows Authentication is on

When users go to the site, they are asked for username/password and get through if authenticated. If users click Cancel or mistype password 3 times, they are shown 401 error page:

Ugly 401 page

Now I would like to show custom page explaining how to log-in. So I go to Error pages, select status code 401.2 and point it to the page I would like to display:

Error pages settings

Then make sure the custom errors are turned on for everybody. And kaa-boom! Authentication does not work any more, users are not presented with the password prompt. As documentation says, Windows Authentication works by sending 401 reply first, then browser asks user to provider credentials and then they work out what to do next.

What happens here: on first request for the page IIS tries to send 401-header, but notices that web.config says "on 401 redirect to this page". And instead of authentication, it just gives the redirect page.

I've tried replacing 401, 401.1, 401.2 - made no difference.

What am I doing wrong and how to give custom page on user authentication error?

p.s. Here is the web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpErrors errorMode="Custom">
            <remove statusCode="500" subStatusCode="-1" />
            <remove statusCode="404" subStatusCode="-1" />
            <remove statusCode="401" subStatusCode="-1" />
            <error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="/not_restricted/401.htm" responseMode="ExecuteURL" />
            <error statusCode="404" prefixLanguageFilePath="" path="/not_restricted/404.htm" responseMode="ExecuteURL" />
        </httpErrors>
        <httpProtocol>
            <customHeaders>
                <remove name="X-Powered-By" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
    <system.web>
        <identity impersonate="false" />
        <customErrors defaultRedirect="http://www.myserver.com/not_restricted/500.htm" mode="Off">
        </customErrors>
    </system.web>
</configuration>
share|improve this question

4 Answers 4

up vote 6 down vote accepted

Try this:

change:

<error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="/not_restricted/401.htm" responseMode="ExecuteURL" />

to

<error statusCode="401" subStatusCode="2" prefixLanguageFilePath="" path="not_restricted\401.htm" responseMode="File" />

With the response mode 'File' IIS just loads the content of that file and displays it, it still sends the 401 status back to the client.

I used to use 'ExecuteURL' but have learned that File mode works much better. You just have to make sure that any linked resources in your error pages still work.

share|improve this answer
1  
Sir, you are a star! That fixed the problem from the first attempt! –  trailmax Dec 15 '12 at 20:14

I ran into this same issue of users not being prompted with credentials after adding custom httperrors and was able to fix it with a subStatusCode of 0. Hope this helps someone.

<error statusCode="401" subStatusCode="0" path="..." responseMode="ExecuteURL">
share|improve this answer

For some weird reason in my case combination of up 2 solutions worked for me for asp.net MVC 5.

  <error statusCode="401" subStatusCode="0" prefixLanguageFilePath="" path="not_restricted\401.htm" responseMode="File" />
share|improve this answer
    
This is the exact answer as the accepted answer. –  Luminous Apr 28 at 18:49
    
status code is different. –  Teoman shipahi Apr 28 at 19:37

So I was having a hard time with the exact same problem of Basic Auth not prompting the browser. Neither forcing a custom error of 401.0 (i.e. explicitly setting subcode to 0) or setting the registry key creation resolved it for me.

Turned out it was our use of custom error pages to begin with. Turning them off, everything worked fine, back on... specifically the 401 (0) and 401.2 errors prevented the prompt.

Setting the custom error type to 'File' from 'ExecuteURL' did resolve it, but if the user canceled the prompt or entered a bad password, they got a generic "You do not have permission to view this directory or page".

After a lot of getting hints from various posts, but never an exact 'how-to' or 'why'... I was using a relative path for the custom error file which was in a subdirectory of the site. Changing the path to an absolute one caused the above generic error to be replaced with "cannot display this page" if canceled or bad password. A little more digging and I found a post talking about a config attribute "allowAbsolutePathsWhenDelegated" which is set to false by default. It also states that if you just put the customer error file in your site root and then in the custom error location just the file name (i.e. relative path to the root of the site) it would work... sure enough it does, however, I didn't want to put custom errors in the root of my site. So I used the ConfigurationEditor to set the above attribute to true, set the absolute path to the custom error files and everything started to work fine. Prompt remained, custom error displays when triggered.

What I would like is, to be able to use the File attribute with a nested relative path, but so far I've not found out why I can't or how to do this. The other question is, if by using an absolute path, if I'm potentially creating a security hole (i.e. why would this be disabled by default?)

Anyway, hope this helps someone.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.