

The answer is buried in this small article about custom claims. SharePoint on-premises has no clue what this identifier is, tries to map it to local Active Directory SID and fails miserably. And it does work until you enable integration with Online that sends nameid claim that happened to be Azure Active Directory PUID. For on-premises integration, claim emailaddress is mapped to a Work email of a SharePoint user account.

In short, after the trust is established, CRM Online sends claim to SharePoint on-premises where it’s mapped to a local account. Now, if you try to add your on-premises site, the one that was working before, most likely you will receive “Failed authentication” error. Remove all SharePoint sites you configured so far then enable integration with SharePoint Online. Since integrating with on-premises SharePoint requires a SharePoint Online license, you do have access to SharePoint Online. If you don’t need OneNote, skip the rest, and enjoy the rest of your day, documents will work just fine. Chances are though that OneNote integration will not be available. Enjoy the summary.Īs we mentioned before, if you carefully followed the steps to configure server-based authentication for Dynamics CRM Online and SharePoint on-premises, most likely you’ll end up with the working integration.

On this occasion, it did cost me a few hours of mouse-bending investigation. There seems to be a theme here, at CRM Tip of the day, with trios of various components walking into refreshment establishments.
