Email Account Using Microsoft Graph As Receiver With Office 365 Email Provider In 8.4.3 Doesn't Work

General
, , , , , ,
1

Hello All,

Our organization is migrating from the IMAP (using user name and password) approach to Microsoft Graph with Office 365 using OAUTH 2.0.

Hence, my application built on PegaRules 8.4.3 Cloud, has to upgrade all the current email account rules that were configured with IMAP (using user name and password) to Microsoft Graph with Office 365 email provider using OAUTH 2.0.

We came to know from the help that Pega is limiting the grant type of the OAUTH profile to either Client Credentials or Password Credentials. Clearly we cannot use the Password credentials as this is what our organization messaging team are deprecating, hence the only option left for us it to set up the OAUTH 2.0 profile with Client credentials.

Hence, we started this migration procedure with the help of messaging team and we have created the new OAUTH 2.0 profile with grant type as Client credentials.

We have configured OAUTH2.0 profile as below:

  1. Client Identifier = Messaging team provided by creating app in their Azure
  2. Client Secrete = Messaging team provided by creating app in their Azure
  3. Scope = https://graph.microsoft.com/.default (this is mandatory, without this, we cannot establish connection, and the value is generic provided by Microsoft)
  4. Access token end point URL = Sign in to your account (this is mandatory, without this, we cannot establish connection, and the value is generic provided by Microsoft)

Now, when we tested our connection from email account rule using “Test Connectivity” in the receiver section, then we get the exception which is attached as a screen shot.

Response code 401, Unauthorized
Handling error response
Deserializing type GraphErrorResponse
Graph service exception Error code: NoPermissionsInAccessToken
Error message: The token contains no permissions, or permissions can not be understood.

We tried the same in postman tool and get the same error.

When messaging team tries to get Microsoft support teams help, they claimed that they cannot configure an app in Azure without a re-direct URL.

Which is available only if OAUTH2.0 profile is configured with grant type as "Authorization code, which is limited when Microsoft Graph is selected via email account rule.

Now, we are kind of in a confusion state and kind of stuck here and neither team (Pega or Messaging team) know how to resolve this issue.

If this feature was provided by Pega, then

  1. How they tested this?
  2. Are we missing any permissions or configuration setting either from app or cloud perspective?
  3. Did anyone implemented Microsoft Graph option from email account?

Any assistance or hint here is much appreciated.

EmailAccount_With_Graph_Exception.JPG
EmailAccount_With_Graph_Exception.JPG1005×823 60.1 KB

2

@guptr2 can you please comment.

3

Hello All,

The problem is resolved. Thanks to the Pega support team for helping me to resolve this issue. The incident ticket that was created for this issue is INC-151612 if anyone want’s to refer.

After we follow the attached document and especially provided the required permissions as per the document in Azure app configuration, this problem is resolved.

MS Graph with Email Server Reciver.docx (513 KB)

4

@GiriKonatham: Hi, I have tried to use the Microsoft Graph API and found that the Pega Email Listener when configured using this protocol is not able to read emails wherein there is an email attachment. It only processes the parent email and the attachments inside it which in this case is an email is not being able to be read. Could you please confirm if an email with an email as an attachment is being able to be processed by the Pega Listener which is using the Microsoft Graph API from your end ?

Thanks,

Siva

5

@GiriKonatham Can you share the document

6

@GiriKonatham I’m trying to configure the same. I have followed all the steps and still getting 401.

“Access token endpoint invocation failed : {ErrorMessage=Response status : 401 Unauthorized, statuscode=401}”

Not sure if any other configuration from Azure AD is needed. Can you add the platform configuration that needs to be done in Azure AD (like what is the redirect URI for web platform)?

7

@Sivaraman This was supposedly a bug in PEGA 8.4 version. This was resolved to some extent in 8.5.2 but further we identified issue with attachment getting dropped. Finally we got hotfix to resolve all attachment issue after lots of tracing and digging the services calls.