IIS 7.0 での組み込みユーザーとグループ アカウントとは
はじめに
IIS の旧バージョンでは、IUSR_マシン名というローカル アカウントをインストール時に作成していました。IUSR_マシン名アカウントは、匿名認証が有効化されている場合は常に IIS によって使用される既定の ID でした。これは、FTP と HTTP の両方のサービスで使用されました。
また、IIS_WPG というグループもあり、すべてのアプリケーション プール ID のコンテナーとして使用されていました。そして、IIS セットアップ中にシステム上の該当するリソースすべてに対して、IIS_WPG グループへの正しいアクセス許可が設定されるようになっていました。これにより管理者は IIS_ WPG グループに自身の ID を追加するだけで、新しいアプリケーション プール ID を作成できました。
このモデルはうまく機能しましたが、IUSR_マシン名アカウントと IIS_WPG グループの両方が、作成元のシステムのローカルなアカウント/グループであるというデメリットがありました。Windows 内のすべてのアカウントとグループには、他のアカウントと区別するための SID (セキュリティ識別子) と呼ばれる一意の番号が付与されます。ACL の作成時には、この SID のみが使用されます。IIS の旧バージョンの設計の一部として、IUSR_マシン名が metabase.xml ファイルに含まれていました。このため、ユーザーがあるコンピューターから別のコンピューターに metabase.xml をコピーしようとしても、コピー先のコンピューター上のアカウント名が異なるためにうまくいきませんでした。
さらに、SID はコンピューターごとに異なったため、xcopy /o コマンドを実行するだけではあるコンピューターから別のコンピューターに ACL をコピーできませんでした。この問題の対応策とは、ドメイン アカウントを使用することでしたが、インフラストラクチャに Active Directory を追加する必要がありました。IIS_WPG グループにもアクセス許可に関して同じような問題がありました。あるコンピューターのファイル システムに IIS_WPG の ACL を設定し、これらを別のコンピューターに xcopy /o コマンドを実行してコピーしようとした場合、これは失敗します。IIS チームは、このフィードバックを受け取り、IIS 7.0 ではビルトイン アカウントとグループを使用することでこの操作性を改善しました。
ビルトイン アカウントとグループは、常に一意の SID を持つようにオペレーティング システムによって保証されています。IIS 7.0 では、これをさらに一歩進め、新しいアカウントとグループが使用する実際の名前が絶対に翻訳されないようにしました。たとえば、Windows のどの言語版 (日本語版など) をインストールするかに関係なく、IIS アカウント名は常に IUSR となり、グループ名は IIS_IUSRS となります。
以下に、IIS 7.0 の提供する機能の概要を示します。
- IUSR ビルトイン アカウントが IUSR_マシン名アカウントに取って代わりました
- IIS_IUSRS 組み込みグループが IIS_WPG グループに取って代わりました
IUSR アカウントはビルトイン アカウントであるため、パスワードが不要となりました。論理的には、NETWORKSERVICE アカウントや LOCALSERVICE アカウントと同じと考えてください。以下のセクションでは、新しい IUSR アカウントと IIS_IUSRS グループの両方について詳しく説明します。
新しい IUSR アカウントについて
上記のとおり、IIS 7.0 では IUSR_マシン名アカウントが IUSR アカウントで置き換えられました。IUSR_マシン名アカウントは、FTP サーバーがインストールされている場合のみ作成され、使用されます。FTP がインストールされていない場合は作成されません。
このビルトイン アカウントはパスワードを必要とせず、匿名認証が有効になっている場合には既定の ID として使用されます。applicationHost.config ファイルを調べると、以下の定義を確認できます。
<anonymousAuthentication enabled="true" userName="IUSR" defaultLogonDomain="" />
これは、すべての匿名認証要求に対して新しいビルトイン アカウントを使用することを IIS に指示します。このビルトイン アカウントの最大のメリットは、次のとおりです。
- Windows Explorer やさまざまなコマンド ライン ツールを使用して IUSR アカウントのファイル システム アクセス許可を設定できる
- このアカウントについてはパスワードの有効期限を心配する必要がない
- xcopy /o コマンドを使用してファイルを、それらの所有権や ACL の情報と共に別のコンピューターにシームレスにコピーできる
注目すべき重要なポイントは、IUSR アカウントがネットワーク上では匿名として機能するという点で LOCALSERVICE と似ているということです。NETWORKSERVICE アカウントと LOCALSYSTEM アカウントは、コンピューター ID として機能できますが、特権の昇格となるため IUSR アカウントはそのように機能しません。ネットワーク上での権利を持つ匿名アカウントが必要な場合は、匿名認証で以前にも行っていたように新しいユーザー アカウントを作成して、ユーザー名とパスワードを手動で設定する必要があります。これには、IIS 7.0 マネージャーを使用して次の手順を実行します。
- [スタート] をクリックして「INetMgr.exe」と入力し、Enter キーを押します (プロンプトが表示されたら [続行] を選択してアクセス許可を管理者特権にします)。
- [接続] セクションで、コンピューター名の横の [+] ボタンをクリックします。
- IIS 7.0 マネージャーで、管理するサイトをダブルクリックします。
- [機能ビュー] から [認証] 項目をダブルクリックします。
- [匿名認証] を選択して [編集] をクリックします。[資格情報の指定] ダイアログが表示されます。
- [特定のユーザー] オプションをクリックし、[設定] をクリックします。
- 任意のユーザー名とパスワードを入力して、[OK] を選択します。
新しい IIS_IUSRS グループについて
既に説明したように、IIS_IUSRS グループは IIS_WPG グループに取って代わるグループです。この組み込みグループには、必要なすべてのファイルおよびシステム リソースへのアクセス権が付与されています。そのため、アカウントをこのグループに追加すると、そのアカウントはシームレスにアプリケーション プール ID として機能することができます。
ビルトイン アカウントと同様に、この組み込みグループでは XCOPY 展開のいくつもの障害が解決されています。IIS_WPG グループ (IIS 6.0 システムで使用できたグループ) に対するアクセス許可をファイルに設定し、これらのファイルを別の Windows コンピューターにコピーしようとすると、グループの SID がコンピューター間で異なるためにサイトの構成が壊れます。
IIS 7.0 の グループ SID は、Windows Server 2008 が動作するすべてのシステム上で同じであるため、xcopy /o コマンドを使用してファイルをコンピューター間で移動しても ACL および所有権の情報が保持されます。これによって、XCOPY の展開がかなり簡単になりました。
お客様から頂いた 2 つ目の要望は、「アプリケーション プール ID を一度構成したら、必要な変更がすべて IIS によって自動的に実行されるようにして欲しい」というものでした。IIS チームはこのフィードバックに対応し、IIS 7.0 ではこのプロセスをはるかに簡単にしました。IIS はワーカー プロセスを開始する際に、そのプロセスが使用するトークンを作成する必要があります。IIS 7.0 では、このトークンの作成時に、ワーカー プロセスのトークンに対して実行時に IIS_IUSRS メンバーシップが自動的に追加されるようになりました。これによって、「アプリケーション プール ID」として実行するように定義されているアカウントが、明示的に IIS_IUSRS グループの一部になる必要がなくなりました。この変更は、システム セットアップへの障害を減らし、全体的な操作性を向上させるのに役立ちます。
この機能を無効にして、手動で IIS_IUSRS グループにアカウントを追加する場合は、manualGroupMembership の値を true に設定してこの新しい機能を無効にしてください。以下は、defaultAppPool に対する実行例です。
<applicationPools >
<add name="DefaultAppPool">
<processModel manualGroupMembership="true" />
</add>
</applicationPools >