SharePoint Server でユーザー認証方法を計画する

  • [アーティクル]

適用対象:yes-img-13 2013yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

注:

ここで説明するユーザー認証方法は、SharePoint Server 2013、SharePoint Server 2016、SharePoint Server 2019、SharePoint Server サブスクリプション エディションに適用されます。

SharePoint Server でサポートされるユーザー認証の種類と方式について説明し、Web アプリケーションおよびゾーンでどれを使用するか決定する方法について説明します。

Microsoft 365 での SharePoint 認証について説明します。

注:

SharePoint Server サブスクリプション エディションでは、OIDC 1.0 認証がサポートされるようになりました。 この新しい認証の種類を操作する方法の詳細については、「 OpenID Connect 1.0 認証」を参照してください。

概要

ユーザー認証は、認証プロバイダーに対するユーザーの ID の検証です。これは、ユーザーの資格情報を含み、ユーザーが正しく送信したことを確認できるディレクトリまたはデータベースです。 認証プロバイダーの例としては、Active Directory Domain Services (AD DS) があります。 認証プロバイダーのその他の用語は、ユーザー ディレクトリと属性ストアです。

認証方法は、アカウント資格情報と、ユーザーの ID をアサートするその他の情報の特定の交換です。 認証方式の結果は、一般的には、認証プロバイダーがユーザーを認証したというクレームを含むトークンの形式の証明になります。

認証の種類とは、時には業界標準プロトコルを使用して、1 つまたは複数の認証プロバイダーに対して資格情報を確認する特定の方法です。 認証の種類では、複数の認証方式を使用できます。

ユーザー ID の検証後、ユーザーがアクセスできるサイト、コンテンツ、および機能が承認プロセスによって決定されます。

ユーザー認証の種類と方法の計画によって、次の決定が行われます。

  • 各 Web アプリケーションおよびゾーン用のユーザー認証の種類および方式

  • 決定された認証の種類と方式をサポートする目的で必要な認証インフラストラクチャ

    注:

    Windows クラシック モード認証は、SharePoint Server 2016、SharePoint Server 2019、SharePoint Server サブスクリプション エディションではサポートされなくなりました。

クレーム ベース認証

AD DS 内のユーザー ID は、ユーザー アカウントに基づきます。 適切な認証では、ユーザーはアカウント名とパスワードを提出します。 リソースへのアクセスを決定する目的で、アプリケーションは、ネットワーク上でのグループ メンバーシップまたは役割のような、アカウント属性とその他の情報について AD DS に対してクエリを実行することがあります。 この機能は Windows 環境には適していますが、インターネット、パートナー、またはクラウドベースのコンピューティング モデルをサポートするサード パーティの認証プロバイダーやマルチベンダー環境にはスケールアウトされません。

クレームベース ID では、ユーザーは、一般的に、信頼できる ID プロバイダーからデジタル署名セキュリティ トークンを取得します。 トークンには一連のクレームが含まれます。 各要求は、ユーザーの名前、グループ メンバーシップ、ネットワーク上のロールなど、ユーザーに関するデータの特定の項目を表します。 クレームベース認証は、クレームベースの ID テクノロジとインフラストラクチャを使用するユーザー認証です。 クレームベース認証をサポートするアプリケーションは、資格情報の代わりに、ユーザーからセキュリティ トークンを取得し、クレーム内のその情報を使用してリソースへのアクセスを決定します。 AD DS のようなディレクトリ サービスへの個別のクエリは不要です。

Windows でのクレームベース認証は、クレームベースの ID を実装する目的で使用される一連の .NET Framework クラスである Windows Identity Foundation (WIF) に基づいています。 クレームベース認証では、WS-Federation、WS-Trust などの標準や、SAML (Security Assertion Markup Language) などのプロトコルが利用されます。

クレームベース認証の詳細については、以下を参照してください。

