IIS 7.5: Como configurar a página de erro de autenticação personalizada com a autenticação do Windows. 401 problemas de cabeçalho

Eu tenho um site php rodando no IIS 7.5. O site é protegido pela autenticação do Windows e funciona bem:

Quando os usuários acessam o site, é solicitado o nome de usuário / senha e a senha é autenticada. Se os usuários clicarem em Cancelar ou digitar a senha incorretamente três vezes, eles serão mostrados na página de erro 401:

Agora eu gostaria de mostrar uma página personalizada explicando como fazer login. Então, vou para as páginas de erro, selecione o código de status 401.2 e aponte para a página que gostaria de exibir:

Em seguida, verifique se os erros personalizados estão ativados para todos. E kaa-boom! A autenticação não funciona mais, os usuários não recebem o prompt de senha. Como a documentação diz, a Autenticação do Windows funciona enviando 401 respostas primeiro, depois o navegador solicita ao usuário que credencie o provedor e, em seguida, eles decidem o que fazer em seguida.

O que acontece aqui: na primeira solicitação da página, o IIS tenta enviar o cabeçalho 401, mas percebe que o web.config diz "no 401 redirecionar para esta página". E, em vez de autenticação, apenas fornece a página de redirecionamento.

Eu tentei substituir 401, 401.1, 401.2 - não fez diferença.

O que estou fazendo de errado e como dar uma página personalizada ao erro de autenticação do usuário?

ps Aqui está o 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>

Tente o seguinte:

mudança:

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

para

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

Com o modo de resposta 'Arquivo', o IIS apenas carrega o conteúdo desse arquivo e o exibe, mas ainda envia o status 401 para o cliente.

Eu costumava usar 'ExecuteURL', mas aprendi que o modo Arquivo funciona muito melhor. Você só precisa garantir que os recursos vinculados em suas páginas de erro ainda funcionem.

Corri para o mesmo problema de usuários que não eram solicitados com credenciais após adicionar espelhos de ativação personalizados e foi capaz de corrigi-lo com um subStatusCode igual a 0. Espero que isso ajude alguém.

<error statusCode="401" subStatusCode="0" path="..." responseMode="ExecuteURL">

Então, eu estava tendo problemas com exatamente o mesmo problema de autenticação básica, não solicitando ao navegador. Não forçar um erro personalizado 401.0 (ou seja, definir explicitamente o subcódigo como 0) ou definir a criação da chave do Registro.

Acabou que foi o nosso uso de páginas de erro personalizadas para começar. Desligando-os, tudo funcionou bem, voltando ... especificamente os erros 401 (0) e 401.2 impediram o prompt.

A definição do tipo de erro personalizado como 'Arquivo' em 'ExecuteURL' resolveu o problema, mas se o usuário cancelasse o prompt ou inserisse uma senha incorreta, eles obteriam um genérico "Você não tem permissão para exibir este diretório ou página".

Depois de obter muitas dicas de várias postagens, mas nunca um 'como fazer' ou 'por que' exato ... eu estava usando um caminho relativo para o arquivo de erro personalizado que estava em um subdiretório do site. Alterar o caminho para absoluto fez com que o erro genérico acima fosse substituído por "não é possível exibir esta página" se a senha for cancelada ou incorreta. Um pouco mais de escavação e encontrei um postfalando sobre um atributo de configuração "allowAbsolutePathsWhenDelegated" que está definido como false por padrão. Ele também afirma que, se você colocar o arquivo de erro do cliente na raiz do site e, no local do erro personalizado, apenas o nome do arquivo (ou seja, o caminho relativo à raiz do site), ele funcionaria ... com certeza, porém , Não quis colocar erros personalizados na raiz do meu site. Então, usei o ConfigurationEditor para definir o atributo acima como true, definir o caminho absoluto para os arquivos de erro personalizados e tudo começou a funcionar bem. O prompt permaneceu, o erro personalizado é exibido quando acionado.

O que eu gostaria é de poder usar o atributo File com um caminho relativo aninhado, mas até agora não descobri por que não posso ou como fazer isso. A outra pergunta é, se usando um caminho absoluto, se estou criando potencialmente uma falha de segurança (ou seja, por que isso seria desativado por padrão?)

Enfim, espero que isso ajude alguém.

Por alguma razão estranha, no meu caso, a combinação de duas soluções funcionou para mim no asp.net MVC 5.

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