How should I determine if an MSAL account has an Exchange based email system? (got an exception)

Question

I am working with MSAL and have a user who received the following error:

{  
   "error":{  
      "code":"ResourceNotFound",
      "message":"Resource could not be discovered.",
      "innerError":{  
         "request-id":"99b44a33-e5cd-4b69-9730-32d72e1f4ebf",
         "date":"2016-12-11T03:51:37"
      }
   }
}

The code is the default MSAL demo code:

    public async Task<ActionResult> ReadMail()
    {            
        try
        {
            string signedInUserID = ClaimsPrincipal.Current.FindFirst(ClaimTypes.NameIdentifier).Value;
            ConfidentialClientApplication cca = new ConfidentialClientApplication(clientId, null,
                new ClientCredential(appKey), new MSALSessionCache(signedInUserID, this.HttpContext));                
            string[] scopes = { "Mail.Read" };
            AuthenticationResult result = await cca.AcquireTokenSilentAsync(scopes);

            HttpClient hc = new HttpClient();
            hc.DefaultRequestHeaders.Authorization =
                new System.Net.Http.Headers.AuthenticationHeaderValue("bearer", result.Token);                
            HttpResponseMessage hrm = await hc.GetAsync("https://graph.microsoft.com/v1.0/me/messages");
            string rez = await hrm.Content.ReadAsStringAsync();
            ViewBag.Message = rez;

            return View();
        }
        catch (MsalSilentTokenAcquisitionException)
        {
            ViewBag.Relogin = "true";
            return View();
        }
        catch (Exception eee)
        {
            ViewBag.Error = "An error has occurred. Details: " + eee.Message;
            return View();
        }
    }

It turns out that the integration is like this:

It's a Hybrid Exchange system
Some mailboxes are located on Office 365.
Some mailboxes are located on premise.
Other mailboxes are on a 3rd party mail system (Intermedia) (the directory syncs to AD Connect via a custom script)

Question

How should I defensively code for the above situation? (or similar hybrid situations)?

I do not totally understand your request. Can you clarify what you mean by how you could code defensively for the above code. Are you looking for a refactoring of the above code? — Nkosi, May 12 '17 at 02:50
@Nkosi for a given tenant, an account may have "n" configurations listed in 1 through 4. When I connect to a tenant they could have users in any or all of those "buckets". I don't know how to read the "AD only" properties then move on to the "Exchange only" properties. My understanding of Azure AD, O365 directory, and Intune is that they are different AD instances that are synched together. (this can be verified in powershell). — makerofthings7, May 14 '17 at 22:17
Ok that makes sense. I get that. So is the code above going through those 4 authorities or is that an example of just one? Cause I am thinking about a strategy pattern. — Nkosi, May 14 '17 at 22:21
@nkosi Seems like this might go away with EWS merges with Graph https://channel9.msdn.com/Events/Ignite/2016/BRK3045 — makerofthings7, May 14 '17 at 22:38
In my code the method await cca.AcquireTokenSilentAsync(scopes,... asks for 2 parameters : Task AcquireTokenSilentAsync(IEnumerable scopes, IUser user); Am i missing something? — Tal Avissar, May 28 '17 at 06:12

score 1 · Answer 1 · answered Dec 06 '17 at 17:49

Old question but it seems others have run into this.

This isn't really an MSAL issue since the token itself isn't the problem here. The exception stems from calling https://graph.microsoft.com/v1.0/me/messages when the user doesn't have an accessible mailbox.

You generally can determine which resources have been assigned to a user by looking at that user's provisionedPlans collection:

 https://graph.microsoft.com/v1.0/me?$select=provisionedPlans

This will return a collection resources that have been provisioned for the user. For example, this user does not have Exchange provisioned:

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(provisionedPlans)/$entity",
    "provisionedPlans": [
        {
            "capabilityStatus": "Enabled",
            "provisioningStatus": "Success",
            "service": "SharePoint"
        },
        {
            "capabilityStatus": "Enabled",
            "provisioningStatus": "Success",
            "service": "SharePoint"
        }
    ]
}

Compare this with this user that does have Excange provisioned:

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(provisionedPlans)/$entity",
    "provisionedPlans": [
        {
            "capabilityStatus": "Enabled",
            "provisioningStatus": "Success",
            "service": "MicrosoftOffice"
        },
        {
            "capabilityStatus": "Enabled",
            "provisioningStatus": "Success",
            "service": "exchange"
        },
        {
            "capabilityStatus": "Enabled",
            "provisioningStatus": "Success",
            "service": "MicrosoftCommunicationsOnline"
        },
        {
            "capabilityStatus": "Enabled",
            "provisioningStatus": "Success",
            "service": "SharePoint"
        },
        {
            "capabilityStatus": "Enabled",
            "provisioningStatus": "Success",
            "service": "SharePoint"
        }
    ]
}

A similar property that may also be useful is assignedPlans. This returns the resources that have been assigned to the user and is useful for determining if provisioning simply hasn't occurred yet or for resources that are not formally "provisioned" such as Microsoft Teams.

That said, you should always defensively code for the possibility that a user doesn't have or lacks permission for a resource you're requesting. There are several scenarios where a resource may be inaccessible due to an outage or user permissions and the only sure fire way to handle these scenarios is to backstop with solid exception handling.

How should I determine if an MSAL account has an Exchange based email system? (got an exception)

1 Answers1