ユーザー認証、サーバー間認証、アプリ認証に要求ベースの認証が広く使用されているため、SharePoint Server ファームのすべての Web アプリケーションとゾーンに対してクレーム ベースの認証をお勧めします。 詳細については、「SharePoint Server でサーバー間認証を計画する」を参照してください。 要求ベースの認証を使用する場合、サポートされているすべての認証方法を Web アプリケーションで使用でき、サーバー間認証とアプリ認証を使用する SharePoint Server の新機能とシナリオを利用できます。

要求ベースの認証の場合、SharePoint Server はすべてのユーザー アカウントをクレーム ID に自動的に変更します。 この変更により、各ユーザーのセキュリティ トークン (要求トークンとも呼ばれます) が生成されます。 要求トークンには、ユーザーに関連する要求が含まれています。 Windows アカウントは Windows 要求に変換されます。 フォーム ベースのメンバーシップ ユーザーは、フォーム ベースの認証要求に変換されます。 SharePoint Server では、SAML ベースのトークンに含まれる要求を使用できます。 さらに、SharePoint 開発者と管理者は、より多くの要求でユーザー トークンを拡張できます。 たとえば、Windows ユーザー アカウントとフォーム ベースのアカウントは、SharePoint Server で使用される追加の要求で拡張できます。

SharePoint Server でクレーム ベースの認証を使用するためにクレーム アーキテクトである必要はありません。 ただし、「SAML トークンベース認証の計画」で後述するように、SAML トークンベース認証を実装するには、クレームベース環境の管理者との連携が必要です。

SharePoint Server 2013 でのクラシック モード認証

SharePoint 2013では、サーバーの全体管理で Web アプリケーションを作成するとき、クレームベース認証の、認証の種類および方式のみを指定できます。 SharePoint の以前のバージョンでは、サーバーの全体管理で、Web アプリケーションのクラシック モード認証も構成できました。 クラシック モード認証は Windows 認証を使用し、SharePoint 2013は AD DS アカウントとしてユーザー アカウントを処理します。

クラシック モード認証を使用するように Web アプリケーションを構成するには、 New-SPWebApplication PowerShell コマンドレットを使用して作成する必要があります。 クラシック モード認証用に構成された SharePoint 2010 製品 Web アプリケーションは、SharePoint 2013にアップグレードしたとき、その認証設定を保持します。 しかし、SharePoint 2013にアップグレードする前に、Web アプリケーションをクレームベース認証に移行することを推奨します。

SharePoint 2013ファームでは、両方のモードを使用する Web アプリケーションを混合して含めることができます。 一部のサービスでは、従来の Windows アカウントと Windows 要求アカウントであるユーザー アカウントが区別されません。

アップグレードする前に移行することの詳細については、「SharePoint 2013 でクラシックモードからクレームベース認証に移行する」を参照してください。

アップグレード後の移行の詳細については、「Migrate from classic-mode to claims-based authentication in SharePoint Server」を参照してください。

SharePoint 2013でクラシック モード認証を使用する Web アプリケーションを作成する方法については、「クラシック モード認証を使用する Web アプリケーションを作成する (SharePoint Server)」を参照してください。 要求ベースの認証を使用してクラシック モード認証を使用する Web アプリケーションを移行することはできません。

重要

Office Online は、クレームベース認証を使用する SharePoint 2013 Web アプリケーションでのみ使用できます。 クラシック モード認証を使用する SharePoint 2013 Web アプリケーションでは、Office Online の表示と編集は正常に機能しません。 クラシック モード認証を使用する SharePoint 2010 Web アプリケーションを SharePoint 2013 に移行する場合は、それらの Web アプリケーションが Office Online で機能するように認証方法をクレームベース認証に移行する必要があります。

サポートされる認証の種類および方式

SharePoint Server では、次の認証の種類のさまざまな認証方法と認証プロバイダーがサポートされています。

  • Windows 認証

  • フォームベース認証

  • SAML トークンベース認証

Windows 認証

Windows 認証型は、既存のWindows 認証 プロバイダー (AD DS) と、Windows ドメイン環境が接続クライアントの資格情報を検証するために使用する認証プロトコルを利用します。 Windows 認証方法は、両方の要求ベースの認証で使用されます。

  • NTLM

  • Kerberos

  • ダイジェスト

  • 基本

