Configure server-based authentication with Dynamics CRM Online and SharePoint on-premises

 

Applies To: Dynamics CRM 2015

Introduced with Microsoft Dynamics CRM Online 2015 Update 1, server-based Microsoft SharePoint integration for document management can now be used to connect Microsoft Dynamics CRM Online with SharePoint on-premises. When you use server-based authentication, Azure Active Directory Access Control Services (ACS) is used as the trust broker and users do not need to sign-in to SharePoint. Additionally, the list control, which requires the deprecated SharePoint sandboxing feature, is not required to display SharePoint documents in Microsoft Dynamics CRM views.

CRM Online and SharePoint on-premises

Office 365

  • Office 365 Global Administrators membership. This is required for administrative-level access to the Microsoft Office 365 subscription and to run the Microsoft Azure PowerShell cmdlets.

Microsoft Dynamics CRM Online

  • Run SharePoint Integration Wizard privilege. This is required to run the Enable Server-based Authentication wizard in Microsoft Dynamics CRM.

    By default, the System Administrator security role has this permission.

SharePoint on-premises

  • Farm Administrators group membership. This is required to run most of the PowerShell commands on the SharePoint server.

Follow the steps in the order provided to set up CRM Online with SharePoint 2013 on-premises.

System_CAPS_importantImportant

The steps described here must be completed in the order provided. If a task is not completed, such as a PowerShell command that returns an error message, the issue must be resolved before you continue to the next command, task, or step.

Before you configure Microsoft Dynamics CRM Online and SharePoint on-premises for server-based authentication, the following prerequisites must be met.

On the SharePoint on-premises server, in the SharePoint 2013 Management Shell, run these PowerShell commands in the order given.

  1. Prepare the PowerShell session.

    The following cmdlets enable the computer to receive remote commands and add Office 365 modules to the PowerShell session. For more information about these cmdlets see Windows PowerShell Core Cmdlets.

    
    Enable-PSRemoting -force
    New-PSSession
    Import-Module MSOnline -force
    Import-Module MSOnlineExtended -force
    
  2. Connect to Office 365.

    When you run the Connect-MsolService command, you must provide a valid Microsoft account that has Office 365 Global Administrator membership for the SharePoint Online license that is required.

    For detailed information about each of the Azure Active Directory PowerShell commands listed here, see MSDN: Manage Azure AD using Windows PowerShell.

    $msolcred = get-credential
    connect-msolservice -credential $msolcred
    
    
  3. Set the SharePoint host name.

    The value that you set for the variable HostName must be the complete host name of the SharePoint site collection. The hostname must be derived from the site collection url and is case sensitive. In this example, the site collection url is https://SharePoint.constoso.com/sites/salesteam, so the hostname is SharePoint.contoso.com.

    $HostName = "SharePoint.contoso.com"
    
    
  4. Get the Office 365 object (tenant) id and SharePoint Server Service Principal Name (SPN).

    $SPOAppId = "00000003-0000-0ff1-ce00-000000000000"
    $SPOContextId = (Get-MsolCompanyInformation).ObjectID
    $SharePoint = Get-MsolServicePrincipal -AppPrincipalId $SPOAppId
    $ServicePrincipalName = $SharePoint.ServicePrincipalNames
    
  5. Set the SharePoint Server Service Principal Name (SPN) in ACS.

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

After these commands complete do not close the SharePoint 2013 Management Shell, and continue to the next step.

On the SharePoint on-premises server, in the SharePoint 2013 Management Shell, run this Windows PowerShell command.

The following command requires SharePoint farm administrator membership and sets the authentication realm of the SharePoint on-premises farm.

System_CAPS_cautionCaution

Running this command changes the authentication realm of the SharePoint on-premises farm. For applications that use an existing security token service (STS), this may cause unexpected behavior with other applications that use access tokens. More information: Set-SPAuthenticationRealm.


Set-SPAuthenticationRealm -Realm $SPOContextId

On the SharePoint on-premises server, in the SharePoint 2013 Management Shell, run these PowerShell commands in the order given.

The following commands require SharePoint farm administrator membership.

