Kerberos 認証を構成する: コア構成 (SharePoint Server 2010)
適用先: SharePoint Server 2010
トピックの最終更新日: 2017-01-18
この最初のシナリオでは、Kerberos プロトコルを使用して受信したクライアント要求を認証するように 2 つの SharePoint Server 2010 Web アプリケーションを構成します。デモンストレーションの目的で、1つの Web アプリケーションは標準ポート (80/443) を使用するように構成し、もう 1 つのアプリケーションは既定以外のポート (5555) を使用するように構成します。このシナリオは、後に続くすべてのシナリオの基礎となります。これらのシナリオは、以下に示す作業が完了していることを前提としています。
重要
Kerberos 認証を使用するクラシック Windows 認証を使用して Web アプリケーションを構成し、シナリオが期待どおりに機能することを確認することが要件となります。Windows クレーム認証はシナリオによっては使用できますが、以下のシナリオで詳しく説明している結果を得られない可能性があります。
注意
Windows Server 2008 にインストールする場合は、Kerberos 認証用に次の修正プログラムのインストールが必要になる可能性があります。
Kerberos 認証は 0X80090302 または 0x8009030f、AES アルゴリズムが使用するとき Windows Server 2008 や Windows Vista を実行がコンピューターには、エラー コードと共に失敗します。 (https://support.microsoft.com/kb/969083/ja-jp)
このシナリオでは、次のことを行います。
認証に Kerberos プロトコルを使用する 2 つの Web アプリケーションを既定のゾーンを使用して構成します。
Web アプリケーションごとに 1 つのテスト サイト コレクションを作成し、合計で 2 つ作成します。
Web アプリケーションの IIS 構成を確認します。
クライアントが Web アプリケーションと認証を行うことができることを確認し、認証に Kerberos プロトコルが使用されていることを確認します。
ローカルとリモートの Web アプリケーションに RSS フィードを表示するように RSS ビューアー Web パーツを構成します。
各 Web アプリケーションをクロールして、各テスト サイト コレクションで検索コンテンツをテストします。
構成チェックリスト
| 構成の領域 | 説明 |
|---|---|
DNS |
Web アプリケーションのネットワーク ロード バランス (NLB) 仮想 IP (VIP) の DNS A レコードを登録する |
Active Directory |
Web アプリケーションの IIS アプリケーション プール用のサービス アカウントを作成する Web アプリケーションの IIS アプリケーション プール用に作成したサービス アカウントで Web アプリケーションのサービス プリンシパル名 (SPN) を登録する サービス アカウントに対して Kerberos の制約付き委任を構成する |
SharePoint Web アプリケーション |
SharePoint Server 管理アカウントを作成する SharePoint Search Service アプリケーションを作成する SharePoint Web アプリケーションを作成する |
IIS |
Kerberos 認証が有効になっていることを確認する カーネル モード認証が無効になっていることを確認する SSL 証明書をインストールする |
Windows 7 クライアント |
Web アプリケーションの URL がイントラネット ゾーン、または、統合 Windows 認証を使用して自動的に認証するように構成されているゾーン内にあることを確認する |
ファイアウォールの構成 |
ファイアウォール ポートを開き、既定のポートと既定以外のポートで HTTP トラフィックを許可する クライアントが Active Directory の Kerberos ポートに接続できることを確認する |
ブラウザー認証のテスト |
ブラウザーで認証が正常に機能することを確認する Web サーバーのセキュリティ イベント ログでログオン情報を確認する サード パーティのツールを使用して、Kerberos 認証が正しく構成されていることを確認する |
SharePoint Server の検索のインデックスとクエリをテストする |
インデックス サーバーからのブラウザー アクセスを確認する サンプル コンテンツをアップロードして、クロールを実行する 検索をテストする |
WFE 委任のテスト |
各サイト コレクションで RSS フィードのソースを構成する RSS ビューアーの Web パーツを各サイト コレクションのホーム ページに追加する |
構成手順
DNS を構成する
環境で Web アプリケーションの DNS を構成します。この例では、2 つの Web アプリケーション http://portal と http://teams:5555 について構成します。両方とも、同じ NLB VIP (192.168.24.140/24) に解決されます。
DNS の構成方法に関する一般的な情報については、「Managing DNS Records (英語)」を参照してください。
SharePoint Server Web アプリケーション
http://portal — ポータル Web アプリケーションの新しい DNS A レコードを構成します。この例では、ロード バランスされる VIP に解決されるようにホスト "portal" を構成します。
.jpg "DNS レコードのイメージ")
http://teams:5555 — チームの Web アプリケーションの新しい DNS A レコードを構成します。
.jpg "DNS レコードのイメージ")
注意
ホスト ヘッダーと個別の専用サービス アカウントを持つ複数の Web アプリケーションを実行している環境で Kerberos 認証が正常に機能するためには、DNS エントリを CNAME エイリアスではなく A レコードにすることが重要です。Kerberos が有効な Web アプリケーションで CNAME を使用する場合の既知の問題については、「Kerberos 構成の既知の問題 (SharePoint Server 2010)」を参照してください。
Active Directory を構成する
次に、環境で Web アプリケーションの Active Directory アカウントを構成します。ベスト プラクティスとして、各 Web アプリケーションは、各自のセキュリティ コンテキスト (アプリケーション プール ID) を使用して各自の IIS アプリケーション プールで実行するように構成することをお勧めします。
SharePoint サービス アプリケーションのサービス アカウント
この例では、2 つ SharePoint Server Web アプリケーションを各自のアプリケーション プール ID を使用して 2 つの個別の IIS アプリケーション プールで実行します。
| Web アプリケーション (既定のゾーン) | IIS App プール ID |
|---|---|
vmlab\svcPortal10App |
|
vmlab\ svcTeams10App |
サービス プリンシパル名 (SPN)
サービス アカウントごとに、各 Web アプリケーションに割り当てられている DNS ホスト名にマップされるサービス プリンシパル名を構成します。
Windows Server 2008 のコマンド ライン ツールである SetSPN を使用して、新しいサービス プリンシパル名を構成します。SetSPN の使用方法の詳細については、「Setspn (英語)」を参照してください。Windows Server 2008 での SetSPN の機能向上について確認するには、「Care, Share and Grow! : New features in SETSPN.EXE on Windows Server 2008 (英語)」を参照してください。
ポート番号にかかわらず、すべての SharePoint Server Web アプリケーションでは、次の SPN 形式を使用します。
HTTP/<DNS ホスト名>
HTTP/<DNS FQDN>
例:
HTTP/portal
HTTP/portal.vmlab.local
既定以外のポート (80/443 以外のポート) で実行している Web アプリケーションについては、ポート番号を使用して追加の SPN を登録します。
HTTP/<DNS ホスト名>:<ポート>
HTTP/<DNS FQDN>:<ポート>
例:
HTTP/teams:5555
HTTP/teams.vmlab.local:5555
注意
既定のポート (80、443) 以外のポートで実行している HTTP サービスのポート番号を指定した SPN と指定しない SPN を構成することを推奨する理由については、付録を参照してください。既定以外のポートで実行する HTTP サービスを参照する技術的に正しい方法は、SPN にポート番号を指定する方法です。ただし、付録で説明している既知の問題が原因で、ポートを指定せずに SPN を構成する必要があります。この例では、ポートを指定せずに teams Web アプリケーションの SPN を構成しても、サービスが既定のポート (80、443) を使用してアクセスされることにはなりません。
この例では、前の手順で作成した 2 つのアカウントに対して次のサービス プリンシパル名を構成しました。
| DNS ホスト | IIS App プール ID | サービス プリンシパル名 |
|---|---|---|
Portal.vmlab.local |
vmlab\svcPortal10App |
HTTP/portal HTTP/portal.vmlab.local |
Teams.vmlab.local |
vmlab\ svcTeams10App |
HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
サービス プリンシパル名を作成するために、以下のコマンドを実行しました。
SetSPN -S HTTP/Portal vmlab\svcportal10App
SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App
SetSPN -S HTTP/Teams vmlab\svcTeams10App
SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App
SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App
SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App
重要
Web アプリケーションで SSL を使用する場合でも、HTTPS を使用してサービス プリンシパル名を構成しないでください。
この例では、Windows Server 2008 で導入された新しいコマンド ライン スイッチ (-S) を使用しました。このスイッチは、アカウントで SPN を作成する前に SPN が存在するかどうかを確認します。SPN が既に存在する場合は、新しい SPN は作成されず、エラー メッセージが表示されます。
重複する SPN が見つかった場合、Web アプリケーションに別の DNS 名を使用し、SPN を変更するか、重複する SPN が検出されたアカウントから既存の SPN を削除して、問題を解決する必要があります。
重要
既存の SPN を削除する前に、その SPN が不要であることを確認してください。確認しなかった場合、環境内の別のアプリケーションの Kerberos 認証が壊れる可能性があります。
サービス プリンシパル名と SSL
http Web アプリケーションの場合、Kerberos サービス プリンシパル名は URL と間違えられることがよくあります。これは、SPN 形式と URI 形式は構文が非常に似ているためです。この 2 つはまったく異なり、それぞれ固有のものであることを理解することが重要です。Kerberos サービス プリンシパル名は、サービスを識別するために使用します。そのサービスが http アプリケーションの場合、そのサービスが SSL を使用してアクセスされるかどうかに関係なく、サービス スキームは "HTTP" になります。つまり、"https://someapp" を使用して Web アプリケーションにアクセスする場合でも、"HTTPS/someapp" のように HTTPS を使用してサービス プリンシパル名を構成しないでください。
コンピューターおよびサービス アカウントに対して Kerberos の制約付き委任を構成する
シナリオによっては、SharePoint Server 2010 の一部の機能が正常に機能するために制約付き委任が必要になる可能性があります。たとえば、認証されたソースからの RSS フィードを表示するように RSS ビューアー Web パーツを構成する場合、ソース フィードを利用するには委任が必要です。これ以外の状況でも、制約付き委任を構成して、サービス アプリケーション (Excel Services など) がクライアントの ID をバックエンド システムに委任できるようにする必要がある場合があります。
このシナリオでは、Kerberos の制約付き委任を構成して、RSS ビューアー Web パーツがセキュリティで保護されたローカル RSS フィードおよびセキュリティで保護されたリモート RSS フィードをリモート Web アプリケーションから読み取ることができるようにします。後のシナリオでは、他の SharePoint Server 2010 サービス アプリケーションに合わせて Kerberos の制約付き委任を構成します。
次の図は、このシナリオで構成する項目を概念的に示しています。
.jpg "シナリオの図")
このシナリオには 2 つの Web アプリケーションがあり、各アプリケーションには、2 つの RSS ビューアー Web パーツをホストするサイト ページを含んでいる固有のサイト コレクションがあります。各 Web アプリケーションには、Kerberos 認証を使用するように構成された 1 つの既定のゾーンがあるので、これらの Web サイトからのすべてのフィードには認証が必要になります。各サイトでは、1 つの RSS ビューアーをリストからローカル RSS フィードを読み取るように構成し、もう 1 つのビューアーは、リモート サイトの認証フィードを読み取るように構成します。
これを実現するために、IIS アプリケーション プールのサービス アカウント間で委任を行えるように Kerberos の制約付き委任を構成します。次の図は、必要な制約付き委任のパスを概念的に示しています。
.jpg "アプリケーション プールの委任の図")
Web アプリケーションは、IIS アプリケーション プールの ID に割り当てられたサービス プリンシパル名 (SPN) を使用してサービス名によって識別します。このサービス アカウント処理要求は、クライアント ID を指定のサービスに委任できる必要があります。まとめると、次の制約付き委任のパスを構成します。
| プリンシパルの種類 | プリンシパル名 | サービスへの委任 |
|---|---|---|
ユーザー |
svcPortal10App |
HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
ユーザー |
svcTeams10App |
HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555 |
注意
ポータル サービス アカウントをポータル サービス アプリケーションに委任するなど、サービスからそのサービスへの委任を構成するのは余計な作業であるように見えますが、この作業は、同じサービスを実行するサーバーが複数存在するシナリオで必要です。これにより、ローカル Web アプリケーションをデータ ソースとして使用する RSS ビューアーが構成された、要求を処理する WFE など、あるサーバーが同じサービスを実行している別のサーバーに委任する可能性があるシナリオに対応できます。ファームのトポロジと構成によっては、RSS 要求を別のサーバーによって処理できる可能性があります。ただし、これが正常に機能するには委任が必要です。
委任を構成するには、[Active Directory ユーザーとコンピューター] スナップインを使用します。各サービス アカウントを右クリックしてプロパティ ダイアログを開きます。ダイアログには、委任を行うためのタブが表示されます (ただし、このタブは、オブジェクトに SPN が割り当てられている場合にのみ表示されます。既定では、コンピューターには SPN が割り当てられています)。[委任] タブで、[指定されたサービスへの委任でのみこのユーザーを信頼する] を選択し、[任意の認証プロトコルを使う] を選択します。
[追加] ボタンをクリックして、ユーザー (サービス アカウント) が委任できるサービスを追加します。SPN を選択するには、SPN が割り当てられているオブジェクトを探します。この例では、HTTP サービスに委任しようとしているので、前の手順で SPN を割り当てた IIS アプリケーション プールのサービス アカウントを探します。
[ユーザーまたはコンピューターの選択] ダイアログ ボックスで、[ユーザーとコンピューター] をクリックし、IIS アプリケーション プールのサービス アカウント (この例では、vmlab\svcPortal10App と vmlab\svcTeams10App) を見つけて、[OK] をクリックします。
サービス プリンシパル名を使用してオブジェクトに割り当てられているサービスを選択するように指示されます。
[サービスの追加] ダイアログ ボックスで、[すべて選択] をクリックして、[OK] をクリックします。委任ダイアログに戻ったとき、実際には選択した SPN はどれも表示されません。すべての SPN を表示するには、左下にある [展開済み] チェック ボックスをオンにします。
環境で委任が必要なサービス アカウントごとにこの手順を実行します。この例では、これはサービス アカウントの一覧です。
SharePoint Server を構成する
Active Directory と DNS を構成した後で、SharePoint Server 2010 ファームで Web アプリケーションを作成します。ここでは、SharePoint Server のインストールは既に完了していて、ファーム トポロジとサポート インフラストラクチャ (たとえば、ロード バランシング) は構成済みであることを前提としています。SharePoint ファームのインストール方法と構成方法の詳細については、「SharePoint Server 2010 の展開」を参照してください。
管理サービス アカウントを構成する
Web アプリケーションを作成する前に、前の手順で作成したサービス アカウントを SharePoint Server で管理サービス アカウントとして構成します。事前に構成することで、Web アプリケーションを作成するときにこの手順を実行しなくて済みます。
管理アカウントを構成するには
SharePoint サーバーの全体管理で、[セキュリティ] をクリックします。
[一般的なセキュリティ] の [管理アカウントの構成] をクリックします。
[管理アカウントの登録] をクリックして、各サービス アカウントの管理アカウントを作成します。この例では、次の 5 つの管理サービス アカウントを作成しました。
アカウント 用途 VMLAB\svcSP10Search
SharePoint Search Service アカウント
VMLAB\svcSearchAdmin
SharePoint Search Administration Service アカウント
VMLAB\svcSearchQuery
SharePoint Search Query Service アカウント
VMLAB\svcPortal10App
ポータル Web アプリケーション IIS アプリケーション プール アカウント
VMLAB\svcTeams10App
チーム Web アプリケーション IIS アプリケーション プール アカウント
注意
SharePoint Server 2010 の管理アカウントは、Windows Server 2008 R2 Active Directory の管理サービス アカウントと同じではありません。
SharePoint Server Search Service アプリケーションを作成する
この例では、新しく作成する Web アプリケーションを正常にクロールおよび検索できるようにするために SharePoint Server Search Service アプリケーションを構成します。新しい SharePoint Server Search Web アプリケーションを作成し、アプリケーション サーバー (この例では、vmSP10App01) に Search Service、Query Service、Administration Service を配置します。Search Service アプリケーションの構成方法の詳細については、「Step-by-Step: Provisioning the Search Service Application (英語)」を参照してください。
注意
すべての Search Service を 1 台のアプリケーション サーバーに配置するのは、デモンストレーションを行う場合だけです。SharePoint Server 2010 検索トポロジのオプションとベスト プラクティスの詳細については、ここでは説明しません。
Web アプリケーションを作成する
サーバーの全体管理に移動し、[アプリケーション構成の管理] セクションの [Web アプリケーションの管理] に移動します。ツール バーで [新規作成] を選択し、Web アプリケーションを作成します。必ず次のように構成します。
[クラシック モード認証] を選択します。
各 Web アプリケーションのポートおよびホスト ヘッダーを構成します。
認証プロバイダーとして [ネゴシエート] を選択します。
アプリケーション プールで [新しいアプリケーション プールを作成する] を選択し、前の手順で作成した管理アカウントを選択します。
この例では、次の設定を使用して 2 つの Web アプリケーション プールを作成しました。
| 設定 | http://ポータル Web アプリケーション | http://チーム Web アプリケーション |
|---|---|---|
認証 |
クラシック モード |
クラシック モード |
IIS Web サイト |
名前: SharePoint – Portal – 80 ポート: 80 ホスト ヘッダー: Portal |
名前: SharePoint – Teams – 5555 ポート: 80 ホスト ヘッダー: Teams |
セキュリティの構成 |
認証プロバイダー: ネゴシエート 匿名アクセスを許可: いいえ Secure Sockets Layer の使用: いいえ |
認証プロバイダー: ネゴシエート 匿名アクセスを許可: いいえ Secure Sockets Layer の使用: いいえ |
パブリック URL |
http://Portal:80 |
http://Teams:5555 |
アプリケーション プール |
名前: SharePoint – Portal80 セキュリティ アカウント: vmlab\svcPortal10App |
名前: SharePoint – Teams5555 セキュリティ アカウント: vmlab\svcTeams10App |
新しい Web アプリケーションを作成するときは、Windows 認証プロバイダーを使用するように構成した新しいゾーン (既定のゾーン) も作成します。最初に Web アプリケーションを選択し、ツール バーの [認証プロバイダー] をクリックすると、Web アプリケーション構成の管理でそのゾーンのプロバイダーと設定を確認できます。認証プロバイダー ダイアログ ボックスには、選択した Web アプリケーションのすべてのゾーンと各ゾーンの認証プロバイダーが一覧表示されます。ゾーンを選択すると、そのゾーンの認証オプションが表示されます。
Web アプリケーションを作成するときに Windows の設定を間違え、NTLM を選択した場合は、目的のゾーンの [認証の編集] ダイアログを使用して、ゾーンを [NTLM] から [ネゴシエート] に切り替えることができます。認証モードに [クラシック モード認証] を選択しなかった場合は、その Web アプリケーションを新しい IIS Web サイトに拡張して新しいゾーンを作成するか、その Web アプリケーションを削除して作成し直す必要があります。
サイト コレクションを作成する
認証が正常に機能しているかどうかをテストするには、各 Web アプリケーションに 1 つ以上のサイト コレクションを作成する必要があります。サイト コレクションの作成と構成は Kerberos の機能に影響しないので、「サイト コレクションを作成する (SharePoint Foundation 2010)」に記載されているサイト コレクションの作成方法に従って作成します。
この例では、次の 2 つのサイト コレクションを構成しました。
| Web アプリケーション | サイト コレクションのパス | サイト コレクション テンプレート |
|---|---|---|
http://portal |
/ |
発行ポータル |
http://teams:5555 |
/ |
チーム サイト |
代替アクセス マッピングを作成する
ポータル Web アプリケーションは、HTTPS および HTTP を使用するように構成して、SSL で保護されたサービスに対する委任の動作をデモンストレーションします。SSL を構成するには、ポータル Web アプリケーションに、HTTPS エンドポイント用の 2 つ目の SharePoint Server 代替アクセス マッピング (AAM) が必要です。
代替アクセス マッピングを構成するには
サーバーの全体管理で [アプリケーション構成の管理] をクリックします。
[Web アプリケーション] で、[代替アクセス マッピングの構成] をクリックします。
[代替アクセス マッピング コレクションの選択] ドロップダウンで、[代替アクセス マッピング コレクションの変更] を選択します。
ポータル Web アプリケーションを選択します。
上部のツール バーの [パブリック URL の編集] をクリックします。
空いているゾーンに、Web アプリケーションの https URL を追加します。この URL は、次の手順で作成する SSL 証明書で名前として使用します。
[保存] をクリックします。
Web アプリケーションのゾーンの一覧には、HTTPS URL が表示されているはずです。
IIS の構成
SSL 証明書をインストールする
SSL を使用する Web アプリケーションごとに、Web アプリケーション サービスをホストする各 SharePoint Server で SSL 証明書を構成する必要があります。SSL 証明書と証明書信頼を構成する方法については、ここでは説明しません。IIS で SSL 証明書を構成する方法に関する資料については、このドキュメントの「SSL の構成」セクションを参照してください。
Kerberos 認証が有効になっていることを確認する
Web サイトで Kerberos 認証が有効になっていることを確認するには
IIS マネージャーを開きます。
確認する IIS Web サイトを選択します。
機能ビューの IIS で、[認証] をクリックします。
有効になっている必要がある [Windows 認証] を選択します。
[アクション] の下の右側にある [プロバイダー] を選択します。[ネゴシエート] が一覧の一番上にあることを確認します。
カーネル モード認証が無効になっていることを確認する
**カーネル モード認証は、SharePoint Server 2010 ではサポートされていません。**既定では、すべての SharePoint Server Web アプリケーションでは、その対応する IIS Web サイトでカーネル モード認証が既定で無効にされるはずです。Web アプリケーションを既存の IIS Web サイト上で構成した場合でも、SharePoint Server は、既存の IIS サイトで新しい Web アプリケーションを準備するときにカーネル モード認証を無効にします。
カーネル モード認証が無効になっていることを確認するには
IIS マネージャーを開きます。
確認する IIS Web サイトを選択します。
機能ビューの IIS で、[認証] をクリックします。
有効になっている必要がある [Windows 認証] を選択します。
[詳細設定] をクリックします。
EAP とカーネル モード認証が無効になっていることを確認します。
ファイアウォールを構成する
認証をテストする前に、構成した HTTP ポートで実行する SharePoint Server Web アプリケーションにクライアントがアクセスできることを確認します。また、クライアントが Active Directory と認証を行い、標準の Kerberos ポートを経由して KDC に Kerberos チケットを要求できることを確認します。
ファイアウォール ポートを開き、既定のポートと既定以外のポートで HTTP トラフィックを許可する
通常は、ポート TCP 80 と TCP 443 を経由して要求を受信できるように各フロントエンド Web でファイアウォールを構成する必要があります。[セキュリティが強化された Windows ファイアウォール] を開き、次の受信の規則を参照します。
World Wide Web サービス (HTTP トラフィック)
World Wide Web サービス (HTTPS トラフィック)
環境で適切なポートが開いていることを確認します。この例では、HTTP (ポート 80) を経由して SharePoint Server にアクセスするので、この規則を有効にしました。
また、この例では、既定以外のポート (TCP 5555) を開く必要があります。既定以外のポートで実行している Web サイトがある場合には、そのポートで HTTP トラフィックを許可するためにカスタムの規則を構成する必要があります。
クライアントが Active Directory ロールの Kerberos ポートに接続できることを確認する
Kerberos 認証を使用するには、クライアントは、UDP または TCP ポート 88 を経由してキー配布センター (KDC) にチケット保証チケット (TGT) とサービス チケット (ST) を要求する必要があります。既定では、Windows Server 2008 以降で Active Directory ロールをインストールするときに、ロールは、この通信を既定で許可するために次の受信の規則を構成します。
Kerberos キー配布センター – PCR (TCP 受信)
Kerberos キー配布センター – PCR (UDP 受信)
Kerberos キー配布センター (TCP 受信)
Kerberos キー配布センター (UDP 受信)
環境で、これらの規則が有効になっていること、およびクライアントがポート 88 を経由して KDC (ドメイン コントローラー) に接続できることを確認します。
ブラウザー認証をテストする
Active Directory、DNS、および SharePoint Server を構成した後でブラウザーで Web アプリケーションに移動して、Kerberos 認証が正しく構成されているかどうかをテストできます。ブラウザーでテストするときには、次の条件を確実に満たす必要があります。
テスト ユーザーは、SharePoint Server がインストールされているドメインに参加している Windows XP、Vista、または Windows 7 コンピューター、または SharePoint Server ドメインによって信頼されているドメインにログインする必要があります。
テスト ユーザーは、Internet Explorer 7.0 以降を使用する必要があります (Internet Explorer 6.0 は SharePoint Server 2010 でサポートされなくなりました。「ブラウザー サポートを計画する (SharePoint Server 2010)」を参照してください)。
統合 Windows 認証がブラウザーで有効になっている必要があります。[インターネット オプション] の [詳細設定] タブで、[セキュリティ] セクションにある [統合 Windows 認証を使用する] が有効になっていることを確認します。
ローカル イントラネットは、クライアントを自動的にログオンするように構成されている必要があります。Internet Explorer のオプションで、[セキュリティ] タブの [ローカル イントラネット] を選択し、[レベルのカスタマイズ] ボタンをクリックします。下にスクロールして、[イントラネット ゾーンでのみ自動的にログオンする] が選択されていることを確認します。
注意
他のゾーンで自動的にログオンするように構成することもできますが、IE セキュリティ ゾーンのベスト プラクティスに関しては、ここでは説明しません。このデモンストレーションでは、すべてのテストにイントラネット ゾーンを使用します。
[インターネット オプション]、[セキュリティ]、[イントラネット ゾーン]、[サイト] の順に選択して、[イントラネットのネットワークを自動的に検出する] が選択されていることを確認します。
完全修飾ドメイン名を使用して、SharePoint Server Web アプリケーションにアクセスする場合には、その FQDN が明示的にまたはワイルドカードを使用して (たとえば、"*.vmlab.local")、イントラネット ゾーンに含まれていることを確認します。
Kerberos 認証が使用されているかどうかを最も簡単に確認できる方法は、テスト ワークステーションにログインして、目的の Web サイトに移動する方法です。ユーザーに資格情報が要求されず、サイトが正常に表示された場合、統合 Windows 認証が機能していると考えることができます。次に、要求に対して Kerberos 認証を認証プロバイダーとしてネゴシエートするためにネゴシエート プロトコルが使用されたかどうかを確認します。これは、次の方法で確認できます。
フロントエンド Web のセキュリティ ログ
Kerberos 認証が正常に機能している場合、フロントエンド Web のセキュリティ イベント ログでイベント ID = 4624 のログオン イベントを確認できます。これらのイベントに関する一般情報には、コンピューターにログオンしているセキュリティ ID および使用されているログオン プロセスが表示されます。これは [Kerberos] である必要があります。
KList
KList は、Windows Server 2008 と Windows Server 2008 R2 の既定のインストールに含まれるコマンド ライン ユーティリティで、このユーティリティを使用して特定のコンピューターの Kerberos チケットを一覧に表示したり削除できます。KLIST を実行するには、Windows Server 2008 でコマンド プロンプトを開き、「Klist」と入力します。
チケット キャッシュを削除する場合は、オプションの purge パラメーターを指定して Klist を実行します。「Klist purge」と入力します。
KerbTray
KerbTray は、Windows Server 2000 Resource Kit Tool に含まれる無償のユーティリティで、クライアント コンピューターにインストールして Kerberos チケット キャッシュを表示できます。「Windows 2000 Resource Kit Tool: Kerbtray.exe (英語)」からダウンロードしてインストールします。インストール後に、次の操作を実行します。
Kerberos 認証を使用している Web サイトに移動します。
KerbTray.exe を実行します。
システム トレイにある KerbTray のアイコンを右クリックして、[List Tickets] を選択して、Kerberos チケット キャッシュを表示します。
ユーザーが認証された Web アプリケーションのサービス チケットがキャッシュされたチケットの一覧に存在することを確認します。この例では、次の SPN が登録されている次の Web サイトに移動しました。
Web サイトの URL SPN http://portal
HTTP/Portal.vmlab.local
http://teams:5555
HTTP/Teams.vmlab.local
Fiddler
Fiddler は、http://www.fiddlertool.com/ (英語) からダウンロードできる無償の HTTP トラフィック分析ツールです。Fiddler では、クライアントとサーバーが Kerberos 認証をネゴシエートしている様子を確認できるので、クライアントが Kerberos サービス チケットを各要求の HTTP ヘッダーに入れてサーバーに送信していることを確認できます。Kerberos 認証が正常に機能していることを確認するには、Fiddler を使用して次の操作を実行します。
Fiddler (www.fiddlertool.com (英語)) をクライアント コンピューターにダウンロードしてインストールします。
デスクトップからログアウトしてログインし直すことで、キャッシュされた Web サーバーへの接続をすべてフラッシュし、Kerberos 認証をネゴシエートし、認証ハンドシェイクを行うようにブラウザーに強制します。
Fiddler を起動します。
Internet Explorer を起動し、Web アプリケーションに移動します (この例では、http://portal)。
Fiddler には SharePoint Server フロントエンド Web とやり取りした要求と応答が表示されるはずです。
最初の HTTP 401 は、ブラウザーが認証を行わずに GET 要求を行おうとしたことを示しています。応答で、サーバーは、"HTTP 401 – unauthorized" を送信し、この応答でサーバーがサポートする認証方法を示します。次の要求で、クライアントは前の要求を再送信しますが、今回は要求のヘッダーに Web アプリケーション用のサービス チケットを入れて送信します。正常に認証され、サーバーは要求されたリソースを返します。
NetMon 3.4
NetMon 3.4 は、Microsoft が提供する無償のネットワーク パケット分析ツールで、Microsoft ダウンロード センター (Microsoft Network Monitor 3.4 (英語)) からダウンロードできます。
NetMon では、KDC および SharePoint Server Web サーバーとやり取りしたすべての TCP 要求と応答を確認でき、完全な認証要求を形成するトラフィック全体を表示できます。netmon を使用して Kerberos 認証が機能していることを確認するには、次の操作を実行します。
NetMon 3.4 (Microsoft Network Monitor 3.4 (英語)) をダウンロードしてインストールします。
クライアントからログアウトしてログインし直し、Kerberos チケット キャッシュをフラッシュします。必要に応じて、KerbTray を右クリックし、[Purge Tickets] を選択して、チケット キャッシュを削除できます。
管理者モードで NetMon を起動します。NetMon のショートカットを右クリックして、[管理者として実行] を選択します。
環境の Active Directory コントローラーと Web フロントエンドに接続されているインターフェイスで新しい取り込みを開始します。
Internet Explorer を起動し、Web アプリケーションに移動します。
Web サイトが表示された後に、取り込みを停止し、表示フィルターを追加して Kerberos 認証と HTTP トラフィックのフレームを表示します。
フレーム ウィンドウには、HTTP と KerberosV5 両方のトラフィックが表示されるはずです。
SSL を経由して Kerberos 認証をテストする
クライアントが SSL で保護されたリソースにアクセスするときに要求される SPN をわかりやすくデモンストレーションするには、netmon のようなツールを使用してクライアントとサーバー間でやり取りされるトラフィックを取り込み、Kerberos サービス チケット要求を調べることができます。
クライアント コンピューターからログアウトしてログインし直すか、KerbTray を使用してキャッシュされたすべての Kerberos チケットを消去します。
クライアント コンピューターで NetMon による新しい取り込みを開始します。NetMon は管理者アクセス許可で起動する必要があります。
SSL を使用して Web アプリケーションに移動します (この例では、https://portal)。
NetMon による取り込みを停止し、KerberosV5 トラフィックを調べます。取り込みの表示をフィルター処理する方法については、この記事の「NetMon 3.4」セクションの説明を参照してください。
クライアントが送信した TGS 要求を探します。この要求では、"Sname" パラメーターで要求された SPN を確認できます。
"Sname" は HTTP/portal.vmlab.local です。HTTPS/portal.vmlab.local ではありません。
SharePoint Server の検索のインデックスとクエリをテストする
インデックス サーバーからのブラウザー アクセスを確認する
クロールを実行する前に、インデックス サーバーから Web アプリケーションにアクセスし、正常に認証を行うことができることを確認します。インデックス サーバーにログインして、テスト サイト コレクションをブラウザーで開きます。サイトが正常に表示され、認証ダイアログが表示されなかった場合、次の手順に進みます。ブラウザーでサイトにアクセスしているときに問題が発生した場合は、前の手順に戻り、すべての構成作業が正しく行われていることを確認します。
サンプル コンテンツをアップロードして、クロールを実行する
各サイト コレクションで、"元になる" ドキュメント (検索で簡単に識別できるドキュメント) をそのサイト コレクションのドキュメント ライブラリにアップロードします。たとえば、単語 "alpha、beta、delta" を含んでいるテキスト ドキュメントを作成し、各サイト コレクションのドキュメント ライブラリに保存します。
次に、SharePoint サーバーの全体管理に移動し、ローカルの SharePoint サイト コンテンツ ソース (既定で 2 つのテスト サイト コレクションが格納されているはずです) でフル クロールを開始します。
検索をテストする
インデックス作成が正常に完了した場合、インデックスには検索可能なアイテムがあり、クロール ログにエラーは記録されていないはずです。
注意
ユーザー プロファイル アプリケーション (UPA) を構成していて、そのプロファイル ストアでクロールを実行している場合は、必ず UPA で適切なアクセス許可を構成して、コンテンツ アクセス アカウントがプロファイル データにアクセスできるようにします。UPA アクセス許可を構成しなかった場合、クローラーがプロファイル サービスにアクセスしようとしたときに HTTP 401 を受け取り、そのサービスにアクセスできなかったことを示すエラーがクロール ログに表示されます。401 が返されたのは、Kerberos が原因ではなく、コンテンツ アクセス アカウントにプロファイル データを読み取るアクセス許可が割り当てられていないためです。
次に、各サイト コレクションに移動して、元になるドキュメントを検索します。各サイト コレクションの検索クエリは、アップロードした元になるドキュメントを返すはずです。
フロントエンド Web 委任をテストする
このシナリオでの最後の手順として、RSS ビューアー Web パーツを各サイト コレクションで使用して、委任がローカルおよびリモートで機能していることを確認します。
各サイト コレクションで RSS フィードのソースを構成する
ポータル アプリケーションの場合、サイト コレクションで RSS フィードを有効にする必要があります。RSS フィードを有効にするには、Office.com の「RSS フィードを管理する」の手順に従います。
RSS フィードを有効にしてから、テストの目的で新しいカスタム リストを作成し、リスト アイテムを追加します。[リスト] ツール バー メニューに移動し、[RSS フィード] をクリックして RSS フィードを表示します。次の手順で使用するためにフィード URL をコピーします。
サイト コレクションごとにこの手順を実行します。
RSS ビューアーの Web パーツを各サイト コレクションのホーム ページに追加する
ポータル アプリケーションで、RSS ビューアー Web パーツを使用するために SharePoint Enterprise 機能サイト コレクション機能を有効にする必要があります。有効にした後で、2 つの RSS ビューアー Web パーツをホーム ページに追加します。最初の Web パーツで、前の手順で作成したローカル RSS フィードを参照するフィード URL を構成します。2 つ目の Web パーツで、リモート フィード URL を参照するフィード URL を構成します。構成が完了すると、ローカルとリモートの RSS フィードからのコンテンツが両方の Web パーツによって正常に表示されるはずです。