Kerberos の概要とチケット取得の様子を目で確認した結果

この資料では Kerberos 認証を使って、あるクライアントの IE から IIS にアクセスする場合に、 その裏でどのようなモジュールが何をしているのか、各種ツールを使って確認します。

状況設定

ここでは、alice というユーザーアカウントが、Windows ドメイン環境にログインして、 ドメイン内の IIS にアクセスするシナリオを考えます。下図の左下のユーザが Alice と思ってください。 Alice は Windows ドメインにログインしてから、クライアントマシン上の IE から、右下に描かれている IIS へとアクセスします。

この時に発生する Kerberos の動作に着目すると、次のようになります。

  1. クライアントからドメインコントローラ (AS, Authentication Service) への TGT (Ticket Granting Ticket) の要求
  2. TGT とセッションキーの応答
  3. Web サーバの ST (Service Ticket) の要求
  4. ST の応答
  5. ST を用いて IIS へアクセス
  6. アクセス許可

この動きを図にすると下図のようになります。

この流れが、それぞれのサーバーで実際にどのようになっているか、イベントログなどのメッセージを追ってみましょう。

Alice がクライアント A にログオンするとき

まずは上記ステップ 1, 2 の TGT を要求するところです。これは Alice がクライアントにログインするときに 発生します。

ログインしたときに、AS 上のイベントログに TGT が発行されたイベントログが記録されます。 「認証チケットの許可」というメッセージです。

クライアントマシン上で Kerbtray を用いて取得したチケットを確認すると、initial TGT がキャッシュ されたことがわかります。

ちなみに、このときのやり取りをパケットで見ると、このような情報となります。メッセージタイプは AS-REQ です。

続いて、サーバーからのレスポンス AS-RES が確認できます。

TGT のやり取りが終わった後に、TGS では複数の ST を発行したイベントが記録されます。

こちらもパケットを見てみると、サーバーへのリクエストが見えます (= TGS-REQ)。

続いて、サーバーからのレスポンスです (= TGS-REP)。

さらに、TGS へのアクセスは AS と違って ST を複数もらうことになるので、 パケットを見てみると、確かに TGS-REQ/TGS-REP のペアがたくさん見えます。

Alice が Web サーバへアクセス

ここまでで TGT が取得できたことが確認できました。続いて Alice が IIS にアクセスします。

TGS に対して ST を要求します。イベントログから TGS でサービスチケットが発行されたことがわかる。

引き続き、alice がログオンに成功したことが記録されている。

クライアント側に、確かに HTTP をターゲットとした ST がキャッシュされている。

上記のやり取りについてネットワークのパケットを見てみると、確かに HTTP 401 ではじかれた後、Service Name = HTTP として TGS-REQ が TGS に送信されている様子が見えます。 この結果上記のように HTTP の ST が取得されます。

ここまでお読みいただき、誠にありがとうございます。SNS 等でこの記事をシェアしていただけますと、大変励みになります。どうぞよろしくお願いします。

© 2024 Web/DB プログラミング徹底解説