For detailed information about these PowerShell commands, see Use Windows PowerShell cmdlets to administer security in SharePoint 2013.

  1. Enable the PowerShell session to make changes to the security token service for the SharePoint farm.

    $c = Get-SPSecurityTokenServiceConfig
    $c.AllowMetadataOverHttp = $true
    $c.AllowOAuthOverHttp= $true
    $c.Update()
    
    
  2. Set the metadata endpoint.

    $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. Create the new token control service application proxy in ACS.

    New-SPAzureAccessControlServiceApplicationProxy -Name "ACSInternal" -MetadataServiceEndpointUri $metadataEndpoint -DefaultProxyGroup
    
    
    System_CAPS_noteNote

    The New- SPAzureAccessControlServiceApplicationProxy command may return an error message indicating that an ACS application proxy with the same name already exists. If the named ACS application proxy already exists, you can ignore the error.

  4. Create the new token control service issuer in SharePoint on-premises for ACS

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

On the SharePoint on-premises server, in the SharePoint 2013 Management Shell, run these PowerShell commands in the order given.

The following commands require SharePoint site collection administration membership.

  1. Register Microsoft Dynamics CRM with the SharePoint site collection.

    Enter the SharePoint on-premises site collection URL. In this example, https://sharepoint.contoso.com/sites/crm/ is used.

    System_CAPS_importantImportant

    To complete this command, the SharePoint App Management Service Application Proxy must exist and be running. For more information about how to start and configure the service, see the Configure the Subscription Settings and App Management service applications subtopic in Configure an environment for apps for SharePoint (SharePoint 2013).

    
    $site = Get-SPSite "https://sharepoint.contoso.com/sites/crm/"
    Register-SPAppPrincipal -site $site.RootWeb -NameIdentifier $issuer -DisplayName "crm"
    
    
  2. Grant Microsoft Dynamics CRM application access to the SharePoint site. Replace https://sharepoint.contoso.com/sites/crm/ with your SharePoint site URL.

    System_CAPS_noteNote

    In the following example, the CRM application is granted permission to the specified SharePoint site collection by using the –Scope site collection parameter. The Scope parameter accepts the following options. Choose the scope that is most appropriate for your SharePoint configuration.

    • site. Grants the CRM application permission to the specified SharePoint website only. It doesn’t grant permission to any subsites under the named site.

    • sitecollection. Grants the CRM application permission to all websites and subsites within the specified SharePoint site collection.

    • sitesubscription. Grants the CRM application permission to all websites in the SharePoint farm, including all site collections, websites, and subsites.

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

    System_CAPS_importantImportant

    By default, the claims-based authentication mapping will use the user’s Microsoft account email address and the user’s SharePoint on-premises Work email address for mapping. When you use this, the user’s email addresses must match between the two systems. For more information, see Selecting a claims-based authentication mapping type.

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

In the Microsoft Dynamics CRM app, follow these steps.

  1. Go to Settings > Document Management.

  2. In the Document Management area, choose Enable server-based SharePoint integration.

  3. Review the information and then choose Next.

  4. For the SharePoint sites, choose On-Premises, and then choose Next.

  5. Enter the SharePoint on-premises site collection URL, such as https://sharepoint.contoso.com/sites/crm. The site must be configured for SSL.

  6. Choose Next.

  7. The validate sites section appears. If all sites are determined valid, choose Enable. If one or more sites are determined invalid, see Troubleshooting server-based authentication.

By default, Account, Article, Lead, Product, Quote, and Sales Literature entities are included. You can add or remove the entities that will be used for document management with SharePoint in Document Management Settings in Microsoft Dynamics CRM. Go to Settings > Document Management. More information: Customer Center: Enable document management on entities

By default, the claims-based authentication mapping will use the user’s Microsoft account email address and the user’s SharePoint on-premises work email address for mapping. Notice that, whatever claims-based authentication type you use, the values, such as email addresses, must match between the Microsoft Dynamics CRM Online and SharePoint. Office 365 directory synchronization can help with this. More information: Deploy Office 365 Directory Synchronization (DirSync) in Microsoft Azure To use a different type of claims-based authentication mapping, see MSDN: Define custom claim mapping for SharePoint server-based integration.

System_CAPS_importantImportant

To enable the Work email property, SharePoint on-premises must have a User Profile Service Application configured and started. To enable a User Profile Service Application in SharePoint, see Create, edit, or delete User Profile service applications in SharePoint Server 2013. To make changes to a user property, such as Work email, see Edit a user profile property. For more information about the User Profile Service Application, see Overview of the User Profile service application in SharePoint Server 2013.

© 2016 Microsoft Corporation. All rights reserved. Copyright

Show: