認証について

ユーザーがサーバー上の情報にアクセスする前に、有効な Microsoft Windows のユーザー アカウント名とパスワードの入力を要求できます。この識別プロセスは、"認証" と呼ばれています。認証は、IIS のほとんどの機能と同様に、Web サイト、ディレクトリ、またはファイル レベルで設定することができます。IIS では、サーバー上のコンテンツへのアクセスを制御するため、次の認証方式が提供されています。

WWW 方式

FTP 方式

認証の設定については、「認証を有効にし、構成する」を参照してください。


認証方式の概要

認証方式 セキュリティ レベル パスワードの送信方法 プロキシ サーバーおよびファイアウォール経由での使用 クライアント要件
匿名認証 なし N/A ブラウザ
基本認証 Base64 でエンコードしたクリア テキスト 可 (ただし、Base64 でエンコードしたクリア テキストは暗号化されないため、プロキシ サーバーまたはファイアウォール経由でクリア テキストのパスワードを送信すれば、セキュリティ上のリスクが伴う) ほとんどのブラウザ
ダイジェスト認証 ハッシュ化 Internet Explorer 5.0 以降
高度ダイジェスト認証 ハッシュ化 Internet Explorer 5.0 以降
統合 Windows 認証 NTLM 使用ならハッシュ化、
Kerberos 使用なら Kerberos チケット
不可 (ただし、PPTP 接続で使用すれば可) NTLM の場合 Internet Explorer 2.0 以降、Kerberos の場合 Internet Explorer 5.0 以降を搭載した Windows 2000 以降
証明書認証 N/A 可 (SSL 接続を使用) Internet Explorer および Netscape
匿名 FTP 認証 なし N/A 任意の FTP クライアント
基本 FTP 認証 クリア テキスト 任意の FTP クライアント


匿名認証

匿名認証では、ユーザーはユーザー名やパスワードを入力せずに、Web サイトや FTP サイトの公開領域にアクセスできます。ユーザーが一般の Web サイトや FTP サイトに接続しようとすると、Web サーバーはその接続を IUSR_computername という Windows ユーザー アカウントに割り当てます。この computername は、IIS を実行しているサーバー名です。既定の設定では、IUSR_computername アカウントは、Windows ユーザー グループの Guests アカウントに含まれています。Guests グループには、NTFS のアクセス権によって決まるセキュリティ制限があり、これによって一般のユーザーが利用できるアクセス レベルとコンテンツの種類が指定されています。

サーバー上に複数のサイトがある場合や、別のアクセス権が必要な領域がサイトにある場合は、複数の匿名アカウントを作成して、各 Web サイトや FTP サイト、ディレクトリ、またはファイルにそれぞれ割り当てることができます。アカウントに異なるアクセス権を与えたり、アカウントを異なる Windows ユーザー グループに割り当てたりすることで、公開された Web または FTP コンテンツの異なる領域への匿名アクセスをユーザーに許可することができます。

次のプロセスでは、IIS によって IUSR_computername アカウントがどのように使用されるかを説明します。

  1. IUSR_computername アカウントが、セットアップ過程で IIS コンピュータの Guests グループに追加されます。
  2. IIS は、要求を受け取ると、コードを実行したりファイルにアクセスしたりする前に、IUSR_computername アカウントを偽装します。IIS では IUSR_computername アカウントのユーザー名およびパスワードが分かっているため、このアカウントを偽装することができます。
  3. IIS は、IUSR_computername アカウントがファイルへのアクセスを許可されているかどうかを調べるために、NTFS ファイルおよびディレクトリのアクセス権を確認してから、ページをクライアントに返します。
  4. アクセスが許可されている場合、認証は完了し、ユーザーはリソースを使用できます。
  5. アクセスが許可されていない場合、IIS は別の認証方式を試します。別の認証方式が選択されていない場合は、"HTTP 403 Access Denied" というエラー メッセージがブラウザに返されます。

重要    IIS では、匿名認証が有効になっていると、ほかの認証方式を有効にしている場合でも、必ず最初に匿名認証によってユーザーの認証を試みます。

