MovieJukeBoxのワーカプロセス実行アカウントを、NT AUTHORITY\NETWORK SERVICE から、VMJBのローカルアカウント A に変更

アプリケーションプールのワーカプロセス実行アカウントを、NT AUTHORITY\NETWORK SERVICE から、VMJBのローカルアカウント A に変更した。

背景

（変更前）

MEDIASV に共有動画コンテンツ、IIS、SQLServer

（変更後）

MEDIASV に共有動画コンテンツ、MEDIASV の Hyper-V 上の仮想マシン VMJB に IIS、SQLServer

というように、構成を変更していた。

問題

インポートボタン押下すると、MEDIASVの共有フォルダのファイル一覧を作成する。このときアプリケーションプールのワーカプロセス実行アカウント NT AUTHORITY\NETWORK SERVICE の権限で、MEDIASVの共有フォルダにアクセスするみたいだ。NT AUTHORITY\NETWORK SERVICE は  VMJB のビルトインアカウントなので、MEDIASVの共有ファイルにアクセスすることができないみたいだ。

変更前は、共有動画コンテンツ、IIS、SQLServer がすべて同じパソコン上で構成されていたので、ワーカプロセスの実行アカウントが NT AUTHORITY\NETWORK SERVICE で問題なく運用できていた。
※NT AUTHORITY\NETWORK SERVICE へ SQLServerの権限「db_reader、db_writer、ddl_admin及び実行」は付与する必要あり。

対処

アプリケーションプールのワーカプロセス実行アカウントを、NT AUTHORITY\NETWORK SERVICE から、VMJBのローカルアカウント A に変更した。

MEDIASVにも同じ名前のローカルアカウント A がある。

WORKGROUP運用なので、同じ名前のアカウント名だから、VMJBで動作するWEBアプリの実行アカウント A は、MEDIASVの共有ファイルにアクセスできるようになったわけだ。

評価

VMJB\A は一般ユーザだが、SQLServerの権限は sysadmin を付与されているので、DBアクセスは問題ない。というか、権限が強すぎる。

MovieJukeBoxで必要となるDBアクセス権限は、db_reader、db_writer、ddl_admin及び実行のみである。例えば、 W-SQL というローカルアカウントを MEDIASV と VMJB 双方に作成し、W-SQL をワーカプロセスの実行アカウントにし、W-SQL に対し、上述のSQLServerの権限を付与するのがよいと思う。

今回は個人利用なのと自分で作成したWEBアプリなので、ローカルアカウント A のままにすることにした。