Share via

Microsoft SharePoint 2010 製品での Kerberos 認証の概要

  • [アーティクル]

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

Microsoft SharePoint 2010 製品では、プラットフォームで ID を管理する方法が大幅に向上しました。ユーザー ID を統合システムに委任する必要があるシナリオを実現するうえで、これらの変更がソリューション設計とプラットフォーム構成に与える影響を理解することが重要です。Kerberos バージョン 5 プロトコルは、委任を実現するうえで重要な役割を果たし、このようなシナリオで必要とされる場合があります。

この一連の記事では、以下の項目に役立つ情報を提供します。

  • SharePoint 2010 製品での ID の概念を理解する

  • 認証と委任のシナリオで Kerberos 認証が果たす重要な役割について理解する

  • ソリューション設計で Kerberos 認証を利用することが望ましい状況または必要とする可能性がある状況を識別する

  • SharePoint Server でさまざまなサービス アプリケーションを使用するシナリオを含む、自分の環境におけるエンド ツー エンドの Kerberos 認証を構成する

  • Kerberos 認証が正しく構成されていること、期待どおりに機能することをテストし、確認する

  • Kerberos 認証を自分の環境で構成するときに役立つその他のツールとリソースを見つける

この一連の記事は、次の 2 つの主なセクションに分かれています。

  • SharePoint 2010 製品での Kerberos 認証の概要に関するこの記事

    この記事では、SharePoint 2010 Productsで ID を管理する方法についての概念的な情報、Kerberos プロトコル、および SharePoint 2010 ソリューションで Kerberos 認証が果たす重要な役割について説明します。

  • ステップ バイ ステップ構成

    この記事のグループでは、Kerberos 認証と委任をさまざまな SharePoint ソリューション シナリオで構成するときに必要な手順について説明します。

この Kerberos 認証に関する記事の対象読者

SharePoint 2010 Productsの ID と委任は範囲の広いトピックで、理解の状態や深さは多岐にわたります。この一連の記事では、概念レベルと技術レベルの両方からこのトピックに取り組み、さまざまな読者のニーズに対応できるように構成されています。

最初から最後まで

"SharePoint 2010 Productsの ID と Kerberos 認証について理解する必要があるすべてのことを説明します"

SharePoint 2010 Products、Kerberos 認証、およびクレーム認証を始めたばかりで学習中の場合は、このドキュメントの最初のセクションを読むことをお勧めします。このセクションでは、ID と委任の基本概念について説明し、クレーム認証と Kerberos 認証の入門書の役割を果たしています。リンク先の外部の記事と追加情報を必ず読み、知識のしっかりとした基盤を築いてからステップ バイ ステップ構成記事に進みます。

Office SharePoint Server 2007 からのアップグレード

"2007 からの変更点、および 2010 にアップグレードするときに準備する必要がある内容について説明します"

Kerberos 認証と Kerberos 委任を使用するように構成されている既存の Microsoft Office SharePoint Server 2007 環境を構築している場合には、次の記事を読むことをお勧めします。

  • SharePoint 2010 製品での ID シナリオ

  • クレーム入門

  • Windows 2008 R2 と Windows 7 での Kerberos 認証の変更点

  • SharePoint 2010 製品での Kerberos 構成の変更点

  • SharePoint Server 2007 からアップグレードするときの考慮事項

特定の機能またはシナリオに関して委任を構成する方法について他に質問がある場合には、ステップ バイ ステップ構成記事の特に構成チェックリストをお読みください。これにより、アップグレード後の環境が正しく構成されていることを確認できます。

ステップ バイ ステップ チュートリアル

"SharePoint Server と適用できる SharePoint Server サービス アプリケーションで Kerberos 委任を構成する手順を詳しく説明します"

ステップ バイ ステップ構成記事では、Kerberos 委任を使用するように構成できる複数の SharePoint 2010 Productsシナリオに対応しています。各シナリオでは、構成チェックリスト、詳細な手順を詳しく説明しているので、自分の環境で Kerberos 認証を適切に構成するのに役立ちます。次のシナリオを対象としています。

