IIS Insider

既定で、Web ブラウザはリクエストを Web サーバーに行なう時、ユーザーの資格情報 (ユーザーの Windows ユーザー名を含みます) を送りません。これがほとんどの一般的な Web サイトが動作する方法です。- ユーザーは自分自身の Windows ユーザー名をリモートの Web サイトに提供しないで匿名で Web サイトにアクセスすることができます。

ブラウザに資格情報をサーバーに送らせるためには、[匿名アクセスを許可する] を無効にし (後に説明しますが、例外が 1 つあります)、基本、ダイジェストまたは統合 Windows 認証などのそのほかの認証メカニズムのうち 1 つを有効にする必要があります。

これを行なった後、クライアントとサーバー間のやりとりは下の図 1 のようになります。クライアントが IIS にユーザー名を送っているため、Logon_User サーバーの変数が入力されます。

IIS 6 は今やリソースにアクセスする (例: ハード ディスクからファイルを読み取るまたはデータベースにアクセスする) ために、構成された匿名ユーザー アカウント (既定で IUSR_<コンピュータ名>) を使用していないため、ユーザーが提供しているユーザー アカウントがどのようなものであろうとも、それが IUSR_<コンピュータ名> が現在所有しているものと同じアクセス許可を持つようにする必要があります。これには Web サイト内の ASP ファイルに NTFS 読み取り許可を与える、アプリケーションにより必要とされるそのほかのファイルまたはデータベースへのこれらのアカウントのアクセスを許可するなどが含まれます。NTFS のアクセス許可を構成するためには、Windows エクスプローラの Web アプリケーションのルート フォルダを右クリックし、[セキュリティ] を選択します。[追加] ボタンを介し必要なユーザー アカウントを追加し、それらに [読み取り] アクセス許可を追加します。これらの変更をすべてのサブフォルダおよびファイルに適用します。ユーザーが多く存在する場合、Windows グループを作成することにより、このプロセスを迅速に行なうことができます。次にそれらのユーザーをグループに追加します。そのグループにファイルへの NTFS 読み取りアクセス許可を付与することができます。

ユーザーが依然としてアプリケーションにアクセスできない場合、その状況についてトラブルシューティングを行ない、根本原因を確認する必要があります。ユーザーがユーザー名 (ドメイン コンポーネントを含む) およびパスワードを正しく入力していること、IIS サーバー (およびすべての該当するグループ ポリシー オブジェクト) 上のローカル セキュリティ ポリシーがこれらのユーザーにサーバーへのログオンを許可していること、およびユーザーがサーバー上の必要なリソースへのアクセス許可を所有していることを確認してください。認証および承認診断 (AuthDiag) ツールが認証および承認に関する問題のトラブルシューティングを行なう手助けとなります。IIS 5.x および 6.0 について、AuthDiag ツールは次の Web サイトからダウンロードできます。http://www.microsoft.com/downloads/details.aspx?FamilyID=e90fe777-4a21-4066-bd22-b931f7572e9a&DisplayLang=en (英語)

匿名アクセスと少なくとも 1 つのそのほかの認証メカニズムの両方が有効であり、また構成された匿名ユーザー (既定で IUSR_<コンピュータ名>) が問題となっているファイルへの NTFS アクセス許可を持たない場合、前述の 1 つの例外が起こります。この場合、IIS は、ハード ディスクからファイルを読み取るために匿名ユーザー アカウントを使用できなくなり、その代わりにユーザーに使用される資格情報を提供するようメッセージを表示します。

これは、ワークグループのシナリオでもあり得ます。しかし、この構成は少々手間がかかり、使用しているアプリケーションの種類 (例: ASP.NET に対してクラシック ASP) により、変わります。しかし、基本的な原則は、使用している技術が何であっても同じです。Windows XP は (Windows NT、Windows 2000 および Windows Server 2003 がサポートするように) 「パススルー認証」をサポートします。これにより、ユーザーはリモート コンピュータで有効な資格情報を使用してリモート コンピュータに認証を行なうことができます。つまり、ローカル コンピュータで使用しているユーザー名およびパスワードがリモート コンピュータで使用しているものと同じ場合、この認証プロセスはユーザーに透過的であり得ます。

