次の方法で共有

Dynamics 365 Online と SharePoint (設置型) でのサーバー ベース認証の構成

  • [アーティクル]

 

公開日: 2017年2月

対象: Dynamics 365 (online)、Dynamics 365 (on-premises)、Dynamics CRM 2016、Dynamics CRM Online

Microsoft Dynamics CRM Online 2015 更新プログラム 1 で導入された、ドキュメント管理のためのサーバー ベース Microsoft SharePoint の統合が、Microsoft Dynamics 365 (オンライン) と SharePoint 設置型との接続で使用できるようになりました。 サーバー ベースの認証を使用すると、Azure AD Domain Services がトラスト ブローカーとして使用されて、ユーザーが SharePoint にサインインする必要がなくなります。

Dynamics 365 (オンライン) および SharePoint 設置型

このトピックの内容

必要なアクセス許可

Dynamics 365 (オンライン) と SharePoint (設置型) でのサーバー間認証の設定

OneDrive for Business 統合の追加

クレームベース認証のマッピングの種類の選択

必要なアクセス許可

Office 365

  • Office 365 グローバル管理者メンバーシップ - これは、Microsoft Office 365 サブスクリプションへの管理レベルのアクセスのために、また Microsoft AzurePowerShell コマンドレットを実行するために必要です。

Microsoft Dynamics 365 (オンライン)

  • [SharePoint 統合ウィザードを実行する] 特権。 これは、Microsoft Dynamics 365 で [サーバー ベース認証の有効化] ウィザードを実行するときに必要となります。

    既定では、システム管理者セキュリティ ロールにはこのアクセス許可が含まれています。

設置型 SharePoint

  • ファーム管理者グループのメンバーシップ - これは、SharePoint サーバー上で PowerShell のほとんどのコマンドを実行するときに必要となります。

Dynamics 365 (オンライン) と SharePoint (設置型) でのサーバー間認証の設定

指定された順序で手順を実行して、Dynamics 365 (オンライン) を SharePoint 2013 (設置型) に対して設定します。

重要

  • ここで説明する手順は、指定されている順序で実行する必要があります。 エラー メッセージを返す PowerShell コマンドなどで作業が完了しない場合は、次のコマンド、作業、またはステップに進む前に、問題を解決しておく必要があります。

  • サーバー ベースの SharePoint統合を有効にすると、以前のクライアントベースの認証方式に戻ることができなくなります。 したがって、サーバーベースの SharePoint 統合に Dynamics 365 組織を構成した後は、Microsoft Dynamics CRM リスト コンポーネント を使用することはできません。

前提条件の確認

サーバーベース認証用に Microsoft Dynamics 365 (オンライン) と SharePoint (設置型) を構成する前に、次の前提条件が満たされている必要があります:

SharePoint の前提条件

その他の前提条件

  • SharePoint Online ライセンス。Microsoft Dynamics 365 (オンライン) から SharePoint 設置型サーバー ベースの認証には、Azure Active Directory に登録された SharePoint サービス プリンシパル名 (SPN) が必要です。 これを達成するには、少なくとも一つの SharePoint Online ユーザー ライセンスが必要です。SharePoint Online ライセンスは、単一ユーザー ライセンスを使用でき、通常は次のいずれかを使用します。

    • SharePoint Online サブスクリプション。 ライセンスがユーザーに割り当てられていない場合でも、任意の SharePoint Online 計画を使用できます。

    • SharePoint Online を含む Office 365 サブスクリプション。 たとえば、Office 365 E3 を所有している場合、ライセンスがユーザーに割り当てられなくても適切なライセンスがあります。

    これらの計画の詳細については、Office 365: 計画の選択 と SharePoint のオプションの比較を参照してください

  • 次のソフトウェア機能は、このトピックで説明する PowerShell のコマンドレットの実行に必要となります。

    重要

    この記述の時点では、IT プロフェッショナル用 Microsoft Online Services サインイン アシスタントの RTW バージョンには問題がありました。 この問題が解決するまでは、ベータ版の使用をお勧めします。詳細:Microsoft Azure フォーラム: Windows PowerShell 用 Azure Active Directory モジュールをインストールすることができません。MOSSIA がインストールされません。

  • Microsoft Dynamics 365 (オンライン) と SharePoint (設置型) 間の ID のマッピングに使用する、最適なクレームベース認証のマッピングの種類。 既定では、電子メール アドレスが使用されます。詳細:SharePoint にアクセスし、クレームベース認証のマッピングを構成するための Microsoft Dynamics 365 アクセス許可を付与する

Azure Active Directory ドメイン サービスの SharePoint Server を更新します。

SharePoint (設置型) サーバー上で、SharePoint 2013 管理シェルで、これらの PowerShell コマンドを指定された順序で実行します。

  1. PowerShell セッションを準備します。

    次のコマンドレットにより、コンピューターがリモート コマンドを受け取り、Office 365 モジュールを PowerShell セッションに追加できます。 これらコマンドレットの詳細については、「Windows PowerShell Core コマンドレット」を参照してください。

    Enable-PSRemoting -force
New-PSSession
Import-Module MSOnline -force
Import-Module MSOnlineExtended -force

  2. Office 365 に接続。

    Connect-MsolService コマンドを実行するとき、必要な SharePoint Online ライセンス用 Office 365 グローバル管理者メンバーシップを保持している、有効な Microsoft アカウント を提供する必要があります。

    ここに示す Azure Active DirectoryPowerShell の各コマンドの詳細については、「MSDN: Windows PowerShell を使用した Azure AD の管理」を参照してください。

    $msolcred = get-credential
connect-msolservice -credential $msolcred

  3. SharePoint のホスト名を設定します。

    変数 ホスト名 に設定する値は、SharePoint のサイト コレクションの完全なホスト名である必要があります。 ホスト名は、サイト コレクションの URL から取得する必要があり、大文字と小文字が区別されます。 この例では、サイト コレクションの URL は https://SharePoint.constoso.com/sites/salesteam なので、ホスト名は SharePoint.contoso.com です。

    $HostName = "SharePoint.contoso.com"

  4. Office 365 の (テナント) の ID と SharePoint Serverの サービス プリンシパル名 (SPN) を取得します。

    $SPOAppId = "00000003-0000-0ff1-ce00-000000000000"
$SPOContextId = (Get-MsolCompanyInformation).ObjectID
$SharePoint = Get-MsolServicePrincipal -AppPrincipalId $SPOAppId
$ServicePrincipalName = $SharePoint.ServicePrincipalNames

  5. SharePoint Server サービス プリンシパル名 (SPN) を Azure Active Directoryで設定します。

    $ServicePrincipalName.Add("$SPOAppId/$HostName") 
Set-MsolServicePrincipal -AppPrincipalId $SPOAppId -ServicePrincipalNames $ServicePrincipalName

これらのコマンドの実行後、SharePoint 2013 Management シェルを閉じないで、次の手順に進んでください。

SharePoint Online のレルムと一致するように SharePoint レルムを更新

SharePoint (設置型) サーバー上で、SharePoint 2013 管理シェルで、この Windows PowerShell コマンドを実行します。

次のコマンドは、SharePoint のファーム管理者メンバーシップを必要とし、SharePoint (設置型) ファームの認証レルムを設定します。

注意

このコマンドを実行すると、SharePoint (設置型) ファームの認証レルムが変更されます。 既存の Security Token Service (STS) を使用するアプリケーションの場合、これにより、トークン アクセスを使用する他のアプリケーションに、予期しない動作が生じることがあります。 詳細: Set-SPAuthenticationRealm。

Set-SPAuthenticationRealm -Realm $SPOContextId

SharePoint の Azure Active Directory に対して信頼されたセキュリティ トークンの発行者を作成

SharePoint (設置型) サーバー上で、SharePoint 2013 管理シェルで、これらの PowerShell コマンドを指定された順序で実行します。

次のコマンドは、SharePoint ファーム管理者メンバーシップを必要とします。

これらの PowerShell のコマンドの詳細については、「Windows PowerShell コマンドレットを使用して SharePoint 2013 のセキュリティを管理」を参照してください。

  1. SharePoint ファームのセキュリティ トークン サービスを変更する PowerShell セッションを有効にします。

    $c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp= $true
$c.Update()

  2. メタデータのエンドポイントを設定します。

    $metadataEndpoint = "https://accounts.accesscontrol.windows.net/" + $SPOContextId + "/metadata/json/1"
