Outlook for Mac 2016 - Repeated password prompts still an issue ...

Anonymous
2015-06-20T22:09:21+00:00

All-

As we know, one of the biggest bugs in Outlook for Mac 2016 is the ever-so-annoying repeated password prompt problem. This refers to the constant pop-ups that make it appear like Outlook is forgetting your password every few minutes, etc. The problem was much discussed during the Preview phase of Office for Mac 2016 but never corrected. I did some digging on the forums here and found other threads that covered this problem with slight variances, but the core issue is the same -- credentials are somehow not being stored properly or become corrupted during normal operation of the software. List of the relevant threads I found below. This list may not be comprehensive:

It seems odd that a major bug like this remained unresolved after the official release of Office for Mac 2016 ... and still hasn't been corrected! Per post responses on Microsoft's official Office Blog, they are looking into authentication issues with Exchange Server, but who knows what that means or how long that will take. Based on what I can gather:

  • Bug shows up in Outlook for Mac versions 15.9.x and up, therefore ...
  • Version 15.8 and earlier are not affected, but that is a super old preview version from 2015
  • Changing the way you present your credentials can sometimes help:

            e.g. username@DOMAIN vs. DOMAIN\username vs. username

  • Problems seem to affect Exchange Server authentication as well as IMAP or POP,
  • Deleting your account and setting up Outlook from scratch sometimes helps,
  • The issue seems to be intermittent, comes and goes.

A ticket submitted by forum member *Filip Herman* to Microsoft's technical support around early August 2015 indicated that Microsoft is aware of the problem and has a planned fix in progress. Obviously its been years since that. Others have submitted tickets to support since. Scroll to the end to read the most current progress.

I'd encourage everyone to mark this post, indicating that you "recommend this discussion." This thread has tens of thousands of views and hundreds of comments, so its clearly not an isolated issue. Unfortunately, my company abandoned the use of Outlook for Mac 2016 some while back because of this issue, so I don't have an active platform to test on anymore. However, keep trading ideas here as needed.

Best of luck-

Seattle_Expat

Outlook | MacOS | Legacy Outlook for Mac | For business

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

263 answers

Sort by: Most helpful
  1. Anonymous
    2015-07-08T21:12:42+00:00

    So, confirming that entering password get's you credentialed to the server and then it corrupts the credentials and saves the corrupted version to the Keychain.

    I'm still looking for a way to change the keychain credentials manually so that it becomes a viable entry for Outlook to use for authentication.  This could be viable workaround.

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2015-07-08T16:00:58+00:00

    ...

    This is quite simply an Outlook writing to keychain issue and it's desire to use the domain in the server entry of the Account settings rather than the user entry in the password dialog box.  Not sure why they would program it this way, but it is creating hassle in Keychain that I can't seem to fix.  It continue to overwrite anything I try to fix in Keychain as a possible work around.  Can anyone else try?   Keychain entry is "Exchange".

    ...

    Nice work!

    I was tempted to get into the weeds on this too, but time hasn't allowed in the last few weeks. Kudos for doing it first. But I can confirm that the same thing is happening for me. It appears that this is, indeed, a bug that needs fixing. I can't figure out why Microsoft would program it this way either. Makes no sense. 

    This is also (probably) why we all get prompted for the password after the machine goes into sleep mode or the like. During an active session, the creds are in memory and the session stays connected, even if they have been written to the KeyChain incorrectly. But after the machine sleeps or is not used for a while, Outlook reaches out to the KeyChain, tries to re-auth the session, and uses the mal-formed creds. Interesting.

    Seattle Expat

    Was this answer helpful?

    0 comments No comments
  3. Anonymous
    2015-07-08T15:35:48+00:00

    I'm seeing what I think is the issue in Keychain on the Mac.  I'm running all relevant latest versions (Mac 10.10.4, Outlook 15.11.1).  It seems it may be a simple error of how the keychain entry is being created when password is entered.  I'm finding that Outlook is insisting on appending the server address to any entry in the username field.  I'm betting that this issue is related to Exchange servers with different access domains to the email address domain.

    In our current setup, we access the exchange server at owa.xxx.xxx, but our email addresses are *** Email address is removed for privacy ***   The keychain entry that is being created:

    *** Email address is removed for privacy ***@owa.xxx.xxx

    Odd, right?

    If I enter my username only, then I get a keychain entry of *** Email address is removed for privacy *** - still wrong for my server.

    If I enter domain\username, I get Keychain entry of *** Email address is removed for privacy *** - still wrong, but find it interesting that the domain is removed entirely.

    This is quite simply an Outlook writing to keychain issue and it's desire to use the domain in the server entry of the Account settings rather than the user entry in the password dialog box.  Not sure why they would program it this way, but it is creating hassle in Keychain that I can't seem to fix.  It continue to overwrite anything I try to fix in Keychain as a possible work around.  Can anyone else try?   Keychain entry is "Exchange".

    Note: this is only about Exchange servers, not gmail or other issues.

    No it won't help. I have tried doing every thing. Even I tried re installing the OS.

    Was this answer helpful?

    0 comments No comments
  4. Anonymous
    2015-07-08T15:26:56+00:00

    I'm seeing what I think is the issue in Keychain on the Mac.  I'm running all relevant latest versions (Mac 10.10.4, Outlook 15.11.1).  It seems it may be a simple error of how the keychain entry is being created when password is entered.  I'm finding that Outlook is insisting on appending the server address to any entry in the username field.  I'm betting that this issue is related to Exchange servers with different access domains to the email address domain.

    In our current setup, we access the exchange server at owa.xxx.xxx, but our email addresses are ******@xxx.xxx   The keychain entry that is being created:

    ******@xxx.xxx@owa.xxx.xxx

    Odd, right?

    If I enter my username only, then I get a keychain entry of ******@owa.xxx.xxx - still wrong for my server.

    If I enter domain\username, I get Keychain entry of ******@owa.xxx.xxx - still wrong, but find it interesting that the domain is removed entirely.

    This is quite simply an Outlook writing to keychain issue and it's desire to use the domain in the server entry of the Account settings rather than the user entry in the password dialog box.  Not sure why they would program it this way, but it is creating hassle in Keychain that I can't seem to fix.  It continue to overwrite anything I try to fix in Keychain as a possible work around.  Can anyone else try?   Keychain entry is "Exchange".

    Note: this is only about Exchange servers, not gmail or other issues.

    Was this answer helpful?

    0 comments No comments
  5. Anonymous
    2015-07-06T18:02:57+00:00

    Same issue here. I just downgraded to 5.8 and now its working properly. Here's to hoping for a permanent fix. I hope all these bugs are worked out when the final version of Outlook for Mac 2016 hits "in the second half of 2015".

    Was this answer helpful?

    0 comments No comments