IIS はブラウザー クライアントを認証します

この記事では、IIS がブラウザー クライアントを認証する方法について説明します。

元の製品バージョン:インターネット エクスプローラー
元の KB 番号: 264921

概要

この記事では、WINDOWS NT 4.0、Windows 2000 以降の Windows バージョンで IIS で使用できるさまざまな認証方法について説明します。 この記事で説明する情報の詳細については、「Windows NT 4.0 および Windows 2000 リソース ガイド」を参照してください。

Windows NT 4.0 で使用できる認証方法

匿名 - ログオンは必要なく、このメソッドで保護されているデータへのアクセスは誰でも許可されます。 サーバーは、組み込みのアカウント (既定では IUSR_[コンピューター名]) を使用して、ファイルに対するアクセス許可を制御します。 ブラウザーは、この種類の要求で資格情報やユーザー情報を送信しません。

  • サポートされているブラウザー: 任意
  • 制限事項: なし
  • [ユーザー権限が必要]: サーバーで定義されている匿名ユーザー アカウントには、 ローカルアクセス許可のログオンが 必要です。
  • 暗号化の種類: なし

基本 (クリア テキスト) - サーバーはユーザーにログオンを要求し、必要な資格情報を入力できるダイアログ ボックスがブラウザーに表示されます。 これらの資格情報は、ユーザーがアクセスしようとしているファイルで定義されているユーザー資格情報と一致する必要があります。

  • サポートされているブラウザー: 任意
  • 制限事項: セキュリティで保護されていません。 パスワードは簡単に解読できます。
  • [ユーザー権限が必要]: ユーザー アカウントには ローカルアクセス許可のログオンが 必要です。
  • 暗号化の種類: Base 64 Encoding (true 暗号化ではない)

Windows NTチャレンジ/応答 - サーバーはユーザーにログオンを要求します。 ブラウザーがチャレンジ/応答Windows NTサポートしている場合、ユーザーがログオンしている場合、ユーザーの資格情報が自動的に送信されます。 ユーザーがオンになっているドメインがサーバーのドメインと異なる場合、またはユーザーがログオンしていない場合は、資格情報の送信を要求するダイアログ ボックスが表示されます。 Windows NTチャレンジ/応答では、アルゴリズムを使用して、ユーザーの資格情報とユーザーが使用しているコンピューターに基づいてハッシュを生成します。 次に、このハッシュをサーバーに送信します。 ブラウザーは、ユーザーのパスワードをサーバーに送信しません。

  • サポートされているブラウザー: インターネット エクスプローラー バージョン 3.01 以降

  • 制限事項: ポイントツーポイント接続が必要です。 通常、回線は "401 未承認" エラー メッセージの後に閉じられます。ただし、Windows NTチャレンジ/応答認証シーケンス (複数のラウンド トリップが必要) をネゴシエートする場合、クライアントがチャレンジ/応答を使用することをクライアントが示した後も、サーバーは回線 Windows NTを開いたままにします。 CERN プロキシやその他の特定のインターネット デバイスでは、これが機能しなくなります。 また、Windows NTチャレンジ/応答では、ダブルホップの偽装はサポートされていません (IIS サーバーに渡されると、認証のために同じ資格情報をバックエンド サーバーに渡すことはできません)。

  • ユーザー権限が必要: サーバーにアクセスするユーザー アカウントには、"ネットワークからこのコンピューターにアクセスする" アクセス許可が必要です。

  • 暗号化の種類: コード化されていない NTLM ハッシュ アルゴリズム。

優先順位: ブラウザーが要求を行うと、最初の要求は常に匿名と見なされます。 そのため、資格情報は送信されません。 サーバーが匿名を受け入れない場合、またはサーバーに設定されている匿名ユーザー アカウントに要求されているファイルに対するアクセス許可がない場合、IIS サーバーは アクセス拒否 エラー メッセージで応答し、次のいずれかのシナリオを使用してサポートされている認証の種類の一覧を送信します。

  • Windows NTチャレンジ/応答がサポートされている唯一のメソッドである場合 (または匿名が失敗した場合)、ブラウザーはサーバーと通信するためにこのメソッドをサポートする必要があります。 そうしないと、サーバーとネゴシエートできず、ユーザーは アクセス拒否 エラー メッセージを受け取ります。
  • Basic が唯一サポートされているメソッドの場合 (または匿名が失敗した場合)、ブラウザーに資格情報を取得するためのダイアログ ボックスが表示され、これらの資格情報がサーバーに渡されます。 これらの資格情報を最大 3 回送信しようとします。 これらすべてが失敗した場合、ブラウザーはサーバーに接続されません。
  • Basic と Windows NT Challenge/Response の両方がサポートされている場合は、使用するメソッドがブラウザーによって決定されます。 ブラウザーがチャレンジ/応答Windows NTサポートしている場合は、このメソッドを使用し、Basic にフォールバックしません。 チャレンジ/応答Windows NTサポートされていない場合、ブラウザーは Basic を使用します。