詳細については、この記事の「Windows 認証の計画」を参照してください。

SharePoint 2013 および SharePoint Server 2016 での Windows クレーム認証のビデオを参照してください

Windows 認証の種類ではありませんが、SharePoint Server は、匿名認証もサポートします。 ユーザーは、自分の資格情報を確認されることなく SharePoint コンテンツにアクセスできます。 匿名認証は既定で無効です。 通常、SharePoint Server を使用してセキュリティを必要とせず、パブリック インターネット Web サイトなど、すべてのユーザーが利用できるコンテンツを公開する場合は、匿名認証を使用します。

匿名認証を有効にするだけでなく、サイトとサイト リソースに対する匿名アクセス (アクセス許可) も構成する必要があります。

注:

匿名認証とフォーム認証の SharePoint の設定が無効であっても、Web アプリケーションを提供するために SharePoint によって作成された インターネット インフォメーション サービス (IIS) Web サイトでは、匿名認証とフォーム認証のメソッドが常に有効になります。 　　　これは意図的なものであり、IIS 設定で匿名認証またはフォーム認証を直接無効にすると SharePoint サイトでエラーが発生します。

フォームベース認証

フォームベース認証は、ASP.NET のメンバーシップ プロバイダーとロール プロバイダーの認証に基づく、クレームベース ID 管理システムです。 フォーム ベースの認証は、次のような認証プロバイダーに格納されている資格情報に対して使用できます。

  • AD DS

  • SQL Server データベースのようなデータベース

  • Novell eDirectory、NDS (Novell Directory Services)、または Sun ONE などの LDAP (Lightweight Directory Access Protocol) データ ストア

フォーム ベース認証では、ユーザーがログオン フォーム (一般的には Web ページ) で入力する資格情報に基づいてユーザーを検証します。 認証されていない要求はサインイン ページにリダイレクトされます。ここで、ユーザーは有効な資格情報を指定し、フォームを送信する必要があります。 後続の要求の ID を再確立するキーを含む Cookie が発行されます。

SharePoint 2013 および SharePoint Server 2016 でのフォーム ベース クレーム認証のビデオを参照してください

注:

フォーム ベース認証では、ユーザー アカウント資格情報はプレーンテキストとして送信されます。 したがって、Web サイト トラフィックを暗号化する SSL (Secure Sockets Layer) を使用していない場合は、フォーム ベース認証を使用しないでください。

詳細については、「フォームベース認証の計画」を参照してください。

SAML トークンベース認証

SharePoint Server での SAML トークンベース認証は、SAML 1.1 プロトコルと WS-Federation パッシブ リクエスター プロファイル (WS-F PRP) を使用します。 SAML トークンベース認証では、独自の内部環境とパートナーの環境のどちらの場合でも、クレームベース環境の管理者との連携が必要です。 Active Directory フェデレーション サービス (ADFS) 2.0 を使用する場合、SAML トークンベース認証環境を既に持っています。

SAML トークンベース認証環境には、ID プロバイダー セキュリティ トークン サービス (IP-STS) が含まれます。 IP-STS は、関連する認証プロバイダーにアカウントが含まれるユーザーに代わって、SAML トークンを発行します。 トークンには、ユーザー名、ユーザーが属するグループなど、ユーザーに関する任意の数のクレームを含めることができます。 AD FS 2.0 サーバーは IP-STS の一例です。

SharePoint Server では、IP-STS が発行するトークンに含まれるクレームを利用してユーザーを認証します。 クレーム環境内で SAML トークンを受け取るアプリケーションを、証明書利用者 STS (RP-STS) と呼びます。 証明書利用者アプリケーションは SAML トークンを受け取り、その中のクレームを使用して、要求されたリソースへのアクセス権をクライアントに付与するかどうかを判断します。 SharePoint Server では、SAML プロバイダーを使用するように構成されている各 Web アプリケーションは、個別の RP-STS エントリとして IP-STS サーバーに追加されます。 SharePoint ファームは、IP-STS 内の複数の RP-STS エントリを含むことができます。

