IIS 7.5: Cómo configurar la página de error de autenticación personalizada con la autenticación de Windows. 401 problemas de encabezado

Tengo un sitio web php que se ejecuta en IIS 7.5. El sitio está protegido por la autenticación de Windows y eso funciona bien:

Cuando los usuarios acceden al sitio, se les pide nombre de usuario / contraseña y se comunican si se autentican. Si los usuarios hacen clic en Cancelar o escriben mal la contraseña 3 veces, se les muestra la página de error 401:

Ahora me gustaría mostrar una página personalizada que explica cómo iniciar sesión. Así que voy a las páginas de error, selecciono el código de estado 401.2 y lo señalo a la página que me gustaría mostrar:

Luego, asegúrese de que los errores personalizados estén activados para todos. Y kaa-boom! La autenticación ya no funciona, los usuarios no reciben la solicitud de contraseña. Como dice la documentación, la autenticación de Windows funciona enviando primero la respuesta 401, luego el navegador le pregunta al usuario las credenciales del proveedor y luego determina qué hacer a continuación.

Lo que sucede aquí: en la primera solicitud de la página, IIS intenta enviar el encabezado 401, pero se da cuenta de que web.config dice "en el redireccionamiento 401 a esta página". Y en lugar de autenticación, solo da la página de redireccionamiento.

He intentado reemplazar 401, 401.1, 401.2, no hizo ninguna diferencia.

¿Qué estoy haciendo mal y cómo dar una página personalizada en el error de autenticación de usuario?

ps Aquí está el 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>

Prueba esto:

cambio:

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

a

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

Con el modo de respuesta 'Archivo', IIS solo carga el contenido de ese archivo y lo muestra, aún envía el estado 401 de vuelta al cliente.

Solía ​​usar 'ExecuteURL' pero he aprendido que el modo de archivo funciona mucho mejor. Solo tiene que asegurarse de que los recursos vinculados en sus páginas de error sigan funcionando.

Me encontré con este mismo problema de usuarios que no reciben credenciales después de agregar httperrors personalizados y pude solucionarlo con un subStatusCode de 0. Espero que esto ayude a alguien.

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

Así que estaba teniendo dificultades con el mismo problema de que la autenticación básica no solicitaba el navegador. Ni forzar un error personalizado de 401.0 (es decir, establecer explícitamente el subcódigo a 0) ni configurar la creación de la clave de registro lo resolvió por mí.

Resultó que para empezar era nuestro uso de páginas de error personalizadas. Apagándolos, todo funcionó bien, volvió a encenderse ... específicamente los errores 401 (0) y 401.2 impidieron el aviso.

Establecer el tipo de error personalizado en 'Archivo' desde 'ExecuteURL' lo resolvió, pero si el usuario cancela la solicitud o ingresa una contraseña incorrecta, obtiene un genérico "No tiene permiso para ver este directorio o página".

Después de obtener muchas sugerencias de varias publicaciones, pero nunca un 'cómo' o 'por qué' exacto ... Estaba usando una ruta relativa para el archivo de error personalizado que estaba en un subdirectorio del sitio. Cambiar la ruta a una absoluta provocó que el error genérico anterior se reemplazara por "no se puede mostrar esta página" si se cancela o si la contraseña es incorrecta. Un poco más cavando y encontré una publicaciónhablando de un atributo de configuración "allowAbsolutePathsWhenDelegated" que se establece en falso de forma predeterminada. También indica que si solo coloca el archivo de error del cliente en la raíz del sitio y luego en la ubicación de error personalizada, solo el nombre del archivo (es decir, la ruta relativa a la raíz del sitio) funcionaría ... , No quería poner errores personalizados en la raíz de mi sitio. Así que utilicé el ConfigurationEditor para establecer el atributo anterior en verdadero, establecer la ruta absoluta a los archivos de error personalizados y todo comenzó a funcionar bien. Se mantuvo el aviso, se muestra un error personalizado cuando se activa.

Lo que me gustaría es poder usar el atributo File con una ruta relativa anidada, pero hasta ahora no he descubierto por qué no puedo hacerlo o cómo hacerlo. La otra pregunta es, si al usar una ruta absoluta, si potencialmente estoy creando un agujero de seguridad (es decir, ¿por qué estaría deshabilitado de forma predeterminada?)

De todos modos, espero que esto ayude a alguien.

Por alguna extraña razón en mi caso, la combinación de hasta 2 soluciones funcionó para mí para asp.net MVC 5.

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