次の方法で共有

認証について

  • [アーティクル]

認証について

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

WWW 方式

  • 匿名認証
  • 基本認証
  • ダイジェスト認証
  • 統合 Windows 認証
  • 証明書認証

FTP 方式

  • 匿名 FTP 認証
  • 基本 FTP 認証

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

認証方式の概要

認証方法 セキュリティ レベル サーバー要件 クライアント要件 コメント
匿名認証 なし IUSR_computername アカウント。 ブラウザ インターネット サイトの公開領域で使用されます。
基本認証 低 有効なアカウント。 ユーザー名とパスワードの入力 パスワードは暗号化されずに転送されます。
ダイジェスト認証 高 パスワードのテキスト形式のコピー。有効なアカウント。 互換性 プロキシ サーバーとその他のファイアウォールとの間で使用可能です。
統合 Windows 認証 高 有効なアカウント。 ブラウザのサポート イントラネットの専用領域で使用します。
証明書認証 高 サーバーの証明書を取得します。初回のみ、証明書信頼リスト (CTL) を構成します。 ブラウザのサポート インターネットで安全に取引を行うために広く使用されています。
匿名 FTP 認証 なし IUSR_computername アカウント。 なし 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 アカウントは、コンピュータの Guests グループに追加されます。
  2. IIS は要求を受け取ると、コードを実行したりファイルにアクセスしたりする前に、IUSR_computername アカウントを偽装します。IIS では IUSR_computername アカウントのユーザー名およびパスワードが分かっているため、このアカウントを偽装することができます。
  3. IIS は、IUSR_computername アカウントがファイルへのアクセスを許可されているかどうかを調べるために、NTFS ファイルおよびディレクトリのアクセス権を確認してから、ページをクライアントに返します。
  4. アクセスが許可されている場合、認証は完了し、ユーザーはリソースを使用できます。
  5. アクセスが許可されていない場合、IIS は別の認証方式を試します。別の認証方式が選択されていない場合は、"HTTP 403 Access Denied" というエラー メッセージがブラウザに返されます。

注

  • 匿名認証が使用できる場合、ほかの認証方法が使用可能であっても、IIS は常に匿名認証を最初に使用して認証を試みます。
  • ユーザーに対して、ユーザー名とパスワードの入力を要求する場合もあります。

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

注   Active Directory Service Interface (ADSI) を使用して、ローカル ログオン権限の条件を変更できます。「Active Server Pages ガイド」の「LogonMethod」を参照してください。

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

重要   IUSR_computername アカウントを変更すると、Web サーバー上で提供されている "すべて" の匿名 HTTP 要求に影響します。このアカウントを変更する際は、注意が必要です。

基本認証

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

  1. ユーザーの Web ブラウザにダイアログ ボックスが表示されます。事前に割り当てられた Windows 2000 アカウントのユーザー名とパスワードをダイアログ ボックスに入力します。
  2. Web ブラウザは入力された情報を使用して接続の確立を試みます。(パスワードは、ネットワークへ送られる前に Base64 形式でエンコードされます。)
  3. サーバーがその情報を受け付けない場合は、ユーザーが有効なユーザー名とパスワードを入力するか、またはダイアログ ボックスを閉じるまで、Web ブラウザはユーザーに繰り返し入力を要求します。
  4. Web サーバーによってユーザー名とパスワードが有効な Windows  ユーザー アカウントと一致することが確認されると、接続が確立されます。

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

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

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

ダイジェスト認証

IIS 5.0 の新機能であるダイジェスト認証は、基本認証と同じ機能を提供しますが、認証資格情報の転送方法が異なります。認証資格情報は、一般に "ハッシング" と呼ばれる一方向プロセスを通して送られます。このプロセスの結果は "ハッシュ" または "メッセージ ダイジェスト" と呼ばれ、解読することができません。つまり、元のテキストをハッシュから解読することはできません。

ダイジェスト認証は次のように行われます。

  1. サーバーは、認証プロセスで使用される所定の情報をブラウザに送ります。
  2. ブラウザはこの情報を、ユーザー名とパスワード、およびその他の情報に付加してから、ハッシングを行います。情報を付加することで、ほかのユーザーがハッシュ値をコピーしてハッシュ値を再使用するのを防ぐことができます。
  3. 生成されたハッシュは、クリア テキストの追加情報と共にネットワークを介してサーバーに送られます。
  4. サーバーは、サーバーにあるクライアントのパスワードのテキスト形式コピーに追加情報を付加してから、情報全体に対してハッシングを行います。
  5. サーバーは、クライアントから受け取ったハッシュ値とサーバーで生成したハッシュ値を比較します。
  6. アクセスは、2 つのハッシュ値が完全に一致した場合にのみ許可されます。

