[INFO] IIS におけるブラウザ クライアントの認証方法

この資料では、IIS で利用できる各種の認証方法を、Windows NT 4.0 と Windows 2000 の両方について説明します。この資料に記載されている情報に関してより詳細な説明が必要な場合は、Windows NT 4.0 および Windows 2000 の『リソース ガイド』を参照してください。

Windows NT 4.0 で利用可能な認証方法

匿名認証 - ログオンする必要がなく、この方法で保護されたデータにはだれでもアクセスできます。サーバーは、ビルトイン アカウント (既定では IUSR_computer name) を使用してファイルのアクセス許可を制御します。この種類の要求では、ブラウザから資格情報やユーザー情報が送信されることはありません。

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

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

• サポートされるブラウザ : すべて。
• 制限 : セキュリティはそれほど高くありません。パスワードの解読は簡単です。
• 必要なユーザー権利 : ユーザー アカウントに "ローカル ログオン" のアクセス許可が必要です。
• 暗号化の種類 : Base 64 エンコード (本当の暗号化ではありません)。

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

• サポートされるブラウザ : Internet Explorer 3.01 以降。
• 制限 : ポイント ツー ポイント接続が必要です。通常、"401 権限がありません" というエラー メッセージの後には回線が切断されますが、複数のラウンド トリップが必要な NTLM 認証シーケンスをネゴシエートする場合は、クライアントによって NTLM 認証を使用することが決定されてから認証シーケンスが完了するまでの間、サーバーの回線は開かれたままになります。この動作は、CERN プロキシやその他のインターネット デバイスによって妨げられることがあります。また、NTLM 認証では、ダブルホップ偽装はサポートされていません (つまり、いったん IIS サーバーに渡された資格情報を、そのままバックエンド サーバーに渡して認証することはできません)。
• 必要なユーザー権利 : サーバーにアクセスするユーザー アカウントに、"ネットワーク経由でコンピュータへアクセス" のアクセス許可が必要です。
• 暗号化の種類 : NTLM ハッシュ アルゴリズム。さらに UUENCODE 形式でエンコードされます。

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

• サポートされている認証方法が NTLM 認証のみの場合 (または匿名認証に失敗した場合) は、この方法によるサーバーとの通信がブラウザでサポートされている必要があります。そうでない場合は、サーバーとのネゴシエートができず、"アクセスが拒否されました" というエラー メッセージがユーザーに返されます。
• サポートされている認証方法が基本認証のみの場合 (または匿名認証に失敗した場合) は、資格情報を取得するためのダイアログ ボックスがブラウザに表示され、ここで入力された資格情報がサーバーに渡されます。これらの資格情報の送信は 3 回まで試行されます。3 回とも失敗すると、ブラウザからサーバーへの接続は確立されません。
• 基本認証と NTLM 認証の両方がサポートされている場合、使用される認証方法はブラウザによって決定します。ブラウザで NTLM 認証がサポートされていれば NTLM 認証が使用され、NTLM 認証に失敗しても基本認証に切り替えられることはありません。ブラウザで NTLM 認証がサポートされていない場合は、基本認証が使用されます。

注

• ブラウザで基本認証または NTLM 認証を使用して Web サイトとの接続を確立した場合、そのサーバーとの接続確立後のセッションにおいて、匿名認証への切り替えが発生することはありません。認証後、匿名認証でのみアクセス可能な Web ページにアクセスすると、アクセスは拒否されます (Netscape では、拒否される場合と拒否されない場合があります)。
• Internet Explorer では、基本認証または NTLM 認証を使用してサーバーとの接続を確立すると、そのセッションが継続している間、新しい要求ではすべて自動的に同じ資格情報が渡されます。

Windows 2000 で利用可能な認証方法

匿名認証 - ログオンする必要がなく、この方法で保護されたデータにはだれでもアクセスできます。サーバーは、ビルトイン アカウント (既定では IUSR_computer name) を使用してファイルのアクセス許可を制御します。この種類の要求では、ブラウザから資格情報やユーザー情報が送信されることはありません。

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

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

• サポートされるブラウザ : すべて。
• 制限 : セキュリティはそれほど高くありません。パスワードの解読は簡単です。
• 必要なユーザー権利 : ユーザー アカウントに "ローカル ログオン" のアクセス許可が必要です。
• 暗号化の種類 : Base 64 エンコード (本当の暗号化ではありません)。

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

• サポートされるブラウザ : Internet Explorer 5.0 のみ。
• 制限 : セキュリティは統合認証ほど高くありません。ダイジェスト認証用にセットアップされた Active Directory サーバーに、IIS サーバーからアクセスできる必要があります。
• 必要なユーザー権利 : アカウント オプションで [暗号化を元に戻せる状態でパスワードを保存する] チェック ボックスがオンになっている必要があります。
• 暗号化の種類 : サーバーから送信された NONCE に基づきます。

関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。 Fortezza - IIS 5.0 で Fortezza セキュリティを使用するには、http://www.spyrus.com/ などの Fortezza プロバイダから、適切な暗号化 API サービス プロバイダ (CSP) ファイルを入手する必要があります。

Windows 統合認証 (2 つに分類されます)
Kerberos 認証 - サーバーからユーザーのログオンが要求されます。ブラウザで Kerberos 認証がサポートされていると、次の処理が実行されます。

