IIS 7.5: So konfigurieren Sie die Seite "Benutzerdefinierter Authentifizierungsfehler" mit der Windows-Authentifizierung. 401 Header Probleme

Ich habe eine PHP-Website unter IIS 7.5. Die Site ist durch Windows-Authentifizierung geschützt und das funktioniert einwandfrei:

Wenn Benutzer die Site besuchen, werden sie nach Benutzername / Kennwort gefragt und erhalten eine Bestätigung, wenn sie authentifiziert sind. Wenn Benutzer dreimal auf Abbrechen klicken oder das Kennwort falsch eingeben, wird die Fehlerseite 401 angezeigt:

Jetzt möchte ich eine benutzerdefinierte Seite anzeigen, die erklärt, wie man sich anmeldet. Also gehe ich zu Fehlerseiten, wähle den Statuscode 401.2 und zeige ihn auf die Seite, die ich anzeigen möchte:

Stellen Sie dann sicher, dass die benutzerdefinierten Fehler für alle aktiviert sind. Und Kaa-Boom! Die Authentifizierung funktioniert nicht mehr, Benutzer erhalten keine Passwortabfrage mehr. Wie aus der Dokumentation hervorgeht, sendet die Windows-Authentifizierung zunächst eine 401-Antwort. Anschließend fordert der Browser den Benutzer auf, die Anmeldeinformationen des Anbieters einzugeben, und ermittelt anschließend, was als Nächstes zu tun ist.

Was hier passiert: Bei der ersten Anforderung für die Seite versucht IIS, 401-Header zu senden, stellt jedoch fest, dass in der Datei web.config "on 401 redirect to this page" (Auf diese Seite umleiten) angegeben ist. Und anstelle der Authentifizierung wird nur die Umleitungsseite angezeigt.

Ich habe versucht, 401, 401.1, 401.2 zu ersetzen - machte keinen Unterschied.

Was mache ich falsch und wie gebe ich benutzerdefinierte Seite auf Benutzerauthentifizierungsfehler?

ps Hier ist die 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>

Versuche dies:

Veränderung:

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

zu

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

Im Antwortmodus 'Datei' lädt IIS nur den Inhalt dieser Datei und zeigt ihn an. Der 401-Status wird dennoch an den Client zurückgesendet.

Früher habe ich 'ExecuteURL' verwendet, aber ich habe gelernt, dass der Dateimodus viel besser funktioniert. Sie müssen nur sicherstellen, dass alle verknüpften Ressourcen auf Ihren Fehlerseiten weiterhin funktionieren.

Ich bin auf dasselbe Problem gestoßen, bei dem Benutzer nach dem Hinzufügen benutzerdefinierter httperrors nicht zur Eingabe von Anmeldeinformationen aufgefordert wurden, und konnte es mit einem subStatusCode von 0 beheben. Ich hoffe, dies hilft jemandem.

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

Ich hatte es also nicht leicht mit dem exakt gleichen Problem, dass Basic Auth den Browser nicht auffordert. Weder das Erzwingen eines benutzerdefinierten Fehlers von 401.0 (dh das explizite Festlegen des Subcodes auf 0) noch das Festlegen der Registrierungsschlüsselerstellung lösten diesen Fehler für mich.

Es stellte sich heraus, dass wir zunächst benutzerdefinierte Fehlerseiten verwendet haben. Beim Ausschalten funktionierte alles einwandfrei. Insbesondere die Fehler 401 (0) und 401.2 verhinderten die Eingabeaufforderung.

Das Festlegen des benutzerdefinierten Fehlertyps auf "Datei" in "ExecuteURL" hat das Problem behoben. Wenn der Benutzer die Eingabeaufforderung abbricht oder ein falsches Kennwort eingibt, wird die allgemeine Meldung "Sie haben keine Berechtigung zum Anzeigen dieses Verzeichnisses oder dieser Seite" angezeigt.

Nach vielen Hinweisen aus verschiedenen Posts, aber nie einem genauen "How-to" oder "Warum" ... habe ich einen relativen Pfad für die benutzerdefinierte Fehlerdatei verwendet, die sich in einem Unterverzeichnis der Site befand. Das Ändern des Pfads in einen absoluten Pfad führte dazu, dass der oben genannte allgemeine Fehler durch "Diese Seite kann nicht angezeigt werden" ersetzt wurde, wenn das abgebrochen wurde oder das Kennwort falsch war. Ein bisschen mehr graben und ich fand einen BeitragEs handelt sich um ein Konfigurationsattribut "allowAbsolutePathsWhenDelegated", das standardmäßig auf false festgelegt ist. Es heißt auch, dass es funktionieren würde, wenn Sie die Kundenfehlerdatei nur im Stammverzeichnis Ihrer Site ablegen und dann im benutzerdefinierten Fehlerverzeichnis nur den Dateinamen (dh den relativen Pfad zum Stammverzeichnis der Site) Ich wollte keine benutzerdefinierten Fehler im Stammverzeichnis meiner Website platzieren. Also habe ich mit dem ConfigurationEditor das obige Attribut auf true gesetzt, den absoluten Pfad zu den benutzerdefinierten Fehlerdateien festgelegt und alles hat gut funktioniert. Eingabeaufforderung bleibt bestehen, benutzerdefinierter Fehler wird beim Auslösen angezeigt.

Was ich möchte, ist, dass ich das File-Attribut mit einem verschachtelten relativen Pfad verwenden kann, aber bisher habe ich nicht herausgefunden, warum ich das nicht kann oder wie ich das tun soll. Die andere Frage ist, ob ich unter Verwendung eines absoluten Pfads möglicherweise eine Sicherheitslücke erzeuge (dh warum sollte dies standardmäßig deaktiviert sein?).

Wie auch immer, hoffe das hilft jemandem.

Aus irgendeinem Grund funktionierte in meinem Fall die Kombination von bis zu 2 Lösungen für asp.net MVC 5.

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