注:

  • ブラウザーで、または NTLM 認証を使用Basicして Web サイトとの接続を確立しても、サーバーとのそのセッションの残りの期間は匿名にフォールバックしません。 認証後にのみ匿名としてマークされている Web ページに接続しようとすると、拒否されます。 (Netscape の場合、これは true である場合と保持されない場合があります)。
  • インターネット エクスプローラーが、または NTLM 認証を使用Basicしてサーバーとの接続を確立すると、セッションの間、新しい要求ごとに資格情報が渡されます。

Windows 2000 以降で使用できる認証方法

匿名 - ログオンは必要なく、このメソッドで保護されたデータへのアクセスは誰でも許可されます。 サーバーは、組み込みのアカウント (既定では IUSR_[コンピューター名]) を使用して、ファイルに対するアクセス許可を制御します。 ブラウザーは、この種類の要求で資格情報やユーザー情報を送信しません。

  • サポートされているブラウザー: 任意
  • 制限事項: なし
  • ユーザー権限が必要: サーバーで定義されている匿名ユーザー アカウントには、"ローカルログオン" アクセス許可が必要です。
  • 暗号化の種類: なし

基本 (クリア テキスト) - サーバーはユーザーにログオンを要求し、必要な資格情報を入力できるダイアログ ボックスがブラウザーに表示されます。 これらの資格情報は、ユーザーがアクセスしようとしているファイルで定義されているユーザー資格情報と一致する必要があります。

  • サポートされているブラウザー: 任意
  • 制限事項: セキュリティで保護されていません。 パスワードは簡単に解読できます。
  • ユーザー権限が必要: ユーザー アカウントには ローカルでのログオン権限が 必要です
  • 暗号化の種類: Base 64 Encoding (true 暗号化ではない)

ダイジェスト - サーバーはユーザーにログオンを要求し、パスワードの暗号化に使用される NONCE も送信します。 ブラウザーは NONCE を使用してパスワードを暗号化し、これをサーバーに送信します。 その後、サーバーはユーザーのパスワードの独自のコピーを暗号化し、2 つを比較します。 一致し、ユーザーにアクセス許可がある場合は、アクセス権が付与されます。

  • サポートされているブラウザー: インターネット エクスプローラー 5 以降のバージョン
  • 制限事項: 統合ほど安全ではありません。 ダイジェスト認証用に設定されている Active Directory サーバーへのアクセス権をサーバーに付与する必要があります。
  • ユーザー権限が必要: パスワードに "暗号化されたクリア テキストとしてパスワードを保存する" が必要です
  • 暗号化の種類: サーバーによって送信される NONCE に基づいています。

Windows 統合 (2 つのサブカテゴリに分割)

Kerberos - サーバーはユーザーにログオンを要求します。 ブラウザーで Kerberos がサポートされている場合は、次の処理が行われます。

  • IIS は認証を要求します。
  • クライアントがドメインにログオンしていない場合は、資格情報を要求エクスプローラーインターネットにダイアログ ボックスが表示され、KDC に連絡してチケット許可チケットを要求して受信します。 その後、チケット許可チケットと IIS サーバーに関する情報が KDC に送信されます。
  • IE クライアントが既にドメインにログインし、チケット許可チケットを受け取った場合、IIS サーバーに関する情報と共にこのチケットを KDC に送信します
  • KDC はクライアントにリソース チケットを発行します。
  • クライアントはこのチケットを IIS サーバーに渡します。

Kerberos は、チケット許可サーバー (KDC) で生成されたチケットを使用して認証します。 このチケットは IIS サーバーに送信されます。 ブラウザーは、ユーザーのパスワードをサーバーに送信しません。

  • サポートされているブラウザー: インターネット エクスプローラー バージョン 5.0 以降
  • 制限事項: サーバーは Active Directory サーバーにアクセスできる必要があります。 サーバーとクライアントの両方に KDC への信頼された接続が必要です。
  • ユーザー権限が必要: サーバーで定義されている匿名ユーザー アカウントには、 ローカルアクセス許可にログオンしている 必要があります。
  • 暗号化の種類: 暗号化されたチケット。

