Hi everyone,

First of all, a big thank you to this amazing community for your continuous support and the wealth of knowledge shared here. It's truly appreciated!

We are currently using osTicket version 1.18 installed on an Azure B2MS VM. The system is connected to a MySQL Flexible Server instance via a private VNET.

Previously, we successfully configured a dedicated mailbox on Microsoft 365 using oAuth2 registration. However, recent changes on Microsoft’s side seem to have disrupted our setup. Now, we’re completely locked out of the system as both agents and administrators cannot access it due to email-based MFA being enabled (emails with token are not beeing sent).

We have tried following some suggestions found in this forum, such as modifying the 2FA settings directly in the database. Unfortunately, this approach has not worked for us. After every configuration attempt, we have restarted both the VM running osTicket and the Azure-managed MySQL instance, but the issue persists.

Additionally, we’ve noticed that the system is no longer polling the dedicated M365 mailbox or opening tickets from incoming emails.

We are including a screenshot of the current configuration for reference.

Could we have missed something? Is there anything else we should do to regain access to the system? Your guidance would be greatly appreciated!

Thanks in advance for your help!

  • KevinTheJedi replied to this.

  • DSMatic

    Could we have missed something? Is there anything else we should do to regain access to the system?

    Yes, on top of the global setting to require it for all Agents you also have the configured 2FA for each Agent. In the _config table you should see records with namespace matching staff.ID where ID is the Agent's actual ID. Find the records with key of default_2fa and 2fa-email for the Agent and delete them. Once deleted that Agent should be able to login. I would recommend doing this with an Administrator account so they can login and address the email stuff which should get the 2FA back up and running for the rest of the Agents. To fix the email you'll likely need to follow the steps listed in the Attention warning at the top of this page:

    I will say that you should have the Agents setup 2FA with an Authenticator app instead of Email. This issue will likely never happen with Authenticator apps since they are virtually always available vs email where it can have issues like this.

    Cheers.

      DSMatic

      Could we have missed something? Is there anything else we should do to regain access to the system?

      Yes, on top of the global setting to require it for all Agents you also have the configured 2FA for each Agent. In the _config table you should see records with namespace matching staff.ID where ID is the Agent's actual ID. Find the records with key of default_2fa and 2fa-email for the Agent and delete them. Once deleted that Agent should be able to login. I would recommend doing this with an Administrator account so they can login and address the email stuff which should get the 2FA back up and running for the rest of the Agents. To fix the email you'll likely need to follow the steps listed in the Attention warning at the top of this page:

      I will say that you should have the Agents setup 2FA with an Authenticator app instead of Email. This issue will likely never happen with Authenticator apps since they are virtually always available vs email where it can have issues like this.

      Cheers.

        I confirm that the issue has been resolved following your guidance. By accessing the admin panel, I was able to upload the new plugin and restore the full functionality of email fetching and sending.

        Thank you very much for your prompt response and the support you provided, which were truly invaluable in resolving the issue.

        Best regards,

        Write a Reply...