none
イントラ環境でのASP.NET(IIS)によるファイルアクセスについて RRS feed

  • 質問

  • 前スレッドからの、引継ぎとなります。


    ●プログラム内で「偽装」してファイルアクセスをする


    http://social.msdn.microsoft.com/Forums/ja-JP/fcc52e5f-1031-400f-9611-376981bf748a?forum=aspnetja


    【環境】

    Webサーバー:Windows7 Pro(PC名 MYPC)

    IIS8.5、ASP.NET 4.0、Windows認証、ActiveDirectory


    【やりたいこと】

    Windows認証環境で、承認されたユーザID(例 MYDOMAIN\taro)で、別サーバにあるファイル(\\FileSrv\営業\報告.txt)にアクセスしたい。その際、Windowsで設定されているアクセス権を適用したい。


    【これまでの流れ】
    ①いったん「偽装」と「委任」で検証。

    ②その後、「Network Service」アカウントでの運用を勧められ、検証。

    ③以下の設定で、いったんファイルアクセスはできるようになった。

    ・アプリケーションID:Network Service

    ・ファイルのアクセス権:MYMAMAIN\MYPC$ フルコントロール。

    ④ただし、これだと、Webサーバー名が変わったりWebサーバーが増えるとアクセス権の加除が発生する

    →ActiveDirectoryの「グループ」に指定。成功。


    ---ここから懸案事項---

    【アクセスはできるようになったが、逆に必要なユーザに対して「拒否」がされなくなった】


    ファイルへのアクセスはできるようになったが、これまでご教示いただいたことを踏まえると、

    アクセス権の判定は、「特定のユーザ名」ではなく「特定のコンピュータ名」で行われている。

    →つまりWindows認証されたユーザIDとは無関係で、MYDOMAIN\MYPC$名義で権限の判定がされている。

    →よって「ユーザID」(あるいはその所属グループ)によるアクセス権の制御はできなくなる?

    具体的には、

    MYDOMAINにtaroとhanakoがいたとして、


    taro・・・「営業」グループ hanako・・・「倉庫」グループ

    対象ファイル「\\FileSrv\営業\報告.txt」のアクセス権は「営業」。

    「営業」のメンバーに「MYDOMAIN\MYPC$」を追加。

    ASp.NETのページ自体は、Windows認証でtaroもhanakoも通るようにする。

    一方、Buttonクリックで、報告.txtを読む場合、taroはOK、hanakoはNGにならないといけない。

    taroはもちろんのこと、「営業」のメンバーではないhanakoまで読み込みが成功してしまう。

    (∵MYDOMAIN\MYPC$名義で判定しているから?)

    【この問題の解決方法?】

    ①ソース内で、制御する。ソース内でtaroかhanakoかはわかるので、Button打刻時に判定して拒否する。

    ②やはり「委任」が必要?

    理想は、ここのファイルのアクセス権をいじったり、ソースに何か書いたりすることなく、アクセス許可/拒否をすることなのですが。。。

    理解悪く、申し訳ございません。

    2014年10月3日 5:29

回答

  • 以下は参考になりませんでしょうか? 昔、私が勉強した記事なので少し古いですが・・・

    IIS 5.0のユーザー認証が仮想ディレクトリではうまくいかない
    http://www.monyo.com/technical/windows/21.html


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    • 回答の候補に設定 星 睦美 2014年10月6日 7:03
    • 回答としてマーク 星 睦美 2014年10月21日 7:13
    2014年10月3日 6:34
    モデレータ
  • 結局、ユーザー別にファイルサーバーに設定されたアクセス権に従って、Web サーバー経由でのファイルサーバーへのユーザーのアクセス可否を細かくコントロールしたいということが要件のようですね。

    であれば、

    > ①ソース内で、制御する。ソース内でtaroかhanakoかはわかるので、Button打刻時に判定して拒否する。
     
    > ②やはり「委任」が必要?

    現実的な方法としては ② (即ち、偽装 + Kerberos 認証と制約つき委任)しかないと思います。

    ① はファイルサーバーに設定されたアクセス権を Web アプリのプログラムにコーディングする必要があるのでは? それは現実的とは思えません。


    前のスレッドで、

    > 強いアクセス権をもったアカウント(極論を言えばAdministrator@ad.mydomain.co.jp)に設定す
    > れば、リソースへのアクセスは問題ないのですが、運用として適切なのでしょうか?

    という話が質問者さんから持ち出されたので、そんなことをするぐらいなら Network Service を使ってはどうかと言ったのですが・・・ なんか、無駄に遠回りになってしまったようです。

    【追伸】

    前のスレッドで、ワーカープロセスのアカウントにドメインユーザーアカウントを使っていましたが、偽装を行う場合その必要はありません。

    • 編集済み SurferOnWww 2014年10月3日 7:21 一部訂正&追伸追加
    • 回答の候補に設定 星 睦美 2014年10月6日 7:03
    • 回答としてマーク 星 睦美 2014年10月21日 7:13
    2014年10月3日 7:14

すべての返信

  • 以下は参考になりませんでしょうか? 昔、私が勉強した記事なので少し古いですが・・・

    IIS 5.0のユーザー認証が仮想ディレクトリではうまくいかない
    http://www.monyo.com/technical/windows/21.html


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    • 回答の候補に設定 星 睦美 2014年10月6日 7:03
    • 回答としてマーク 星 睦美 2014年10月21日 7:13
    2014年10月3日 6:34
    モデレータ
  • 結局、ユーザー別にファイルサーバーに設定されたアクセス権に従って、Web サーバー経由でのファイルサーバーへのユーザーのアクセス可否を細かくコントロールしたいということが要件のようですね。

    であれば、

    > ①ソース内で、制御する。ソース内でtaroかhanakoかはわかるので、Button打刻時に判定して拒否する。
     
    > ②やはり「委任」が必要?

    現実的な方法としては ② (即ち、偽装 + Kerberos 認証と制約つき委任)しかないと思います。

    ① はファイルサーバーに設定されたアクセス権を Web アプリのプログラムにコーディングする必要があるのでは? それは現実的とは思えません。


    前のスレッドで、

    > 強いアクセス権をもったアカウント(極論を言えばAdministrator@ad.mydomain.co.jp)に設定す
    > れば、リソースへのアクセスは問題ないのですが、運用として適切なのでしょうか?

    という話が質問者さんから持ち出されたので、そんなことをするぐらいなら Network Service を使ってはどうかと言ったのですが・・・ なんか、無駄に遠回りになってしまったようです。

    【追伸】

    前のスレッドで、ワーカープロセスのアカウントにドメインユーザーアカウントを使っていましたが、偽装を行う場合その必要はありません。

    • 編集済み SurferOnWww 2014年10月3日 7:21 一部訂正&追伸追加
    • 回答の候補に設定 星 睦美 2014年10月6日 7:03
    • 回答としてマーク 星 睦美 2014年10月21日 7:13
    2014年10月3日 7:14
  • >SurferOnWwwさま

    「無駄に遠回り」だなんで、どんでもございません。申し訳ございません。

    こちらの理解悪く、ご迷惑おかけしました。

    Administratorの件を持ち出したときに、すでに、、アクセス許可だけを考えて、ユーザごとの「拒否」を考えるのを失念していました。

    教えていただいたことも1案として、実際にどうするか考えていきます。

    ありがとうございます。

    2014年10月3日 7:22
  • ありがとうございます!

    2014年10月3日 7:22