"Modern Authentication" for SMTP Office 365 IFS cloud
Hi!
A customer reached out and asked about the the SMTP authentication for Event Actions in IFS Cloud 22R1. Are there an option to use a modern authentication (like Oauth 2.0) when connecting to Office 365 Exchange server ?
The background is that Microsoft are moving away from legacy authentication methods (in some areas it’s deprecated) and recommend upgrading your authentication method.
Is this feature, promised for 22R2, available yet? We’re on 23R1 and we can’t get it to work. It will be a blocker for our implementation if we can’t send emails through Microsoft Office 365.
I am looking for this functionality too. We are on 23R1, but can’t get it to work. Worked with my partner, no luck. Asked support, they told me to open a consultancy ticket because they don’t support implementing features, opened a consultancy ticket and they forwarded it on to my partner without communicating with me in any way. #momentofservice
Guessing that someone at IFS knows how to configure this. Would be nice if they would share their knowledge.
Exchange Online removed all forms of Basic auth as of 2022-12-31, with Client Submission (SMTP AUTH) being the only exception.
We're already looking to move our email tenant to reduce our spend, and it's going to cost us extra money to keep an ERP around that can't support this.
Is this working yet?
Is this working yet?
Hi all,
Am I right in thinking that if you are on Apps10 that this new feature is not available ?
Thanks
Microsoft is still scheduled to retire basic authentication for client submission, so the deadline is now just six months away. Is this working yet?
Microsoft is still scheduled to retire basic authentication for client submission, so the deadline is now just six months away. Is this working yet?
Hi @durette,
Oauth2 authentication is supported since 23R1 for mail sender/reader. I have not set it up by myself but the steps are included in the documentation.
Does anyone have any more information on the exact flow to follow to set up either client credentials or authorization code with mail senders in Cloud ?
I found a document done by @Krzysztof Ryszkowski on
But it doesn’t really help me as I have some outstanding questions.
For Instance, if we want to use the Authorization Code flow, the document says that the Redirect URI is mandatory when configuring the App on the Azure Portal, but I don’t know what that redirect URI would be ?
When you setup an IDP Provider in Cloud, it does provide you with the redirect URI
But it does not provide you one when you try and set up a Mail Sender.
Should I simply use the same App / Endpoints as my IDP ones? When I log in with SSO, obviously I get asked for my email/password/2FA Auth Challenge, but this can’t be right for a mail account as the Mail Sender config doesn’t actually let you register a password when you switch the Authentication Type to either Authorization Code or Client Credentials ?
It also says that the “user” should be the user that created the app registration in azure, but that seems very weird ? So if one of my IT staff Registers the Azure App I need to use their own email in the User field ?!
Any input appreciated
Ok so I did end up managing to configure this in Cloud using Client Submission (not Authorization code), following roughly the steps outlined by @Krzysztof Ryszkowski.
I did do the powershell steps, I don’t know if they were actually required or not, but I think they are required to basically link the registered azure application to a particular mailbox so that only that mailbox can authenticate using that App (or rather, so that IFS when contacting O365 through App oAuth Authentication is allowed to open that particular mailbox to send emails from)
In short:
Register App In Azure with all required permissions (I used IMAP/POP/SMTP, not sure if IMAP/POP are required, but just followed the steps above). No need for a redirect URI at least when using Client Submission
Create Client Secret, and make sure to keep the Secret Value to input in IFS Later
Get the Token Endpoint ID for your tenant to input in IFS Later
Run Powershell scripts detailed by @Krzysztof Ryszkowski to create service principal and link service principal to the mailbox you want to use to send emails from (typically something like noreply@<yourcompany>.com or any equivalent)
Create your MAIL_SENDER as follows: You might need to figure out which host and port to use. For me, smtp.office365.com worked, smtp-mail.outlook.com did not.
Here, the “user” and “default mail sender” are the same, and they are my dedicated email account used to send emails from ifs (like I said above, something along the lines of noreply@<yourcompanydomain>.com.
The Client ID is the Azure App ID, which you get in the App details in Azure. It is NOT the Secret ID
The Client Secret is the Secret VALUE you get in the Secret Details for the App in Azure. It is NOT the Secret ID
The Access Token URL is the Token Endpoint Url for our Tenant
This has worked and my Cloud Instance now manages to send Emails through our MS O365 Corporate Account using oAuth with Client Submission
Hi all,
Trying to figure out how to configure new SMTP links outside the Basic auth, we followed the step by step from @Krzysztof Ryszkowski but are struggling at the end with following error :
Caused by: com.sun.mail.smtp.SMTPSendFailedException: 530 5.7.57 Client not authenticated to send mail. Error: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled for the Tenant. Visit https://aka.ms/smtp_auth_disabled for more information.
It seems that it is meant to be like that with installation from O365 services, as explained in the attached microsoft link.
Did anyone experienced that ? Dont know what to do to finalize the configuration in Client Credentials mode. Did anyone make it work as Authorization code flow ?
I’m having the same issue since Microsoft changed some stuff around Azure/Graph/Powershell stuff. One account I set up using the steps above like 6 months ago and it still works to this day, but my IT department is trying to set a new account up without success, getting this “Client not Authenticated to send email” errors.