CRM 2016 On Premise claim based enabled & SharePoint 2013 On Premise with server-based authentication integration – 401 error

Article
06/14/2016

This article is regarding CRM 2016 On Premise claim based enabled and SharePoint 2013 On Premise with server-based authentication integration, and CRM users are unable to create SharePoint folders and get 401-Unauthorized error.

After having configured the server-based authentication for the integration between CRM2016 On Premise with claim based enabled and SharePoint 2013 On Premise by following this technical article https://technet.microsoft.com/en-us/library/dn949332.aspx, the CRM user will receive an error from SharePoint saying that he is not authorized to create a SharePoint folder.

This can affect also if a CRM user has administrative privileges on both CRM and SharePoint.

The complete error description received by SharePoint while performing the action, is:

"Authorization Failure - The remote server returned 401 unauthorized error. Please contact your administrator. "

<site>

<url>https://intranet.ufs.ac.za/sites/crm</url>

<exception>The remote server returned an error: (401) Unauthorized.</exception>

</site>

</sites></errorlog>

As a note, SPS does not need to be configured for ADFS.

The cause of this is when CRM 2016 is claims enabled, then the SharePoint 2013 (that was integrated with the server-based authentication method) expects that CRM sends the SharePointEmailAddress attribute value with a value equal to the value that the same ActiveDirectory user has in its Workemail attribute in the SharePoint user profile.

Because this value is taken from the ActiveDirectory Account email attribute or ProxyEmail attribute, on CRM of the CRM user SharePointEmailAddress attribute should be populated with a consistent value.

However, because the mapping of the attributes between Active Directory and SharePoint user profiles can be changed manually or automatically on a SharePoint side (depending on how the SharePoint 2013 is configured, this means that there could be different way on how to populate properly the value for the SharePointEmailAddress attribute (for example a CRM workflow that is triggered when the emailaddress of the CRM user is modified, then it goes to populate with the same value the SharePointemailAddress).

Workaround

As a preamble:

On the SharePoint side, be sure that the CRMuser ActiveDirecotry account is part of the site members to allow the creation of the document library and SharePoint folders from CRM, and also that for the same user, the work email attribute in his profile is exact the same of the attribute SharePointEmailAddress for the CRM user.

In case of you cannot see the WorkEmail attribute on the SharePoint user profile have a look at the communication section of this blog https://sharepointobservations.wordpress.com/2013/07/16/error-you-do-not-have-an-email-address/

On CRM side, be sure that when provisioning the CRM user, double check that the SharePoint Email Address attribute of the CRM user is populated with the same value of the Work Email attribute of the SharePoint user.

Note: for the same ActiveDirectory user, in case of the value of the SharePoint work email attribute or the value of the CRM SharePoint Email Address attribute are not matching, then the 401 error will appear.

As a side note on how to apply the workaround, since it depends on the specific scenario and how it is working the sync between ActiveDirectory users and the SharePoint user profiles, we can do the following on CRM:

- Customize the system user main form on the CRM, to add the sharepointemailaddress attribute on the form

- Publish All

- Locate the CRM users under settings, and open the CRM user form

- Locate the added attribute and fill in the email address value (this need to be exactly the same value that the same related AD user has in SharePoint for the work email attribute in its profile)

For example:

- We have in AD the user user1, where it’s email is user1@localserver.com

- We add the user to the CRM org, so the CRM user user1 will get the primaryemail address equal to user1@localserver.com because it is taken from AD

- On SPS, the same user was added, and (in the OOB scenario) the work email attribute is equal to user1@localserver.com as well, because it is taken from AD

Remark: a remote far situation, but that can happen is that if the customer goes to AD and modify the emailaddress for user1, and then the AD-SPS user profile sync job run and apply the new value on the work email attribute for the user1 in SPS, the customer need to go also on CRM, edit the CRM user1 user information, and update the SharePointemailaddress attribute to maintain the match.

Share via

CRM 2016 On Premise claim based enabled & SharePoint 2013 On Premise with server-based authentication integration – 401 error

Additional resources