KevinTheJedi
Hi Kevin,

The first version I ever used was 1.15.x, which we've since updated to 1.16.3. No problem on either version. For the deployment in question on this ticket, I started it on 1.16.1, and used it for a year with no problem. Always using different e-mails with the same account authentication. I definitely didn't need to modify it at the database level to accomplish this, as I'm really not a database person, I just created the accounts in the WUI. If you want to check into it further, I can give you screenshots or whatever information you wish, if there's a way I can share that with you privately.

I'll try to duplicate the current account at the database level, per ntozier's suggestion, to see if that can at least get the account created. But how can I get around the "too many failed login attempts" error that still seems to persist?

Thank you!

KevinTheJedi

Hi Kevin,

Good suggestion, but 2FA has always been turned off for this account. And, I mentioned in my original post, Microsoft 365 actually shows all the authentication attempts coming from osTicket as successful, even though osTicket thinks it failed. The "too many failed login attempts" seems to have been totally on the local osTicket system's end. Nothing with the Microsoft 365 was changed, or has been changed since. It was spontaneous on osTicket's part.

Things are working fine now. I was able to add the account without needing to do anything in the database. I just removed both e-mail accounts, and re-added them, and it worked. Both using the same account for authentication, no problem.

So, it's still a mystery as to where the failed login attempts came from, and where the record of those failures was being cached in osTicket to prevent me from modifying the account and troubleshoot it. But removing all e-mail accounts and re-adding them fixed it.

Curious if you have any thoughts as to what may have happened. But I guess if it doesn't happen again, we should be good here. You said it's not supposed to allow two e-mail addresses to have the same authentication. Clearly, it does for me, could this be contributing to some problem?

KevinTheJedi

Hi Kevin,

Thanks for the updates! Are you sure the error does not exist in osTicket? This is the exact e-mail alert we receive, which is also recorded in osTicket's system log:

-----Original Message-----
From: [redacted] Tickets <tickets@[redacted]>
Sent: Thursday, July 28, 2022 1:23 PM
To: [redacted]
Subject: Mail Fetch Failure Alert

osTicket is having trouble fetching emails from the following mail account:

User: tickets@[redacted]
Host: outlook.office365.com
Error: Too many login failures

105 consecutive errors. Maximum of 5 allowed

This could be connection issues related to the mail server. Next delayed login attempt in aprox. 10 minutes

I can tell you that the "maximum of 5 allowed" is not imposed by Microsoft 365, as well as the delay of 10 minutes. And, even if Microsoft 365 does keep a count of consecutive errors, it's not something osTicket would be able to access to read. So these "105 consecutive errors" must be counted and recorded somewhere within osTicket, and that must have been saved somewhere that didn't get cleared out until I deleted all e-mail addresses that involved the tickets@ account.

When I was trying to re-add the email address, osTicket was flagging the account as having "too many consecutive errors" before it even allowed me to save it. And I think it wasn't even trying to authenticate at that time, it was just preventing the attempt to authenticate, which prevented me from creating the account. Removing all e-mail addresses that used the account allowed me to finally create it, using the exact same authentication information as previous attempts. So, it really does seem that the error was within osTicket, not Microsoft 365. Again, I made no changes to Microsoft 365 at any point during this whole process, neither before the failures were introduced, nor as part of solving the problem.

KevinTheJedi

Okay, if it's pulling that from the connection, that makes sense. What doesn't make sense is why the account needed to be deleted and re-added before the authentication could be successful, since nothing else changed before or after osTicket began having problems.

To clarify the maximum errors/attempts restrictions is on osTicket's side but not the Too many login failures error.

This is more what I was trying to say earlier. Perhaps, if osTicket was somehow stuck on a limit of max errors, it was necessary to delete all e-mail addresses that use the account, to clear that max error limit out, before it could be allowed to try authenticating again as required when re-adding the account.

Ok, if it happens again, we'll look at what's there in the DB. It seems to have been "stuck", somehow, since the authentication info we were using was the same before the error, during the error, and after the error was fixed by deleting and recreating all accounts.

Anyway, thanks, both, for your help looking at these issues!

I know this is a somewhat old thread, but our exact same initial problem has recurred:

We suddenly started getting error alerts stating "Mail Fetch Failure Alert" and "Too many login failures." Despite receiving this alert, the system continued receiving e-mail tickets for a few more hours, but then stopped. We confirmed the account is not locked. It is an Microsoft 365 account, and we can successfully log into the mailbox using the same password as is configured in osTicket. Also, the Microsoft 365 logs shows all of osTicket's login attempts, and it shows that they are successful! We are also able to send outgoing e-mail successfully using this account from the osTicket Diagnostic tool.

Last time, the solution was to completely delete the e-mail account and re-add it. Though that process ran into several snags due to confusion in how osTicket thought the e-mails were configured, it did work once we were actually able to re-add it. This time, however, we avoided that snag but still cannot re-add the e-mail due to the "too many login failures" error.

Why does this seem to reoccur every few months, and why does osTicket think there is a login failure when we know the settings and credentials are correct, and haven't changed at all throughout any of these failures? What can we check into?

Thanks!

Just an update for anyone who comes across this thread: this time, the issue was that OAuth is now required for osTicket to connect to M365.