MSALアカウントにExchangeベースの電子メールシステムがあるかどうかはどのように判断する必要がありますか？私はMSALで働いていると、次のエラーを受信したユーザ持っ

Question

（例外が発生しました）：

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

をコードは、デフォルトMSALのデモコードです：

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(); 
     } 
    } 

それはことが判明します統合は、このようなものです：

1. それはいくつかのメールボックスがOffic上に配置されているハイブリッド取引システム
2. ですe 365.
3. いくつかのメールボックスは構内にあります。
4. 他のメールボックスには、サードパーティのメールシステム（インター）（カスタムスクリプト経由でAD接続へのディレクトリ同期）である

質問

どのように私はこのような状況のためのコードを防御する必要がありますか？ （または同様のハイブリッド状況）？

Answer 1

古い質問ですが、他にもこのようなことが起こっているようです。

トークン自体はここでは問題ではないため、実際にはMSALの問題ではありません。ユーザーがアクセス可能なメールボックスを持たない場合、例外はhttps://graph.microsoft.com/v1.0/me/messagesを呼び出すことに起因します。

あなたは、一般的に、そのユーザーのprovisionedPlansコレクションを見ることでuserに割り当てられているリソースを決定することができます。

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

これはユーザーのためにプロビジョニングされたコレクションのリソースを返します。たとえば、このユーザーは、Exchangeがプロビジョニングされていない：

{ 
    "@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" 
     } 
    ] 
} 

はExcangeがプロビジョニング持っているこのユーザーとこれを比較します

{ 
    "@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" 
     } 
    ] 
} 

も有用である可能性がある同様の施設はassignedPlansです。これにより、userに割り当てられているリソースが返され、プロビジョニングがまだ発生していないかどうか、またはMicrosoftチームなどの正式にプロビジョニングされていないリソースの判断に役立ちます。

つまり、常には、ユーザーが要求しているリソースに対する権限を持っていないか、許可が足りていない可能性があることを防御的に示しています。リソースが停止またはユーザーのアクセス許可のためにアクセス不能になる可能性のあるシナリオがいくつか存在し、これらのシナリオを処理する唯一の確実な方法は、堅実な例外処理を使用してバックストップすることです。