他のリクエストでは Kerberos が機能するのに、1 つのプロキシリクエストだけパスワードを要求する理由

複数のリクエストが社内プロキシ経由で Kerberos を正常に利用しています。ところが 1 つのリクエストだけがパスワード入力を求めます。keytab を交換する前に、その特定のリクエストがどの認証ポリシーを選んだかを確認してください。

ゲートウェイはポリシーによってレルムと対応スキームを選択できます。同じブラウザから同じプロキシに到達する 2 つのトランザクションが、同じ認証要件を受け取る必要はありません。

次の仮想的なトレースを考えます。

最初の成功した交換は、選択された 1 つの経路が機能することを示します。2 番目のトランザクションがその経路に到達したことは示しません。資格情報が有効でも、その認証方式を選ぶルールが誤っていることがあります。

選択されたルールとその順序を調べる

チャレンジされたリクエストの宛先と時刻を、ゲートウェイのポリシートレースと突き合わせます。最初に適用されるルールが生成するレルム、スキームの選択、認証モードを特定します。それらの値を、同じクライアントからの成功したリクエストと比較します。

IP に関連付けられた ID に基づくポリシーも、接続上での認証を要求するポリシーとは異なる動作をします。新しいハンドシェイクがないことが同じレルムの選択を意味すると決めつけないでください。

リソースが意図しない例外に落ちた場合は、そのルールまたはスコープを修正し、結果のトレースを確認します。許可される認証方式をどこでも広げると不一致を隠せますが、無関係なトラフィックのアクセス動作を変えてしまいます。

意図したレルムが選択され、期待した交換が失敗する場合は、アカウントと Kerberos の証拠へ進みます。その時点で、チケット、サービス名、またはバックエンドの診断が重要になります。