Windows NTチャレンジ/応答 - サーバーはユーザーにログオンを要求します。 ブラウザーがチャレンジ/応答Windows NTサポートしている場合、ユーザーがログオンしている場合、ユーザーの資格情報が自動的に送信されます。 ユーザーがオンになっているドメインがサーバーのドメインと異なる場合、またはユーザーがログオンしていない場合は、資格情報の送信を要求エクスプローラーインターネットにダイアログ ボックスが表示されます。 Windows NTチャレンジ/応答では、アルゴリズムを使用して、ユーザーの資格情報とユーザーが使用しているコンピューターに基づいてハッシュを生成します。 次に、このハッシュをサーバーに送信します。 ブラウザーは、ユーザーのパスワードをサーバーに送信しません。

  • サポートされているブラウザー: インターネット エクスプローラー バージョン 3.01 以降。
  • 制限事項: ポイントツーポイント接続が必要です。 通常、回線は "401 未承認" エラー メッセージの後に閉じられます。ただし、Windows NTチャレンジ/応答認証シーケンス (複数のラウンド トリップが必要) をネゴシエートする場合、クライアントがチャレンジ/応答を使用することをクライアントが示した後も、サーバーは回線 Windows NTを開いたままにします。 CERN プロキシやその他の特定のインターネット デバイスでは、これが機能しなくなります。 また、Windows NTチャレンジ/応答では、ダブルホップの偽装はサポートされていません (つまり、IIS サーバーに渡されると、認証のために同じ資格情報をバックエンド サーバーに渡すことはできません(たとえば、IIS で Windows NT Challenge/Response を使用する場合、SQL 統合セキュリティを使用して別のコンピューター上のSQL Server データベースに対してユーザーを認証することはできません)。
  • ユーザー権限が必要: サーバーにアクセスするユーザー アカウントには、"ネットワークからこのコンピューターにアクセスする" アクセス許可が必要です。
  • 暗号化の種類: コード化されていない NTLM ハッシュ アルゴリズム。

優先順位: ブラウザーが要求を行うと、最初の要求は常に匿名と見なされます。 そのため、資格情報は送信されません。 サーバーが匿名を受け入れない場合、またはサーバーに設定されている匿名ユーザー アカウントに要求されているファイルに対するアクセス許可がない場合、IIS サーバーは アクセス拒否 エラー メッセージで応答し、次のいずれかのシナリオを使用してサポートされている認証の種類の一覧を送信します。

  • Windows Integrated がサポートされている唯一の方法である場合 (または匿名が失敗した場合)、ブラウザーはサーバーと通信するためにこのメソッドをサポートする必要があります。 これが失敗した場合、サーバーは他の方法を試しません。
  • Basic がサポートされている唯一のメソッド (または匿名が失敗した場合) の場合は、 に資格情報を取得するためのダイアログ ボックスが表示され、これらをサーバーに渡します。 資格情報の送信が最大 3 回試行されます。 これらすべてが失敗した場合、ブラウザーはサーバーに接続しません。
  • Basic と Windows Integrated の両方がサポートされている場合、ブラウザーによって使用されるメソッドが決定されます。 ブラウザーが Kerberos またはチャレンジ/応答Windows NTサポートしている場合は、このメソッドを使用します。 Basic にフォールバックしません。 チャレンジ/応答Windows NT Kerberos がサポートされていない場合、ブラウザーでは Basic、Digest、または Fortezza が使用されます (サポートされている場合)。 ここでの優先順位は、Basic、Digest、および Fortezza です。

注:

  • ブラウザーが Basic 認証または Windows 統合認証を使用して Web サイトとの接続を確立しても、サーバーとのそのセッションの残りの期間は匿名にフォールバックしません。 認証後にのみ匿名としてマークされている Web ページに接続しようとすると、拒否されます。 (Netscape の場合、これは true である場合と保持されない場合があります)。
  • インターネット エクスプローラーが Anonymous 以外の認証方法を使用してサーバーとの接続を確立すると、セッションの実行中に新しい要求ごとに資格情報が自動的に渡されます。

関連情報

Windows Server 2003 で IIS Web サイト認証を構成する方法の詳細については、「Windows Server 2003 で IIS Web サイト認証を構成する方法」を参照してください。