チュートリアル: Microsoft Entra ID と SharePoint オンプレミスの間のフェデレーション認証を実装する
シナリオの説明
このチュートリアルでは、Microsoft Entra ID と SharePoint オンプレミスの間のフェデレーション認証を構成します。 ユーザーが Microsoft Entra ID にサインインし、その ID を使用して SharePoint オンプレミス サイトにアクセスできるようにすることが目標です。
前提条件
構成を実行するには、次のリソースが必要です。
- Microsoft Entra テナント。 アカウントがない場合は、無料アカウントを作成することができます。
- SharePoint 2013 以降のファーム。
この記事では、次の値を使用しています。
- エンタープライズ アプリケーション名 (Microsoft Entra ID):
SharePoint corporate farm
- 信頼識別子 (Microsoft Entra ID)、領域 (SharePoint 内):
urn:sharepoint:federation
- loginUrl (Microsoft Entra ID へ):
https://login.microsoftonline.com/dc38a67a-f981-4e24-ba16-4443ada44484/wsfed
- SharePoint サイトの URL:
https://spsites.contoso.local/
- SharePoint サイトの応答 URL:
https://spsites.contoso.local/_trust/
- SharePoint の信頼の構成名:
MicrosoftEntraTrust
- Microsoft Entra テスト ユーザーの UserPrincipalName:
AzureUser1@demo1984.onmicrosoft.com
Microsoft Entra ID でエンタープライズ アプリケーションを構成する
Microsoft Entra ID でフェデレーションを構成するには、専用のエンタープライズ アプリケーションを作成する必要があります。 その構成は、アプリケーション ギャラリーにあるあらかじめ構成されているテンプレート SharePoint on-premises
を使用することで簡単に行うことができます。
エンタープライズ アプリケーションを作成する
- クラウド アプリケーション管理者以上として Microsoft Entra 管理センターにサインインします。
- [ID]>[アプリケーション]>[エンタープライズ アプリケーション]>[新しいアプリケーション] に移動します。
- 検索ボックスに、「SharePoint on-premises」と入力します。 結果ペインで [SharePoint on-premises](SharePoint オンプレミス) を選択します。
- アプリケーションの名前 (このチュートリアルでは
SharePoint corporate farm
) を指定し、 [作成] をクリックしてアプリケーションを追加します。 - 新しいエンタープライズ アプリケーションで [プロパティ] を選択し、 [ユーザーの割り当てが必要ですか?] の値を確認します。 このシナリオでは、その値を [いいえ] に設定し、 [保存] をクリックします。
エンタープライズ アプリケーションを構成する
このセクションでは、SAML 認証を構成し、認証の成功時に SharePoint に送信されるクレームを定義します。
エンタープライズ アプリケーション
SharePoint corporate farm
の [概要] で、 [2. シングル サインオンの設定] を選択し、次のダイアログで [SAML] を選択します。[SAML によるシングル サインオンのセットアップ] ページで、 [基本的な SAML 構成] ペインの編集アイコンを選択します。
[基本的な SAML 構成] セクションで、次の手順を実行します。
[識別子] ボックスに、
urn:sharepoint:federation
という値が存在することを確認します。[応答 URL] ボックスに、次のパターンを使用して URL を入力します:
https://spsites.contoso.local/_trust/
。[サインオン URL] ボックスに、次のパターンを使用して URL を入力します:
https://spsites.contoso.local/
。[保存] を選択します。
[User Attributes & Claims]\(ユーザー属性とクレーム\) セクションで、不要な次のクレームの種類を削除します。SharePoint がアクセス許可を付与する際に、これらは使用されません。
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
設定は次のように表示されます。
この情報をコピーします。後で SharePoint で必要になります。
[SAML 署名証明書] セクションで、証明書 (Base64) をダウンロードします。 これは、Microsoft Entra ID が SAML トークンへの署名に使用する署名証明書の公開キーです。 SharePoint が、受け取った SAML トークンの整合性を検証する際に必要となります。
[Set up SharePoint corporate farm](SharePoint 企業ファームのセットアップ) セクションで、 [ログイン URL] をメモ帳にコピーします。末尾の文字列 /saml2 は /wsfed に置き換えてください。
重要
SharePoint によって必要とされる SAML 1.1 トークンが Microsoft Entra ID から確実に発行されるよう、/saml2 は必ず /wsfed に置き換えてください。
- [Set up SharePoint corporate farm](SharePoint 企業ファームのセットアップ) セクションで、 [ログアウト URL] をコピーします。
Microsoft Entra ID を信頼するように SharePoint を構成する
SharePoint で信頼を作成する
この手順では、SharePoint が Microsoft Entra ID を信頼するために必要な構成を格納する SPTrustedLoginProvider を作成します。 そのため、上記でコピーした Microsoft Entra ID の情報が必要です。Windows PowerShell を使用すると、いくつかのコマンドが失敗する場合があることに注意してください。SharePoint 管理シェルを起動し、次のスクリプトを実行して作成します。
# Path to the public key of the Microsoft Entra SAML signing certificate (self-signed), downloaded from the Enterprise application in the Azure portal
$signingCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Microsoft Entra app\SharePoint corporate farm.cer")
# Unique realm (corresponds to the "Identifier (Entity ID)" in the Microsoft Entra enterprise application)
$realm = "urn:sharepoint:federation"
# Login URL copied from the Microsoft Entra enterprise application. Make sure to replace "saml2" with "wsfed" at the end of the URL:
$loginUrl = "https://login.microsoftonline.com/dc38a67a-f981-4e24-ba16-4443ada44484/wsfed"
# Define the claim types used for the authorization
$userIdentifier = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "name" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
$role = New-SPClaimTypeMapping "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming
# Let SharePoint trust the Microsoft Entra signing certificate
New-SPTrustedRootAuthority -Name "Microsoft Entra signing certificate" -Certificate $signingCert
# Create a new SPTrustedIdentityTokenIssuer in SharePoint
$trust = New-SPTrustedIdentityTokenIssuer -Name "MicrosoftEntraTrust" -Description "Microsoft Entra ID" -Realm $realm -ImportTrustCertificate $signingCert -ClaimsMappings $userIdentifier, $role -SignInUrl $loginUrl -IdentifierClaim $userIdentifier.InputClaimType
SharePoint Web アプリケーションを構成する
この手順では、先ほど作成した Microsoft Entra エンタープライズ アプリケーションを信頼するように SharePoint の Web アプリケーションを構成します。 その際に考慮すべき重要なルールは次のとおりです。
- SharePoint Web アプリケーションの既定のゾーンでは、Windows 認証が有効になっている必要があります。 これは検索クローラーの要件となります。
- Microsoft Entra 認証を使用する SharePoint URL は、HTTPS を使用して設定されている必要があります。
Web アプリケーションを作成または拡張します。 この記事では、想定される 2 つの構成について説明します。
既定のゾーンで Windows 認証と Microsoft Entra 認証の両方を使用する新しい Web アプリケーションを作成した場合:
SharePoint 管理シェルを起動し、次のスクリプトを実行します。
# This script creates a new web application and sets Windows and Microsoft Entra authentication on the Default zone # URL of the SharePoint site federated with Microsoft Entra $trustedSharePointSiteUrl = "https://spsites.contoso.local/" $applicationPoolManagedAccount = "Contoso\spapppool" $winAp = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication -DisableKerberos:$true $sptrust = Get-SPTrustedIdentityTokenIssuer "MicrosoftEntraTrust" $trustedAp = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust New-SPWebApplication -Name "SharePoint - Microsoft Entra" -Port 443 -SecureSocketsLayer -URL $trustedSharePointSiteUrl -ApplicationPool "SharePoint - Microsoft Entra" -ApplicationPoolAccount (Get-SPManagedAccount $applicationPoolManagedAccount) -AuthenticationProvider $winAp, $trustedAp
[SharePoint サーバーの全体管理] サイトを開きます。
[システム設定] で、[代替アクセス マッピングの構成] を選択します。 [代替アクセス マッピング コレクション] ボックスが開きます。
新しい Web アプリケーションで表示をフィルター処理し、次のような内容が表示されることを確認します。
新しいゾーンで Microsoft Entra 認証を使用するように既存の Web アプリケーションを拡張した場合:
SharePoint 管理シェルを起動し、次のスクリプトを実行します。
# This script extends an existing web application to set Microsoft Entra authentication on a new zone # URL of the default zone of the web application $webAppDefaultZoneUrl = "http://spsites/" # URL of the SharePoint site federated with ADFS $trustedSharePointSiteUrl = "https://spsites.contoso.local/" $sptrust = Get-SPTrustedIdentityTokenIssuer "MicrosoftEntraTrust" $ap = New-SPAuthenticationProvider -TrustedIdentityTokenIssuer $sptrust $wa = Get-SPWebApplication $webAppDefaultZoneUrl New-SPWebApplicationExtension -Name "SharePoint - Microsoft Entra" -Identity $wa -SecureSocketsLayer -Zone Internet -Url $trustedSharePointSiteUrl -AuthenticationProvider $ap
[SharePoint サーバーの全体管理] サイトを開きます。
[システム設定] で、[代替アクセス マッピングの構成] を選択します。 [代替アクセス マッピング コレクション] ボックスが開きます。
拡張された Web アプリケーションで表示をフィルター処理し、次のような内容が表示されることを確認します。
Web アプリケーションが作成されたら、ルート サイト コレクションを作成し、自分の Windows アカウントをプライマリ サイト コレクション管理者として追加します。
SharePoint サイトの証明書を作成する
SharePoint URL では HTTPS プロトコル (
https://spsites.contoso.local/
) が使用されるため、対応するインターネット インフォメーション サービス (IIS) サイトで証明書を設定する必要があります。 その手順に従って、自己署名証明書を生成してください。重要
自己署名証明書はテスト目的にのみ適しています。 運用環境では、代わりに証明機関が発行した証明書を使用することを強くお勧めします。
Windows PowerShell コンソールを開きます。
次のスクリプトを実行して自己署名証明書を生成し、それをコンピューターの MY ストアに追加します。
New-SelfSignedCertificate -DnsName "spsites.contoso.local" -CertStoreLocation "cert:\LocalMachine\My"
IIS サイトで証明書を設定します。
- インターネット インフォメーション サービス マネージャー コンソールを開きます。
- ツリー ビューでサーバーを展開し、[サイト] を展開し、[SharePoint - Microsoft Entra ID] サイトを選択して [バインド] を選択します。
- https バインドを選択して、[編集] を選択します。
- [TLS/SSL 証明書] フィールドで、使用する証明書 (先ほど作成した spsites.contoso.local など) を選択し、 [OK] を選択します。
注意
Web フロント エンド サーバーが複数ある場合、この操作を各サーバーで繰り返す必要があります。
SharePoint と Microsoft Entra ID の間の信頼に関する基本的な構成は以上です。 Microsoft Entra ユーザーとして SharePoint サイトにサインインする方法を見てみましょう。
メンバー ユーザーとしてサインインする
Microsoft Entra ID には、2 種類のユーザーが存在します。ゲスト ユーザーとメンバー ユーザーです。 まずは、メンバー ユーザーから見ていきましょう。メンバー ユーザーとは、単に自分の組織に属しているユーザーのことです。
Microsoft Entra ID でメンバー ユーザーを作成する
- Microsoft Entra 管理センターにユーザー管理者以上でサインインしてください。
- [ID]>[ユーザー]>[すべてのユーザー] の順に移動します。
- 画面の上部で [新しいユーザー]>[新しいユーザーの作成] を選択します。
- [ユーザー] プロパティで、以下の手順を実行します。
- "表示名" フィールドに「
B.Simon
」と入力します。 - [ユーザー プリンシパル名] フィールドに「username@companydomain.extension」と入力します。 たとえば、「
B.Simon@contoso.com
」のように入力します。 - [パスワードを表示] チェック ボックスをオンにし、 [パスワード] ボックスに表示された値を書き留めます。
- [Review + create](レビュー + 作成) を選択します。
- "表示名" フィールドに「
- [作成] を選択します。
- このユーザーとサイトを共有し、そこへのアクセスを許可することができます。
SharePoint で Microsoft Entra ユーザーにアクセス許可を付与する
SharePoint ルート サイト コレクションに自分の Windows アカウント (サイト コレクション管理者) としてサインインし、 [共有] をクリックします。
ダイアログには、userprincipalname の正確な値、たとえば「AzureUser1@demo1984.onmicrosoft.com
」を入力する必要があります。また、name クレームの結果を慎重に選択してください (結果にマウスを合わせると、そのクレームの種類が表示されます)。
重要
招待したいユーザーの値を正確に入力し、適切なクレームの種類をリストから選択してください。そうしないと、共有がうまく機能しません。
この制限は、ユーザー ピッカーからの入力が SharePoint によって検証されず、混乱やスペルミスを招いたり、ユーザーが誤って間違ったクレームの種類を選択したりすることがあるためです。
このシナリオを修正するには、EntraCP というオープンソース ソリューションを使用して、SharePoint 2019、2016、2013 を Microsoft Entra ID に接続し、Microsoft Entra テナントに対して入力を解決します。 詳細については、EntraCP を参照してください。
以下に示したのは、EntraCP が構成されている状態で同じ検索を実行した結果です。入力内容に基づいて実際のユーザーが SharePoint から返されます。
重要
EntraCP は Microsoft 製品ではないため、Microsoft サポートではサポートされません。 オンプレミスの SharePoint ファームで EntraCP をダウンロード、インストール、構成するには、EntraCP Web サイトを参照してください。
これで Microsoft Entra ユーザー AzureUser1@demo1984.onmicrosoft.com
が、自分の ID を使用して SharePoint サイト https://spsites.contoso.local/
にサインインできるようになりました。
セキュリティ グループにアクセス許可を付与する
グループ クレームの種類をエンタープライズ アプリケーションに追加する
エンタープライズ アプリケーション
SharePoint corporate farm
の [概要] で、 [2. シングル サインオンの設定] を選択します。グループ クレームが存在しない場合は、[User Attributes & Claims]\(ユーザー属性とクレーム\) セクションで、これらの手順に従います。
- [グループ要求を追加する] を選択し、 [セキュリティ グループ] を選択して、 [ソース属性] を [グループ ID] に設定します。
- [グループ要求の名前をカスタマイズする] チェック ボックスをオンにし、 [グループをロール要求として生成する] チェック ボックスをオンにして、 [保存] をクリックします。
- [User Attributes & Claims]\(ユーザー属性とクレーム\) は次のようになります。
Microsoft Entra ID でセキュリティ グループを作成する
セキュリティ グループを作成しましょう。
[ID]>[グループ] の順に移動します。
[新しいグループ] を選びます。
[グループの種類] (Security)、 [グループ名] (
AzureGroup1
など)、 [メンバーシップの種類] を入力します。 先ほど作成したユーザーをメンバーとして追加し、 [作成] をクリックします。
SharePoint でセキュリティ グループにアクセス許可を付与する
Microsoft Entra のセキュリティ グループは、その Id
属性、つまり GUID (00aa00aa-bb11-cc22-dd33-44ee44ee44ee
など) で識別されます。
カスタム クレーム プロバイダーを使用しなかった場合、ユーザーは、グループの正確な値 (Id
) をユーザー ピッカーで入力し、対応するクレームの種類を選択しなければなりません。 これはユーザー フレンドリではなく、信頼性も高いとは言えません。
それを避けるために、この記事では、サードパーティのクレーム プロバイダー EntraCP を使用することで、グループを SharePoint から簡単に探し出せるようにしています。
ゲスト ユーザー アクセスを管理する
ゲスト アカウントには、次の 2 種類があります。
- B2B ゲスト アカウント: これらのユーザーは、外部の Microsoft Entra テナントに属します
- MSA ゲスト アカウント: これらのユーザーは、Microsoft ID プロバイダー (Hotmail、Outlook) またはソーシャル アカウント プロバイダー (Google など) に属します。
既定では、Microsoft Entra ID によって、"一意のユーザー ID" とクレームの "名前" がどちらも user.userprincipalname
属性に設定されます。
あいにくゲスト アカウントでは、この属性は、あいまいさが生じます。次の表をご覧ください。
Microsoft Entra ID に設定されたソース属性 | B2B ゲストのMicrosoft Entra ID で使用される実際のプロパティ | MSA ゲストのMicrosoft Entra ID で使用される実際のプロパティ | SharePoint が ID の検証に利用できるプロパティ |
---|---|---|---|
user.userprincipalname |
mail (例: guest@PARTNERTENANT ) |
userprincipalname (例: guest_outlook.com#EXT#@TENANT.onmicrosoft.com ) |
あいまい |
user.localuserprincipalname |
userprincipalname (例: guest_PARTNERTENANT#EXT#@TENANT.onmicrosoft.com ) |
userprincipalname (例: guest_outlook.com#EXT#@TENANT.onmicrosoft.com ) |
userprincipalname |
結論として、すべてのゲスト アカウントを確実に同じ属性で識別するためには、user.userprincipalname
ではなく user.localuserprincipalname
属性を使用するように、エンタープライズ アプリケーションの ID クレームを更新する必要があります。
すべてのゲスト ユーザーに対して一貫した属性を使用するようにアプリケーションを更新する
エンタープライズ アプリケーション
SharePoint corporate farm
の [概要] で、 [2. シングル サインオンの設定] を選択します。[SAML でシングル サインオンをセットアップします] ページで、[User Attributes & Claims]\(ユーザー属性とクレーム\) ペインの編集アイコンを選択します。
[User Attributes & Claims]\(ユーザー属性とクレーム\) セクションで、これらの手順に従います。
[一意のユーザー識別子 (名前 ID)] を選択し、その [ソース属性] プロパティを user.localuserprincipalname に変更して、 [保存] をクリックします。
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
を選択し、その [ソース属性] プロパティを user.localuserprincipalname に変更して、[保存] をクリックします。[User Attributes & Claims]\(ユーザー属性とクレーム\) は次のようになります。
SharePoint でゲスト ユーザーを招待する
Note
このセクションでは、クレーム プロバイダー EntraCP が使用されていることを前提としています
上のセクションでは、すべてのゲスト アカウントに対して一貫した属性を使用するようにエンタープライズ アプリケーションを更新しました。
今度は、その変更を反映し、ゲスト アカウントに 属性 userprincipalname
を使用するように、EntraCP の構成を更新する必要があります。
- [SharePoint サーバーの全体管理] サイトを開きます。
- [セキュリティ] で [EntraCP global configuration](EntraCP グローバル構成) を選択します。
- [User identifier property](ユーザー識別子プロパティ) セクションで、 [User identifier for 'Guest' users]("ゲスト" ユーザーのユーザー識別子) を UserPrincipalName に設定します。
- [OK] をクリックします。
SharePoint サイトでゲスト ユーザーを招待できるようになりました。
複数の Web アプリケーションに対してフェデレーションを構成する
この構成は 1 つの Web アプリケーションに役立ちますが、複数の Web アプリケーションに対して同一の信頼できる ID プロバイダーを使用する場合は追加の構成が必要になります。 たとえば、別個の Web アプリケーション https://otherwebapp.contoso.local/
があり、そのアプリケーションの Microsoft Entra 認証を有効にしたいとします。 そのためには、SAML WReply パラメーターを渡すように SharePoint を構成し、該当する URL をエンタープライズ アプリケーションに追加します。
SAML WReply パラメーターを渡すように SharePoint を構成する
- SharePoint サーバーで SharePoint 201x 管理シェルを開き、次のコマンドを実行します。 先ほど使用した信頼できる ID トークン発行者の名前を使用します。
$t = Get-SPTrustedIdentityTokenIssuer "MicrosoftEntraTrust"
$t.UseWReplyParameter = $true
$t.Update()
エンタープライズ アプリケーションに URL を追加する
クラウド アプリケーション管理者以上として Microsoft Entra 管理センターにサインインします。
[ID]>[アプリケーション]>[エンタープライズ アプリケーション]> の順に移動します。先ほど作成したエンタープライズ アプリケーションを選び、[シングル サインオン] を選びます。
[SAML によるシングル サインオンのセットアップ] ページで、 [基本的な SAML 構成] を編集します。
[応答 URL (Assertion Consumer Service URL)] セクションに、Microsoft Entra ID でユーザーをサインインさせるその他すべての Web アプリケーションの URL (例:
https://otherwebapp.contoso.local/
) を追加し、[保存] をクリックします。
セキュリティ トークンの有効期間を構成する
既定では、Microsoft Entra ID は、Azure portal または条件付きアクセス ポリシーを使用してカスタマイズできない、1 時間有効な SAML トークンを作成します。
ただし、カスタム トークン有効期間ポリシーを作成し、SharePoint Server 用に作成したエンタープライズ アプリケーションに割り当てることができます。
これを実現するには、次のスクリプトを実行します。
Install-Module Microsoft.Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration","Policy.Read.All","Application.ReadWrite.All"
$appDisplayName = "SharePoint corporate farm"
$sp = Get-MgServicePrincipal -Search DisplayName:"$appDisplayName" -ConsistencyLevel eventual
$oldPolicy = Get-MgServicePrincipalTokenLifetimePolicy -ServicePrincipalId $sp.Id
if ($null -ne $oldPolicy) {
# There can be only 1 TokenLifetimePolicy associated to the service principal (or 0, as by default)
Remove-MgServicePrincipalAppManagementPolicy -AppManagementPolicyId $oldPolicy.Id -ServicePrincipalId $sp.Id
}
# Get / create a custom token lifetime policy
$policyDisplayName = "WebPolicyScenario"
$policy = Get-MgPolicyTokenLifetimePolicy -Filter "DisplayName eq '$policyDisplayName'"
if ($null -eq $policy) {
$params = @{
Definition = @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"4:00:00"}}')
DisplayName = $policyDisplayName
IsOrganizationDefault = $false
}
$policy = New-MgPolicyTokenLifetimePolicy -BodyParameter $params
}
# Assign the token lifetime policy to an app
$body = @{
"@odata.id" = "https://graph.microsoft.com/v1.0/policies/tokenLifetimePolicies/$($policy.Id)"
}
Invoke-GraphRequest -Uri ('https://graph.microsoft.com/v1.0/servicePrincipals/{0}/tokenLifetimePolicies/$ref' -f $sp.Id) -Method POST -Body $body