1 つ目のコア構成シナリオは、それに続くすべてのシナリオに必須の内容なので、十分に考察する必要があります。

注意

シナリオには、"SetSPN" コマンドが用意されています。このコマンドは、そのドキュメントからコピーして、コマンド プロンプト ウィンドウに貼り付けることができます。これらのコマンドにはハイフン文字が含まれています。Microsoft Word には、ハイフンをダッシュ文字に変換する傾向があるオートフォーマット機能があります。この機能を Word で有効にしている場合にコピーして貼り付ける操作を行うと、コマンドは正しく機能しません。このエラーを修正するには、ダッシュをハイフンに変更します。Word でこのオートフォーマット機能を無効にするには、[ファイル] メニューから [オプション] を選択し、[文章校正] タブをクリックして、[オートコレクト] ダイアログ ボックスを開きます。

既存の SharePoint 2010 製品環境

"既存の SharePoint 2010 製品環境で、Kerberos 認証が機能していると考えられない場合に、その構成を検証し、デバッグする方法について説明します"

ステップ バイ ステップ構成記事には、さまざまなシナリオで、自分の環境をトリアージ方式で判断するのに役立つ複数のチェックリストが用意されています。特にシナリオ 1 の「コア構成」をよく読んでください。Kerberos 構成をトリアージ方式で判断するための基本ツールと方法が記載されています。

SharePoint 2010 製品での ID シナリオ

SharePoint 2010 Productsで認証を行うときの ID について理解するために、3 つの主なシナリオ (受信認証、ファーム間/ファーム内認証、送信認証) でプラットフォームによる ID の処理方法を概念的に考察できます。

ファーム認証の図

受信 ID

受信認証シナリオは、クライアントがその ID をプラットフォームに対して示す、つまり、Web アプリケーションまたは Web サービスとの間で認証を行う方法を表しています。SharePoint Server では、クライアントの ID を使用して、Web ページ、ドキュメントなど、SharePoint Server のセキュリティで保護されたリソースにアクセスする許可をクライアントに付与します。

SharePoint 2010 Productsでは、クライアントがプラットフォームと認証を行うことができる 2 つのモード (クラシック モードとクレーム モード) をサポートしています。

クラシック モード

クラシック モードでは、以前のバージョンの SharePoint Server で既に習得している可能性がある典型的なインターネット インフォメーション サービス (IIS) 認証方法を使用できます。クラシック モードを使用するように SharePoint Server 2010 Web アプリケーションを構成する場合には、次の IIS 認証方法を使用することを選択できます。

統合 Windows 認証

統合 Windows 認証を使用すると、Windows クライアントが資格情報 (ユーザー名/パスワード) を手動で入力しなくても SharePoint Server との認証をシームレスに実行できます。Internet Explorer から SharePoint Server にアクセスするユーザーは、Internet Explorer プロセスを実行している資格情報を使用して認証を行います。既定では、この資格情報はユーザーがデスクトップにログオンするときに使用した資格情報です。Windows 統合モードで SharePoint Server にアクセスするサービスまたはアプリケーションは、実行中のスレッドの資格情報 (既定ではプロセス ID) を使用して認証を試みます。

NTLM

