◆ASP.NET(IIS)からのリソース（DB）アクセス

実運用システムではサーバー屋さんがやってくれるので知らなくても良いが、基礎知識としてメモしておく。（自分用なのでとりあえず動けばOKの簡易的な設定）

昔はMS製品というとインストールさえすれば動いたので、素人な私には非常に楽ちんだった。
なのに、世の中に悪い人たちが沢山いるせいでデフォルトでは何も動かない初期設定が基本になってきた。（TrustWorthy)

なので、開発の前にまずは動かす環境を作る必要がある。（VisualStudioなどはローカルで全部できるようになっているので作るだけは作れるが他人に提供するとなるといきなり困ってしまう）

ASP.NETのアプリケーションはIISのワーカープロセス（アプリケーションプール）でホストされて動く。
なので、ASP.NETからDBなどにアクセスしようとすると、ユーザーID的にはワーカープロセスサービス(w3wp.exe)を実行しているサービスアカウントでアクセスしに行くと言う事になる。（通常は）
IIS6やIIS7ではnetwork serviceアカウントがデフォルトで使われているので、そのままでは（外部の）DBにアクセス出来ない。

そこで以下の手順でサービスの実行アカウントを変更する。（ドメイン環境前提）

1. ドメインに専用のユーザーを作成。(Domain Users権限）
2. SQLServerにそのユーザーを追加し適切な権限を付与する。
3. IISをホストするサーバーのローカルセキュリティポリシーでローカルログオンを拒否。
   
4. 作成したユーザーをIISをホストしているサーバーのIIS_WPGローカルグループに追加する。
   って、IIS7環境にはそんなローカルグループは無いじゃん。
   どうやら、IIS_IUSRSに変更になったらしい。
   （アプリケーションプールの実行アカウントに設定すると勝手に追加されるっぽい情報もあり。）
   
5. IISマネージャでアプリケーションプールの実行アカウントに指定する。
   

ちなみにドメイン環境がない場合はIISとDBを同じサーバーで動かすか、ミラーアカウント（だっけ？）、即ちIISのサーバーとDBのサーバーに同じID/PWDのユーザーを作って運用すればとりあえず可能ではないだろうか。

また、DBでの認証にSQLServer認証を使う場合にはASP.NETアプリケーションにて接続文字列にUID/PWDを指定してアクセスすることになるのかな。

最後に、ワーカープロセスからWindows統合認証でSQLServerにアクセスする際にアプリケーションプールの実行ユーザーではなくクライアントユーザーを使ってアクセスする方法がある。（あまり使われないようだが）
これを使用するとデータベースのアクセスログに実際のクライアントユーザーが記録されるというメリットがある。
これは「偽装」と呼ばれる方法でweb.configのsystem.web要素に以下のように指定する。

<identity impersonate="true" 
          userName="domain\username"
          password="password"/>

userNameとpasswordをこの様に固定することもできるし、これを省略するとIISで認証をうけたWindowsユーザーが使われる。
ただし、匿名認証が使われている場合はIIS側で匿名に割り当てるユーザーを指定できる。

ん～、この画面を見るとIISからも偽装を設定できるようになったっぽい。

 

Windows Server2008R2およびWindows7から(IIS7.5?)はアプリケーションプールの実行アカウントのデフォルトが「Network Service」から「アプリケーションプール名（ID)」に変更になったようだ。
このIDにファイルのアクセス権を与えるには、ACL設定画面で「IIS AppPool\DefaultAppPool」などと指定すれば良い。