このため、裏技として、IIS Server 上の Web アプリケーションが使用しているのと同じユーザー名およびパスワードを持つ SQL Server 上にユーザー アカウントを作成します。状況をさらに複雑にしているものは、固定されたユーザー アカウント (または ID) のいずれかを使用し、Web アプリケーションを実行する、またはブラウジングしているユーザーにより提供された資格情報を使用する Web アプリケーションを実行するための IIS の Web アプリケーションの機能です。(後者の場合では、Web アプリケーションが「エンド ユーザーになりすましている」と言われます。) Web アプリケーションへの匿名アクセスを許可している場合、通常、固定された ID が使用され、また、ユーザーに資格情報の提供を必要とする場合、エンド ユーザーになりすまします。しかし、さらに興味深くするために、ASP.NET は開発者がエンド ユーザーになりすますのではなく、ユーザーに提供を強制することができる機能を提供します。下の表 1 は可能性を要約する手助けとなります。

ご存知のように、多数の可能なシナリオがあります。シナリオにより、バック エンドの SQL Server に異なるユーザー アカウントを作成する必要があります。

Web サイトへの匿名アクセスを許可していない場合 (すなわち、ユーザーに認証を強制している場合)、そのユーザーになりすましており (たとえば ASP.NET の<identity impersonate=”true”>オプションを使用している) 行なう必要のあることは次の通りです。

エンド ユーザーになりすましていない場合 (たとえば、匿名認証を許可している場合)、Web アプリケーションにより使用される固定アカウントに一致するアカウントを SQL Server に作成する必要があります。IIS は Window XP で実行されているため、最初にこちらを説明します。 (Windows 2000 は Windows XP と同じです) Windows Server 2003 で IIS を構成するには、若干の変更が必要であり、これは最後に詳細を説明します。Windows 2000 および Windows XP で実行されている ASP.NET アプリケーションについて、固定された ID は既定で “ASPNET” アカウントです。ASP アプリケーションについて、2 つのアカウントが使用されます。それらは IUSR_<コンピュータ名> (ASP ページについて) および IWAM_<コンピュータ名> (global.asa で処理される特定のイベントについて) です。

Windows 2000 または Windows XP コンピュータで実行されている ASP.NET アプリケーションについて、次のステップを実行する必要があります。

これで ASP.NET アプリケーションは信頼される接続を使用し SQL Server に接続できるはずです。Windows 2000 または Windows XP で実行されているクラシック ASP アプリケーションを使用している場合、次のステップを実行する必要があります。

ASP アプリケーションは信頼される接続を使用し SQL Server に接続できるはずです。global.asa ファイルの (Session_onEnd などの特定のイベント ハンドラの) SQL Server に接続している場合、IWAM_<IISServerName> アカウントについて上記のステップを繰り返す必要があります。この理由は、このアカウントはこれらのイベントが処理される時に使用されるためです。上記のステップ 2 で言及されているスクリプトは、このプロセスを繰り返す必要がある場合、IWAM_<IISServerName> アカウントについてのパスワードを表示します。

IIS Server が既定のワーカー プロセス分離モードで Windows Server 2003 で実行されている場合、いくつかのステップは異なります。ASP.NET アプリケーションについて、アプリケーションが機能している Web アプリケーション プールの ID を編集することにより、ユーザー アカウントを構成することができます。これは IIS マネージャの Web アプリケーション プール ノードを介し行なわれます。既定のネットワークサービス アカウントにパスワードを設定できないため、新しい Windows ユーザー アカウントを作成し、それにワーカー プロセス ID として動作するために必要なアクセス許可を割り当てる必要があります。マイクロソフト サポート技術情報 821614 (英語) がこれらのアクセス許可について詳述しています。

Windows Server 2003 で、既定でワーカー プロセス分離モードで実行されている場合、global.asa イベントは IWAM_<IISServerName> により処理されなくなります。このため、IIS および SQL Server コンピュータで重複した IWAM_<IISServerName> アカウントを構成する必要はありません。

.NET ランタイムは「形式に基づく認証」を提供します。認証されたユーザーが保護されたページをリクエストすると、そのユーザーは自動的にログイン ページにリダイレクトされます。正常にログインした後、ユーザーはリクエストした元のページに戻されます。認証の状況は Cookie を介し保持され、.NET ランタイムはすべての必要な Cookie の管理を受け持つことができます。フォーム認証に関する詳細情報および ASP.NET サイトにフォーム認証を実装する方法については、下記の GotDotNet.com の Forms Based Authentication QuickStart チュートリアルをご覧ください。
http://samples.gotdotnet.com/quickstart/aspplus/default.aspx?url=%2fquickstart%2faspplus%2fdoc%2fformsauth.aspx (英語)

フォーム認証は迅速に ASP.NET リソースに実装されますが、プレーン HTML ファイル、画像、Adobe Acrobat (PDF) 文書などの ASP.NET 以外のリソースを保護しません。この理由を理解するために、IIS および ASP.NET リクエスト処理のパイプラインを見る必要があります。

