none
Kerberosを使用したWebサーバの認証フローについて RRS feed

  • 質問

  • ドメイン内に存在するWebサーバを認証する際のフローについて以下の理解で問題無いでしょうか。

    いまいちWebサーバホスト内のkrb5ccの生成されるタイミングとkeytabの使用タイミングが曖昧なの確認させいただければと思います。

    1. クライアントがAS (KDC) にチケットを要求

    2. ASからドメコンに登録してある対象ユーザのパスワードを使用し、エンコードしたTGTをクライアントへ送付

    3. クライアント側でユーザのパスワードを使用し、暗号化されたTGTをデコードしてTGTを取得

    4. クライアントがTGTを使用し、TGSへWebサーバ(HTTP/server.co.jp@MYDOMAIN.COM)に対するアクセスのリクエストをTGSに行う

    5. TGSからクライアントへWebサーバ(HTTP/server.co.jp@MYDOMAIN.COM)にアクセスする為のTGTが送付される

    6. クライアントからWebサーバへ「5.」で受け取ったチケットを送付

    7. 「6.」で受け取ったチケットをWebサーバ上のホストで管理してあるkeytab内の鍵でデコードし、クライアントから送付されたチケットが正当であることを確認

    8. クライアントから送付されたTGTをWebサーバ内のホストにキャッシュ(krb5cc)として管理

    9. クライアントからWebサーバへ認証成功




    • 編集済み Turing04 2017年9月21日 12:43
    2017年9月21日 6:52

回答

  • チャブーンです。

    Active DirectoryのTGSのやり取りについては、(もちろんTGTの話しも載っていますが)したのページに詳細があります。まずは参考にされることをお奨めします。

    https://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx

    おっしゃる処理はおおむねあっていますが、TGSを提供されたSPNサーバーはkeytab内の鍵情報ではなく、サーバー自身の「コンピューターアカウントのパスワード」でTGSを復号します(7)。発行されるTGSはクライアント(ユーザー)向けとサーバー向けがセットになっていて、クライアント側は(TGS要求時に生成された)TGS Session Keyで暗号し、サーバー側はコンピューターアカウントのパスワード(ドメインコントローラ側でもAD情報からわかります)で暗号する、という違いがある、という理解です。

    追記:見落としてましたが、SPNサーバーに送られるのはTGSで「TGT」ではないですね。誤記でしょうけれど。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。



    2017年9月22日 5:58
    モデレータ
  • ご回答いただきありがとうございます。

    何点か気になった点がございますので、追加質問させていただきます。

    TGSを提供されたSPNサーバーはkeytab内の鍵情報ではなく、サーバー自身の「コンピューターアカウントのパスワード」でTGSを復号します(7)。

    頂いたリンク先の情報を確認すると、以下の通り記載されております。

    How does the authenticator work?
    • The target server uses its secret key to decrypt the ticket, finds the session key inside the ticket, and uses it to decrypt the authenticator.
    • If the target server can successfully decrypt the authenticator and if the authenticator's data is accurate, then the target server will trust the source of the ticket.


    上記の内容からすると、Webサーバのホストに存在する秘密鍵でクライアントから送付されたサービスチケットを復号してセッションキーを取り出す。加えて、サービスチケットの送付元が正当なクライアントであることを確認すると読み取れます。

    だとすれば、ここで言う秘密鍵がWebサーバ用SPNのパスワードということになるのでしょうか。

    秘密鍵がWebサーバSPNの"パスワード"でないとすれば、具体的にkeytab内に格納されてある"鍵"はどういった処理の際に使用されるのでしょうか。

    発行されるTGSはクライアント(ユーザー)向けとサーバー向けがセットになっていて、クライアント側は(TGS要求時に生成された)TGS Session Keyで暗号し、サーバー側はコンピューターアカウントのパスワード(ドメインコントローラ側でもAD情報からわかります)で暗号する、という違いがある、という理解です

    "クライアント(ユーザ)向けとサーバ向けがセット"というのは、AS_TGS_REPに含まれる情報で、TGSが自身の保持するセッションキー(厳密にはTGSがASからもらったキー?)で暗号化したチケットがクライアント(ユーザ向け)、TGSがASの保持するWebサーバー側アカウントのパスワードを使用して暗号化したサービスチケットの2つという理解でよろしいでしょうか。

    また、当然クライアントとWebサーバ側でチケットによる認証が正常に行われれば、チケット有効期間中は当然クライアントはKDCとの通信を必要とせず双方の認証が行われる認識です。ですが、チケットがエクスパイアした後クライアントからWebサーバへ認証リクエストが行われた際は、一度Webサーバからクライアントへチケットが既に期限切れした旨の応答メッセージを受け取った上で、クライアントからKDCへ通常通りチケットの発行要求が行われるという流れでよろしいでしょうか。

    また、クライアントとWebサーバの認証が成功した後は、クライアントとWebサーバ側でセションキーを保持している為、チケット有効期限内はAuthenticator(クライアントの身分証明書)の認証やり取りは当セッションキーを用いて行うという理解でよろしいでしょうか。


    • 編集済み Turing04 2017年9月22日 18:35
    • 回答としてマーク Turing04 2017年9月25日 9:15
    • 回答としてマークされていない Turing04 2017年9月25日 9:15
    • 回答としてマーク Turing04 2017年9月25日 9:15
    2017年9月22日 15:44
  • やきです。

    Webサーバーと認証が成功した「あと」の話は、ちょっと手元の資料には見当たらないです。何かわかったら共有します。
    ということで共通認識の確認についての回答と、参考になりそうなサイトの紹介です。

    だとすれば、ここで言う秘密鍵がWebサーバ用SPNのパスワードということになるのでしょうか。

    はい。「当該SPNを持つWebサーバーのコンピューターアカウント(というかシステムアカウント)のパスワードハッシュ」です。


    > 発行されるTGSはクライアント(ユーザー)向けとサーバー向けがセットになっていて … 二つという理解でよろしいでしょうか

    はい。

    チケットの中身はこちらにも情報があります。2003時代のもので2016はいくつかの拡張がされているようですが。

    How the Kerberos Version 5 Authentication Protocol Works

    https://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx

    >ですが、チケットがエクスパイアした後クライアントからWebサーバへ認証リクエストが行われた際は~
    これは認可のプロセスで、Kerberosの範囲外ですね。チケットに情報はありますが、切れたときにどういう動きをするのか…。「更新」の処理に行くこともあるようです。

    以上、参考まで。

    • 編集済み やき(Yaki) 2017年9月25日 9:10 誤字修正
    • 回答としてマーク Turing04 2017年9月25日 9:15
    2017年9月25日 9:10

