none
Com+ コンポーネントの実行アカウントについて RRS feed

  • 質問

  •  

     

    Com+ コンポーネントを作成(環境:.NET2.0 VS2005で作成)して、サーバ(2003rs)でコンポーネントサービスに登録しました。

    この状態でデフォルトの実行アカウント(IDタグで確認)はシステムアカウント・対話ユーザになります。

     

    この場合、サーバを再起動して、管理者がログインしない場合の実行アカウントは何になりますでしょうか?

     

    やりたいこと

    サーバを再起動するだけで、管理者がログインしなくてもCom+コンポーネントサービスを使ってサーバマシンの

    ファイルにフルアクセスしたいです。

    「たぶん、IDタグでローカルシステムを指定すればできるかなと思いますが、ローカルシステムはなぜか

    グレー(選択不可)の状態です。」

     

    もちろん、「このーユーザ」で管理者ユーザを指定して実行できることも可能と思いますが、

    これは管理者ID・パスワードを指定するので、これをやりたくないというのもあります。

     

     

     

    2008年12月22日 10:45

回答

  •  Wolfgang&al さんからの引用

    もちろん、プロパティの「ID」タグの「このーユーザ」で管理者ユーザを指定して実行できることも可能と思いますが、

    これは管理者ID・パスワードを指定するので、これをやりたくない。

     

    管理者なんて必要ないでしょうに。

    扱う resource を格納する場所は決まっているので、専用の account 作って resource を格納する場所には適切な ACL を構成してやる。それで、その account で COM+ server application 起動するように構成するべきですね。

    2008年12月23日 12:56
  • Windows 統合認証を設定し、user が Web application へ server 管理者の account を使って logon してもらうようにします。

    COM+ は使わなくてもよいですけど、使うなら library application ですね。

    2008年12月24日 3:51
  •  Wolfgang&al さんからの引用

    1.フォーム認証をやめて、Windows 統合認証を使い。

    2.ASP.NETユーザ偽装を使うということでしょうか?

     

    違います。明示的な偽装は必要ありません。

     

    IIS の認証を利用した場合には、logon 時に生成される thread は logon された Windows account に偽装されて実行されます。

    2008年12月29日 6:07
  • こんにちは。

     

    # 途中のやり取りについていけなかった感がありますので、

    # 最初の質問にレスしたいとおもいます(汗)

     

    対話ユーザを選択している場合、誰もローカルログインしていなかったら COM+ コンポーネントは実行できないと思います。

     

    おっしゃるとおり、「このユーザ」 で管理者ユーザを指定されると良いと思います。

    (セキュリティの話はさておき、ですが)

     

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

     

    -----------------------------------------------

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

     

    2009年1月7日 2:41