$acsissuer  = "00000001-0000-0000-c000-000000000000@" + $SPOContextId
$issuer = "00000007-0000-0000-c000-000000000000@" + $SPOContextId

  3. 新しいトークン制御サービス アプリケーション プロキシを Azure Active Directory で作成します。

    New-SPAzureAccessControlServiceApplicationProxy -Name "Internal" -MetadataServiceEndpointUri $metadataEndpoint -DefaultProxyGroup

    注意

    New- SPAzureAccessControlServiceApplicationProxy コマンドは、同じ名前のアプリケーション プロキシが既にあることを示すエラー メッセージを返す場合があります。 名前付きアプリケーション プロキシが既に存在する場合、そのエラーを無視できます。

  4. SharePoint (設置型) で、Azure Active Directory 用の新しいトークン制御サービス発行者を作成します。

    $ = New-SPTrustedSecurityTokenIssuer –Name "ACSInternal" –IsTrustBroker:$true –MetadataEndpoint $metadataEndpoint -RegisteredIssuerName $acsissuer

SharePoint にアクセスし、クレームベース認証のマッピングを構成するための Microsoft Dynamics 365 アクセス許可を付与する

SharePoint (設置型) サーバー上で、SharePoint 2013 管理シェルで、これらの PowerShell コマンドを指定された順序で実行します。

次のコマンドは、SharePoint サイト コレクション管理メンバーシップを必要とします。

  1. Microsoft Dynamics 365 を SharePoint サイト コレクションに登録します。

    SharePoint (設置型) サイト コレクション URL を入力します。 この例では、https://sharepoint.contoso.com/sites/crm/ が使用されます。

    重要

    このコマンドを実行するには、SharePoint App Management Service アプリケーションのプロキシが存在し、実行されている必要があります。 サービスの開始と構成の方法の詳細については、SharePoint (SharePoint 2013) のアプリケーション用環境の構成 の「サブスクリプションの設定および App Management サービス アプリケーションの構成」のサブトピックを参照してください。

    $site = Get-SPSite "https://sharepoint.contoso.com/sites/crm/"
Register-SPAppPrincipal -site $site.RootWeb -NameIdentifier $issuer -DisplayName "crm"

  2. Microsoft Dynamics 365 のアプリケーション アクセスを SharePoint のサービス拠点に付与します。SharePoint のサービス拠点の URL を https://sharepoint.contoso.com/sites/crm/ に置き換えます。

    注意

    次の例では、-Scope サイト コレクション パラメーターを使用して、指定した SharePoint のサイト コレクションに対するアクセス許可が Dynamics 365 アプリケーションに付与されます。 スコープ パラメーターは、次のオプションを受入れます。SharePoint 構成に最適なスコープを選択します。

    • site。 選択した SharePoint Web サイトにのみ Dynamics 365 アプリケーションのアクセス許可を付与します。 名前付きサービス拠点の下のサブサイトにはアクセス許可が付与されません。

    • sitecollection。 指定した SharePoint サイト コレクション内のすべての Web サイトおよびサブサイトに対し、Dynamics 365 アプリケーションのアクセス許可を付与します。

    • sitesubscription。 すべてのサイト コレクション、Web サイト、およびサブサイトを含む、SharePoint ファーム内のすべての Web サイトに対し、Dynamics 365 アプリケーションのアクセス許可を付与します。

    $app = Get-SPAppPrincipal -NameIdentifier $issuer -Site "https://sharepoint.contoso.com/sites/crm/"
Set-SPAppPrincipalPermission -AppPrincipal $app -Site $site.Rootweb -Scope "sitecollection" -Right "FullControl"

  3. クレームベース認証のマッピングの種類を設定します。

    重要

    既定では、クレームベース認証のマッピングでは、ユーザーの Microsoft アカウント 電子メール アドレスとユーザーの SharePoint (設置型) の [勤務先の電子メール] アドレスがマッピングに使用されます。 これを使用するとき、ユーザーの電子メール アドレスは、2 つのシステム間で一致する必要があります。 詳細については、「クレームベース認証のマッピングの種類の選択」を参照してください。

    $map1 = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

サーバーベースの SharePoint 統合の有効化ウィザードの実行

