Developers are familiar with the concept of impersonating Dynamics 365 users. It’s easy – all you need to do is to add MSCRMCallerID header to your Web API request, and you’re done (assuming that you have prvActOnBehalfOfAnotherUser privilege).

One of the typical scenarios where you’d want to use the impersonation when you have a web site that connects to your Dynamics 365 instance using either non-interactive user or, better, S2S authentication and then you need to impersonate a currently logged on Azure AD user. The typical flow is: look for a UPN claim, then use that value to find the user in systemuser entity filtered by domainname attribute.

The problem is that UPN claim does not seem to be available when you’re using B2B guest users. In both scenarios a different oid claim is available that returns Azure AD object ID. That value can be used to query systemuser entity using azureactivedirectoryobjectid attribute. Then it’s business as usual, plonk systemuserid value into MSCRMCallerID header and you’re done.

Shortcut

The following approach is undocumented (hopefully not for long!). The usual Tîpp Jäår’s disclaimer applies: not [currently] supported, use at your own risk, contains small children between the flags, not to be consumed with alcohol while driving.

Instead of using Azure AD object ID to lookup the user, pass that id as MSCRMCallerObjectID header.

POST [Organization URI]/api/data/v9.0/accounts HTTP/1.1
MSCRMCallerObjectID: 00000000-0000-0000-000000000002
Accept: application/json
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0

Saves you the need to lookup systemuser and splitting the logic depending on the user type.

Facebook and twitter cover photo by Greg Ortega on Unsplash.