- - PR -
ASP.net偽装ユーザでのbatファイルの起動
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2008-03-17 22:45
Webサービスの動いているサーバに配置された「CreateText.bat」をWebサービスより
起動させ、作成したテキストをTestドメインに参加しているクライアントにコピーしたい と思っています。 Web.configには、以下の記述をし偽装ユーザにて処理をします。 <identity impersonate="true" userName="Testdomain\TestUser" password="test" /> 「ドメインに参加しているクライアントにテキストをコピーする」のは出来たのですが、 テキストを作成するバッチを呼び出すところで以下のようなエラーが出てしまいます。 System.ComponentModel.Win32Exception: アクセスが拒否されました。 以下の3つにはTestdomain\TestUserに対しフルコントロールを付与しています。 ・Webアプリケーションフォルダ ・バッチファイルの格納されたフォルダ ・C:\WINDOWS\Microsoft.NET\Framework\<version>\Temporary ASP.NET Files また、[管理ツール] → [ローカル セキュリティ ポリシー] → [ローカル ポリシー] → [ユーザー権利の割り当て] より、以下の特権をTestdomain\TestUserに割り当ててあります。 ネットワーク経由でコンピュータへアクセス バッチ ジョブとしてログオン サービスとしてログオン 何が問題で、アクセス拒否されているのでしょうか？？ 設定等の漏れや、間違い等ありましたら教えて下さい。 Windows Server 2003 .NetFramework1.1 IIS5.0 |
|
投稿日時: 2008-03-18 14:05
追記です。
実際にエラーが起きるのは、『Process.Start()』の部分です。 ------------------------------------------------------------------ Dim ExecuteFile As String Dim pinf As New ProcessStartInfo Dim proc As New Process Dim rtnProc As Boolean 'Web.configファイルより起動バッチのパスを取得 ExecuteFile = System.Configuration.ConfigurationSettings.AppSettings("CreateText") 'プロセス開始時の設定 pinf.FileName = ExecuteFile pinf.UseShellExecute = False pinf.RedirectStandardOutput = True pinf.CreateNoWindow = True 'バッチの起動 proc.StartInfo = pinf rtnProc = proc.Start() ←ここでエラー 'バッチが終了するまで待機 proc.WaitForExit() ------------------------------------------------------------------ また、 <identity impersonate="true" userName="Testdomain\TestUser" password="test" /> の記述をやめ、ASPNETユーザで処理を行う場合はバッチは問題なく呼び出せます。 Testドメインに参加しているクライアントにテキストをコピーする事が出来なくなって しまいますが… <location path="…">の記述をすればいいのでしょうか？ うーん。 よく分かっていないのでもう少し調べます。 分かる方がいらっしゃいましたら教えて下さい。 |
|
投稿日時: 2008-03-18 22:39
ユーザアカウントのアクセスレベルをAdministratorにしても同じエラーがでました。
また、テキストコピーとバッチの呼び出しは一連の処理としているので同じサービスです。 なので、<location path="…">の指定でどうにかできることではなさそうです。 サービスを分ければよいのかもしれませんが、仕様上難しい状態です。 うーーーーん |
|
投稿日時: 2008-03-18 22:43
とりあえず、情報収集。
エラーが発生するところを Try 〜 Catch で囲み、エラー情報を中の中まで（InnerException やその他のエラー情報を探れるだけ）書き出してみてください。 |
|
投稿日時: 2008-03-19 10:23
Jittaさん、返信ありがとうございます。
エラー情報を分かるだけ探ってみました。 HelpLink:Nothing InnerException：Nothing Message：アクセスが拒否されました。 Source：System StackTrace： at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start() at TestWebService.Center.SendInfoText() TargetSite：{System.Reflection.RuntimeMethodInfo} Tostring:System.ComponentModel.Win32Exception: アクセスが拒否されました。 at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo) at System.Diagnostics.Process.Start() at TestWebService.Center.SendInfoText() はっ！ NET Framework セキュリティ: System.Security.SecurityPermission (完全信頼を指定して System.Diagnostic.Process のメンバを呼び出すためのアクセス許可) PermissionState.Unrestricted (関連する列挙体) ここが怪しいような… 設定してみます。 |
|
投稿日時: 2008-03-20 00:00
Batch file を起動とのことですが、こちらは cmd.exe によって起動されます。
で、この cmd.exe の ACL は一般の user では、interactive (対話的) に logon した場合のみ実行できるように許可されています。 IIS で動作している Web application はどのような logon type で動作しているかというと基本認証以外では、network logon します。 また、その process 内で偽装した場合も interactive ではなく、network logon となります。 したがって、cmd.exe の ACL ではじかれます。 では、cmd.exe の ACL を緩和すればいいんじゃないか？と思うかもしれませんが、何で default 許可されていないんでしょう？ というのは、cmd.exe に対し user の入力を引き渡すと OS command injection を発生させる可能性があるからです。この脆弱性を悪用されると対象の user がその server 上で認められているすべてのことが実行できてしまいます。 そういう事態を避けるためにも、Web application では cmd.exe を全く利用しないほうがよいでしょう。ぶっちゃけた話、cmd.exe を利用しないとできないなんてこと無いわけですし。 _________________ |
|
投稿日時: 2008-03-21 16:12
ちゃっぴさん、返信ありがとうござます。
>OS command injection を発生させる可能性があるからです。 ！！恐ろしいですね！ 別の方法で処理する方向で考えていきたいと思います。 ただ、出来なかった…で終わるのは悔しいので、後学の為に教えて下さい。 cmd.exe の ACL を緩和する場合、どこで設定を行うのでしょうか？ >ACL は一般の user では、interactive (対話的) に logon した場合のみ実行できるように許可されています。 cmd.exeの［プロパティ］→［セキュリティ］→［詳細設定］では、network logon でも実行できるようにするといった権限が見当たらないので… |
|
投稿日時: 2008-03-21 22:48
cmd.exe の ACL を見ればわかると思いますけど、INTERACTIVE というのがあると思います。
これが、interactive (対話的) に logon する場合に利用される group です。 同様に logon type によって割り当てられる group に NETWORK, BATCH, SERVICE 等があります。上記 group には、logon したときに自動的にその logon type に対応した group が割り当てられます。 つまり、どの account を利用しているか？どんな group に所属しているか？に関わらず logon type のみで制御する場合に利用する group です。したがって、これらの group で ACL を許可した場合、対応する logon type で logon したすべての user が対象になるため、注意が必要です。 多くの場合、logon type で ACL を付与する必要はなく、独自に定義した group で ACL を付与するほうがよいでしょう。 なお、今回の場合では Web application ということなので、すでに書きましたが cmd.exe を利用しないというのが推奨される方法です。 _________________ |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。