IIS 7.5: Come configurare la pagina di errore di autenticazione personalizzata con l'autenticazione di Windows. 401 problemi di intestazione

Ho un sito Web PHP in esecuzione su IIS 7.5. Il sito è protetto dall'autenticazione di Windows e funziona perfettamente:

Quando gli utenti accedono al sito, vengono richiesti nome utente / password e, se autenticati, riescono ad accedere. Se gli utenti fanno clic su Annulla o digitano erroneamente la password 3 volte, viene visualizzata la pagina di errore 401:

Ora vorrei mostrare una pagina personalizzata che spiega come accedere. Quindi vado alle pagine di errore, seleziono il codice di stato 401.2 e lo punto sulla pagina che vorrei visualizzare:

Quindi assicurati che gli errori personalizzati siano attivi per tutti. E kaa-boom! L'autenticazione non funziona più, agli utenti non viene presentata la richiesta della password. Come dice la documentazione, l'autenticazione di Windows funziona inviando prima la risposta 401, quindi il browser chiede all'utente le credenziali del provider e poi decide cosa fare dopo.

Cosa succede qui: alla prima richiesta per la pagina IIS tenta di inviare 401-header, ma nota che web.config dice "su 401 reindirizzare a questa pagina". E invece dell'autenticazione, fornisce solo la pagina di reindirizzamento.

Ho provato a sostituire 401, 401.1, 401.2, senza alcuna differenza.

Cosa sto facendo di sbagliato e come dare una pagina personalizzata sull'errore di autenticazione dell'utente?

ps Ecco il 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>

Prova questo:

modificare:

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

per

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

Con la modalità di risposta 'File' IIS carica semplicemente il contenuto di quel file e lo visualizza, rimanda ancora lo stato 401 al client.

Ho usato 'ExecuteURL' ma ho imparato che la modalità File funziona molto meglio. Devi solo assicurarti che tutte le risorse collegate nelle tue pagine di errore funzionino ancora.

Mi sono imbattuto in questo stesso problema di utenti che non hanno ricevuto le credenziali dopo aver aggiunto httperrors personalizzati e sono stato in grado di risolverlo con un subStatusCode di 0. Spero che questo aiuti qualcuno.

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

Quindi stavo attraversando un periodo difficile con lo stesso identico problema di Basic Auth che non richiedeva il browser. Né forzando un errore personalizzato di 401.0 (ovvero impostando esplicitamente il sottocodice su 0) o impostando la creazione della chiave di registro, è stato risolto per me.

Si è scoperto che era il nostro uso delle pagine di errore personalizzate per cominciare. Disattivandoli, tutto ha funzionato bene, riacceso ... in particolare gli errori 401 (0) e 401.2 hanno impedito il prompt.

L'impostazione del tipo di errore personalizzato su "File" da "ExecuteURL" lo ha risolto, ma se l'utente ha annullato il prompt o immesso una password errata, ha ottenuto un generico "Non si dispone dell'autorizzazione per visualizzare questa directory o pagina".

Dopo aver ricevuto molti suggerimenti da vari post, ma mai un 'how-to' o 'why' esatto ... Stavo usando un percorso relativo per il file di errore personalizzato che si trovava in una sottodirectory del sito. La modifica del percorso in assoluto ha causato la sostituzione dell'errore generico sopra riportato con "impossibile visualizzare questa pagina" se la password è annullata o errata. Un po 'più di scavo e ho trovato un postparlando di un attributo di configurazione "allowAbsolutePathsWhenDelegated" che è impostato su false per impostazione predefinita. Indica anche che se si inserisce semplicemente il file di errore del cliente nella radice del sito e quindi nella posizione dell'errore personalizzata solo il nome del file (ovvero il percorso relativo alla radice del sito) funzionerebbe ... abbastanza sicuro, tuttavia , Non volevo inserire errori personalizzati nella radice del mio sito. Quindi ho usato ConfigurationEditor per impostare l'attributo sopra su true, impostare il percorso assoluto per i file di errore personalizzati e tutto ha iniziato a funzionare correttamente. Il prompt è rimasto, viene visualizzato l'errore personalizzato quando attivato.

Quello che mi piacerebbe è poter usare l'attributo File con un percorso relativo annidato, ma finora non ho scoperto perché non riesco o come farlo. L'altra domanda è, se usando un percorso assoluto, se sto potenzialmente creando un buco di sicurezza (cioè perché questo dovrebbe essere disabilitato di default?)

Ad ogni modo, spero che questo aiuti qualcuno.

Per qualche strana ragione nel mio caso la combinazione di fino a 2 soluzioni ha funzionato per me per asp.net MVC 5.

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