ほかのユーザーがパスワードのハッシュを傍受し、それを使用して本物のクライアントであるかのように偽装することがないように、追加情報は、ハッシングの直前にパスワードに付加されます。クライアント、クライアントのコンピュータ、およびクライアントが属する領域またはドメインを識別するための値が付加されます。また、パスワードが無効になった後にそれが使用されることを防ぐために、タイム スタンプも付加されます。

権限のないユーザーにパスワードが傍受されて使用される可能性がある基本認証と比べて、このダイジェスト認証には、明らかに利点があります。ダイジェスト認証は、プロキシ サーバーおよびその他のファイアウォール アプリケーション間で使用するように構成されています。また、WebDAV (Web Distributed Authoring and Versioning) で使用することもできます。ダイジェスト認証は、新しい HTTP 1.1 の機能であるため、すべてのブラウザでサポートされているとは限りません。ダイジェスト認証に対応していないブラウザが、ダイジェスト認証が必要なサーバーに要求を行った場合、サーバーは要求を拒否し、クライアントにエラー メッセージを返します。ダイジェスト認証は、Windows 2000 ドメイン コントローラを備えているドメインでのみサポートされます。

重要   ダイジェスト認証は、要求先のドメイン サーバーに、要求元のユーザーのパスワードのテキスト形式コピーがある場合のみ行われます。ドメイン コントローラはパスワードのテキスト形式コピーを格納しているため、物理的な不正アクセスとネットワーク上の不正アクセスの両方から保護されている必要があります。ドメイン コントローラの保護の詳細については、『Microsoft Windows 2000 Server リソース キット』を参照してください。

注   ハッシュ値は、通常は 160 ビット以下の 2 進データによって構成されています。この値は、"ハッシング アルゴリズム" によって生成されます。すべてのハッシュ値には、使用するアルゴリズムに関係なく、次の共通した特性があります。

  • ハッシュ長 ハッシュ値の長さは、使用するアルゴリズムによって決まります。ハッシュ値の長さがメッセージのサイズによって変化することはありません。メッセージが数キロバイトまたは数ギガバイトでも、ハッシュ値の長さは同じです。最も一般的なハッシュ値の長さは、128 ビットまたは 160 ビットです。
  • 発見不可能 2 つのメッセージに 1 ビットでも 違いがあれば、まったく異なる 2 つのハッシュ値に変換されます。現在の技術では、同じハッシュ値に変換されるメッセージを発見することはできません。
  • 再現可能 同じアルゴリズムを使用して特定のメッセージのハッシュを行うと、常にまったく同じハッシュ値が生成されます。
  • 逆変換不可能 すべてのハッシング アルゴリズムは一方向です。ハッシュ値から元のメッセージを復元することはできません。使用したハッシング アルゴリズムを使用しても、復元は不可能です。ハッシュ値のみでは、元のメッセージのプロパティを特定することもできません。

統合 Windows 認証

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

統合 Windows 認証では、Kerberos Version 5 認証プロトコルと、独自のチャレンジ/レスポンス認証プロトコルの両方を使用できます。サーバーにディレクトリ サービスがインストールされていて、ブラウザに Kerberos v5 認証プロトコルとの互換性がある場合、Kerberos v5 認証プロトコルとチャレンジ/レスポンス プロトコルの両方が使用されます。その他の場合は、チャレンジ/レスポンス プロトコルのみが使用されます。

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

統合 Windows 認証は次のように行われます。

  1. 基本認証とは異なり、最初にユーザー名とパスワードの入力を要求しません。統合 Windows 認証では、クライアント コンピュータ上にある最新の Windows ユーザー情報が使用されます。

    注   Internet Explorer Version 4.0 以降では、必要に応じて最初にユーザー情報の入力を要求するように構成できます。詳細については、Internet Explorer のマニュアルを参照してください。

  2. 最初に認証処理がユーザーの識別に失敗した場合、ブラウザはユーザーに対して Windows ユーザー アカウントのユーザー名とパスワードの入力を要求します。入力された情報は、統合 Windows 認証によって処理されます。

  3. Internet Explorer は、ユーザーが有効なユーザー名とパスワードを入力するか、またはダイアログ ボックスを閉じるまで、ユーザーに繰り返し入力を要求します。

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

  1. この認証方式は、Microsoft 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 サイトや証明書を発行した組織についての情報が含まれています。クライアント証明書には、通常ユーザーや証明書を発行した組織についての識別情報が含まれています。詳細については、「証明書について」を参照してください。

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

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

FTP 認証

匿名 FTP 認証

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

基本 FTP 認証

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