Infos:
- Zammad Version: 6.5.2
- Installation Type: Package
- OS: Ubuntu 22.04 LTS
- Browser: Multiple (tested with Chrome)
Problem / Question
We started experiencing the following error after our administrator enabled multi-factor authentication (MFA):
Can’t use Channel::Driver::MicrosoftGraphInbound: #<RuntimeError: Failed to refresh XOAUTH2 access_token of provider ‘microsoft_graph’: Request failed! ERROR: invalid_grant (AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access ‘00000003-0000-0000-c000-000000000000’. Trace ID: … Correlation ID: … Timestamp: 2026-05-18 09:43:58Z)>
We had to re-authenticate 12 mail accounts after MFA was enabled. The issue only seems to happen with shared mailboxes.
After re-authenticating the shared mailbox connection in Zammad, all emails from those shared mailboxes were imported again into the system. This happened multiple times this morning after different re-authentications.
We did not change any configuration here. The only action performed was re-authenticating the accounts after MFA was enabled.
We also skipped the ‘archive emails’ option because we wanted to avoid importing all emails again, but the issue still occurred.
Could this be related to how Zammad handles OAuth token renewal or shared mailbox identification after MFA is enabled in Microsoft Graph?
Has anyone experienced similar behavior with shared mailboxes?
Any guidance would be greatly appreciated.
Thanks in advance!
Normally, this should not be the case, because the emails are already marked as read.
Look at the screenshot. Keep messages on server: no. Possibly the form ‚forgot‘ the setting state and begun importing the read mail. Technically a data loss if the admin doesn‘t notice.
In my tests, the form is working as expected and uses the “previous” value. So when “Yes” was selected before, it’s also pre-filled like that in the form after a re-authentication.
That’s odd. The only other reason would be that Zammad would use a wrong authenticated user, but if I recall correctly that was fixed in 6.4 or 6.5 so this shouldn’t be the case for 6.5.2 as well…
Thank you for your responses.
After further investigation, we have identified that in some cases, the keep_on_server flag appears to be modified automatically during re-authentication. We were unable to find a consistent pattern, but out of 19 re-authenticated accounts, 8 had their keep_on_server value silently changed from true to false.
This caused emails to start being deleted from those accounts. Each deleted email was re-ingested into Zammad, regardless of whether it already existed in Zammad or whether it had been read on the server, generating duplicate messages.
We have JSON snapshots of the email account configurations from before and after the re-authentication. It is unclear whether the form failed to load the correct value or whether it was saved incorrectly. We did not catch it at the time because we had no reason to expect that setting to change on its own.
We are happy to share the JSON evidence if it would help with the investigation.
I think a JSON will not really help. It would also be good to update to 7.0. It could be that this part was also improved in the meantime.
We’ll look into updating it and, if it keeps happening, we’ll bring it up again. Appreciate it, and thanks for the replies.