SharePoint 2013 および SharePoint Server 2016 での SAML ベース クレーム認証のビデオを参照してください

SAML トークンベース認証の認証プロバイダーのセットは、クレーム環境の IP-STS に基づきます。 AD FS 2.0 を使用する場合、認証プロバイダー (AD FS 2.0 の属性ストアと呼ばれます) には次のものが含まれます。

  • Windows Server 2003 Active Directory と Windows Server 2008 での AD DS

  • SQL Server 2005 および SQL Server 2008 のすべてのエディション

  • カスタム属性ストア

詳細については、「SAML トークンベース認証の計画」を参照してください。

LDAP 環境での認証の種類の選択

SAML トークンベース認証、またはフォーム ベース認証は LDAP 環境を使用することができます。 現在の LDAP 環境に一致する認証の種類を使用します。 LDAP 環境がまだない場合は、複雑さが少ないため、フォームベースの認証を使用することをお勧めします。 しかし、認証環境が既に WS-Federation 1.1 と SAML 1.1 をサポートしている場合は、SAML をお勧めします。 SharePoint Server には、LDAP プロバイダーが組み込まれています。

Windows 認証の計画

Windows 認証方法の計画と実装の過程は、クレームベース認証の場合に似ています。 Web アプリケーションの要求ベースの認証では、Windows 認証メソッドの実装の複雑さが増すわけではありません。 ここでは、Windows 認証方式の計画の概要を示します。

NTLM および Kerberos プロトコル

NTLM および Kerberos プロトコルは、両方とも統合 Windows 認証方法であり、ユーザーは資格情報の入力を求められずにシームレスに認証されます。 次に例を示します。

  • Internet Explorer から SharePoint サイトにアクセスするユーザーは、Internet Explorer プロセスが認証用に実行されている資格情報を使用します。 既定では、これらの資格情報は、ユーザーがコンピューターのサインインに使用した資格情報です。

  • 統合 Windows 認証方式を使用し SharePoint リソースにアクセスするサービスまたはアプリケーションは、既定でプロセスの ID である実行中のスレッドの資格情報を使用して、認証を試みます。

NTLM は実装するWindows 認証の最も簡単な形式であり、通常は認証インフラストラクチャの追加構成を必要としません。 Web アプリケーションを作成または構成するときに、このオプションを選択します。

Kerberos プロトコルは、チケット認証をサポートします。 Kerberos プロトコルを使用するには、環境の構成を増やす必要があります。 Kerberos 認証を有効にするには、クライアント コンピューターおよびサーバー コンピューターが、ドメインのキー配布センター (KDC) への信頼関係接続を保持している必要があります。 Kerberos プロトコルを構成する場合、SharePoint Server をインストールする前に、AD DS でサービス プリンシパル名 (SPN) を設定します。

Kerberos 認証を検討すべき理由は、以下のとおりです。

  • Kerberos プロトコルは最も強力な統合 Windows 認証プロトコルであり、クライアントおよびサーバーの高度暗号化標準 (AES) 暗号、相互認証などの高度なセキュリティ機能をサポートしています。

  • Kerberos プロトコルを使用すると、クライアントの資格情報の委任を行うことができます。

  • 安全な認証方法の中でも Kerberos は AD DS ドメイン コントローラーへのトラフィックが最も少なくて済む方法です。 Kerberos では、特定のシナリオでページの遅延を減らすことができ、状況によってはフロントエンド Web サーバーの処理ペース数を増やすことができます。 Kerberos はドメイン コントローラーへの負荷を減らすこともできます。

  • Kerberos プロトコルは、多くのプラットフォームおよびベンダーがサポートするオープンなプロトコルです。

