IIS Insider

IIS 6 および IIS 5 上では、統合 Windows 認証は同じ方法で実行されます。そのため、この問題は NTLM vs Kerberos の問題に関連しないと思います。しかし、この件を NTLM vs Kerberos の問題であると考え、トラブルシューティングを行う際、潜在的な問題を解決できる可能性があります。まず、Kerberos の部分の相関関係に関して考えてみましょう。

IIS では、次の条件のすべてが満たされる場合にのみ Kerberos による認証が試行されます。

1. 統合 Windows 認証が有効に設定されている場合

2. IIS が Active Directory ドメインのメンバである場合

3. Web サイトが Kerberos でサービス プリンシパル名 (SPN) として登録されている場合

4. クライアントが信頼するドメインのメンバである場合

5. クライアントが Kerberos が有効にされたブラウザまたは OS を使用している場合

Kerberos での認証に失敗する原因となる最も一般的なものの 1 つは、Web サイトの名前が SPN として登録されていない場合に起こります。これは、URL で使用される Web サイト名がコンピュータの NetBIOS 名以外である場合、起こります。この場合、Setspn.exe ツールを使用して、Web サイト名を Kerberos でサービス プリンシパルとして登録する必要があります。Web サイトでコンピュータの NetBIOS 名に応答するように構成し、このテストを行うことができます。Active Directory を持つイントラネット上では、単にすべての未使用の ＩＰ アドレスまたはサーバー名の接続を確認する際に返された ＩＰ アドレスに応答するように Web サイトを設定することにより、このテストを行うことができます。認証が成功したら、Kerberos の問題の原因を突き止めることができます。

この件に関する詳細は、他の懸念事項もあるため、統合 Windows 認証の IIS Resource Guide (英語) のセクションをご覧ください。

また、IIS で、Kerberos のネゴシエーションを省略し、直接 NTLM 認証を行うように構成することができます。これを行うためには、Metabase キーの “NtAuthenticationProviders" を “NTLM” に設定します。このキーは、IIS 5、5.1、6.0 のサイト レベルで設定することができます。この変更を記録しておくことは非常に重要です。その後、Kerberos を再度有効に設定する必要がある場合、ユーザー インターフェイスで確認することができないため、なぜ、Kerberos が有効になっていないのかわからない状況が出てきます。

Kerberos を無効に設定し、認証が実行される場合、何らかの問題が発生することが予測されます。認証が依然として失敗する場合、クライアントおよびサーバーが、以下のようにローカル セキュリティ ポリシーで同じ NTLM 認証が行われるようにしてください。

クライアントを図のように設定し、IIS を “NTLM v2 only refuse all others” に設定した場合、認証は失敗します。これは、IIS の既定の設定ではありませんが、グループ ポリシーまたはセキュリティ テンプレートで変更することができます。

また、IIS サーバーの前にプロキシ サーバーを使用している場合、統合 Windows 認証が失敗する可能性があります。ISA サーバーには NTLM プロキシ機能があるため、利用することができますが、ほとんどの場合において、統合 Windows 認証を使用して IIS サーバーの前でプロキシを使用することはできません。IIS および認証に関する詳細は、サポート技術情報 264921 IIS におけるブラウザ クライアントの認証方法 をご覧ください。

[ISAPI アプリケーションをキャッシュする] というチェックボックスは、以下のように、アプリケーション構成プロパティのページのアプリケーション マッピング タブにあります。このボックスは、Web サイトのアプリケーション マッピング タブから設定することができます。仮想ディレクトリまたはディレクトリのアプリケーション構成ウインドが表示された場合、そのチェックボックスは設定できません。これは、回避策がある IIS 5.0 の問題により発生します。詳細は、以下のマイクロソフト サポート技術情報をご覧ください。「キャッシュ ISAPI アプリケーション」プロパティは変更できません。

[ISAPI アプリケーションをキャッシュする] に関連するメタベースのプロパティは、メタベースの CacheISAPI プロパティとなります。Metaedit 2.2 により、または adsutil.vbs スクリプトを使用してこのプロパティを有効または無効に設定することができます。たとえば、ISAPI アプリケーションのキャッシュを無効に設定するには、以下のようにコマンド プロンプトから adsutil を使用します。

仮想ディレクトリは、おっしゃるように UNC パスを使用してリモートの共有に接続するか、または http:// のリクエストをリダイレクトします。異なるサーバーにリダイレクトを行う場合、ユーザーのセッションはリモート システムにリダイレクトされ、リダイレクトを行った IIS サーバーではなく、そのコンピュータから配布されます。IIS サーバーがリモートの IIS サーバーからコンテンツをフェッチし、コンテンツをクライアントに配信する必要がある場合、最初の IIS サーバーがリモートの IIS サーバーのリバース プロキシのような役割を果たします。リバースプロキシの「ような」とは、リバース プロキシ サーバーは、一般的には Web サイト全体の接続の代理の役割をするためです。この場合、Web サイト全体ではなく、一部のフォルダ上でのみそれが行われるようにする必要があります。

これは、多くの方法にて行うことができますが、すべての方法において、アプリケーションの開発または専用のコンポーネントの使用が必要となります。たとえば、Log Parser Tool 2.2 ベータ版 (TechNet ダウンロード CD 2004 年 8 月号にて利用可能です) には、Log Parser Tool の機能を実装する COM オブジェクトが同梱されています。それらの機能のうちの 1 つにより、http を使用して対象のサーバーのクエリを行うことができます。その後、その結果をクライアントで再現することができます。Log Parser Tool の最終リリース版の 2.2 は、2004 年の夏ごろにリリースされる予定です。

同じ目標を達成する方法はこのほかに多くあります。対象のサーバー上のコンテンツを XML にフォーマットすることができる場合、アプリケーションの一部として XML コンテンツを挿入し、クライアントにそのコンテンツを配信することができます。これは、スクリプトで MSXML オブジェクトを使用して行うことができる場合があります。このオブジェクトの主な機能は、アプリケーション内から XML ファイルと連携を行うことですが、リモートの IIS サーバーから html などのほかのファイルを読み込む機能もあります。

そのほかの潜在的な機能として、net use * http://targetserver/foldername などのドライブ マッピングを使用して、対象のサーバーにマッピングされた Web フォルダの使用があります。この場合、WebClient サービスを有効にする必要があるため、ソース サーバーとして IIS 6 を使用することが必要となります。対象のサーバーでは、WebDAV を有効に設定する必要があります。

そのほか、サード パーティのオブジェクトおよびアプリケーションにより、IIS サーバーから http のコンテンツをフェッチできる可能性があります。研究および創造的な考え方により、問題のソリューションを行うことができます。