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

As 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. Chances are though that OneNote integration will not be available. The link is just not there. If you don’t need OneNote, skip the rest, and enjoy the rest of your day, documents will work just fine.

Trick 1

Since integrating with on-premises SharePoint requires a SharePoint Online license, you do have access to SharePoint Online. Remove all SharePoint sites you configured so far then enable integration with SharePoint Online. OneNote integration will light up. Ta-da? Not so fast. Now, if you try to add your on-premises site, the one that was working before, most likely you will receive “Failed authentication” error.

Trick 2

In short, after the trust is established, CRM Online sends claim to SharePoint on-premises where it’s mapped to a local account. For on-premises integration, claim emailaddress is mapped to a Work email of a SharePoint user account. And it does work until you enable integration with Online that sends nameid claim that happened to be Azure Active Directory PUID. SharePoint on-premises has no clue what this identifier is, tries to map it to local Active Directory SID and fails miserably.

The answer is buried in this small article about custom claims. What you need to do is to tell CRM Online what claim to send to the SharePoint. 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.

service.Create(new Entity("usermapping")
{
    Attributes =
    {
        { "claimtype", "smtp" },
        { "systemuserattributename",
            "sharepointemailaddress" }
    }
});

(First you may want to check if the usermapping record for claimtype smtp already exists).

Trick 3

Everything is working now but only for my account. Ugh. CRM Online is now sending individual claims per user who’s accessing the instance. Since we are not using SharePoint Email Address attribute for anything else, why not to set it for all users to the same single account that is mapped to our SharePoint:

var qba = new QueryByAttribute("systemuser");
qba.AddAttributeValue("isdisabled", false);
var users = service.RetrieveMultiple(qba);
foreach (var user in users.Entities)
{
    service.Update(new Entity("systemuser")
    {
        Attributes =
        {
            { "systemuserid", user.Id },
            { "sharepointemailaddress", 
                "drink@bar.onmicrosoft.com" }
        }
    });
}

(You’d need to skip some user accounts that are outside of your control like Delegate Admin).