処理のパイプラインを下の 図 2 に示します。受信リクエストは http.sys (カーネル モードの HTTP ドライバ) から IIS に渡されます。適用可能な ISAPI フィルタにより処理された後、IIS はリクエストが ISAPI エクステンションにより処理される必要があるかどうかを決定します。リクエストが ISAPI エクステンションにより処理されるかどうかは、リクエストされたリソースのファイル拡張子が IIS メタベースの ISAPI エクステンションにマップされているかどうかによります。マッピングがない場合、リクエストは静的ファイル ハンドラにより処理されます。(図の 1 で示してあります。) これは、HTML ファイル、画像、ビデオおよび Adobe Acrobat (PDF) 文書などの静的なファイルへのリクエストに起こることです。

または、リクエストが ASP.NET ISAPI エクステンションにマップされている拡張子 (ASPX など) を持つファイルについての場合、そのリクエストは (図の 2 で示されているように) その拡張子に渡されます。この時点で、ASP.NET 処理のパイプラインが開始されます。リクエストは登録された HTTP モジュールを介し渡され、次に登録された HTTP ハンドラにより処理されます。

それではフォーム認証についてはどうしたのでしょう? フォーム認証が提供する機能を実装するコードは .NET HTTP モジュールとして実装されています。このため、リクエストが図の 3 により示されている場所に到達する場合のみ フォーム認証が開始します。静的なファイルに対するリクエストはこの時点までうまく到達しないため、フォーム ベース認証はリクエストからこれらのリソースを保護しません。

フォーム認証に静的なリソースを保護させる一般的な方法が 2 つあります。最初の方法は、静的なファイルのファイル拡張子を ASP.NET ISAPI エクステンションにマップすることが含まれます。これが行なわれた後、これらの静的なリソースへのリクエストは静的ファイル ハンドラによってではなく、ASP.NET により処理されます。これにより、フォーム認証 HTTP モジュールはこれらのリソースへのアクセスを保護することができます。このメカニズムを実装すると、コンピュータでオーバーヘッドが発生することに留意してください。これを実装するためには、次の手順にしたがってください。

1.	[IIS マネージャ] を開き静的なリソースが存在する Web サイトまたは Web アプリケーション ルートを探します。
2.	右クリックし、[プロパティ] を選択します。
3.	[ホーム ディレクトリ] (Web サイトについて) または [ディレクトリ] (Web アプリケーションについて) タブで、[構成] ボタンをクリックします。
4.	[マッピング] タブで、ASP.NET ISAPI エクステンションにマップしているエントリ (ASPX など) を探します。そのエントリを選択し、[編集] ボタンをクリックします。[実行可能ファイル] テキスト ボックスで、すべてのテキストを選択し、それを Windows クリップボードに (右クリックし、[コピー] を選択することにより) コピーします。[OK] をクリックし、ダイアログを閉じ、[マッピング] タブに戻ります。
5.	ここで [追加] ボタンをクリックし、新しいマッピングを追加します。実行可能ファイルのパスを (右クリックし、[貼り付け] を選択することにより) 実行可能ファイルのテキスト ボックスに貼り付けます。保護したいファイルのファイル拡張子を [拡張子] テキスト ボックスに追加します。許可された動詞およびアクセスしたいそのほかの HTTP の動詞を “GET,HEAD,POST,DEBUG” に設定します。[スクリプト エンジン] ボックスにチェックが入れられていることを確認します。
6.	[OK] をクリックし、新しいスクリプト マッピングを追加します。ここで、入力したファイル拡張子を持つ文書が .NET ランタイムにより処理され、ASP.NET フォーム認証で保護されます。

第 2 番目に一般的に使用されている方法は、保護したいすべての静的なコンテンツを Web サイト外に移動させることに関連します。Web サイトで、ユーザーが文書のダウンロードを許可されていることを確認するページを作成します。ユーザーが文書のダウンロードを許可されている場合、ASP.NET ページはハード ディスクからファイルを読み取り、適切な HTTP ヘッダーを設定した後、それをユーザーにストリームします。このソリューションは認証および承認のセクションを実装するためにいくつかのカスタム コードを書くことが関連するため、これはこのコラムの取り扱い範囲外です。しかし、多くのチュートリアルが一般的な ASP.NET Web サイトに存在しています。

「2 つのパイプライン」の問題が IIS 7 で解決されることは興味深いです。これは IIS と ASP.NET を完全に統合します。この結果の 1 つは、単一で統合されたイベント パイプラインです。IIS 7 に関する詳細情報は次の Web サイトをご覧ください。http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis7/Ops/9a90c800-3f09-4a3f-87b0-caae34076aca.mspx (英語)