Kerberos の概要とチケット取得の様子を目で確認した結果
この資料では Kerberos 認証を使って、あるクライアントの IE から IIS にアクセスする場合に、 その裏でどのようなモジュールが何をしているのか、各種ツールを使って確認します。
状況設定
ここでは、alice というユーザーアカウントが、Windows ドメイン環境にログインして、 ドメイン内の IIS にアクセスするシナリオを考えます。下図の左下のユーザが Alice と思ってください。 Alice は Windows ドメインにログインしてから、クライアントマシン上の IE から、右下に描かれている IIS へとアクセスします。
この時に発生する Kerberos の動作に着目すると、次のようになります。
- クライアントからドメインコントローラ (AS, Authentication Service) への TGT (Ticket Granting Ticket) の要求
- TGT とセッションキーの応答
- Web サーバの ST (Service Ticket) の要求
- ST の応答
- ST を用いて IIS へアクセス
- アクセス許可
この動きを図にすると下図のようになります。
この流れが、それぞれのサーバーで実際にどのようになっているか、イベントログなどのメッセージを追ってみましょう。
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 が取得されます。
