SharePoint Server のサーバー間認証とユーザー プロファイル
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
サーバー間認証を使用すると、サーバー間認証に対応するいくつかのサーバーがリソースへのアクセスと要求をユーザーに代わって相互に行うことができます。 したがって、SharePoint Server を実行し、受信リソース要求を処理するサービスは、次の 2 つのタスクを完了できる必要があります。
要求を特定の SharePoint ユーザーに解決する
ユーザーに関連付けられた一連のロール クレームを確認する (ユーザーの ID の "リハイドレート" と呼ばれるプロセス)
ユーザーの ID をリハイドレートするために、サーバー間認証を実行できるサーバーは SharePoint リソースへのアクセスを要求します。 SharePoint Server は、受信セキュリティ トークンからクレームを取得して、そのクレームを特定の SharePoint ユーザーに解決します。 既定では、SharePoint Server は、組み込みの User Profile Service アプリケーションを使用して ID を解決します。
対応するユーザー プロファイルを探すための主要なユーザー属性は、次のとおりです。
Windows セキュリティ識別子 (SID)
Active Directory ドメイン サービス (AD DS) ユーザー プリンシパル名 (UPN)
簡易メール転送プロトコル (SMTP) アドレス
セッション開始プロトコル (SIP) アドレス
したがって、ユーザー プロファイル内でこれらのユーザー属性の少なくとも 1 つが最新のものである必要があります。
注:
SharePoint Server 2013 の場合のみ、ID ストアから User Profile Service アプリケーションへの定期的な同期をお勧めします。 詳細については「プロファイルの同期を計画する (SharePoint Server 2013)」を参照してください。
また、SharePoint Server は、上記の 4 つの属性に基づく特定の検索クエリに対して、User Profile Service アプリケーション内のエントリが 1 つだけ一致すると想定します。 そうでない場合、複数のユーザー プロファイルが検出されたというエラー状態を返します。 したがって、User Profile Service アプリケーション内にある現在不使用のユーザー プロファイルを定期的に削除して、これらの 4 つの属性を共有する複数のユーザー プロファイルが存在しないようにする必要があります。
ユーザー プロファイルとそのユーザーの関連するグループ メンバーシップが同期していない場合、SharePoint Server は、特定のリソースへのアクセスを不適切に拒否することがあります。 したがって、グループ メンバーシップが User Profile Service アプリケーションと同期していることをご確認ください。 Windows クレームの場合、User Profile Service アプリケーションが上記の 4 つの主要なユーザー属性とグループ メンバーシップをインポートします。
フォームベースおよび SAML (Security Assertion Markup Language) ベースのクレーム認証の場合、次の 1 つを実行する必要があります。
User Profile Service アプリケーションでサポートされるデータ ソースへの同期接続を作成し、その接続を特定のフォームベース認証プロバイダーまたは SAML 認証プロバイダーに関連付けます。 さらに、属性をユーザー ストアから上記の 4 つのユーザー属性にマップするか、4 つのユーザー属性のうち、データソースからの取得が可能なできるだけ多くのユーザー属性にマップする必要があります。
同期を手動で実行するには、カスタム コンポーネントを作成して展開します。 これは、Windows を使用しないユーザーに最も適切なオプションです。 フォームベースの認証プロバイダーや SAML 認証プロバイダーが呼び出されるのは、ユーザーのロール クレームを取得するためにユーザーの ID がリハイドレートされるときです。
要求側サーバーに応じたユーザーのリハイドレート
要求元サーバーが 2016 Exchange Serverまたは 2015 Skype for Business Server実行されている場合は、標準のWindows 認証メソッドを使用します。要求元サーバーから送信される受信セキュリティ トークンには、ユーザーの UPN が含まれ、SMTP、SIP、ユーザー ID の SID などの他の属性が含まれている可能性があります。 受信サーバーである SharePoint Server は、この情報を使用してユーザー プロファイルを検索します。
要求側のサーバーで SharePoint Server が実行されている場合、受信側のサーバーは、以下のクレームベースの認証方法を使用してユーザーのリハイドレートを行います。
Windows クレーム認証の場合、SharePoint Server は、AD DS 属性を使用して、ユーザーのユーザー プロファイル (UPN、SID の値など) とユーザーのロール クレーム (グループ メンバーシップ) を見つけます。
フォームベース認証の場合、SharePoint Server は、アカウント属性を使用してユーザーのプロファイルを探した後、ロール プロバイダーとすべての追加のカスタム クレーム プロバイダーを呼び出して、対応するロール クレーム セットを取得します。 たとえば、SharePoint Server は、SQL Server データベースなどのデータベース、または LDAP (ライトウェイト ディレクトリ アクセス プロトコル) データ ストアで、AD DS の属性を使用して、ユーザーを表すユーザー プロファイル (UPN、SID の値など) を見つけます。 フォームベース プロバイダーを同期するコンポーネントは、少なくとも、ユーザーのアカウント名でユーザー プロファイルを設定する必要があります。 また、カスタム クレーム プロバイダーを作成して、追加のクレームを属性としてユーザー プロファイルにインポートすることもできます。
SAML ベースの要求認証の場合、SharePoint Server は AccountName 属性を使用してユーザーのプロファイルを検索し、SAML プロバイダーと追加のすべてのカスタム要求プロバイダーを呼び出して、対応するロール要求のセットを取得します。 ユーザー ID 要求は、対応する SAML 要求プロバイダーを介してユーザー プロファイルの Account 属性にマップする必要があります。これは、ユーザー プロファイルを設定するように構成する必要があります。 同様に、UPN 要求を UPN 属性にマップし、SMTP 要求を SMTP 属性にマップする必要があります。 ユーザーが通常 ID プロバイダーから取得する要求のセットを複製するには、要求の拡張を通じて、ロール要求を含む要求を追加する必要があります。 カスタム要求プロバイダーは、それらの要求を属性としてユーザー プロファイルにインポートする必要があります。