Windowsサービスからアプリケーションを起動する

　Windowsサービスから自動でアプリケーションを起動しようとしたところ、起動してもデスクトップに表示されない・・・。

　　　＊　　　＊　　　＊

　よくよく調べてみれば、サービスをSYSTEMユーザーで起動するように構成しているため、そのままアプリケーションを起動すると、SYSTEMユーザーでアプリケーションが起動する。つまりログオンしているユーザーのデスクトップには表示されず、バックグラウンドで実行されるということ。

　.NET frameworkのSystem.Diagnostic.Processクラスを利用して、アプリケーションを起動している
のだけど、アプリケーションの起動ユーザーを指定できるので試してみた。

　　　＊　　　＊　　　＊

　権限がなくてNG・・・。普通のコンソールアプリやアプリケーションからは起動できるので、メソッドの使用方法は間違っていない様子。特定のユーザーでアプリケーションを起動させるコンソールアプリを作成し、サービスからそれをキックしても同様のエラー。コンソールアプリ単体では動作するのに・・・。

　ユーザーの偽装ができないように対策されている様子。まあ、当たり前か。

　　　＊　　　＊　　　＊

　Win32APIを利用して、ユーザーを偽装させて実行させることは可能なようだけど、手順が面倒臭いし、普通のアプリケーションを作成するほうが楽チンなので、必要ならばそちらで対応しようと思う。

　　　＊　　　＊　　　＊

　バックグラウンドでExcelマクロなどを実行できるので、特殊な利用方法には使えるかもしれない。サービスをユーザー権限でインストールするようにすればよいのだけど、複数ユーザーが利用する場合はどのように動作するのだろう。興味深いので、そのうち試してみようかな。

　　　＊　　　＊　　　＊

　System.Diagnostic.Processでユーザーを利用して、プロセスを起動する場合、パスワードが必要になる。受け渡しは、System.Security.Stringクラスを利用するのだが、パスワードの入力を省略させる場合、パスワードを保存する手法にはどのようなものがあるのだろうか。例えばWindowsだとネットワークドライブのパスワードの保存ができるが、内部的にはどのように保存しているのだろう？　Windowsでの安全な保存方法（完璧なものはないと思うが）の一般的な方法はあるのだろうか。

　　　＊　　　＊　　　＊

　パスワードつながりで、いつも気になっていることを少し。社内などで認証をしているアプリケーションでは、パスワードの平文がアプリケーションには渡されているわけで、開発している人にはユーザーのパスワードを入手することが簡単。LDAPサーバを立てて、各システムで共用している場合、イントラネットのメールから何から、すべて一つのパスワードで利用できてしまうので、ある意味危険なのかなあ、と思う。とあるシステムの開発担当は、悪意があれば、その社内のすべてのアプリケーションの利用をするためのパスワードを入手することが可能なのではないか。

　同じことがネット上でも言えるかもしれない。たいていのサービスはメールアドレスがユーザIDとなっている。異なるサービスのユーザーIDを共通にすることは多いだろう。パスワードをメールのアカウントと同じにしている人も多いかもしれないが、サービスごとに変えておいたほうが安全かもしれない。

　だらだらと書きなぐり。