Microsoft Dynamics 365 アプリケーションでは、次の手順に従います:

  1. [設定]、[ドキュメント管理] の順に移動します。(どのように取得しますか。)

  2. [ドキュメント管理] 領域で、[サーバーベースの SharePoint 統合の有効化] をクリックします。

  3. 情報を確認し、[次へ] をクリックします。

  4. SharePoint サイトの場合、[設置型] 、[次へ] の順にクリックします。

  5. https://sharepoint.contoso.com/sites/crm などの、SharePoint (設置型) のサイト コレクション URL を入力します。 サービス拠点を SSL 用に構成する必要があります。

  6. [次へ] をクリックします。

  7. サイトの検証セクションが表示されます。 すべてのサービス拠点が有効であると決定された場合、[有効化] をクリックします。 1 つ以上のサービス拠点が無効であると決定された場合は、「サーバー ベース認証のトラブルシューティング」を参照してください。

ドキュメント管理に含めるエンティティの選択

既定では、取引先企業、記事、潜在顧客、製品、見積もり、営業資料のエンティティが含まれます。Microsoft Dynamics 365 の [ドキュメント管理の設定] で SharePoint でのドキュメント管理に使用されるエンティティを追加または削除できます。[設定]、[ドキュメント管理] の順に移動します。(どのように取得しますか。)詳細:顧客センター: エンティティに対するドキュメント管理の有効化

OneDrive for Business 統合の追加

Microsoft Dynamics 365 と SharePoint 設置型サーバーベース認証の構成が完了したら、OneDrive for Business を統合することもできます。Microsoft Dynamics 365 と OneDrive for Business を統合すると、Dynamics 365 ユーザーは、OneDrive for Business を使ってプライベート ドキュメントを作成および管理できます。 システム管理者が OneDrive for Business を有効にすると、Dynamics 365 内からこれらのドキュメントにアクセスできます。

OneDrive for Business の有効化

設置型 SharePoint Server が実行されている Windows Server で、SharePoint 管理シェルを開き、次のコマンドを実行します:

Add-Pssnapin *
# Access WellKnown App principal
[Microsoft.SharePoint.Administration.SPWebService]::ContentService.WellKnownAppPrincipals

# Create WellKnown App principal
$ClientId = "00000007-0000-0000-c000-000000000000"
$PermissionXml = "<AppPermissionRequests AllowAppOnlyPolicy=""true""><AppPermissionRequest Scope=""https://sharepoint/content/tenant"" Right=""FullControl"" /><AppPermissionRequest Scope=""https://sharepoint/social/tenant"" Right=""Read"" /><AppPermissionRequest Scope=""https://sharepoint/search"" Right=""QueryAsUserIgnoreAppPrincipal"" /></AppPermissionRequests>"

$wellKnownApp= New-Object -TypeName "Microsoft.SharePoint.Administration.SPWellKnownAppPrincipal" -ArgumentList ($ClientId, $PermissionXml)

$wellKnownApp.Update()

クレームベース認証のマッピングの種類の選択

既定では、クレームベース認証のマッピングでは、ユーザーの Microsoft アカウント 電子メール アドレスとユーザーの SharePoint (設置型) の勤務先の電子メール アドレスがマッピングに使用されます。 どのクレームベース認証の種類を使用する場合でも、電子メール アドレスなどの値は、Microsoft Dynamics 365 (オンライン) と SharePoint の間で 一致する必要があります。Office 365 のディレクトリの同期でこれを実行しやすくなります。詳細:Microsoft Azure での Office 365 ディレクトリ同期 (DirSync) の展開異なる種類のクレームベース認証マッピングを使用するには、「SharePoint のサーバー ベースの統合のためのユーザー定義のクレーム マッピングの定義」を参照してください。

重要

勤務先の電子メールのプロパティを有効にするには、SharePoint (設置型) の User Profile Service アプリケーションを構成して起動する必要があります。SharePoint の User Profile Service アプリケーションを有効にするには、「SharePoint Server 2013 の User Profile Service アプリケーションの作成、編集、または削除」を参照してください。 勤務先の電子メールなどの、ユーザー プロパティを変更するには、「ユーザー プロファイル プロパティの編集」を参照してください。 User Profile Service アプリケーションの詳細については、「SharePoint Server 2013 の User Profile Service アプリケーションの概要」を参照してください。

関連項目

サーバー ベース認証のトラブルシューティング
SharePoint と Microsoft Dynamics 365 との統合のセットアップ

© 2017 Microsoft. All rights reserved. 著作権