none
アプリケーションプールの識別IDをドメインアカウントにする RRS feed

  • 質問

  • お世話になります。

    IIS6にてアプリケーションプールの識別IDをドメインカウントにして
    そのプールに所属するWEBアプリケーションの動作についての質問です。
    ※WEBアプリケーションからSQLサーバーのアクセスは統合認証(SSPI)で接続しております。

    [クライアントPC]→[(統合認証)WEBアプリケーション]→[(統合認証)SQLサーバー]
    でアクセスを行うと、WEBアプリケーションからSQLサーバーへの接続に失敗します。

    このフォーラムに「IIS6 ワーカプロセスアカウントをドメインアカウントにすると・・・」の内容では、
    「ダブルホップしているので、認証に失敗している」と記述されています。

    確かに、WEBアプリケーションが動作しているPC上のIEからアクセスすると問題なく動作します。

    しかし、SQLサーバーへのアクセスは、ドメインアカウントでアクセスをおこなっているのだから
    ダブルホップしている思われません。

    Keroberos認証を使用するために、ActiveDirectoryにSPNを設定してみると
    [クライアントPC]→[(統合認証)WEBアプリケーション]→[(統合認証)SQLサーバー]
    の環境でも問題なく動作しました。

    本当にダブルホップで失敗しているのなら、どの認証で失敗しているのかが知りたいのですが
    おしえてください。

    またKeroberos認証とネットワークログオン認証の違いはなんなんでしょうか。
    ネットワークログオンの場合は、対象となるサービスがActiveDirectoryに資格の確認をするとか
    Keroberos認証の場合は、アクセス対象となるサービスのチケットをActiveDirectoryから取得して、
    サービスへチケットを提示することで、認証ができるなどはわかるのですが、
    それがSQLサーバへのアクセスにどのような影響があるのかが、理解できません。









    2009年2月24日 11:54

回答

  •  こんにちは。

    # すみません、なんか前回の私の回答がいまひとつ不明瞭だったようで・・・
    # こんかいスッキリしていただけると良いのですが。

    前回のスレッドに書いていることと、りばてぃさんの書いていることと内容がかぶってしまうかもしれませんが、あらかじめご了承ください。

    さて、ダブルホップですが、OTAKA さんの状況はこちらですよね?

    [クライアントPC]→[(統合認証)WEBアプリケーション]→[(統合認証)SQLサーバー]

    この状況ですと、SQL サーバへ接続するためには、ダブルホップしないといけないです。

    なぜかといいますと統合認証でアクセスする場合、ドメインアカウントを使っていても、認証されるのはあくまで [クライアントPC]→[(統合認証)WEBアプリケーション] のアクセス時点だからです。

    つまり、クライアント PC から Web アプリにログインしたトークンで、さらにその先のネットワーク越しの SQL Server へ接続できるのかどうか? という点がポイントになります。

    ここで NTLM で認証したトークンだと、前回の説明の通り、ネットワークログオンというタイプのログインになります。ネットワークログオンというログオンタイプでは、ネットワーク越しのリソースへのアクセスが出来ません。(これは IIS というより Windows のセキュリティの仕組みです) 

    ですから、結局この状況だと、「ダブルホップできない」 ということになります。

    一方、Kerberos の場合の認証はりばてぃさんもご指摘のように、Kerberos は委任という仕組みをサポートしていて、委任されたユーザーはその先の(ネットワーク越しの)リソースにもアクセスできるのです。

    ですから、結局 Keberos の時はダブルホップできる、ということになります。

    いかがでしたでしょうか?

    ご参考になりましたら幸いです。

    ------------------------------
    だどさん http://keicode.com/


    • 回答としてマーク OTAKA 2009年2月25日 9:28
    2009年2月25日 0:32

