ユーザーがサーバー上の情報にアクセスする前に、有効な Microsoft Windows のユーザー アカウント名とパスワードの入力を要求できます。この識別プロセスは、"認証" と呼ばれています。認証は、IIS のほとんどの機能と同様に、Web サイト、ディレクトリ、またはファイル レベルで設定することができます。IIS では、サーバー上のコンテンツへのアクセスを制御するため、次の認証方式が提供されています。
認証の設定については、「認証を有効にし、構成する」を参照してください。
認証方式 | セキュリティ レベル | パスワードの送信方法 | プロキシ サーバーおよびファイアウォール経由での使用 | クライアント要件 |
匿名認証 | なし | 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 アカウントがどのように使用されるかを説明します。
重要 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 要求に影響が現れます。このアカウントを変更する際には、細心の注意が必要です。
基本認証方式は、ユーザー名とパスワードの情報を収集する手段として広く使われている業界標準の方式です。
重要 Base64 でのエンコードは、暗号化とは異なります。Base64 でエンコードされたパスワードがネットワーク上でネットワーク スニッファによって傍受された場合、権限のない第三者によってパスワードが簡単に解読され、再使用される可能性があります。
基本認証の設定については、「認証を有効にし、構成する」を参照してください。
基本認証の利点は、基本認証が HTTP の仕様の一部であり、ほとんどのブラウザでサポートされていることです。欠点は、基本認証を使用している Web ブラウザでは、パスワードが暗号化されていない形式で転送されることです。ほかのユーザーが、ネットワーク上の通信を監視することで容易にパスワードを傍受し、一般に入手できるツールによって容易に解読する可能性があります。このため、基本認証は、専用回線や Secure Sockets Layer (SSL) 接続など、ユーザーと Web サーバー間の接続が安全であると確信できる場合にのみ使用することをお勧めします。詳細については、「暗号化」を参照してください。
注 統合 Windows 認証は、基本認証より優先して使用されます。ブラウザはユーザーにユーザー名とパスワードの入力を求める前に、統合 Windows 認証を選択し、最新の Windows ログオン情報の使用を試みます。現在は、Internet Explorer Version 2.0 以降でのみ、統合 Windows 認証をサポートしています。
クライアント ソフトウェアの追加インストールは不要ですが、ダイジェスト認証は、World Wide Web Consortium の Web サイトの RFC 2617 仕様で定義されている HTTP 1.1 プロトコルに依存しています。ダイジェスト認証は HTTP 1.1 準拠が要件であるため、一部のブラウザではサポートされません。HTTP 1.1 非準拠のブラウザがダイジェスト認証を使用してサーバーからファイルを要求した場合、サーバーではクライアントに対してダイジェスト資格情報を要求します。HTTP 1.1.非準拠のクライアントではダイジェスト認証がサポートされないため、この要求を拒否します。
重要 ダイジェスト認証は、Active Directory に格納されている要求側ユーザー パスワードのクリア テキスト コピーが DC に存在する場合にのみ完了します。DC はパスワードのクリア テキスト コピーを格納しているため、Active Directory は物理的な不正アクセスとネットワーク上の不正アクセスの両方から保護されている必要があります。
クライアント ソフトウェアの追加インストールは不要ですが、高度ダイジェスト認証は、World Wide Web Consortium の Web サイトの RFC 2617 仕様で定義されている HTTP 1.1 プロトコルに依存しています。高度ダイジェスト認証は HTTP 1.1 プロトコルに依存するため、一部のブラウザではサポートされません。HTTP 1.1 非準拠のブラウザがダイジェスト認証を使用してサーバーからファイルを要求した場合、サーバーではクライアントに対してダイジェスト資格情報を要求します。HTTP 1.1.非準拠のクライアントではダイジェスト認証がサポートされないため、この要求を拒否します。
重要 高度ダイジェスト認証は、DC および IIS サーバーの両方で Windows XP が実行されている場合にのみ有効です。DC または IIS サーバーのどちらかで Windows 2000 以前が実行されている場合、IIS ではユーザーに警告することなく既定でダイジェスト認証になります。
注 手順 2. では、IIS サーバーからクライアント (Internet Explorer) に、高度ダイジェスト認証ではなくダイジェスト認証が使用されていることを通知します。これは、ダイジェスト認証と高度ダイジェスト認証の両方とも、IIS サーバーとクライアント間で同一のダイジェスト認証アルゴリズムが使用されているためです。
統合 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 オンライン マニュアルを参照してください。
注 Internet Explorer Version 4.0 以降では、必要に応じて最初にユーザー情報の入力を要求するように構成できます。詳細については、Internet Explorer のマニュアルを参照してください。
統合 Windows 認証は安全な認証ですが、制限が 2 つあります。
このため、統合 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 認証を選択すると、そのリソースに対するすべての要求は、ユーザーにユーザー名やパスワードの入力を要求することなく、受け付けられます。これは、IIS によって、IUSR_computername と呼ばれる Windows ユーザー アカウントが自動的に作成されるためです。 computername は、IIS を実行しているサーバー名です。匿名 FTP 認証は Web ベースの匿名認証と似ています。匿名 FTP 認証が有効な場合、基本 FTP 認証が使用可能な場合でも、IIS は常にこの認証方式を最初に使用します。詳細については、「匿名認証」を参照してください。
基本 FTP 認証を使用して Web サーバーへの FTP 接続を確立するには、ユーザーは有効な Windows ユーザー アカウントに対応するユーザー名とパスワードを使用してログオンする必要があります。FTP サーバーがユーザーを識別できない場合、サーバーはエラー メッセージを返します。FTP 認証では、ユーザーはパスワードとユーザー名を暗号化されていない形式でネットワークに転送するため、安全ではありません。詳細については、「アクセス制御について」を参照してください。