Why is the Outlook plugin asking for Sugar password repeatedly?

I am running an "onsite" instance of SugarCRM (version 7.6.2.1) with the Outlook 2010 32 bit Plugin (version 2.1.0) and throughout the day I am repeatedly asked for my Sugar password within Outlook. Once entered it works fine for a period of time (hour or two) and then the username/password dialog pops up with the password field empty. The username seems to be stored properly within the plugin setting, however the password is not. Other users I have spoken to within my place of business do not have this issue. I seems to be a local situation. Is there a timeout setting or something of that nature that I'm not seeing within the plugin settings?

Any suggestions would be appreciated, Thanks.

  • Hi Adam (and three other people so far)

    This is an interesting item. The Outlook Plug In (OPI) does not store the password by design. This was determined to be a security risk as that is a static secret and storing static secrets in a completely zero-interaction manner is insecure by nature. As a result, the credentials provided are used to log in and acquire the OAuth2 tokens, then are discarded as is standard for security. When both access and refresh tokens are invalid when presented, OPI will prompt for the user's password.

    Several things can cause the tokens to become invalid.Common issues based on normal events and configurations:

    • Changing IP if IP validation is turned on (Such as when a laptop migrates networks or moves from wireless to wired).
    • Short durations or improper durations set for the token expirations. The default expire time for a refresh token is two weeks. Settings shorter than an hour especially have a strong potential to impact OPI.
    • Third party token reissue (Another OPI logging in as the same user)

    Other items that cause the end result of "OPI presents its access token and is denied, then presents its refresh token and is denied" will also cause the password prompt and none of these are encountered in common or normal situations, but can be found in a limitless supply of potential edge cases that nobody has ever thought of before. In those situations, working with our wonderful support team might be called for to track down the cause of the behavior.

    So check the three things above and see what you find. Remember the "end result" that triggers it if those three don't pan out.

  • We frequently see this behavior:  OPI loses its credentials and requires a re-login.  Word Plugin also loses it's credentials and requires a re-login.  Presumably the Excel plugin will also misbehave.

    No other known applications are logging in as us,

    Our IP is static and

    Our token expiry is high:

      array (
        'access_token_lifetime' => 86400,
        'refresh_token_lifetime' => 86400,
      )

    Are there other reasons our OAuth Tokens are becoming invalid?

    What are those "corner cases" you mentioned?

  • Hi Kevin,

    IP-Wise, the IP that the server sees the user come from can impact it, not the IP the server is at.

    However, if I was taking a guess, I'd surmise that folks are getting logged out most likely once a day minimum. Likely on the web UI too.

    86400 seconds, at 3600 seconds per hour, is 24 hours of token lifetime for both tokens. The refresh being set identically to the access token means that when the access token expires, it will always require a new login.

    Normally access tokens are short-lived (30-60 minutes, for example) with the idea that they are multiple-use credentials and if they are sniffed, you don't want them to be able to be used for a long time. When the access token expires, the client is denied access and told the token is not usable. The client then presents the refresh token, which is a single-use "Get a new pair of tokens" token. If the refresh token is valid, the client is given a new access token and a new refresh token,

    Having both of the tokens expire at the same time obviously means that the refresh token will not be valid when the access token expires, so a new log-in will be required. You'll most likely want to reduce the lifespan of the access tokens for proper security, and increase the lifespan of the refresh tokens. The refresh token lifetime should reflect "The longest period of time that you want somebody to 'stay logged in' after logging in and while not actively using the system

    If they are getting logged out more frequently than once a day, some examples of edge cases...

    • A windows server was found to have antivirus software deleting certain session files on occasion
    • A session handler cache server repeatedly crashed on an instance, causing all sessions to become invalid.
    • A database was misconfigured in a way that caused the oauth_tokens table to not store data accurately.
    • A person with database access decided to tamper and randomly delete entries from the oauth_tokens table.
    • A server had a bad DIMM that intermittently corrupted data in some tables, including the oauth_tokens table.
    • A user logged in on two different computers in OPI, (which counts as "somewhere else logging in as you"). Or in the Web UI, on two different browsers because they normally used Chrome for SugarCRM but when they clicked on a link in Email, it opened Sugar in Edge, so they logged in there, peeked at the record, closed that, and found Chrome logged out as a result.

    Other examples of things that can cause issues are known bugs in some versions that cause sessions to be lost and some users to be logged out when server cache or metadata rebuilds occur. Those bugs are corrected in the most up to date versions (7.8.2+ and 7.9. If any of these bugs are impacting the server, they would occur generally when any changes are made from any Administration menu system,

    So in your case, if it's daily, it's the settings. If it's multiple times per day, see the above, and if all else fails, if you're on a supported version, go ahead and drop a case in with us so we can look at your specific situation for you.