CRM Online is now sending individual claims per user who’s accessing the instance. Trick 3Įverything is working now but only for my account. (First you may want to check if the usermapping record for claimtype smtp already exists). Turns out, there is a perfectly named sharepointemailaddress attribute on the systemuser so simply add it to the user form and tell CRM to send it as a claim. What you need to do is to tell CRM Online what claim to send to the SharePoint. 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.
0 Comments
Leave a Reply. |