NT LAN Manager (NTLM) は、統合 Windows 認証を選択したときの既定のプロトコルの種類です。このプロトコルでは、3 部構成のチャレンジ レスポンス シーケンスを利用してクライアントを認証します。NTLM の詳細については、「Microsoft NTLM (英語)」(https://go.microsoft.com/fwlink/?linkid=196643&clcid=0x411) (英語) を参照してください。

利点:

  • 構成が簡単で、通常は、インフラストラクチャまたは環境構成を追加しなくても機能します。

  • クライアントがドメインの一部でない場合、または、SharePoint Server が存在するドメインによって信頼されているドメインに存在しない場合にも機能します。

欠点:

  • クライアントの認証応答を検証する必要があるたびに SharePoint Server はドメイン コントローラーと通信する必要があります。このため、ドメイン コントローラーへのトラフィックが増えます。

  • バックエンド システムへのクライアント資格情報の委任は実行できません (ダブルホップ ルールと呼ばれています)。

  • これは財産的価値のあるプロトコルです。

  • サーバー認証をサポートしていません。

  • Kerberos 認証よりもセキュリティが低いと考えられます。

Kerberos プロトコル

Kerberos プロトコルは、チケット認証をサポートするセキュリティが高いプロトコルです。Kerberos 認証サーバーは、有効なユーザー資格情報とサービス プリンシパル名 (SPN) がクライアント コンピューター認証要求に含まれている場合、その要求に対する応答でチケットを発行します。クライアント コンピューターは、そのチケットを使用してネットワーク リソースにアクセスします。Kerberos 認証を有効にするには、クライアント コンピューターおよびサーバー コンピューターがドメインのキー配布センター (KDC) との間に信頼関係接続を保持している必要があります。KDC は、共有秘密キーを配布して暗号化を有効にします。さらに、クライアント コンピューターおよびサーバー コンピューターは、Active Directory ディレクトリ サービスにアクセスできる必要があります。Active Directory では、フォレスト ルート ドメインが Kerberos 認証参照の中心となります。Kerberos プロトコルの詳細については、「How the Kerberos Version 5 Authentication Protocol Works (英語)」(https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x411) (英語) および「Microsoft Kerberos (英語)」(https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x411) (英語) を参照してください。

利点:

  • 最もセキュリティが高い統合 Windows 認証プロトコルです。

  • クライアント資格情報を委任できます。

  • クライアントとサーバーの相互認証をサポートしています。

  • ドメイン コントローラーへのトラフィックを少なくします。

  • 多数のプラットフォームとベンダーでサポートされているオープン プロトコルです。

欠点:

  • 適切に機能するには、インフラストラクチャと環境の追加構成が必要です。

  • クライアントは、TCP/UDP ポート 88 (Kerberos) および TCP/UDP ポート 464 (Kerberos パスワード変更 – Windows) を経由して KDC (Windows 環境では Active Directory ドメイン コントローラー) に接続する必要があります。

その他の方法

NTLM と Kerberos 認証の他に、SharePoint Server では、基本認証、ダイジェスト認証、証明書ベースの認証など、他の種類の IIS 認証をサポートしています。ここでは、これらの認証方法については説明しません。これらのプロトコルの機能の詳細については、「Authentication Methods Supported in IIS 6.0 (IIS 6.0) (英語)」(https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x411) (英語) を参照してください。

クレーム ベース認証

クレーム認証のサポートは、SharePoint 2010 Productsの新機能で、Windows Identity Foundation (WIF) に基づいて構築されています。クレーム モデルでは、SharePoint Server は、認証対象のクライアントに関する 1 つ以上のクレームを受け付けて、クライアントを識別および承認します。クレームとは、SAML トークンの形で発行され、信頼できる機関によって示されるクライアントに関する情報のことです。たとえば、クレームで、"Bob はドメイン Contoso.com の Enterprise Admins グループのメンバーである" と示されることがあります。このクレームが、SharePoint Server が信頼しているプロバイダーから発行された場合、プラットフォームはこの情報を使用して Bob を認証し、SharePoint Server リソースへのアクセスを承認できます。クレーム認証の詳細については、「A Guide to Claims-based Identity and Access Control (英語)」(https://go.microsoft.com/fwlink/?linkid=187911&clcid=0x411) (英語) を参照してください。

受信認証に関して SharePoint 2010 Productsでサポートされるクレームの種類は、Windows クレーム、フォーム ベース認証クレーム、および SAML クレームです。

Windows クレーム

Windows クレーム モードのサインインでは、SharePoint Server は、標準の統合 Windows 認証 (NTLM/Kerberos) を使用してクライアントを認証し、その結果生成された Windows ID をクレーム ID に変換します。

フォーム ベース認証クレーム

フォーム ベース認証クレーム モードでは、SharePoint Server は、標準の ASP.NET ログオン コントロールをホストしているログオン ページにクライアントをリダイレクトします。このページでは、ASP.NET メンバーシップとロール プロバイダーを使用してクライアントを認証します。これは、Office SharePoint Server 2007 でのフォーム ベース認証の動作と似ています。ユーザーを表す ID オブジェクトが作成されると、SharePoint Server はこの ID をクレーム ID オブジェクトに変換します。

SAML クレーム

SAML クレーム モードでは、SharePoint Server は、信頼できる外部のセキュリティ トークン プロバイダー (STS) から発行された SAML トークンを受け付けます。ユーザーがログオンしようとすると、コメントが表示され、外部のクレーム プロバイダー (たとえば、Windows Live ID クレーム プロバイダー) に転送されます。このクレーム プロバイダーが、ユーザーを認証して SAML トークンを生成します。SharePoint Server は、このトークンを受け付けて処理し、クレームの強化とそのユーザーのクレーム ID オブジェクトの作成を行います。

SharePoint 2010 Productsでのクレーム ベース認証の詳細については、「SharePoint クレームベース ID」を参照してください。

受信クレーム認証と Claims to Windows Token Service (C2WTS) に関する注意事項

一部のサービス アプリケーションでは、Windows Identity Foundation (WIF) Claims to Windows Token Service (C2WTS) を使用してファーム内のクレームを Windows 資格情報に変換し、送信認証を行う必要があります。C2WTS が機能するのは、受信認証の方法がクラシック モードまたは Windows クレームのどちらかの場合だけであることを理解することが重要です。クレームが構成されている場合、C2WTS は Windows クレームだけを要求します。このため、Web アプリケーションは、その Web アプリケーションに対して複数の形式のクレームを使用できません。複数の形式を使用した場合、C2WTS は機能しません。

SharePoint 2010 製品環境内での ID

SharePoint 2010 Products環境では、使用されている受信認証の方法に関係なく、ほとんどの SharePoint サービス アプリケーションと SharePoint 統合製品とのファーム内およびファーム間通信にクレーム認証を使用します。つまり、特定の Web アプリケーションとの認証にクラシック認証が使用されている場合でも、SharePoint 製品は受信 ID をクレーム ID に変換して、クレームに対応している SharePoint サービス アプリケーションおよび製品との認証を行います。ファーム内またはファーム間通信に関してクレーム モデルを標準とすることによって、プラットフォームは使用されている受信プロトコルからプラットフォーム自体を分離できます。

注意

SQL Server Reporting Services のような、SharePoint Server と統合されている一部の製品は、クレームに対応しておらず、ファーム内のクレーム認証アーキテクチャを利用しません。例えば、RSS ビューアー Web パーツが認証されたフィードを使用するように構成されている場合、SharePoint Server では、他のシナリオでクラシック Kerberos 委任とクレームを利用することがあります。クレームベースの認証と ID 委任をサポートできるかどうか確認するには、各製品またはサービス アプリケーションのドキュメントを参照してください。

送信 ID

SharePoint 2010 Productsの送信 ID は、ファーム内のサービスが外部の基幹業務システムおよびサービスと認証を行う必要があるシナリオを表しています。シナリオに応じて、次の 2 つの基本概念モデルのどちらかを使用して認証を実行できます。

信頼されたサブシステム

信頼されたサブシステムでは、フロントエンド サービスは、クライアントを認証および承認してから、クライアント ID をバックエンド システムに渡さずに他のバックエンド サービスとの認証を行います。バックエンド システムは、フロントエンド サービスを信頼して、バックエンド システムの代わりに認証と承認を行ってもらいます。このモデルを実装する最も一般的な方法は、共有サービス アカウントを使用して外部システムとの認証を行う方法です。

信頼されたサブシステムの図

SharePoint Server では、このモデルは以下の複数の方法で実装できます。

  • IIS アプリケーション プール ID を使用する — 通常、これは、外部システムを呼び出しているときにアクセス許可を昇格するコードを Web アプリケーションで実行することで実現します。RevertToSelf を使用するなど、他の方法でもアプリケーション プールの ID を使用して外部システムとの認証を行うことができます。

  • サービス アカウントを使用する — 通常は、これは、アプリケーション資格情報を Secure Store に格納し、その資格情報を使用して外部システムとの認証を行うことで実現します。埋め込み接続文字列のような他の方法でサービス アカウント資格情報を格納する方法もあります。

  • 匿名認証 — これは、外部システムに認証が必要ない場合の方法です。このため、フロントエンド SharePoint Server サービスは、バックエンド システムに ID を渡す必要がありません。

委任

委任モデルでは、フロントエンド サービスは、最初に、クライアントを認証し、次にクライアントの ID を使用して、独自の認証と承認を実行する別のバックエンド システムとの認証を行います。

委任プロセスの図

SharePoint 2010 Productsでは、このモデルは以下の複数の方法で実装できます。

  • Kerberos 委任 — クライアントが Kerberos 認証を使用してフロントエンド サービスとの認証を行う場合、Kerberos 委任を使用してクライアントの ID をバックエンド システムに渡すことができます。

  • クレーム — クレーム認証では、2 つのサービス間に信頼関係があり、両方のサービスがクレームに対応している場合は、クライアントのクレームをそのサービス間で渡すことができます。

注意

現在、SharePoint Server に用意されているほとんどのサービス アプリケーションは、送信クレーム認証に対応していませんが、送信クレームは、今後利用されるプラットフォーム機能の 1 つです。また、今日の普及している基幹業務システムの多くでは、受信クレーム認証をサポートしていません。つまり、送信クレーム認証は使用できないか、適切に機能するためには追加の開発が必要です。

ドメインとフォレストの境界を越えた委任

この一連の Kerberos 認証に関する記事のシナリオでは、SharePoint Server サービスと外部データ ソースは同じ Windows ドメインに存在する必要があります。これは、Kerberos の制約付き委任に必要な条件です。Kerberos プロトコルでは、基本 (制約なし) と制約付きの 2 種類の委任をサポートしています。基本 Kerberos 委任では、1 つのフォレスト内でドメインの境界を越えることはできますが、信頼関係にかかわらずフォレストの境界を越えることはできません。Kerberos の制約付き委任では、すべてのシナリオで、ドメインまたはフォレストの境界を越えることができません。

一部の SharePoint Server サービスは、基本 Kerberos 委任を使用するように構成できますが、他のサービスでは制約付き委任を使用する必要があります。Claims to Windows Token Service (C2WTS) を利用するサービスでは、Kerberos の制約付き委任を使用して、C2WTS が Kerberos のプロトコル遷移を使用してクレームを Windows 資格情報に変換できるようにする必要があります。

次のサービス アプリケーションと製品には、C2WTS と Kerberos の制約付き委任が必要です。

  • Excel Services

  • PerformancePoint Services

  • InfoPath Forms Services

  • Visio Services

次のサービス アプリケーションと製品は、これらの要件の影響を受けないので、必要に応じて基本委任を使用できます。

  • Business Data Connectivity Service および Microsoft Business Connectivity Services

  • Access Services

  • Microsoft SQL Server Reporting Services (SSRS)

  • Microsoft Project Server 2010

次のサービス アプリケーションでは、クライアント資格情報の委任を実行できないので、これらの要件の影響を受けません。

  • Microsoft SQL Server PowerPivot for Microsoft SharePoint

クレーム入門

クレームの概念とクレーム ベース認証の概要については、「An Introduction to Claims (英語)」(https://go.microsoft.com/fwlink/?linkid=196648&clcid=0x411) (英語) および「SharePoint クレームベース ID」(https://go.microsoft.com/fwlink/?linkid=196647&clcid=0x411) を参照してください。

Kerberos プロトコル入門

Kerberos プロトコルの概念の概要については、「Microsoft Kerberos (Windows) (英語)」(https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x411) (英語)、「Kerberos Explained (英語)」(https://go.microsoft.com/fwlink/?linkid=196649&clcid=0x411) (英語)、および「Ask the Directory Services Team: Kerberos for the Busy Admin (英語)」(https://go.microsoft.com/fwlink/?linkid=196650&clcid=0x411) (英語) を参照してください。

Kerberos プロトコルの利点

SharePoint Server (または任意の Web アプリケーション) を Kerberos プロトコルを使用するように構成する方法を詳しく説明する前に、Kerberos プロトコルの概要と使用を推奨する理由について説明します。

通常、Kerberos プロトコルを使用する理由は主に 3 つあります。

  1. クライアント資格情報の委任 — Kerberos プロトコルでは、クライアントの ID をサービスが偽装して、偽装を行っているサービスがクライアントの代わりにその ID を他のネットワーク サービスに渡すことができます。NTLM では、このような委任は実行できません (この NTLM の制限は "ダブルホップ ルール" と呼ばれています)。Kerberos 認証のようなクレーム認証を使用して、クライアント資格情報を委任できますが、バックエンド アプリケーションがクレームに対応している必要があります。

  2. セキュリティ — Kerberos プロトコルには、AES 暗号化、相互認証、データ整合性とデータ プライバシーのサポートをはじめとする機能が備わっているので、NTLM プロトコルよりもセキュリティが高いです。

  3. パフォーマンスを向上できる可能性 — Kerberos 認証に必要なドメイン コントローラーに対するトラフィックは、NTLM に比べて少なくなります (PAC 検証によって異なります。「Microsoft Open Specification Support Team Blog: Understanding Microsoft Kerberos PAC Validation (英語)」を参照してください)。PAC 検証が無効または不要な場合、クライアントを認証するサービスは、DC に対して RPC 呼び出しを行う必要がありません (「Windows 2000 または Windows Server 2003 でドメイン メンバーに大容量のサーバー プログラムを実行すると、ユーザー認証プロセスで遅延が発生します。」を参照してください)。また、Kerberos 認証は、NTLM と比べてクライアントとサーバー間に必要なトラフィックも少なくなります。クライアントは、2 つの要求/応答で Web サーバーとの認証を行うことができるのに対し、NTLM では、通常、3 回のハンドシェイクが必要です。ただし、遅延の短いネットワークのトランザクション単位では、ほとんどの場合、この機能向上に気付きません。全体のシステム スループットでは、この機能向上に気付く可能性があります。多くの環境要因が認証パフォーマンスに影響する可能性があることに注意してください。このため、ユーザーの環境で Kerberos 認証と NTLM のパフォーマンス テストを実施してから、どちらの方法のパフォーマンスが優れているかどうかを確認することをお勧めします。

Kerberos プロトコルを使用する利点はこれだけではありません。相互認証、プラットフォーム間の相互運用性、遷移的なドメイン間の信頼関係などの利点があります。ただし、ほとんどの場合、委任とセキュリティが Kerberos プロトコルを採用する主なきっかけとなります。

Kerberos 委任、制約付き委任、およびプロトコル遷移

Windows プラットフォーム上の Kerberos バージョン 5 プロトコルでは、基本 (制約なし) 委任と制約付き委任の 2 種類の ID 委任をサポートしています。

種類 利点 欠点

基本委任

  • 1 つのフォレスト内でドメインの境界を越えることができる。

  • 制約付き委任よりも必要な構成が少ない。

  • プロトコル遷移をサポートしていない。

  • セキュリティ。フロントエンド サービスが危害を受けた場合、クライアント ID をフォレスト内の Kerberos 認証を受け付ける任意のサービスに委任できる。

制約付き委任

  • Kerberos 以外の受信認証プロトコルを Kerberos に遷移できる (たとえば、NTLM から Kerberos、クレームから Kerberos)。

  • セキュリティが高い。ID は指定のサービスにのみ委任できる。

  • ドメインの境界を越えることができない。

  • 追加のセットアップ構成が必要。

Kerberos 対応のサービスは、複数のサービスと複数のポップに対して複数回 ID を委任できます。ID をサービスからサービスに移動するときに委任方法を基本から制約付きに変更できます。ただし、逆方向には変更できません。これは、理解しておく必要がある重要な設計の詳細です。バックエンド サービスに基本委任が必要な場合 (たとえば、ドメインの境界を越えて委任を行う場合)、バックエンド サービスの前にあるすべてのサービスは、基本委任を使用する必要があります。任意のフロントエンド サービスで制約付き委任を使用した場合、バックエンド サービスは、ドメインの境界を越えるためにその制約付きトークンを制約なしトークンに変換できません。

プロトコル遷移により、Kerberos 認証に対応しているサービス (フロントエンド サービス) は、Kerberos 以外の ID を、Kerberos に対応している他のサービス (バックエンド サービス) に委任できる Kerberos ID に変換できます。プロトコル遷移には、Kerberos の制約付き委任が必要なので、プロトコル遷移が行われる ID はドメインの境界を越えることができません。フロントエンド サービスのユーザー権限に応じて、プロトコル遷移によって返される Kerberos チケットは、識別トークンまたは偽装トークンになります。制約付き委任とプロトコル遷移の詳細については、以下の記事を参照してください。

一般的なベスト プラクティスとして、Kerberos 委任が必要な場合は、可能な限り制約付き委任を使用することをお勧めします。ドメインの境界を越える委任が必要な場合には、委任パス上のすべてのサービスで基本委任を使用する必要があります。

Windows 2008 R2 と Windows 7 での Kerberos 認証の変更点

Windows Server 2008 R2 と Windows 7 では、Kerberos 認証に新機能が導入されています。変更点の概要については、「Kerberos 認証の変更点」(https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x411) および「Kerberos Enhancements (英語)」(https://go.microsoft.com/fwlink/?linkid=196656&clcid=0x411) (英語) を参照してください。また、IIS 7.0 カーネル モード認証 (「Internet Information Services (IIS) 7.0 Kernel Mode Authentication Settings (英語)」(https://go.microsoft.com/fwlink/?linkid=196657&clcid=0x411) (英語)) は、SharePoint Server ファームでサポートされていませんが、この認証機能について理解しておくことをお勧めします。

SharePoint 2010 製品での Kerberos 構成の変更点

SharePoint 2010 Productsで Kerberos 認証を構成するときの基本概念はほとんど変わっていません。引き続き、サービス プリンシパル名を構成し、コンピューターとサービス アカウントで委任設定を構成する必要があります。ただし、以下に示す複数の変更に注意する必要があります。

  • 制約付き委任 — Claims to Windows Token Service を使用するサービスに必要です。クレームを Windows トークンに変換するプロトコル遷移を実行できるようにするには、制約付き委任が必要です。

  • サービス アプリケーション — Office SharePoint Server 2007 では、SSP サービスには、委任を有効にするために特別な SPN とサーバー レジストリの変更が必要でした。SharePoint 2010 Productsでは、サービス アプリケーションはクレーム認証と Claims to Windows Token Service を使用するので、これらの変更は必要ありません。

  • Windows Identity Foundation (WIF) — WIF Claims to Windows Token Service (C2WTS) は、委任シナリオでクレームを Windows トークンに変換するために SharePoint 2010 Productsによって利用される新しいサービスです。

Office SharePoint Server 2007 からアップグレードするときの考慮事項

Office SharePoint Server 2007 ファームを SharePoint Server 2010 にアップグレードする場合は、以下の複数の項目について考慮して、このアップグレードを完了する必要があります。

  • Web アプリケーションが URL を変更している場合、必ずサービス プリンシパル名を更新して、DNS 名を反映します。

  • SSP サービス プリンシパル名を削除します。これは、SharePoint Server 2010 では必要ありません。

  • 委任が必要なサービス アプリケーション (たとえば、Excel Services、Visio Graphics Service) を実行しているサーバーで Claims to Windows Token Service を開始します。

  • [任意の認証プロトコルを使う] を使用して Kerberos の制約付き委任を構成し、C2WTS を使用した Kerberos の制約付き委任を実行できるようにします。

  • IIS でカーネル モード認証が無効になっていることを確認します。