匿名認証に使用されるアカウントは、IIS スナップインから、Web サーバー サービス レベル、または個別の仮想ディレクトリおよびファイルに対して変更できます。匿名アカウントには、ローカル ログオンするユーザー権利が必要です。アカウントにローカル ログオンの権利がない場合、IIS は匿名要求に応えることができません。IIS のインストールでは、IUSR_computername アカウントにローカル ログオン権限が与えられます。既定では、ドメイン コントローラ上の IUSR_computername アカウントに、ゲスト アカウントを与えることができません。匿名ログオンを許可するには、IUSR_computername アカウントをローカル ログオンに変更する必要があります。

   Active Directory Service Interface (ADSI) では、ローカル ログオン権限の条件をプログラムによって変更できます。詳細については、「Active Server Pages ガイド」の「LogonMethod」を参照してください。

また、Microsoft 管理コンソール (MMC) のグループ ポリシー スナップインを使用して、Windows の IUSR_computername アカウントのセキュリティ権限を変更することもできます。ただし、匿名ユーザー アカウントに特定のファイルやリソースへのアクセス権がない場合は、Web サーバーはリソースへの匿名接続の確立を拒否します。詳細については、「Web サーバーのアクセス権を設定する」を参照してください。

重要   IUSR_computername アカウントを変更した場合、Web サーバーが処理するすべての匿名 HTTP 要求に影響が現れます。このアカウントを変更する際には、細心の注意が必要です。

基本認証

基本認証方式は、ユーザー名とパスワードの情報を収集する手段として広く使われている業界標準の方式です。

クライアント認証プロセス

  1. Web ブラウザ Internet Explorer では、ユーザーに割り当てられた Windows アカウントのユーザー名およびパスワード (資格情報) を入力するためのダイアログ ボックスが表示されます。
  2. 次に、Web ブラウザが、ユーザーの資格情報を使用してサーバーへの接続の確立を試みます。クリア テキストのパスワードは、Base64 でのエンコードを経て、ネットワーク上に送信されます。
  3. 重要   Base64 でのエンコードは、暗号化とは異なります。Base64 でエンコードされたパスワードがネットワーク上でネットワーク スニッファによって傍受された場合、権限のない第三者によってパスワードが簡単に解読され、再使用される可能性があります。

  4. ユーザーの資格情報が拒否された場合、Internet Explorer では資格情報の再入力を促す認証ダイアログ ウィンドウが表示されます。Internet Explorer の場合、ユーザーは 3 回まで接続を試みることができ、接続が失敗するとエラー メッセージが表示されます。
  5. Web サーバーによってユーザー名とパスワードが有効な Microsoft Windows ユーザー アカウントと一致することが確認されると、接続が確立されます。

基本認証の設定については、「認証を有効にし、構成する」を参照してください。

基本認証の利点は、基本認証が HTTP の仕様の一部であり、ほとんどのブラウザでサポートされていることです。欠点は、基本認証を使用している Web ブラウザでは、パスワードが暗号化されていない形式で転送されることです。ほかのユーザーが、ネットワーク上の通信を監視することで容易にパスワードを傍受し、一般に入手できるツールによって容易に解読する可能性があります。このため、基本認証は、専用回線や Secure Sockets Layer (SSL) 接続など、ユーザーと Web サーバー間の接続が安全であると確信できる場合にのみ使用することをお勧めします。詳細については、「暗号化」を参照してください。

   統合 Windows 認証は、基本認証より優先して使用されます。ブラウザはユーザーにユーザー名とパスワードの入力を求める前に、統合 Windows 認証を選択し、最新の Windows ログオン情報の使用を試みます。現在は、Internet Explorer Version 2.0 以降でのみ、統合 Windows 認証をサポートしています。

ダイジェスト認証