すべての返信

  • こんにちは、りばてぃです。

    とりあえず前提の確認ですが、ASP.NETで偽装を有効にしてるということですよね?

    若干うる覚えですが、偽装を利用して、クライアントPC上にログインしたWindowsユーザで
    SQLサーバーに対して認証を行うことになると、ADを利用していてもダブルホップは発生します。

    #一部イメージをわかりやすくするために若干語弊があります・・・
    クライアントPCからWEBアプリケーションに接続した際には、
    クライアントPC上にあるユーザー名/パスワードを利用して認証情報をWEBアプリに引き渡します。
    ただし、認証情報のみでパスワード情報は引き渡しません。
    次に、WEBアプリからDBサーバに接続する時も同様にしたいのですが、パスワード情報がないので
    SQLサーバーに認証情報を引き渡すことができずに、認証に失敗します。

    イメージ的にはこんな感じで、ただADでサービスの委任をできるようにしたり、Kerberosを利用するようにしたりすると
    この辺の問題が解決します。

    この辺の詳しい解説は「.NETエンタープライズ Webアプリケーション開発技術大全 Vol.4 セキュアアプリケーション設計編」
    の第一部第一章1.4 リソースアクセスストラテジに書いてあったような気がします。
    2009年2月24日 15:34
  • ご返事ありがとうございます。

    りばてぃさんの内容、つまりダブルホップがなぜ起こるのかはわかるのですが、

    つまり、ClassicASPの場合、統合認証でWEBサービスにアクセスすると、
    ワーカスレッドはそのユーザーで偽装されて、SQLサーバーへアクセスを行いますが、
    そのときにパスワード情報がないため、認情報証を引き渡すことができないことで、
    ダブルホップ問題が発生すること理解しております。

    但し、ASPNETの場合、アプリケーションプールの識別IDで設定されたアカウントで
    プロセス(w3wp.exe)が実行され、SQLサーバーへのアクセスは、
    識別IDで設定されたアカウントアクセスします。
    SQLサーバーのログイン情報は、アプリケーションプールの識別IDで設定されたドメインアカウントを設定しているだけです。

    ここで、なぜクライアントの資格情報をSQLサーバーに渡す必要があるのかが理解できません。
    ただ、WEBサーバ上からのIEを使用して、WEBアプリケーションにアクセスすると
    実行されるので、ダブルホップされているのだろうなと思うのですが・・・・・




    2009年2月25日 0:20
  •  こんにちは。

    # すみません、なんか前回の私の回答がいまひとつ不明瞭だったようで・・・
    # こんかいスッキリしていただけると良いのですが。

    前回のスレッドに書いていることと、りばてぃさんの書いていることと内容がかぶってしまうかもしれませんが、あらかじめご了承ください。

    さて、ダブルホップですが、OTAKA さんの状況はこちらですよね?

    [クライアントPC]→[(統合認証)WEBアプリケーション]→[(統合認証)SQLサーバー]

    この状況ですと、SQL サーバへ接続するためには、ダブルホップしないといけないです。

    なぜかといいますと統合認証でアクセスする場合、ドメインアカウントを使っていても、認証されるのはあくまで [クライアントPC]→[(統合認証)WEBアプリケーション] のアクセス時点だからです。

    つまり、クライアント PC から Web アプリにログインしたトークンで、さらにその先のネットワーク越しの SQL Server へ接続できるのかどうか? という点がポイントになります。

    ここで NTLM で認証したトークンだと、前回の説明の通り、ネットワークログオンというタイプのログインになります。ネットワークログオンというログオンタイプでは、ネットワーク越しのリソースへのアクセスが出来ません。(これは IIS というより Windows のセキュリティの仕組みです) 

    ですから、結局この状況だと、「ダブルホップできない」 ということになります。

    一方、Kerberos の場合の認証はりばてぃさんもご指摘のように、Kerberos は委任という仕組みをサポートしていて、委任されたユーザーはその先の(ネットワーク越しの)リソースにもアクセスできるのです。

    ですから、結局 Keberos の時はダブルホップできる、ということになります。

    いかがでしたでしょうか?

    ご参考になりましたら幸いです。

    ------------------------------
    だどさん http://keicode.com/


    • 回答としてマーク OTAKA 2009年2月25日 9:28
    2009年2月25日 0:32
  • ご返事ありがとうございます。
    旋回のスレッドと今回のスレッドを合わせて考えてみると理解しかかっていますので、
    もう少しお付き合いください。


    だどさん の発言:

    つまり、クライアント PC から Web アプリにログインしたトークンで、さらにその先のネットワーク越しの SQL Server へ接続できるのかどうか? という点がポイントになります。


    だれがSQLサーバーにアクセスするという以前の問題で、WEBサーバー自体が、現在の実行中のトークン情報が、
    ネットワーク越しのリソースにアクセスが可能かを判断して、問題がなければ処理を実行、問題があれば処理を中断させるイメージでしょうか。

    つまりWEBサーバーでは、ダブルホップできるかどうかとう判断を行っており、SQLサーバーへのアクセスは、
    実際はダブルホップしていないと解釈したのですが、まちがっておりますでしょうか。
    2009年2月25日 4:22
  •  自己レスです。

    私が上記でのべた内容は、まちがっていますよね。

    アプリケーションプールの識別IDを、WEBのローカルアカウントにしたとき、リモート側にも同名のアカウント、パスワードを
    設定すれば(当然SQLサーバのログイン情報に設定したうえ)アクセスが可能になりますよね。

    このときは、WEBアプリにログインしたトークンは意識されないこととっているので、
    わたしまちっがた理解をしていますね。

    むづい・・・
    2009年2月25日 6:07
  • こんにちは。

    # 話が複雑になりすぎますので、一旦、ワーカープロセスの ID についてはおいておきましょう。

    基本的に、最初のご返信の通りの認識でよいと思います。

    だれがSQLサーバーにアクセスするという以前の問題で、WEBサーバー自体が、現在の実行中のトークン情報が、ネットワーク越しのリソースにアクセスが可能かを判断して、問題がなければ処理を実行、問題があれば処理を中断させるイメージでしょうか。

    はい、そういうイメージになります。

    蛇足になるかもしれませんが、補足すると、IIS にトークンの種別を識別するロジックが組み込まれているのか、というと、そうではなく、Windows のセキュリティシステム自体がそのように出来ているので、自然とそういう動きになるのです。

    (繰り返すようですが、ネットワークログインタイプのログインのトークンで走っているスレッドからは、リモートのリソースにアクセスできないのです)

    ご参考になりましたら幸いです。

    ----------------------------------
    だどさん http://keicode.com/

    2009年2月25日 7:24
  • たどさん、ご返事ありがとうございます。

    とても参考となりました。

    アクセストークンとワーカプロセスIDの関係については、別モノとして勉強します。
    「回答としてマーク」させて頂いた内容がすべてなんでしょうが、理解能力が低く申し訳ないです。
    懇切丁寧ありがとうございました。

    ※今ちょっと 頭が「うに」状態ですが・・・

    2009年2月25日 9:28