I’m migrating our mail accounts from legacy IMAP provider to Microsoft 365. Also there are multiple mailboxes that are connected to Zammad. I’ve started reading the documentation and also added a Microsoft 365 Channel connection. But now I’m lost. And the more I’ve read here in the community the more I’m confused what’s the best way is.
My expectation was, that it’s appropriate to connect my admin account and then I can select the shared mailboxes I’ve access on. But obviously it’s not that easy.
Could someone tell me what’s the best way? I have enough licenses, so that will not be an issue. But I have enabled MFA for the whole organization. So it’s not possible to simply create a password for each shared mailbox because authentication would also need a fully MFA setup. And I have also enabled Modern Authentication which should be the default for MS 365 now.
Thank you for your help and merry Christmas
Pascal
You should connect to the email account using the oAuth app configuration described in the documentation.
The MFA should only affect the login to the 365 account and not the oAuth app.
When you have connected to Office365 you can add your other alias/shared email addresses by using add account.
Thank you chan for your response. Unfortunately it doesn’t address my problem. I’ve already connected the Application and it works with my personal account. Now I want to add Shared Mailboxes and authorize them via my personal account. Currently the only way I could find out is creating a password for each Shared Mailbox and authorize them separately what is annoying because you need to setup MFA for each of the Shared Mailboxes.
I am no expert at the Office365 suite, so my logic might be flawed and my answer might not help , i will be sorry in advance and hope that someone else can give you a better answer.
Would it be a approach for you to create a new user with a email license and convert shared email adresses to aliases instead, which i can confirm works in Zammad?
in short: connect one M365 user to zammad, setup aliases and shared mailboxes, give the M365 user rights on the shared mailboxes, add the emails in zammad under the M365 user and create email filters to route the incoming emails to the right groups; use the emails as sending emails from groups.
We had the same problems and I invested a lot of time into the Shared Mailbox topic and the new Microsoft 365 OAuth feature solved it without the need of additional licenses, security risks or (known) restrictions.
Set up the Azure Zammad OAuth App (what you already did)
Connect at least one Microsoft user Account with a valid Office 365 license to Zammad (what you already did with your private account, would recommend a general service account)
If you need multiple E-Mail addresses, in order to be used by your customers only, just add an email alias for the connected account on your exchange server; add it in Zammad as an additional email address of the same account and if needed add an E-Mail Filter to route incoming emails to another group in Zammad
If you need an email address, in order to be used also by people from your company (on the same exchange server), you need to create a shared mailbox and give the Microsoft User, that is connected to Zammad, full and/or send as rights for the shared mailbox on the exchange server (you don’t need to enable the user behind the shared mailbox or give it a password); forward all incoming messages (and don’t keep it in the shared mailbox) to the Microsoft User, that is connected to Zammad, on your exchange server; add it in Zammad as an additional email address of the same account and if needed add an E-Mail Filter to route incoming emails to another group in Zammad (same as with aliases). The reason behind this is, that (at least in our exchange env) aliases are converted before reaching to the primary email address and therefore zammad will not know that the internal person used an alias. When using shared mailboxes this doesn’t happen.
The limitations and problems we face by using this configuration:
users cannot drag&drop emails in the shared mailbox. Workaround is to give all users full access rights for the connected Microsoft user (security concern) in order to drag&drop email to Zammad and therefore keeping the right customer; like with aliases implement an email filter on the “To” instead of “From” field to route agent drag&droped emails to another support group (make one filter for multiple agents from the same group).
all spam and phishing emails will be in the same users quarantine (for us it is a good thing as we don’t need to train multiple users for this), i’m not sure for the shared mailbox forwarded emails
I have not seen this kind of setup anywhere and therefore cannot guarantee that Zammad or Microsoft will change the way the technology works
Wow, thanks allot for this great answer. I’ll give it a try after my vacation and if it works, I would recommend at it tot the official Zammad Documentation.
FYI we were able to set “passwords” via the o365 admin Interface to each shared mailbox. With this password you are able to connect a shared mailbox easily with zammad once you have done the initial setup: just add a new account in zammad and enter the email & password during the setup as if it is a user account.
With this approach no routing / full access etc is needed.
This is (still) technically possible but not recommended by Microsoft, or at least not officially allowed. They explicit say that you don’t enable the account and don’t give it a known password. Their recommendation is to give another user rights on the shared mailbox, like I mentioned above. You will have a problem with this configuration once they change the way it works and they can change it whenever they want as it was never supposed to work that way.
10 By default, shared mailboxes have an associated active user account with a system-generated (unknown) password. To block sign-in for the associated shared mailbox account, see Block sign-in for the shared mailbox account.
Every shared mailbox has a corresponding user account. Notice how you weren’t asked to provide a password when you created the shared mailbox? The account has a password, but it’s system-generated (unknown). You aren’t supposed to use the account to log in to the shared mailbox.
But what if an admin simply resets the password of the shared mailbox user account? Or what if an attacker gains access to the shared mailbox account credentials? This would allow the user account to log in to the shared mailbox and send email. To prevent this, you need to block sign-in for the account that’s associated with the shared mailbox.