ダイジェスト認証は、基本認証と同じ機能を提供します。ただし、ダイジェスト認証は、ネットワーク上でユーザーの資格情報が転送される方法に関して、セキュリティが強化されています。ダイジェスト認証では、ネットワーク上で資格情報を MD5 ハッシュとして転送します。これは、メッセージ ダイジェストとも呼ばれ、元のユーザー名とパスワードがハッシュから解読されることはありません。ダイジェスト認証は、WebDAV (Web Distributed Authoring and Versioning) ディレクトリで使用できます。

クライアント ソフトウェアの追加インストールは不要ですが、ダイジェスト認証は、World Wide Web Consortium の Web サイトRFC 2617 仕様で定義されている HTTP 1.1 プロトコルに依存しています。ダイジェスト認証は HTTP 1.1 準拠が要件であるため、一部のブラウザではサポートされません。HTTP 1.1 非準拠のブラウザがダイジェスト認証を使用してサーバーからファイルを要求した場合、サーバーではクライアントに対してダイジェスト資格情報を要求します。HTTP 1.1.非準拠のクライアントではダイジェスト認証がサポートされないため、この要求を拒否します。

ダイジェスト認証の要件

IIS サーバーでダイジェスト認証を有効にする前に、次の最低要件がすべて満たされていることを確認します。ドメイン管理者のみが、ドメイン コントローラ (DC) 要件が満たされていることを確認できます。DC が次の要件を満たしているかどうか不明である場合、ドメイン管理者に問い合わせてください。

クライアント認証プロセス

次の手順は、ダイジェスト認証を使用したクライアント認証の概要を示しています。 ダイジェスト認証のクライアント認証
  1. クライアントが IIS サーバーのファイルを要求します。
  2. IIS サーバーでは要求を拒否し、クライアントに次の情報を送信します。
  3. Internet Explorer では、ユーザーに資格情報 (ユーザー名とパスワード) の入力が要求されます。資格情報は領域名と結合され、MD5 ハッシュが作成されます。今回は MD5 ハッシュが送信され、IIS サーバーに対してファイル要求を再発行します。
  4. IIS サーバーがハッシュを受信し、クライアントのハッシュを確認するためにドメイン コントローラに送信します。
  5. ドメイン コントローラでは、IIS サーバーに認証結果を通知します。
  6. クライアントが認証されたら、IIS は要求されたドキュメントまたはデータをクライアントに送信します。

重要    ダイジェスト認証は、Active Directory に格納されている要求側ユーザー パスワードのクリア テキスト コピーが DC に存在する場合にのみ完了します。DC はパスワードのクリア テキスト コピーを格納しているため、Active Directory は物理的な不正アクセスとネットワーク上の不正アクセスの両方から保護されている必要があります。

高度ダイジェスト認証

高度ダイジェスト認証は、ユーザーの資格情報がドメイン コントローラ (DC) で格納される方式を除き、ダイジェスト認証と同じです。高度ダイジェスト認証がダイジェスト認証よりセキュリティが強化されているのは、ネットワーク上でユーザーの資格情報を MD5 ハッシュとして送信するだけでなく、DC の Active Directory でもユーザーの資格情報を MD5 ハッシュ (メッセージ ダイジェスト) として格納するためです。資格情報は Active Directory に MD5 ハッシュとして格納されるので、DC にアクセスできる第三者によってユーザーのパスワードが検出される可能性はありません。高度ダイジェスト認証は WebDAV (Web Distributed Authoring and Versioning) ディレクトリで使用でき、ダイジェスト認証と置き換えることはできません。

クライアント ソフトウェアの追加インストールは不要ですが、高度ダイジェスト認証は、World Wide Web Consortium の Web サイトRFC 2617 仕様で定義されている HTTP 1.1 プロトコルに依存しています。高度ダイジェスト認証は HTTP 1.1 プロトコルに依存するため、一部のブラウザではサポートされません。HTTP 1.1 非準拠のブラウザがダイジェスト認証を使用してサーバーからファイルを要求した場合、サーバーではクライアントに対してダイジェスト資格情報を要求します。HTTP 1.1.非準拠のクライアントではダイジェスト認証がサポートされないため、この要求を拒否します。

