Continuing authentication problems with Outlook 2016 on Mac/Windows

After installing Outlook 2016 (on both Mac El Capitan and Windows 7/8/10), I was able to use Outlook ok... until I wanted to change my password. In previous versions, Outlook failed the authentication, asked me to re-enter my credentials, and from that point on, it used the new credentials. This is no longer the case. For the last 2 or 3 updates to Outlook (including 15.36, the most current) , it consistently fails to authenticate, supplying old or incorrect information and not correctly updating whatever local password cache it uses.

I've already tried removing the credential manager/keychain manager entries, deleting and readding the account, reinstalling the software, and modifying the credential format specified, all to no avail. Every time I start Outlook, I get prompted for password. This is local Exchange 2016 server; no federated id, office 365, no cloudy stuff.

I'm about at the end of my rope here - all the bogus authentication attempts cause our breakin detection sw to trigger, resulting in having to re-enable my mailbox multiple times a day.

Is there a tool that reliably fully eliminates all stored password information for Outlook so I can enter the correct info, or how do I get this to work beyond a single session? The password change appears to have precipitated the problem -- and now I can't seem to shake it. I know the password is correct.

It's reached the point of users refusing to use Outlook in favor of Apple Mail or Windows Mail. Help?

 

Question Info


Last updated August 20, 2019 Views 1,830 Applies to:

Hi David,

This issue can be due to settings and system conflict. There's no tool to eliminate all stored password information, but you can remove a profile in your Outlook 2016 account.

We suggest that you follow the steps provided in this article and check if it helps. (Note: This troubleshooting is only for Windows.)

Update us with the outcome so we can provide further assistance.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Hi David,

We've noticed the post has been inactive for 48 hours now. May we ask if you still need assistance regarding your concern?  
 
If the steps or procedure given to you resolved your issue, we encourage you to inform the Community by marking the post as an answer or by clicking on Helpful.
 
Let us know if there’s anything else we can help you with.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Sorry, I've been dealing with the hundreds of my users that are experiencing this problem and attempting to find out what happens in this bloated dog of an application with a instruction-level debugger. The suggestion you supplied worked inconsistently -- it worked OK for some users, ok for a while then failed again for other users, and not at all for others.

From tracing the executable (do you know how much system code Outlook passes through? *shudder* -- seriously, I stopped shooting system dumps with OS/360 in 1962, and I *had* source code for that), it appears the 2nd case is caused by a previous dot release of Outlook incompletely updating a value for the stored password and later versions fail to remove and replace the failed update entry when storing the new password when it changes. Outlook appears to use one of the entries at some points, and another one in other locations, which caused the client to decide inconsistently which stored version of the password used (looks like a storage pointer overlay somewhere, but that's a guess based on observation), leading to locked accounts due to too many invalid access attempts in a short period.

Seriously, folks, we need a tool that eradicates any and all stored passwords wherever Outlook has or might store them so we can start from scratch. You guys know all the places Outlook has historically put them -- why is this so hard to produce?

This worked faultlessly in Outlook 2010 and 2011 for Mac. We have halted Outlook 2016 rollout and are actively examining alternatives -- changing passwords is no longer an occasional activity, and we need this to work reliably.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Thank you for the response David. For now, what we can suggest is sending a feedback via the Outlook uservoice since the issue is ongoing.

Don't hesitate to get back to us if you need further assistance.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

FWIW, I solved this problem.

I ended up writing a short script that eliminates the credential entries for Outlook 2016 Windows from the Credential Manager on Win10 and the old locations for stored passwords in Outlook 2010, 2013 and 2016. Total of about a dozen places by the time I tested it on XP, Win 7, Win10 and the server variations. Run it, and you're back to the same state as the first time you run Outlook and cache the passwords in the first place, and the current version of 2016 can put everything in the proper places.

On Mac, I did a similar thing with AppleScript and the Keychain Access app supplied in the Applications folder. Requires an administrator id to run, but does a similar process for Entourage, Entourage Web Services, Outlook 2011, and Office 2016 and also eliminates the entries inserted by Apple Mail/Calendar/Tasks/etc to bring workstations back into compliance.

If I can get approval from the bosses, I'll make it available so others don't have to deal with this.  

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

David,

I've been following your post because we have several people experiencing the same issue on the Mac Outlook desktop client.  We opened a support ticket with Microsoft but it's on hold pending the renewal of our contact.

Hopefully you'll receive approval to share your fix.

Thanks,

Beth Cordova 

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

hi,

I am having same issue for my windows client. it's effecting only few user not all of them in my business. it's look like something going on Microsoft exchange side.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.

Still pending the powers that be, but something to manually check in the meantime:

Apple Mail/Calendar/Tasks/etc do not use the same credential structure/keys that Outlook does. If the user has ever started one of these apps and given it access to an account, it will keep sending requests with old/bad passwords, eventually leading to a lockout. An easy test is to start Apple Mail and delete the stored account info for the offending account (Mail and the other apps share the same structure). If that was it, the undesired behavior will stop.

I've opened a ticket with Apple to try to get Mail/etc to do smarter backoff if it gets an authentication failure. Hammering 10-20 attempts per second isn't acceptable behavior for a utility application.

Did this solve your problem?

Sorry this didn't help.

Great! Thanks for marking this as the answer.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this response?

Thanks for your feedback.