Kerberos 認証が適切ではないかもしれない状況は、以下のとおりです。

  • Kerberos 認証を有効に機能させるには、その他の認証方式と比較して、インフラおよび環境で追加の構成が必要です。 多くの場合、Kerberos プロトコルを構成するにはドメイン管理者の権限が必要とされます。 Kerberos 認証は、セットアップや管理が複雑な面があります。 Kerberos を誤って構成すると、サイトへの認証がうまく行われません。

  • Kerberos 認証では、KDC および AD DS ドメイン コントローラーにクライアント コンピューターが接続できる必要があります。 Windows 展開では、AD DS ドメイン コントローラーが KDC となります。 このネットワーク構成は組織のイントラネットで一般的ですが、インターネットに接続する展開は通常、この方法では構成されません。

以下の手順では、Kerberos 認証を構成する方法を要約して説明します。

  1. SQL Server サービス アカウント用の SPN を AD DS で作成することにより、SQL Server 通信用の Kerberos 認証を構成します。

  2. Kerberos 認証を使用する Web アプリケーションの SPN を作成します。

  3. SharePoint Server ファームをインストールします。

  4. 特定のアカウントを使用する特定のサービスをファーム内で構成します。

  5. Kerberos 認証を使用する Web アプリケーションを作成します。

ダイジェストと基本

ダイジェスト認証方式では、ユーザー アカウント資格情報は、Web アプリケーションまたはゾーンをホストする Web サーバー上のインターネット インフォメーション サービス (IIS) サービスに、MD5 メッセージ ダイジェストとして送信されます。 基本認証方式では、ユーザー アカウント資格情報はプレーンテキストとして送信されます。 そのため、Ssl を使用して Web サイトトラフィックを暗号化しない限り、基本認証方法を使用しないでください。

現在の環境が、Web サイトに対してダイジェストまたはベーシックな認証のみをサポートする Web ブラウザーまたはサービスを使用している場合、これらの旧式の認証方式を使用する必要があることがあります。

NTLM、Kerberos、および匿名認証方式と異なり、ダイジェストおよび基本認証方式は、インターネット インフォメーション サービス (IIS) スナップインで Web アプリケーションまたはゾーンに対応する、Web サイトのプロパティから構成します。

要求ベースの認証を使用している場合は、次を参照してください。

フォームベース認証の計画

フォーム ベースの認証を使用して、Windows に基づいていない ID 管理システムまたは外部の ID 管理システムに対してユーザーを認証するには、メンバーシップ プロバイダーとロール マネージャーを Web.config ファイルに登録する必要があります。 SharePoint Server では、標準の ASP.NET ロール マネージャー インターフェイスを使用して、現在のユーザーに関するグループ情報を収集します。 SharePoint Server の承認プロセスは、各 ASP.NET ロールを 1 つのドメイン グループのように処理します。 Web.config ファイルでのロール マネージャーの登録は、認証用のメンバーシップ プロバイダーの登録と同じ方法で行います。

サーバーの全体管理 Web サイトからメンバーシップ ユーザーやロールを管理する場合は、サーバーの全体管理 Web サイトの Web.config ファイルにメンバーシップ プロバイダーとロール マネージャーを登録する必要があります。 コンテンツをホストする Web アプリケーションのWeb.config ファイルにメンバーシップ プロバイダーとロール マネージャーを登録します。

フォーム ベース認証を構成する詳細な手順については、「SharePoint Server でクレームベースの Web アプリケーション用にフォームベース認証を構成する」を参照してください。

SAML トークンベース認証の計画

