Deprecation of Basic Authentication for POP3/IMAP in Exchange Online

[ewilson]

What's Changing?
Microsoft are removing the ability to use Basic Authentication in Exchange Online for POP, IMAP, and other protocols.

https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online

From Microsoft's announcement:
"SMTP AUTH will still be available when Basic authentication is permanently disabled on October 1, 2022. The reason SMTP will still be available is that many multi-function devices such as printers and scanners can't be updated to use modern authentication. However, we strongly encourage customers to move away from using Basic authentication with SMTP AUTH when possible. Other options for sending authenticated mail include using alternative protocols, such as the Microsoft Graph API."

Microsoft's change does NOT impact the Outlook EMail VBO or the Microsoft Graph-based Outlook connector.

Updated VBO
We have released an update to the EMail - POP3/SMTP VBO which includes support for OAuth2 authentication with POP3. If you don't require OAuth2 support for POP3, you can continue to use the VBO as you normally would. If you do require OAuth2 authentication to access your mailboxes via POP3 (ex. Exchange Online), there are two new input parameters that must be set on the Configure action. They are Use OAuth2 (Flag) and Access Token (Text). You must retrieve an Access Token first, before calling the Configure action. For Microsoft Exchange Online, you can leverage the Microsoft Authentication Library (MSAL.NET) VBO to get a Delegated Access token based on username and password. That token can then be passed in to the POP3 VBO to perform any actions.

#Email #POP3 #SMTP

Cheers,

​​​

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[Neel1]

Thanks @ewilson for this. This is need of hour.

One Query - The changes which you are doing for replacing the Smtp Client with mime Kit​ will be done in same VBO . Right?​

------------------------------
Neeraj Kumar
Technical Architect
------------------------------

[ewilson]

Hi @Neeraj Kumar,

Yes, it's the same VBO. It's just been enhanced. It does have some DLL decencies now​ due to the use of MailKit/MimeKit, so be aware of those. The actions are largely the same, in terms of input, except for the Configure action. It has two additional input parameters now.

Cheers,

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[Árni_GunnarAndr]

Hi Eric, appreciate the detailed instructions.

I am however having issues with the coding of the MSAL VBO.
When testing the object in Object studio [Get Auth Token - Client Secret], it returns an access token without issue.
As soon as I integrate the VBO Action into any Blue Prism process it results in an internal error:

• Internal : Could not execute code stage because exception thrown by code stage: One or more errors occurred.

Do you have any insight into what might be the cause?

Edit: Resolved. Access Token had to be changed from the auto chosen Password to Text.


------------------------------
Árni Gunnar Andrason
------------------------------

[ewilson]

Hello @Árni Gunnar Andrason 

So the issue you're running into is specifically with the MSAL.NET VBO as opposed to the POP3/SMTP VBO? I assume you have a valid Tenant ID, Client ID, Client Secret, and Scope and that you deployed the Microsoft.Identity.Client.dll library to the Blue Prism Automate folder?

UPDATE - I other question. What version of Blue Prism are you using?

Cheers,

​​​​

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[Kirk.Russell]

Hi @ewilson

I am also having issues with the MSAL.NET VBO - while trying to use it to retrieve a token to use with the new configuration action in the Email/POP3 vbo​.

I have TenantID, ClientID, Client Secret and Scope, I have added the dll to the Automate folder on the Management Server but the worker does not seem to be able to access that? I don't seem to have permissions to add the dll directly to the worker's automate folder. Am I misunderstanding something here and adding the dll to the wrong place or in the wrong way? I have logged out and back in again to Blue Prism and restarted the worker.

Running a process with the MSAL Get Token using Client Secret gets a compiler error on the worker ( can't find dll), on the MS it compiles okay but still gets a similar error response as posted by Arni - one or more errors occurred.

We are using v6.10.1

I realise this may be some basic error on my part installing the MSAL vbo and dll, but any help or suggestion would be appreciated.

Thanks
Kirk

------------------------------
Kirk Russell Senior Robotics Developer
NHS Dorset
NHS Dorset
------------------------------

[ewilson]

Hello @Kirk Russell,

There are two ways to address this. Assuming you do not have permissions to add files to the ​Blue Prism folder (i.e. C:\Program Files\Blue Prism Limited\Blue Prism Automate) you can either:

1. Raise a support ticket with your IT folks and request that they add the DLL to that folder.
   OR
2. Place the DLL in a different folder (one you have access to) and then change the DLL reference in the VBO.

If you opt for #2, you can change the DLL reference by opening the MSAL.NET VBO and then double-clicking on the Note stage on the Initialise tab. From there, you want to go to the Code Options tab and edit the definition of Microsoft.Identity.Client.dll within the External References list. You'll want to add the fully qualified path to the DLL. Here's an example with the DLL placed in the Temp folder (not ideal):


You will need to restart your Blue Prism client after making this change.

Cheers,

​

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[Kirk.Russell]

Hi @ewilson

Thanks for getting back to me​, I added the dll into the folder on the worker and restarted and tried again, getting a similar error message to that Arni got

Is there some other config we need to do to allow this object to connect with the Authentication agent on Azure? I am using the IDs and Secret supplied by our IT department.

Also as an aside do we need to add the dll into every worker individually if wanting them to use this?

Thanks
Kirk

------------------------------
Kirk Russell Senior Robotics Developer
NHS Dorset
NHS Dorset
------------------------------

[ewilson]

Hi @Kirk Russell,

@Árni Gunnar Andrason appears to have resolved his issue by changing a data item definition from Password to Text. I'm not clear on what exactly he changed or what version of Blue Prism he's using. Perhaps he'll see this and provide some additional detail.

The only thing I can think, relative to your specific issue, is that there is some sort of DLL conflict. That does pop-up from time to time with different versions of Blue Prism. Let me get a clean v6.10 install stood up and see if I can recreate your issue.

Regarding your last question, yes you would need to deploy that DLL to every runtime resource that would potentially use this VBO.

Cheers,
​​

------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------

[Kirk.Russell]

Hi @ewilson

I saw what Arni mentioned and tried changing the Token data item to text from password - but that didn't make any difference.

We are on a legacy Thoughtonomy version of the platform and mid changing to our new Blue Prism platform as well - in case that may be adding to any possible conflicts​.

Thanks for clarifying the need to add the dll to all workers - I wasn't aware of that.

Thanks for looking into this for us
Kirk​​

------------------------------
Kirk Russell Senior Robotics Developer
NHS Dorset
NHS Dorset
------------------------------