Enabling Modern Auth (OAuth 2.0) for service mailbox
Hi!
I am about to test out Modern auth (OAuth 2.0) for a customer in their test-environment.
System upgraded to 10.1.2
I did see this post talking about issues if same serial was activated 2 times ?
OAuth 2.0 Service mailbox - invalid client_id (superoffice.com)
How are we suposed to handle test/prod environements using the same serialnumber after activating Modern Auth (OAuth2)
Some of our customers have a separate test-environment that is production dump with separate mailbox(es) for testing of service , forms, and mailing, inbox etc. I mean If i test out modern auth in the test-environment that will, if I understand correctly, block the activation in the Production Environment?
If Possible, you should allow 2 registrations per serial , so that a test-environment can co-exist with a production envrionment. It would also be nice with some sort of partner-self-service for checking/unblocking a serialnumber. (Maybe that would possible in the new devloper portal somehow)
Since there will be a lot of preasure on upgrades for on prem customers until october, when MS starts the deactivation of Basic Auth for MAPI,POP,EWS protocols.
How do I switch a mailbox from MAPI(S) to modern auth?
Just "change auth" button?
Or do I need to recreate the mailbox from scratch?
It would help with a conversion-guide for MAPIS => Modern Auth?
Does one exist?
What must be prepared on the M365 side for a certain dedicated service email-box?
Best regards
Anders
All Replies (3)
Hi Anders,
Maybe you can request a separate SuperOffice serial nr for the test enviroment? As far as I know the SuperOffice serial nr is used as unique key when registering the SuperOffice environment in the 'access gateway' used by SuperOffice for authorizing OnSite environments using OAuth to access the Microsoft 365 Api.
You can switch a service mailbox to using OAuth by clicking the 'Change OAuth' button when opening the service mailbox. For this to be able to work make sure you have user credentials that directly authorize you on the mailbox, not an user which has access to it as a shared mailbox. You also need to make sure the DNS records and UPN is setup correctly so that SuperOffice can identify the mailbox correctly (see https://docs.superoffice.com/email/service.html#oauth-20)
No support for 2 duplicate onsite-env. to run OAuth 2.0 at the same time:
Onsite prod. env. --> Onsite test evn. - where using duplicate serial number - does not comply with the way 'access gateway' does its security today:
You need separate serial numbers for each site/DB to use OAuth/AccessGateway email authentication.
You shouldn't need separate serial numbers if you use app passwords instead of OAuth 2.0 in the second (...or third, or all) sites. Only the first site that tries to register with a given serial number will register successfully without manual assistance from Operations (via Support).
Basically, you need to change serial number to a unique one with the concequenses it have, or use app passwords instead of OAuth 2.0 (or get manual assistance from Operations (via Support) to activly change / delete serial number when customer wants to change from one onsite env. to another onsite evn.)
For customer who have 2 duplicate onsite-env. and already have OAuth 2.0 registered for "tenant a" and wish to change to use OAuth 2.0 to "tenant b":
* Alt. 1: For those who connect to Google mail services: use app passwords instead of OAuth 2.0 on "tenant b"
* Alt. 2: 'create' a new serial number and change to this new serial number on "tenant b". You may now use OAuth 2.0 for "tenant b":
* Alt. 3: register a support request, where you submit the serial number for "tenant a" and request to delete it from OAuth/AccessGateway - to be able to to use this serialnumber for another tenant. When you get confirmation the serial number is deleted, you may use OAuth 2.0 for "tenant b":
Turns out that Microsoft handles the App Password a bit differently than Google in terms of basic auth - and MS does not allow for usage of App Password in O365 (Cloud) from October 2022:
The use of App Passwords is dependent on basic authentication (meaning the application sends a username and password with every request, and those credentials are often stored or saved on the device). This type of authentication will be discontinued by Microsoft in October 2022
So, the "alternative 1" will only be applicable towards Google unfortunately. (leaving you with only option 2 or 3 if you connect to Microsoft, or connect to Google in your test-evn. perhaps?)
Modern authentication is enabled by default in Exchange Online(and for tenants created before August 1, 2017, modern authentication is turned off by default for Exchange Online)
https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online
The customer also need to make sure the MX Record is pointing to the Microsoft® Exchange Online server.
- If we recognize the UPN as an Microsoft 365 email account, we redirect you to Microsoft for authentication. Smart to check the UPN of a user.