SAML トークンベース プロバイダーの実装のアーキテクチャは、以下のコンポーネントから成ります。

  • SharePoint Security Token Service このサービスは、ファームが使用する SAML トークンを作成します。 サービスは自動的に作成され、サーバー ファーム内のすべてのサーバー上で開始されます。 すべてのファーム間通信でクレームベース認証を使用することから、このサービスはファーム間通信で使用されます。 また、クレーム認証を使用する Web アプリケーションに対して実装される認証方法でもこのサービスが使用されます。 これらの方法には、Windows 認証、フォーム ベースの認証、SAML トークンベースの認証が含まれます。

  • トークン署名証明書 (ImportTrustCertificate) この証明書は、IP-STS からエクスポートした後、ファーム内の 1 つのサーバーにコピーし、ファームの信頼されたルート機関の一覧に追加する証明書です。 この証明書を使用して SPTrustedIdentityTokenIssuer を作成すると、それを使用して別の証明書を作成することはできません。 証明書を使用して別の SPTrustedIdentityTokenIssuer を作成するには、最初に既存の SPTrustedIdentityTokenIssuer を削除する必要があります。 既存のものを削除する前に、それを使用しているすべての Web アプリケーションから関連付けを解除する必要があります。

  • ID クレーム SAML トークンからのクレームで、ユーザーの一意の ID です。 ユーザーごとに常に一意になるトークン内の値を理解しているのは IP-STS の所有者だけです。 ID クレームは、必要なすべてのクレームをマッピングの中で、標準のクレーム マッピングとして作成されます。 ID クレームとしての役割を果たすクレームは、SPTrustedIdentityTokenIssuer の作成時に宣言されます。

  • その他の要求 これらの要求は、ユーザーを記述する SAML チケットからの追加の要求で構成されます。 ユーザー ロールやユーザー グループに加えて、年齢など他の種類のクレームが含まれます。 すべてのクレーム マッピングは、SharePoint Server ファーム内のサーバー間でレプリケートされるオブジェクトとして作成されます。

  • 領域 SharePoint クレーム アーキテクチャで、SAML トークンベース プロバイダーを使用するように構成されている SharePoint Web アプリケーションに関連付けられた URI または URL が、領域を表します。 ファーム上で SAML トークンベース認証プロバイダーを作成するときに、IP-STS が認識する領域、つまり Web アプリケーションの URL を 1 つずつ指定します。 最初の領域は、SPTrustedIdentityTokenIssuer を作成するときに指定します。 SPTrustedIdentityTokenIssuer の作成後に、別の領域を追加できます。 領域は、 $realm = "urn:sharepoint:mysites" のような構文で指定します。 SPTrustedIdentityTokenIssuer に領域を追加した後、IP-STS サーバー上に領域識別子を持つ RP-STS 信頼関係を作成する必要があります。 このプロセスでは、Web アプリケーションの URL を指定します。

  • SPTrustedIdentityTokenIssuer IP-STS との間で通信したり、トークンを受け取ったりするのに必要な値を含む、SharePoint ファーム上に作成されるオブジェクトです。 SPTrustedIdentityTokenIssuer を作成するときは、使用するトークン署名証明書、最初の領域、ID 要求を表す要求、およびその他の要求を指定します。 STS からのトークン署名証明書は、1 つの SPTrustedIdentityTokenIssuer にのみ関連付けることができます。 ただし、SPTrustedIdentityTokenIssuer を作成した後は、追加の Web アプリケーション用に領域を追加できます。 SPTrustedIdentityTokenIssuer に領域を追加した後は、それを証明書利用者として IP-STS にも追加する必要があります。 SPTrustedIdentityTokenIssuer オブジェクトは、SharePoint Server ファーム内のサーバー間でレプリケートされます。

  • 証明書利用者 STS (RP-STS) SharePoint Server では、SAML プロバイダーを使用するように構成されている各 Web アプリケーションは、RP-STS エントリとして IP-STS サーバーに追加されます。 SharePoint Server ファームは、複数の RP-STS エントリを含むことができます。

  • ID プロバイダーセキュリティ トークン サービス (IP-STS) このサービスは、関連するユーザー ディレクトリに含まれているユーザーに代わって SAML トークンを発行する、要求環境のセキュリティで保護されたトークンです。

以下の図は、SharePoint Server SAML トークン クレーム アーキテクチャを示します。

SAML トークン クレーム アーキテクチャ

SharePoint クレーム認証コンポーネント

SPTrustedIdentityTokenIssuer オブジェクトは、次のようないくつかのパラメーターで作成されます。

  • 単一 ID クレーム。

  • 単一の SignInURL パラメーター。

    SignInURL パラメーターは、IP-STS に対する認証を行うために、ユーザー要求を リダイレクトする URL を指定します。

  • 単一の Wreply パラメーター。

    一部の IP-STS サーバーでは 、Wreply パラメーターが必要です。これは true または false に設定されます。 既定は False です。 Wreply パラメーターは、IP-STS で必要な場合にのみ使用します。

  • 複数の領域。

  • 複数のクレーム マッピング。

