In the earlier blog posts, we discussed setting up an Azure function with AAD authentication and then creating a custom connector for the Azure function that also requires AAD authentication to make a connection to the connector.
Given that the Azure function is configured for AAD authentication in the Authentication / Authorization section of the function as shown below
Now that we have provided for AAD authentication that requires a user login, it would be good if all operations are executed within the context of the same user.
Within your Azure function, you can get the details of the logged-in user using the ClaimsPrincipal
ClaimsPrincipal principal = req.HttpContext.User;
if (principal.Identity != null)
log.LogInformation(“Claims identity ” + principal.Identity.Name);
if (principal.Claims != null)
foreach (Claim c in principal.Claims)
log.LogInformation(“CLAIM TYPE: ” + c.Type + “; CLAIM VALUE: ” + c.Value + “</br>”);
In the console, you can see all the claims returned
One of the claims returned is AADID
Read this specific claim value
Claim claim = principal.Claims.FirstOrDefault(c => c.Type.Contains(“objectidentifier”));
string aadobjid = “”;
if (claim != null)
aadobjid = claim.Value;
log.LogInformation(“aadobjid = ” + aadobjid);
Every CRM User that we create has an associated AADID stored along which is this objectid.
Set this to the cds client object we have created for impersonation
//establish connection with CDS
CdsServiceClient client = new CdsServiceClient(connectionString);
client.CallerAADObjectId = new Guid(aadobjid);
Do note if you run a WhoAmI request – it still returns the id of the original credentials used for establishing the connection.
However, when you create a record, you will notice that the owner of the new record is the same user that had logged in to the connector.