Using osTicket 1.16.1, 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.

As a troubleshooting step, I tried to re-enter the password for the e-mail into osTicket, but when I clicked "Save Changes," an error message appeared saying that the "Email already exists." This seems to be a bug, as we are not adding a new account, just editing the password of the existing one.

As another troubleshooting step, I upgraded osTicket to version 1.16.3, but that did not fix the issue.

In another troubleshooting step, I DELETED the e-mail account from osTicket entirely, so that I could re-add it. However, now when I try to re-add it, I still get an error saying "Email already exists." 🙁

Trying to play around with it, if I change the e-mail address to try to create a completely different one, but still leave the same Email login information, it still gives an error preventing me from adding the email. The error states "Too many login failures," which goes back to the original problem. Seems like quite the tangled web.

We've rebooted both the web server and the database server, multiple times throughout this process.

I would appreciate any help!



Take a peak at your *email (where * is your db table prefix. default is ost_) table.
You can do that via a 3rd party DB browser (like HeidiSQL, MySQL workbench, or hosted phpmyadmin).

Alternatively you could also run a SQL query like:
SELECT email_id,email,name,mail_active FROM ost_email;

Does your email address you want to use appear there?

Hi ntozier,

Thanks for the reply! The address does not appear in the SQL query results, nor is it listed in the ost_email table's data.

Is it possibly cached somewhere? It also seems to remember that this account has "too many login failures," even though the account was deleted. How can we clear out that record of failed login attempts? Or, is there something else you'd recommend?

    jiit

    Seems like the database has a record for this email or you are using this email as the username for login for another system email. You can only setup auth for on username; ie. it has to be unique authentication for each system email.

    Cheers.

    • jiit replied to this.

      KevinTheJedi Hi Kevin,

      Correct, the same username is used to manage more than one e-mail address. This is because a distribution list is used to receive e-mails, and that distribution list is also used as the address when ticket responses are sent. The tickets@ mailbox is a member of this group, and has Send As permissions.

      Can you elaborate that each system e-mail needs unique authentication? We've done it this way for years, on multiple distinct deployments of osTicket. We currently have it working on another deployment, with no issues. And, for the instance in this ticket, is was working for over a year before we suddenly ran into this authentication error.

      Open to any suggestions, just trying to make sure I understand everything. Thanks a lot!

        KevinTheJedi

        Hi Kevin,

        This must be a very recent change, within the past year or so? It didn't give us any such errors when we set it up initially, just about a year ago. Nor on other, separate deployments of osTicket that are currently working fine.

        If that's correct and this is a recent change in requirements, we'll need to buy another license to create a separate user account just to be able to send e-mail from the distribution group e-mail address. That's too bad, but so be it if that's the change. I just wonder why this requirement would have been added, though?

        Once we've got the authentication accounts separated, do you have any advice for the "Too many login failures" message we're also running into, which is what started the problem in the beginning?

        Thank you!

          jiit

          This has been a thing since like 6+ years ago...so not sure what you mean. Were you installing a really old version or something?

          Where we check the records in the database and throw the error:

          Where we lookup email in the db by email and userid:

          Cheers.

          • jiit replied to this.

            It's been like this as long as I can remember... but there is a way to get around it.
            Create a new email with any email address you want.
            Since they are the same account though you could then copy the email address in the db from the working one into the other one at the database level.

            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!

              jiit

              You probably have modern authentication enabled in which you can either setup 2FA + App Paasword or re-instate basic authentication. There are other threads with these instructions.

              If all else fails you’ll have to contact your mail admin/mail provider for further assistance.

              Cheers.

              • jiit replied to this.

                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?

                  jiit

                  That error does not exist in osTicket. You can search the code and you will not find it. So it definitely came from MS end.

                  Not sure why it's letting you do that as the code I referenced earlier clearly says no-no. 🤷‍♂️ I see now, it's only passing the email value so you are correct as long as the email is different you should be fine.

                  Cheers.

                  • jiit replied to this.

                    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.

                      jiit

                      Search the code. You will not find Too many login failures anywhere.

                      Cheers.

                      • jiit replied to this.

                        jiit

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

                        Cheers.

                        KevinTheJedi

                        Okay... Did you see the screenshot in my original post that shows the WUI giving the "too many login failures" error? Are you saying the WUI is pulling in and displaying error information from an external source?

                        I wouldn't know how to search the code. Just trying to understand what the problem was and get to the bottom of it.

                          jiit

                          Yes the error will be pulled from the connection. So whatever error MS returns we display it so you know what their response was.

                          At this point it seems like you need to contact your mail admin and/or mail provider for further assistance.

                          Cheers.

                          • jiit replied to this.

                            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.