SharePoint Server で SAML トークンベースの認証を実装するには、事前に計画する必要がある次の手順を実装します。

  1. IP-STS からトークン署名証明書をエクスポートします。 SharePoint Server ファーム内のサーバーに証明書をコピーします。

  2. ユーザーの一意識別子として使用するクレームを定義します。 この要求は、ID 要求と呼ばれます。 ユーザー プリンシパル名 (UPN) またはユーザーの電子メール名がユーザー ID としてしばしば使用されます。 ユーザーごとに常に一意になるトークン内の値を理解しているのは IP-STS の所有者のみなので、IP-STS の管理者と連携して適切な ID を決定します。 ユーザーの一意識別子の識別は、クレーム マッピング プロセスに含まれます。 クレーム マッピングを作成するには、Microsoft PowerShell を使用します。

  3. 追加の要求マッピングを定義します。 SharePoint Server ファームが使用する受信トークンからの追加の要求を定義します。 ユーザー ロールは、SharePoint Server ファーム内のリソースにアクセス許可を割り当てるために使用できる要求の例です。 マッピングを持たない受信トークンからの要求はすべて破棄されます。

  4. PowerShell を使用して新しい認証プロバイダーを作成して、トークン署名証明書をインポートします。 このプロセスによって、 SPTrustedIdentityTokenIssuer が作成されます。 このプロセスでは、マップした ID 要求と追加の要求を指定します。 SAML トークンベースの認証用に構成する最初の SharePoint Web アプリケーションに関連付けられている領域を作成して指定します。 SPTrustedIdentityTokenIssuer を作成したら、追加の SharePoint Web アプリケーションの領域を作成して追加できます。 この手順では、同じ SPTrustedIdentityTokenIssuer を使用するように複数の Web アプリケーションを構成できます。

  5. SPTrustedIdentityTokenIssuer に追加される領域ごとに、IP-STS 上に RP-STS エントリを作成する必要があります。 このエントリは、SharePoint Web アプリケーションが存在する前に作成できます。 いずれにしても、Web アプリケーションを作成する前に URL を計画する必要があります。

  6. 既存、または新しい SharePoint Web のアプリケーションを、新しく作成した認証プロバイダーを使用するように構成します。 Web アプリケーションを作成したとき、認証プロバイダーはサーバーの全体管理で信頼できる ID プロバイダーとして表示されます。

複数の SAML トークンベース認証プロバイダーを構成できます。 ただし、トークン署名証明書を使用できるのは、ファーム内で 1 回のみです。 すべての構成済みのプロバイダーが、サーバーの全体管理にオプションとして表示されます。 異なる信頼された STS 環境からの要求は競合しません。

パートナー企業と SAML トークンベース認証を実装していて、独自の環境に IP-STS が含まれている場合、内部クレーム環境の管理者と連携して、内部の IP-STS からパートナーの STS への一方向の信頼関係を確立することをお勧めします。 この方法では、認証プロバイダーを SharePoint Server ファームに追加する必要はありません。 クレーム管理者がクレーム環境全体を管理することもできます。

重要

SharePoint Server でクレームベース認証を使用するときは、ネットワーク負荷分散を単一のアフィニティに設定する必要はなくなりました。

注:

SAML トークン ベース認証を使用するように Web アプリケーションが構成されている場合、ユーザー選択ウィンドウ コントロールに対する検索機能が SPTrustedClaimProvider クラスで提供されません。 ユーザー選択ウィンドウ コントロールで入力されたテキストは、有効なユーザー、グループ、またはクレームであるかどうかにかかわらず、解決済みであるかのように自動的に表示されます。 SharePoint Server ソリューションで SAML トークン ベース認証を使用する場合、独自の検索、名前解決を実装するカスタム クレーム プロバイダーの作成を計画してください。

AD FS を使用して SAML トークンベース認証を構成する詳細な手順については、「SharePoint Server で AD FS を使用して SAML ベースのクレーム認証を構成する」を参照してください。

