IIS 7.5：Windows認証でカスタム認証エラーページを構成する方法。401ヘッダーの問題

IIS 7.5で実行されているphp Webサイトがあります。サイトはWindows認証によって保護されており、正常に機能します。

ユーザーがサイトにアクセスすると、ユーザー名/パスワードの入力を求められ、認証された場合は通過します。ユーザーが[キャンセル]をクリックするか、パスワードを3回誤入力すると、401エラーページが表示されます。

次に、ログイン方法を説明するカスタムページを表示したいと思います。だから私はエラーページに行き、ステータスコード401.2を選択して、表示したいページを指し示します：

次に、すべてのユーザーに対してカスタムエラーがオンになっていることを確認します。そしてカーブーム！認証は機能しなくなり、ユーザーにはパスワードプロンプトが表示されません。文書によると、Windows認証は最初に401応答を送信することで機能し、次にブラウザーはユーザーにプロバイダーの資格情報を要求し、次に何をするかを決定します。

ここで何が起こるか：IISがページの最初のリクエストで401ヘッダーを送信しようとしますが、web.configが「401でこのページにリダイレクトする」と言うことに気付きます。そして、認証の代わりに、リダイレクトページを提供するだけです。

401、401.1、401.2を交換しようとしましたが、違いはありませんでした。

私は何を間違えていますか？ユーザー認証エラーでカスタムページを表示する方法は？

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

これを試して：

変化する：

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

に

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

応答モード「ファイル」を使用すると、IISはそのファイルのコンテンツをロードして表示するだけで、401ステータスをクライアントに送り返します。

以前は「ExecuteURL」を使用していましたが、ファイルモードの方がはるかに優れていることがわかりました。エラーページ内のリンクされたリソースが引き続き機能することを確認する必要があります。

カスタムhttperrorsを追加した後、ユーザーに資格情報のプロンプトが表示されないという同じ問題に遭遇しました。subStatusCodeを0にすると修正できました。これが誰かの助けになることを願っています。

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

そのため、Basic Authがブラウザにプロンプ​​トを表示しないというまったく同じ問題に苦労していました。401.0のカスタムエラーを強制する（つまり、明示的にサブコードを0に設定する）ことも、レジストリキーの作成を設定することも解決しませんでした。

そもそも、カスタムエラーページの使用でした。それらをオフにすると、すべてが正常に機能し、元に戻りました...特に401（0）および401.2エラーがプロンプトを防ぎました。

カスタムエラータイプを「ExecuteURL」から「File」に設定すると解決しましたが、ユーザーがプロンプトをキャンセルするか、間違ったパスワードを入力すると、「このディレクトリまたはページを表示する権限がありません」という一般的なメッセージが表示されます。

さまざまな投稿から多くのヒントを得ましたが、正確な「ハウツー」または「理由」はありませんでした...サイトのサブディレクトリにあるカスタムエラーファイルの相対パスを使用していました。パスを絶対パスに変更すると、上記の一般的なエラーは、キャンセルされた場合やパスワードが間違っている場合、「このページを表示できません」に置き換えられます。もう少し掘り下げて、投稿を見つけましたデフォルトでfalseに設定されている構成属性「allowAbsolutePathsWhenDelegated」について説明します。また、顧客のエラーファイルをサイトのルートに配置し、カスタムエラーの場所にファイル名（つまり、サイトのルートへの相対パス）を配置するだけで機能することも示しています... 、サイトのルートにカスタムエラーを配置したくありませんでした。そこで、ConfigurationEditorを使用して上記の属性をtrueに設定し、カスタムエラーファイルへの絶対パスを設定すると、すべてが正常に動作し始めました。プロンプトが残り、トリガーされるとカスタムエラーが表示されます。

私が望むのは、ネストされた相対パスでFile属性を使用できるようにすることですが、今のところ、なぜできないのか、どうすればよいのかわかりません。もう1つの質問は、絶対パスを使用する場合、セキュリティホールを作成する可能性があるかどうか（つまり、これがデフォルトで無効になっているのはなぜか）です。

とにかく、これが誰かを助けることを願っています。

私の場合、奇妙な理由で、asp.net MVC 5で最大2つのソリューションの組み合わせが機能しました。

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