2

クライアントが HTTP プロキシに対して自分自身を認証することを望んでいると仮定しましょう。プロキシは kerberos で構成されており、その構成でサービス名HTTP/proxy.foo.barが明確に設定されています。クライアントは、チケットを要求するサービス名をどのようにして知ることができますか? 彼が要求しているドメイン名へのチケットを要求しますか (この場合は実際にはproxy.foo.bar です)、または認証シーケンスで名前を受け取りますか (この場合は 407 応答で) (これには挑戦を交渉しますが、それを調べる方法があるかどうかはわかりません) ?

一部のクライアントの認証が突然停止したプロキシで kerberos エラーをデバッグしようとしています。問題は、Wireshark を見ると、クライアントがプロキシで構成されたサービス名 (使用するように指示された名前と同じ)、HTTP/proxy.foo.barではなく、その名前のチケットを要求していることがわかります。プロキシ IP はHTTP/host.foo.barに解決されます(まあ、少なくともプロキシが解決する名前であり、クライアントが別の方法で取得する可能性があります)、TGS はそれを見つけることができないため、エラーが発生します。 .

4

1 に答える 1

3

したがって、ここに 2 つの質問があります (問題を実際に解決する方法は尋ねていません。そのためには、より詳細な情報が必要です - コメントを参照してください)。

  1. 「プロキシは kerberos で構成されており、その構成で明らかにサービス名 HTTP/proxy.foo.bar が設定されています。クライアントは、チケットを要求するサービス名をどのようにして知ることができますか?」

A. このように機能します。クライアントは Web ブラウザに URL を入力するか、ハイパーリンクをクリックします。URL のホスト名と一致する DNS ドメインの IP ホストを検索します。次に、その IP ホストに移動し、URL で定義されたサービス (この場合は HTTP サービス) を探します。Kerberos で保護されているため、Web サーバーから HTTP 401 ネゴシエート チャレンジ (407 ではなく 401) を受信すると、KDC に移動し、HTTP/proxy.foo.bar の Kerberos サービス チケットを要求し、圧縮して戻ります。 proxy.foo.bar に送信し、そのホストで実行されている HTTP サービスのチケットをそのホストに提示します。ホストはこのチケットを検証し、問題がなければクライアントの Web ブラウザーが HTML をレンダリングします。クライアントで klist を実行すると、Kerberos チケット チケットが表示されます。Web リファレンスはありませんが、

  1. また、「<em>彼が要求しているドメイン名 (この場合は実際には proxy.foo.bar) へのチケットを要求しますか、それとも認証シーケンスで名前を受け取りますか?」と 407 応答で尋ねました。このケース (ネゴシエート チャレンジは含まれていませんが、調べる方法があるかどうかわかりません) ?」</li>

A. あなたの質問は少しわかりにくかったですが、私の理解が正しければ、答えは、Web サーバーからの HTTP 401 ネゴシエート認証チャレンジの結果として、Web クライアントがチケットを要求することです (上記を参照)。

このプロセスを順序付けた図がウェブ上に多数あります。たとえば、http: //www.zeroshell.org/kerberos/Kerberos-operation/

于 2016-11-17T01:33:39.957 に答える