Web アプリケーションのゾーンの計画

ゾーンは、Web アプリケーション内の同じサイトにアクセスするさまざまな論理パスを表します。 各 Web アプリケーションには、最大で 5 つのゾーンを含めることができます。 Web アプリケーションの作成時に、サーバーの全体管理は "既定" という名前のゾーンを作成します。 追加のゾーンを作成するには、Web アプリケーションを拡張し、残りのゾーン名の 1 つ (イントラネット、エクストラネット、インターネット、またはカスタム) を選択します。

ゾーンの計画は以下に基づきます。

  • クレームベース認証 (推奨) - 単一のゾーンに複数の認証プロバイダーを実装できます。 複数のゾーンも使用できます。

単一のゾーンに複数の種類の認証を実装する

クレームベース認証を使用していて、複数の方式の認証を実装しようとしている場合は、既定のゾーンに複数の種類の認証を実装することをお勧めします。 これにより、すべてのユーザーに対して同じ URL が生成されます。

同じゾーンに複数の認証方式を実装しようとしている場合、以下の制約があります。

  • 1 つのゾーンには、フォームベース認証の 1 つのインスタンスのみ実装できます。

  • サーバーの全体管理では、統合 Windows 方式と基本方式の両方を同時に使用できます。 それ以外の場合は、ゾーンに複数の種類のWindows 認証を実装することはできません。

ファームに対して複数の SAML トークンベース認証プロバイダーが構成されている場合、Web アプリケーションや新しいゾーンの作成時に、これらはすべてオプションとして表示されます。 同じゾーンに複数の SAML プロバイダーを構成できます。

次の図は、パートナーとのグループ作業用のサイトの既定のゾーンに実装されている複数の種類の認証を示しています。

既定のゾーンに複数の種類の認証を実装する

ゾーンでの複数の種類の認証

図では、異なるディレクトリ ストアからのユーザーが、同じ URL を使用してパートナーの Web サイトにアクセスしています。 パートナー企業を囲む点線のボックスは、ユーザー ディレクトリと、既定のゾーン内で構成されている認証の種類との間の関係を示しています。

コンテンツのクロールの計画

クロール コンポーネントは、コンテンツへのアクセスに NTLM を必要とします。 少なくとも 1 つのゾーンを、NTLM 認証を使用するように構成する必要があります。 既定のゾーンで NTLM 認証が構成されていない場合、クロール コンポーネントは NTLM 認証を使用するように構成された別のゾーンを使用できます。

複数のゾーンの実装

Web アプリケーションに対して複数のゾーンを実装する場合は、次のガイドラインに従ってください。

  • 既定のゾーンを使用して、最も安全な認証設定を実装します。 要求を特定のゾーンに関連付けることができない場合は、既定のゾーンの認証設定やその他のセキュリティ ポリシーが適用されます。 既定のゾーンは、Web アプリケーションの作成時に作成されるゾーンです。 通常、最も安全な認証設定はエンド ユーザー アクセス用に設計されています。 そのため、エンド ユーザーは既定のゾーンにアクセスする可能性があります。

  • ユーザーにアクセスを提供するのに必要な最小限度のゾーンを使用します。 各ゾーンは、Web アプリケーションにアクセスする新規 IIS サイトとドメインに関連付けられます。 必要な場合にのみ、新しいアクセス ポイントを追加します。

  • 少なくとも 1 つのゾーンに、クロール コンポーネント用の NTLM 認証の使用を構成します。 必要な場合を除き、インデックス コンポーネントの専用ゾーンを作成しないでください。

次の図は、パートナーとのグループ作業用のサイトでさまざまな種類の認証に対応するように実装されている複数のゾーンを示しています。

認証の種類ごとに 1 つのゾーン

各種類の認証に対して 1 つのゾーン

図の中で、既定のゾーンはリモートの従業員用に使用されています。 各ゾーンには、それぞれ異なる URL が関連付けられています。 従業員は、オフィスで作業しているか、リモートで作業しているかによって異なるゾーンを使用します。