高度ダイジェスト認証の要件

IIS サーバーで高度ダイジェスト認証を有効にする前に、次の最低要件がすべて満たされていることを確認します。ドメイン管理者のみが、ドメイン コントローラ (DC) 要件が満たされていることを確認できます。DC が次の要件を満たしているかどうか不明である場合、ドメイン管理者に問い合わせてください。

重要   高度ダイジェスト認証は、DC および IIS サーバーの両方で Windows XP が実行されている場合にのみ有効です。DC または IIS サーバーのどちらかで Windows 2000 以前が実行されている場合、IIS ではユーザーに警告することなく既定でダイジェスト認証になります。

クライアント認証プロセス

次の手順では、高度ダイジェスト認証を使用したクライアント認証の概要を示します。

ダイジェスト認証のクライアント認証

  1. クライアントが IIS サーバーのファイルを要求します。
  2. IIS サーバーは最初の要求を拒否し、クライアントに次の情報を送信します。
  3. Internet Explorer では、ユーザーに資格情報 (ユーザー名とパスワード) の入力が要求されます。資格情報は領域名と結合され、MD5 ハッシュが作成されます。今回は HTTP 要求のヘッダー内で MD5 ハッシュが送信され、IIS サーバーに対してファイル要求を再発行します。
  4. IIS サーバーがクライアントのハッシュを受信し、確認のためにドメイン コントローラに送信します。
  5. ドメイン コントローラでは、クライアントのハッシュが Active Directory に格納されているコピーと比較されます。ハッシュ値が一致した場合、ドメイン コントローラでは、IIS サーバーにクライアントが認証されたことを通知します。
  6. IIS サーバーは要求されたファイルをクライアントに送信します。

   手順 2. では、IIS サーバーからクライアント (Internet Explorer) に、高度ダイジェスト認証ではなくダイジェスト認証が使用されていることを通知します。これは、ダイジェスト認証と高度ダイジェスト認証の両方とも、IIS サーバーとクライアント間で同一のダイジェスト認証アルゴリズムが使用されているためです。

統合 Windows 認証

統合 Windows 認証は、ユーザー名およびパスワードがハッシュ化されてからネットワーク上で転送される安全な認証形式です。以前は、"NTLM" または "Windows NT チャレンジ/レスポンス認証" と呼ばれていました。統合 Windows 認証を有効にした場合、ユーザーのブラウザは、ハッシングを使用して Web サーバーと暗号化された情報を交換し、パスワードを知っていることを証明します。

統合 Windows 認証では、Kerberos v5 認証と NTLM 認証が使用されます。Active Directory サービスが Windows 2000 以降のドメイン コントローラにインストールされており、ユーザーのブラウザで Kerberos v5 認証プロトコルがサポートされる場合、Kerberos v5 認証が使用されます。それ以外の場合は、NTLM 認証が使用されます。

Kerberos v5 認証プロトコルは、Windows 2000 の分散サービス アーキテクチャの一機能です。Kerberos v5 認証が機能するには、クライアントとサーバーの両方にキー配布センター (KDC) への信頼された接続があり、ディレクトリ サービスとの互換性があることが必要です。Kerberos および NTLM の詳細については、Windows XP オンライン マニュアルを参照してください。

統合 Windows 認証プロセス

次の手順は、統合 Windows 認証を使用したクライアント認証の概要を示しています。
  1. 基本認証とは異なり、統合 Windows 認証では、最初にユーザー名とパスワードの入力を要求しません。統合 Windows 認証では、クライアント コンピュータ上にある最新の Windows ユーザー情報が使用されます。
  2.    Internet Explorer Version 4.0 以降では、必要に応じて最初にユーザー情報の入力を要求するように構成できます。詳細については、Internet Explorer のマニュアルを参照してください。

  3. 最初に認証処理がユーザーの識別に失敗した場合、ブラウザはユーザーに対して Windows ユーザー アカウントのユーザー名とパスワードの入力を要求します。入力された情報は、統合 Windows 認証によって処理されます。
  4. Internet Explorer は、ユーザーが有効なユーザー名とパスワードを入力するか、またはダイアログ ボックスを閉じるまで、ユーザーに繰り返し入力を要求します。