すべての返信

  •  Wolfgang&al さんからの引用

    Com+ コンポーネントを作成(環境:.NET2.0 VS2005で作成)して、サーバ(2003rs)でコンポーネントサービスに登録しました。

    この状態でデフォルトの実行アカウント(IDタグで確認)はシステムアカウント・対話ユーザになります。

     

    この場合、サーバを再起動して、管理者がログインしない場合の実行アカウントは何になりますでしょうか?

     

    やりたいこと

    サーバを再起動するだけで、管理者がログインしなくてもCom+コンポーネントサービスを使ってサーバマシンの

    ファイルにフルアクセスしたいです。

    「たぶん、IDタグでローカルシステムを指定すればできるかなと思いますが、ローカルシステムはなぜか

    グレー(選択不可)の状態です。」

     

    もちろん、「このーユーザ」で管理者ユーザを指定して実行できることも可能と思いますが、

    これは管理者ID・パスワードを指定するので、これをやりたくないというのもあります。

     

    サービスとしてCOM+が動くわけですから、管理者としてログインしなくてもCOM+コンポーネントは使えると思いますけど。

     システムアカウントとして設定されている理由としては、(おそらくは)[管理ツール]-[サービス]でCOM+関連のサービスが[ローカルシステム]として設定されているためで、グレーアウトされていること自体は問題ないと思います。

     

    ※もしかして質問の意図を外していますでしょうか?

     

    2008年12月22日 15:29
  • CatTailさん

     

    こんにちは、投稿ありがとうございます。

     

    わかりにくい書き込みですみません。

    補足説明すると

    IIS(WEBサイト)→「Com+ コンポーネント」をコールしてサーバの任意の場所のファイルをダウンロードまたはアップロードを行う。

    (→設計はこれできまりなので、これはいま変更不可。)

    (→「Com+ コンポーネント」が担当するのが、サーバファイルの書き込み、読み取り。)

    (→現状は「Com+ コンポーネント」の呼び出すができるが、ファイルに対してアクセス権限ないと怒られる(たぶんIISのユーザで実行されちゃうので、))

     

    もちろん、プロパティの「ID」タグの「このーユーザ」で管理者ユーザを指定して実行できることも可能と思いますが、

    これは管理者ID・パスワードを指定するので、これをやりたくない。

     

     

    CatTailさん

    余談ですが、「サービス」と「コンポーネントサービス」はまだちょっと違うと思います。

     

     

     

     

    2008年12月23日 1:20
  •  Wolfgang&al さんからの引用

    もちろん、プロパティの「ID」タグの「このーユーザ」で管理者ユーザを指定して実行できることも可能と思いますが、

    これは管理者ID・パスワードを指定するので、これをやりたくない。

     

    管理者なんて必要ないでしょうに。

    扱う resource を格納する場所は決まっているので、専用の account 作って resource を格納する場所には適切な ACL を構成してやる。それで、その account で COM+ server application 起動するように構成するべきですね。

    2008年12月23日 12:56
  •  Wolfgang&al さんからの引用

    補足説明すると

    IIS(WEBサイト)→「Com+ コンポーネント」をコールしてサーバの任意の場所のファイルをダウンロードまたはアップロードを行う。

    (→設計はこれできまりなので、これはいま変更不可。)

    (→「Com+ コンポーネント」が担当するのが、サーバファイルの書き込み、読み取り。)

    (→現状は「Com+ コンポーネント」の呼び出すができるが、ファイルに対してアクセス権限ないと怒られる(たぶんIISのユーザで実行されちゃうので、))

     

    もちろん、プロパティの「ID」タグの「このーユーザ」で管理者ユーザを指定して実行できることも可能と思いますが、

    これは管理者ID・パスワードを指定するので、これをやりたくない。

     

    逆にCOM+コンポーネントがアクセスするフォルダに対して、IISユーザーに対して許可を与える方法もあると思います。

    が、IISが管理するフォルダ以外に対してアクセス権を与える事はセキュリティ上、まずいような気が…。

    (もちろん、外部に後悔しない場合は別ですけど)

     

     Wolfgang&al さんからの引用

    CatTailさん

    余談ですが、「サービス」と「コンポーネントサービス」はまだちょっと違うと思います。

    ごめんなさい。サービスの中にある「COM+ Event System」「COM+ System Application」と勘違いしていました。

     

    2008年12月23日 12:58
  •  CatTail さんからの引用

    逆にCOM+コンポーネントがアクセスするフォルダに対して、IISユーザーに対して許可を与える方法もあると思います。

    が、IISが管理するフォルダ以外に対してアクセス権を与える事はセキュリティ上、まずいような気が…。

    (もちろん、外部に後悔しない場合は別ですけど)

     

    これは逆ですね。IIS user に高い権限を与えることはそれだけ攻撃できる範囲が広がるのでお勧めできません。

    COM+ 側で高い権限を与える方がよっぽど望ましいです。

     

    また、そもそも任意の場所を扱えるようにするという設計自体がダメですね。

     

    どうしても、必要であるならばそれができるのは管理者ということになりますから、Windows 統合認証で処理するべきでしょうね。

    2008年12月23日 13:18
  •  ちゃっぴ さんからの引用

    これは逆ですね。IIS user に高い権限を与えることはそれだけ攻撃できる範囲が広がるのでお勧めできません。

    COM+ 側で高い権限を与える方がよっぽど望ましいです。

     

    また、そもそも任意の場所を扱えるようにするという設計自体がダメですね。

     

    どうしても、必要であるならばそれができるのは管理者ということになりますから、Windows 統合認証で処理するべきでしょうね。

     

    そうでした。各サービスアカウントには必要最小限の権限しか与えないようにするという、基本的なことを失念していました。

    「IIS Userに権限を…」のくだりに関しては撤回します。

     

     

    > また、そもそも任意の場所を扱えるようにするという設計自体がダメですね。

     

    これには完全に同意します。

    昔ですが、隠しCGIでサーバーの情報が漏洩した事故(事件?)もあったことですし。

     

    2008年12月24日 0:45
  • ちゃっぴさん

     

    投稿ありがとうございます。

     

    まさに「COM+ 側で高い権限を与える」方針で開発しているプログラムです。

    ごめんなさい、設計の話はここで遠慮させていただきたい。そもそも設計いろいろむずかしい・・・・

     

    では、「管理者ということになりますから、Windows 統合認証で処理するべきでしょうね」

    の意味あまり理解できていないが、もうちょっと教えてもらってもいいですか?

     

    要は「IISの設定をWindows統合認証」にすれば、「COM+」でわざわざ管理者権限つけなくても

    サーバ内の任意の場所のファイルがアクセスできるということでしょうか?

    今のプログラムは「Form認証」です。

     

    よろしくお願いいたします。

     

     

     

    2008年12月24日 1:28
  • Windows 統合認証を設定し、user が Web application へ server 管理者の account を使って logon してもらうようにします。

    COM+ は使わなくてもよいですけど、使うなら library application ですね。

    2008年12月24日 3:51
  • ちゃっぴさん

     

    こんにちは、投稿ありがとうございます。

     

    勉強不足で、くだらない質問かもしれないが、

    「Windows 統合認証を設定しuser が Web application へ server 管理者の account を使って logon 」

    1.フォーム認証をやめて、Windows 統合認証を使い。

    2.ASP.NETユーザ偽装を使うということでしょうか?

    <あとで時間作って自分でいろいろ試します、たぶん年明けだな>

     

     

    2008年12月28日 0:27
  •  Wolfgang&al さんからの引用

    1.フォーム認証をやめて、Windows 統合認証を使い。

    2.ASP.NETユーザ偽装を使うということでしょうか?

     

    違います。明示的な偽装は必要ありません。

     

    IIS の認証を利用した場合には、logon 時に生成される thread は logon された Windows account に偽装されて実行されます。

    2008年12月29日 6:07
  • >違います。明示的な偽装は必要ありません。

    >IIS の認証を利用した場合には、logon 時に生成される thread は logon された Windows account に偽装されて実行されます。

     

    あれ?統合認証にしたうえで偽装を有効にする必要がありませんでしたっけ?

    なんか勘違いしてるかも…

    2008年12月29日 14:03
  • こんにちは。

     

    # 途中のやり取りについていけなかった感がありますので、

    # 最初の質問にレスしたいとおもいます(汗)

     

    対話ユーザを選択している場合、誰もローカルログインしていなかったら COM+ コンポーネントは実行できないと思います。

     

    おっしゃるとおり、「このユーザ」 で管理者ユーザを指定されると良いと思います。

    (セキュリティの話はさておき、ですが)

     

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

     

    -----------------------------------------------

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

     

    2009年1月7日 2:41
  • こんにちは。中川俊輔 です。

     

    皆様、回答ありがとうございます。

     

    Wolfgang&alさん、フォーラムのご利用ありがとうございます。

    実行アカウント設定はうまくいきましたか?

    勝手ながら、有用な情報と思われる回答へ回答済みチェックをつけさせていただきました。

     

    今後ともフォーラムをよろしくお願いします。

    それでは!

    2009年1月16日 7:40
  • このスレッド自体はちょっとテーマから離れたましたが、

    回答としては下記スレッドになります。

    http://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=4264845&SiteID=7

    2009年1月23日 23:29