すべての返信

  • チャブーンです。

    Active DirectoryのTGSのやり取りについては、(もちろんTGTの話しも載っていますが)したのページに詳細があります。まずは参考にされることをお奨めします。

    https://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx

    おっしゃる処理はおおむねあっていますが、TGSを提供されたSPNサーバーはkeytab内の鍵情報ではなく、サーバー自身の「コンピューターアカウントのパスワード」でTGSを復号します(7)。発行されるTGSはクライアント(ユーザー)向けとサーバー向けがセットになっていて、クライアント側は(TGS要求時に生成された)TGS Session Keyで暗号し、サーバー側はコンピューターアカウントのパスワード(ドメインコントローラ側でもAD情報からわかります)で暗号する、という違いがある、という理解です。

    追記:見落としてましたが、SPNサーバーに送られるのはTGSで「TGT」ではないですね。誤記でしょうけれど。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。



    2017年9月22日 5:58
    モデレータ
  • ご回答いただきありがとうございます。

    何点か気になった点がございますので、追加質問させていただきます。

    TGSを提供されたSPNサーバーはkeytab内の鍵情報ではなく、サーバー自身の「コンピューターアカウントのパスワード」でTGSを復号します(7)。

    頂いたリンク先の情報を確認すると、以下の通り記載されております。

    How does the authenticator work?
    • The target server uses its secret key to decrypt the ticket, finds the session key inside the ticket, and uses it to decrypt the authenticator.
    • If the target server can successfully decrypt the authenticator and if the authenticator's data is accurate, then the target server will trust the source of the ticket.


    上記の内容からすると、Webサーバのホストに存在する秘密鍵でクライアントから送付されたサービスチケットを復号してセッションキーを取り出す。加えて、サービスチケットの送付元が正当なクライアントであることを確認すると読み取れます。

    だとすれば、ここで言う秘密鍵がWebサーバ用SPNのパスワードということになるのでしょうか。

    秘密鍵がWebサーバSPNの"パスワード"でないとすれば、具体的にkeytab内に格納されてある"鍵"はどういった処理の際に使用されるのでしょうか。

    発行されるTGSはクライアント(ユーザー)向けとサーバー向けがセットになっていて、クライアント側は(TGS要求時に生成された)TGS Session Keyで暗号し、サーバー側はコンピューターアカウントのパスワード(ドメインコントローラ側でもAD情報からわかります)で暗号する、という違いがある、という理解です

    "クライアント(ユーザ)向けとサーバ向けがセット"というのは、AS_TGS_REPに含まれる情報で、TGSが自身の保持するセッションキー(厳密にはTGSがASからもらったキー?)で暗号化したチケットがクライアント(ユーザ向け)、TGSがASの保持するWebサーバー側アカウントのパスワードを使用して暗号化したサービスチケットの2つという理解でよろしいでしょうか。

    また、当然クライアントとWebサーバ側でチケットによる認証が正常に行われれば、チケット有効期間中は当然クライアントはKDCとの通信を必要とせず双方の認証が行われる認識です。ですが、チケットがエクスパイアした後クライアントからWebサーバへ認証リクエストが行われた際は、一度Webサーバからクライアントへチケットが既に期限切れした旨の応答メッセージを受け取った上で、クライアントからKDCへ通常通りチケットの発行要求が行われるという流れでよろしいでしょうか。

    また、クライアントとWebサーバの認証が成功した後は、クライアントとWebサーバ側でセションキーを保持している為、チケット有効期限内はAuthenticator(クライアントの身分証明書)の認証やり取りは当セッションキーを用いて行うという理解でよろしいでしょうか。


    • 編集済み Turing04 2017年9月22日 18:35
    • 回答としてマーク Turing04 2017年9月25日 9:15
    • 回答としてマークされていない Turing04 2017年9月25日 9:15
    • 回答としてマーク Turing04 2017年9月25日 9:15
    2017年9月22日 15:44
  • やきです。

    Webサーバーと認証が成功した「あと」の話は、ちょっと手元の資料には見当たらないです。何かわかったら共有します。
    ということで共通認識の確認についての回答と、参考になりそうなサイトの紹介です。

    だとすれば、ここで言う秘密鍵がWebサーバ用SPNのパスワードということになるのでしょうか。

    はい。「当該SPNを持つWebサーバーのコンピューターアカウント(というかシステムアカウント)のパスワードハッシュ」です。


    > 発行されるTGSはクライアント(ユーザー)向けとサーバー向けがセットになっていて … 二つという理解でよろしいでしょうか

    はい。

    チケットの中身はこちらにも情報があります。2003時代のもので2016はいくつかの拡張がされているようですが。

    How the Kerberos Version 5 Authentication Protocol Works

    https://technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx

    >ですが、チケットがエクスパイアした後クライアントからWebサーバへ認証リクエストが行われた際は~
    これは認可のプロセスで、Kerberosの範囲外ですね。チケットに情報はありますが、切れたときにどういう動きをするのか…。「更新」の処理に行くこともあるようです。

    以上、参考まで。

    • 編集済み やき(Yaki) 2017年9月25日 9:10 誤字修正
    • 回答としてマーク Turing04 2017年9月25日 9:15
    2017年9月25日 9:10
  • やきです。

    URLがチャブーンさんのと全く同じですね…。失礼しました。

    探してみたのですが、IISやWindowsが具体的にどう動くか見当たりませんでした。
    とりあえず、更新の動きはエラーを受け取ったクライアントがKDCに更新依頼するのと、通信中に期限が切れても中断はないのは間違いなさそうですが。

    なので、実際にIISに対して動きをするかパケットキャプチャや klist コマンドで観察してみるのがはやそうです。

    ・ポリシーでKerberos有効期限を短縮させてみる
    → Kerberosのポリシー設定は「コンピューターの構成\Windows の設定\セキュリティの設定\アカウント ポリシー\Kerberos ポリシー」にあります。

    ・klist purge コマンドを実行することで、最長有効期限が切れたときの状態をシミュレートしてみる

    あとはこちらの投稿のツールも参考になりそうです。

    Kerberos認証の確認方法について
    https://social.technet.microsoft.com/Forums/ja-JP/9d1287c1-0620-4713-839d-911f2a5fa55a/kerberos?forum=iis7ja

    以上、参考まで。

    2017年9月26日 6:46
  • チャブーンです。

    返答が遅くなっていますが、ご容赦ください。

    keytabにこだわっておられるようですが、まずWindows Kerberosにはkeytabという概念はないという理解です。もちろんTGSチケット復号キーは存在しますが、それは「コンピュータアカウントのパスワード」として物理メモリ内に格納されています(サーバーは起動時に必ずコンピューター認証を行います)。MIT Kerberos(一般的なKerberos)を使いたい場合、専用のツールでkeytabを作成して、それを使います。

    https://technet.microsoft.com/en-us/library/cc753771(v=ws.11).aspx

    チケット有効期限後の動作ですが、この動作の詳細を知りたい本意はなんなのでしょうか?TGSが期限切れになる場合、ほとんどのケースでTGTの期限も切れているでしょうから、結局最初からやり直し(クライアントがTGTを再取得後、TGSを取得)になると思います。

    つまり、クライアントがWebサーバーにアクセスすると「使えるTGSがないから持ってきてください」という要求がクライアントにあり、クライアントがTGT再取得→TGS再取得というながれになるのだろう、と予測できるように思います。


    フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

    2017年9月27日 5:40
    モデレータ