Can't login with MFA

Hi all,

I have MFA enabled for all my users in SuiteCRM 7.10.9 and it’s been working fine since I enabled it. However today, whenever a user tried to login, they got a message saying:

Once I disabled MFA for that user, they were able to login no problem.

Has anyone experienced this?

I found the cause, somehow something changed the configuration of the outbound email account. I set it to the correct credentials and it started working again.

Although the cause has been found, the error message that was displayed was quite misleading, would it be a good idea to raise an issue about making the error message more accurate?

Are you sure you found the cause? Is the username the same as the email address? Once you are logged in the email address should have nothing to do with session duration/expiration.

Could you provide specific information?
. Operating system
. php version

Typically that error message occurs when something is incorrect in the settings. For example: file system permissions, file system ownership, incorrect values in site_url or host within config.php, incorrect entries within .htaccess.

Isn’t it possible that MFA interferes with some of the above?

The SuiteCRM username is not the same as the email address, but the email account username is the same as the email address (is that what you meant?)

System Details:
SuiteCRM 7.10.9 (fresh install)
PHP 7.0
Ubuntu 18.04 Server
SuiteCRM is being hosted on an Amazon EC2 instance

I screwed up the outbound email account password on purpose, logged out, tried to log back in again and I got the same error message on the login page, so it seems to be the cause…

Very strange because I don’t know of any correlation between email address and session expiration.

Could you describe the PRECISE steps you are following to reproduce it?

Could you also check (at the time the error occurs) what is in your suitecrm.log as well as php/web server logs? Report any errors found there. Similarly check the browser javascript console.

Have you set file permissions/ownership correctly? (are you 100% sure or you just thik so? Why? What did yo do to set them correctly? How did you check that they are set correctly?)

Have you, by any chance, upgraded or migrated anything in the system (OS/PHP/DB/Webserver/SuiteCRM)?

Try to reset file permissions/ownership correctly then run Admin->Repairs->Quick Repair and Rebuild, then clear the browser cache (Ctrl+F5)

The following is done with everything setup correctly:

  1. Go to SuiteCRM login page
  2. Login to the admin account (this has MFA disabled)
  3. Go to admin console
  4. Click Email Settings
  5. Click Change password
  6. Enter incorrect password
  7. Click Save
  8. Click logout
  9. Enter credentials of user account with MFA enabled
  10. Hit enter
  11. Get error message saying “You have been logged out because your session has expired”; this is an endless loop
  12. Log back into admin account
  13. Go to admin console
  14. Go to Email Settings
  15. Click Change password
  16. Enter correct password
  17. Click Save
  18. Click Logout
  19. Enter credentials of user account with MFA enabled
  20. Receive email with MFA code
  21. Enter code received from email
  22. Click verify
  23. Able to login successfully

Browser Console:

I don’t believe this is related


This block gets repeated every time I try to log in. So it’s displaying the error message correctly in the logs, but not on the login page. Is it possible the message “You have been logged out because your session has expired.” is just a default when something goes wrong?

Nothing of interest in /var/log/apache2/access.log or /var/log/apache2/error.log

sudo chown -R www-data:www-data ./suitecrm/
sudo chmod -R 755 ./suitecrm/
Still get same error message when the outbound account isn’t correct

I migrated the data over from our old system, but the SuiteCRM instance itself is fresh.

Done, same error message

I don’t think the session has actually expired, it’s just displaying the incorrect error message. At least the logs say the right thing, but it would be nice to have it on the login page too.

I searched the error message and the corresponding string key is LBL_SESSION_EXPIRED.

LBL_SESSION_EXPIRED appears in a few javascript and particularly one php script:
. modules/Users/authentication/SugarAuthenticate/SugarAuthenticate.php
. include/javascript/alerts.js (as well as consolidated and cached files with this file)
. include/MVC/SugarApplication.php

Concentrating on the first file the portion of code is:

        if (!$this->userAuthenticate->loadUserOnSession($_SESSION['authenticated_user_id'])) {
            header("Location: index.php?action=Login&module=Users&loginErrorMessage=LBL_SESSION_EXPIRED");
            $GLOBALS['log']->debug('Current user session does not exist redirecting to login');

This is part of a function called postSessionAuthenticate, which is called immediately after the authentication of a user. The call takes place from a function called sessionAuthenticate wich can be found in the same file:

		if (isset ($_SESSION['authenticated_user_id'])) {

			$GLOBALS['log']->debug("We have an authenticated user id: ".$_SESSION["authenticated_user_id"]);

			$authenticated = $this->postSessionAuthenticate();


For some reason, after the session appears to be set correctly it is no longer correctly set immediately after.

I haven’t continued to reverse engineer because I don’t have time now and because I don’t have the possibility to test as I don’t have MFA.

In any case I hope this puts you in the right track.

Here are some thoughts of the potential causes that I can think of now:

  1. MFA does something to the session variables
  2. The OS user/owner of the MFA processes is not the same as the one of SuiteCRM so, at some point some (OS level) permission fails.
  3. Ajax: there may be some Ajax calls which expect some response. If there is something unexpected in the response the remaining part of the code may fail. To prevent this you should check your configuration in php.ini and look for error_reporting and correct it to avoid any output on screen. Normally I set it in the following way:
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT & ~E_WARNING