☰

Azure Application Gateway 使用時の HTTP 401.2 エラー

tag-icon • tag-icon ntlm iis-10 azure-application-gateway tls-offloading
Azure Application Gateway 使用時の HTTP 401.2 エラー

Azure の Windows Server 2019 DataCenter 上の IIS 10 でホストされている ASP.Net サイトがあります。このサイトでは Windows 認証のみが有効になっています。

サイトに直接アクセスすると（http://mysite-backend.example.com) 資格情報の入力を求められましたが、その後はすべて期待通りに動作します。App Gateway (プライベートIPで構成) 経由でサイトにアクセスすると (https://mysite.example.com) 資格情報の入力を求められ、その後、再度、追加のリソース (同じサイトでホストされ、サブフォルダーに特別なルールはありません) のリクエストの入力を求められます。[キャンセル] をクリックするまで繰り返しプロンプトが表示され、その時点で Chrome のネットワーク ログにリソースのリクエストの 401 が表示されます。

この問題が発生するリソースの1つは、 のGETリクエストですfavicon.png。リソースに直接アクセスすると（https://mysite.example.com/favicon.png) はすべて動作しますが、サイトのページにアクセスして、このリソースのリクエストがページのリソースの一部としてブラウザから送信されると、エラーが表示されます。これは、リソースにアクセスできることを意味しますが、「トランザクション」内での処理方法に関する何かが問題を引き起こしています。

問題の原因となるキャッシュがないことを確認するために、新規インストールや別のクライアント デバイスを含むさまざまなブラウザーで試しました。さらに、Disable CacheF12 ネットワーク設定をチェックして、2 つのサイト間で完全なリクエストと公平な比較を実行していることを確認しました。

バックエンド プールには 1 つのノードしかありません。バックエンド設定では、フロントエンドのホスト名ではなくバックエンド プールのホスト名を使用するように指定されているため、Web サーバーの観点からは、リクエストは同じように見えます。

Web サーバーのセキュリティ イベント ログに、4625テスト ユーザー名を使用した失敗したログオン (イベント ID ) が表示されています。これは、リクエストが正しいユーザー名でバックエンド サーバーに送信されていることを確認したものです (常に正しいパスワードを入力するよう細心の注意を払っています。人為的エラーの可能性を排除するために何度も実行しています。保存したパスワードの使用と上書きの両方を試しました)。試行回数が多すぎると、テスト アカウントがロックアウトされます (つまり、AD で属性lockedoutが に設定されますtrue)。その後、すべてのリクエストに対して 401 応答が返されます (当然のことですが)。

App Gateway のログをチェックして、何もブロックされていないことを確認しました。また、このサイトにカスタム WAF ルールを設定し、detection onlyリクエストをブロックできないようにモードに設定しました。何かがブロックされているがログに記録されていない場合に備えてです。

バックエンド サーバーでステータス 401 の失敗した要求のトレースを有効にしました。これにより、401 が次の場所から送信されたことが示されます。

-MODULE_SET_RESPONSE_ERROR_STATUS 

ModuleName: IIS Web Core 
Notification: AUTHENTICATE_REQUEST 
HttpStatus: 401 
HttpReason: Unauthorized 
HttpSubStatus: 2 
ErrorCode: Access is denied. (0x80070005) 
ConfigExceptionInfo

注: ブロックされるリソース (つまり、401 応答) は、特定の期間内に同じデバイスでテストする場合、通常は一定です。ただし、別の日または別のデバイスでテストすると、ブロックされるリソースが異なる場合があります。デバイスで最初にテストすると (ほとんどの場合)、ページPOSTへの 2 つの xhr 要求が/subfolder###/Search失敗し、その後、そのデバイスで数回テストすると、他のリソースが汚染されるように見えます。これが主な原因のように思えますが、その後、何かがセッションで問題を引き起こします。

バックエンド サイトのソースコードにアクセスして、検索エンドポイントに何がコード化されているかをより深く理解し、それが問題の原因であるかどうかを把握しようとしています。

その間、ここにいる皆さんのアイデアがあれば、ぜひ教えてください。よろしくお願いします。

更新: 検索エンドポイントを直接呼び出すと、HTTP 200 / 有効な応答も返されます。

$resp = Invoke-RestMethod -Method Post -Uri 'https://mySite.example.com/subfolder###/Search' -Form @{recordsToTake=25;recordsToSkip=0;sortColumn='CategorieName';sortDirection='Ascending'} -Credential $cred -StatusCodeVariable sc;"Status $sc";$resp

答え1

NTLM（「Windows認証」）はApp Gatewayではサポートされていません（MSドキュメント）。

一般的にリバースプロキシはセキュリティ上の懸念からNTLMサポートを実装していないようです（MS YARP NTML ディスカッション）。

これを処理できる代​​替リバースプロキシがいくつかあります。例:nginxプラス(商用の nginx 製品)。

関連情報