統合 Windows 認証は安全な認証ですが、制限が 2 つあります。

  1. Internet Explorer Version 2.0 以降でのみ、この認証方式をサポートしています。
  2. 統合 Windows 認証は、HTTP プロキシ接続では機能しません。

このため、統合 Windows 認証は、イントラネット環境で使用することをお勧めします。イントラネット環境の場合、ユーザーのコンピュータと Web サーバー コンピュータは同じドメイン内にあり、管理者は、すべてのユーザーが Microsoft Internet Explorer Version 2.0 以降を使用していることを確認できます。

証明書認証

Web サーバーの Secure Sockets Layer (SSL) セキュリティ機能を 2 種類の認証に対して使用することもできます。"サーバー証明書" を使用すると、クレジット カード番号などの個人的な情報を転送する前のユーザーによる Web サイトの認証が可能になります。また、"クライアント証明書" を使用して、Web サイトの情報を要求しているユーザーを認証することもできます。SSL では、ログオン処理中にユーザーの Web ブラウザから送られる、暗号化されたデジタル識別情報の内容を確認することで認証が行われます。(クライアント証明書は、信頼できる第三者機関から取得します。)サーバー証明書には、通常 Web サイトや証明書を発行した組織についての情報が含まれています。クライアント証明書には、通常ユーザーや証明書を発行した組織についての識別情報が含まれています。詳細については、「証明書について」を参照してください。

クライアント証明書のマッピング

Windows ユーザー アカウントは、ファイルなどのリソースへアクセスするときに必要なので、クライアント証明書を Web サーバー上の Windows ユーザー アカウントに関連付ける、すなわち "マップ" することができます。証明書マップを作成して有効にすると、ユーザーがクライアント証明書を使ってログオンするたびに、Web サーバーはそのユーザーを適切な Windows アカウントに自動的に関連付けます。この方法では、クライアント証明書を使ってログオンするユーザーを、基本認証、ダイジェスト認証、または統合 Windows 認証のいずれも使わずに、自動的に認証できます。1 つのクライアント証明書を 1 つの Windows ユーザー アカウントにマップすることも、複数のクライアント証明書を 1 つのアカウントにマップすることもできます。たとえば、サーバー上に独自の Web サイトを所有している複数の部門または業務がある場合、多対一のマッピングを使用して、各部門または企業のすべてのクライアント証明書を独自の Web サイトにマップすることができます。この方法では、各サイトは関連付けられているクライアントにのみアクセスを提供します。詳細については、「ユーザー アカウントにクライアント証明書をマップする」を参照してください。

FTP 認証

匿名 FTP 認証

FTP サーバーを構成して、FTP リソースへの匿名アクセスを許可できます。リソースに対して匿名 FTP 認証を選択すると、そのリソースに対するすべての要求は、ユーザーにユーザー名やパスワードの入力を要求することなく、受け付けられます。これは、IIS によって、IUSR_computername と呼ばれる Windows ユーザー アカウントが自動的に作成されるためです。 computername は、IIS を実行しているサーバー名です。匿名 FTP 認証は Web ベースの匿名認証と似ています。匿名 FTP 認証が有効な場合、基本 FTP 認証が使用可能な場合でも、IIS は常にこの認証方式を最初に使用します。詳細については、「匿名認証」を参照してください。

基本 FTP 認証

基本 FTP 認証を使用して Web サーバーへの FTP 接続を確立するには、ユーザーは有効な Windows ユーザー アカウントに対応するユーザー名とパスワードを使用してログオンする必要があります。FTP サーバーがユーザーを識別できない場合、サーバーはエラー メッセージを返します。FTP 認証では、ユーザーはパスワードとユーザー名を暗号化されていない形式でネットワークに転送するため、安全ではありません。詳細については、「アクセス制御について」を参照してください。


© 1997-2001 Microsoft Corporation.All rights reserved.