• IIS から認証が要求されます。
• クライアントがドメインにログオンしていない場合は、資格情報を要求するダイアログ ボックスが Internet Explorer に表示されます。クライアントは KDC (Key Distribution Center : キー配布センター) に接続し、TGT (Ticket-Granting Ticket : チケット保証チケット) を要求して取得します。その後、TGT と IIS サーバーに関する情報がクライアントから KDC に送信されます。
• IE クライアントが既にドメインにログインしていて、TGT を受け取っている場合は、そのチケットが IIS サーバーに関する情報と共に KDC に送信されます。
• KDC からクライアントにリソース チケットが発行されます。
• クライアントはこのチケットを IIS サーバーに渡します。

Kerberos では、TGS (Ticket-Granting Service : チケット保証サービス) で生成されたチケットを使用して認証が行われます。このチケットは IIS サーバーに送信されます。ブラウザからサーバーにユーザーのパスワードが送信されることはありません。

• サポートされるブラウザ : Internet Explorer 5.0 以降。
• 制限 : サーバーから Active Directory サーバーにアクセスできる必要があります。また、サーバーとクライアントの両方において、KDC への信頼関係接続が定義されている必要があります。
• 必要なユーザー権利 : サーバー上に定義されている Anonymous ユーザー アカウントに、"ローカル ログオン" のアクセス許可が必要です。
• 暗号化の種類 : 暗号化されたチケット。

Microsoft 暗号化認証 - サーバーからユーザーのログオンが要求されます。Microsoft 暗号化認証をサポートするブラウザでは、ユーザーがログオンしていれば、そのユーザーの資格情報が自動的に送信されます。ログオン中のユーザーのドメインがサーバーのドメインと異なる場合、またはユーザーがログオンしていない場合は、送信する資格情報を要求するダイアログ ボックスが Internet Explorer に表示されます。Microsoft 暗号化認証では、ユーザーの資格情報およびユーザーが使用しているコンピュータに基づいてハッシュを生成するアルゴリズムが使用されます。このハッシュがサーバーに送信されます。ブラウザからサーバーにユーザーのパスワードが送信されることはありません。

• サポートされるブラウザ : Internet Explorer 3.01 以降。
• 制限 : ポイント ツー ポイント接続が必要です。通常、"401 権限がありません" というエラー メッセージの後には回線が切断されますが、複数のラウンド トリップが必要な Microsoft 暗号化認証シーケンスをネゴシエートするときは、クライアントによって Microsoft 暗号化認証を使用することが決定されてから認証シーケンスが完了するまでの間、サーバーの回線は開かれたままになります。この動作は、CERN プロキシやその他のインターネット デバイスによって妨げられることがあります。また、Microsoft 暗号化認証では、ダブルホップの偽装はサポートされていません (つまり、いったん IIS サーバーに渡された資格情報を、バックエンド サーバーに渡して認証することはできません。たとえば、IIS で Microsoft 暗号化認証を使用した後、別のコンピュータにある SQL Server データベースに対し、同じユーザーを SQL 統合セキュリティによって認証することはできません)。
• 必要なユーザー権利 : サーバーにアクセスするユーザー アカウントに、"ネットワーク経由でコンピュータへアクセス" 　のアクセス許可が必要です。
• 暗号化の種類 : NTLM ハッシュ アルゴリズム。さらに UUENCODE 形式でエンコードされます。

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

• サポートされている認証方法が Windows 統合認証のみの場合 (または匿名認証に失敗した場合) は、この方法によるサーバーとの通信がブラウザでサポートされている必要があります。サーバーは、まず Kerberos による認証を試行し、Kerberos 認証が失敗した場合、Microsoft 暗号化認証に切り替えます。この認証方法が失敗しても、他の方法は試行されません。
• サポートされている認証方法が基本認証のみの場合 (または匿名認証に失敗した場合) は、資格情報を取得するためのダイアログ ボックスが表示され、ここで入力された情報がサーバーに渡されます。資格情報の送信は 3 回まで試行されます。3 回とも失敗すると、ブラウザからサーバーへの接続は確立されません。
• 基本認証と Windows 統合認証の両方がサポートされている場合、使用される認証方法はブラウザによって決定します。ブラウザで Kerberos 認証または Microsoft 暗号化認証がサポートされていれば、そのサポートされている方法が使用されます。Kerberos 認証または Microsoft 暗号化認証に失敗しても、基本認証に切り替えられることはありません。Microsoft 暗号化認証と Kerberos 認証がサポートされていない場合は、基本認証、ダイジェスト認証、Fortezza のうち、ブラウザでサポートされている方法が使用されます。この場合の優先順位は、基本認証、ダイジェスト認証、Fortezza の順です。

注

• ブラウザで Windows 統合認証を使用して Web サイトへの接続を確立した場合、そのサーバーとの接続確立後のセッションにおいて、匿名認証への切り替えが発生することはありません。認証後、匿名認証でのみアクセス可能な Web ページにアクセスすると、アクセスは拒否されます (Netscape では、拒否される場合と拒否されない場合があります)。
• Internet Explorer では、匿名認証以外の認証方法を使用してサーバーとの接続を確立すると、そのセッションが継続している間、新しい要求ではすべて自動的に同じ資格情報が渡されます。

この資料は米国 Microsoft Corporation から提供されている Knowledge Base の Article ID 264921? (http://support.microsoft.com/kb/264921/EN-US/ ) (最終更新日 2003-07-03) を基に作成したものです。