none
Outlook Saying "Your login information was incorrect" RRS feed

  • General discussion

  • Hello everyone,

    To give a rundown of what we're seeing:

    Since our migration to Office 365 (Modern Authentication with Hybrid Azure AD), we are seeing the following quite frequently for users all across the globe (can't includes photos as my account isn't verified yet, I've also had to remove all links :( ):

    "Your login information was incorrect. Verify your username and domain, then type your password again. If your account is new or if you administrator requested a password change you need to click Change Password then logon with your new password."


    Things to note:The user accounts are (95% of the time) not locked out, their passwords and accounts are not expired, nor are their accounts disabled (if their account meets any of the above issues, we actually receive a prompt to enter credentials).

    Please note that, upon clicking OK, Outlook reconnects without issue to the exchange server, we also sometimes see that Outlook states "Need Password" in the bottom-right of Outlook, which upon clicking on, Outlook reconnects to the Exchange server without issue.

    After looking for quite a bit of time, I've been unable to find anything with the same symptoms as what I'm seeing in our infrastructure, most of the issues I find online actually provide a prompt upon clicking "OK" or "Need Password".

    There are no issues with the accounts and their ability to log into Outlook Online, and the fact that upon clicking "OK" or "Need Password" does not prompt them for a username/password/domain implies that Exchange acknowledges that their information is correct.

    Our bandaid fix for the issue has been a profile re-creation with clearing of the Credentials Manager in the following manner:

    Deleted local appdata for Outlook, removed profile from mail-32, removed repopulated Gliding folder in appdata, removed credentials from windows credentials manager for Office2016, re-added profile in Mail-32.


    The problem appears to be a delay in syncing with Exchange where there is such a delay that we end up failing authentication.. but I cannot say for certain.

    I recently wrote the following email to our Exchange/Office 365 admins but am now seeking guidance online, please see below email for full details:

    The below is the majority of investigation that I've done into the matter, and I'm wondering if anyone else has seen the same, and if so, what are you recommendations?

    “Hey all, just a brief update.

     

    Here are some example incidents (I have 100+ others if you’d like a larger sample pool):

     

     

    I would like to make a note that this has been an on-going issue since Office 365’s inception.

     

    There are many articles which suggest changing of the Exchange Proxy Settings in Account Settings for the email account as Basic Authentication is typically enabled for the accounts, which is the case for my account at the moment (the Service Desk has yet to be migrated to Office 365, which is really quite interesting since we’re also supposed to be the ones fixing Office 365/Outlook 2016 issues, yet we don’t have accounts ourselves, not even for testing, a little silly if you ask me).

     

    Alternate solutions also recommend changing HKEY_CURRENT_USER\Software\Microsoft\ values for Exchange & Office, but again, these are suggested fixes for people who are actually receiving the login prompt for a username/password/domain.

     

    Articles I’m talking about in the above note

     

    The problem with most of the articles like the following is that they don’t seem to be the exact same issue that we’re facing, in that the users actually receive a prompt upon clicking OK:

     

    Examples:

     

    While a lot of the issues are the same (in that Outlook states the username/password combination is incorrect) when clicking ok in the above threads/forum posts, the user actually receive Exchange login boxes, where as in our case, we do not.

     

    All except for one very promising reddit post:

     

    Outlook Password Prompts and High Latency connecting to Outlook.Office365.com:

     

    =============================================================================================

     

    “I support 40 users who all connect to exchange365 via Outlook 2016 since Friday 5 users have reported getting random prompts for their outlook password, including my self. Outlook Connection Status will sometimes show really high Avg Response times. Screenshot from Friday:

     

    Pinging outlook.office365.com normally is around 100ms but on occasion will fluctuate to around 400-500 and that's usually when the password prompt seams to occur. I've tried clearing out credential manager and the remote connectivity test passes with flying colors. Clicking cancel on the password prompts 1-8times will cause them to go away and outlook is back to connected status, without ever entering a password. (SB: does not happen often, but this activity fixes password prompt)

     

    Trace route right after I get prompted for the password: Tracing route to outlook-namsouth4.office365.com [40.97.132.34] over a maximum of 30 hops:”

     

      1     1 ms     1 ms     1 ms  192.168.1.1

      2    <1 ms    <1 ms    <1 ms  10.0.0.1

      3    <1 ms     1 ms    <1 ms  [REDACTED]

      4    37 ms     6 ms     6 ms  12.247.63.113

      5    12 ms    11 ms    11 ms  cr2.ormfl.ip.att.net [12.122.143.218]

      6    15 ms    15 ms    15 ms  agg1.fldfl.ip.att.net [12.123.6.49]

      7   108 ms    29 ms    59 ms  12.123.34.169

      8   314 ms   311 ms   315 ms  12.251.254.22

      9   465 ms   462 ms   468 ms  be-75-0.ibr02.atb.ntwk.msn.net [104.44.224.230]

    10   458 ms   502 ms   478 ms  be-1-0.ibr01.atb.ntwk.msn.net [104.44.4.38]

    11   489 ms   520 ms   485 ms  be-5-0.ibr03.ch1.ntwk.msn.net [104.44.4.45]

    12   518 ms   464 ms   475 ms  be-2-0.ibr02.ch1.ntwk.msn.net [104.44.4.56]

    13   455 ms   468 ms   464 ms  be-5-0.ibr01.dm2.ntwk.msn.net [104.44.4.76]

    14   459 ms   460 ms   465 ms  be-3-0.ibr01.cnr03.dsm05.ntwk.msn.net [104.44.4.174]

    15   466 ms   464 ms   462 ms  be-4-0.ibr02.den07.ntwk.msn.net [104.44.4.97]

    16   459 ms   477 ms   463 ms  be-1-0.ibr01.den07.ntwk.msn.net [104.44.4.58]

    17   461 ms   465 ms   452 ms  be-6-0.ibr01.cnr01.cys04.ntwk.msn.net [104.44.4.112]

    18   457 ms   465 ms   461 ms  be-2-0.ibr01.cnr04.cys04.ntwk.msn.net [104.44.4.186]

    19   451 ms   450 ms   452 ms  be-7-0.ibr01.cnr03.mwh01.ntwk.msn.net [104.44.4.122]

    20   463 ms   458 ms   457 ms  ae81-0.cys04-96cbe-1a.ntwk.msn.net [104.44.9.215]

    21     *        *        *     Request timed out.

    22     *        *        *     Request timed out.

    23     *        *        *     Request timed out.

    24     *        *        *     Request timed out.

    25     *        *        *     Request timed out.

    26   559 ms   491 ms   454 ms  40.97.132.34

     

    Trace when its working fine:

     

    Tracing route to outlook-namsouth3.office365.com [40.97.133.130] over a maximum of 30 hops:

     

      1     7 ms     1 ms     1 ms  192.168.1.1

      2    <1 ms     1 ms     1 ms  10.0.0.1

      3     5 ms     1 ms     1 ms  [REDACTED]

      4     7 ms     6 ms     7 ms  12.247.63.113

      5    11 ms    11 ms    11 ms  cr2.ormfl.ip.att.net [12.122.143.218]

      6    14 ms    15 ms    15 ms  agg1.fldfl.ip.att.net [12.123.6.49]

      7    10 ms    10 ms    11 ms  12.123.34.169

      8    18 ms    15 ms    12 ms  12.251.254.22

      9   154 ms   235 ms   160 ms  be-75-0.ibr02.atb.ntwk.msn.net [104.44.224.230]

    10   184 ms   184 ms   177 ms  be-1-0.ibr01.atb.ntwk.msn.net [104.44.4.38]

    11   161 ms   161 ms   163 ms  be-5-0.ibr03.ch1.ntwk.msn.net [104.44.4.45]

    12   154 ms   156 ms   156 ms  be-2-0.ibr02.ch1.ntwk.msn.net [104.44.4.56]

    13   182 ms   183 ms   166 ms  be-5-0.ibr01.dm2.ntwk.msn.net [104.44.4.76]

    14   224 ms   165 ms   158 ms  be-3-0.ibr01.cnr03.dsm05.ntwk.msn.net 104.44.4.174]

    15   160 ms   160 ms   235 ms  be-4-0.ibr02.den07.ntwk.msn.net [104.44.4.97]

    16   181 ms   168 ms   172 ms  be-1-0.ibr01.den07.ntwk.msn.net [104.44.4.58]

    17   146 ms   149 ms   156 ms  be-6-0.ibr01.cnr01.cys04.ntwk.msn.net 104.44.4.112]

    18   159 ms   163 ms   166 ms  be-2-0.ibr01.cnr04.cys04.ntwk.msn.net 104.44.4.186]

    19   207 ms   149 ms   152 ms  be-7-0.ibr01.cnr03.mwh01.ntwk.msn.net 104.44.4.122]

    20   208 ms   192 ms   142 ms  ae81-0.cys04-96cbe-1a.ntwk.msn.net 104.44.9.215

     

    =============================================================================================

     

    Now, this would make a lot more sense, and would be a very logical explanation, please note the last comment that is bolded:

     

    On the same thread the following comments were made:

     

    “having the same issue with a few customers now, the password will just keep on popping up so far 7 different users and different companies”

     

    “Same issue here Boss, been getting this for the last 3 days, anyone see anything from Microsoft?

     

    Just FYI, when auditing the Azure Ad... I can see it's an audit failure even though their password is right when entering it into the popup box that appears.”

     

    Now, although this comment states “-when entering it into the popup box that appears.” (implying the issue is not the same as the one we’re seeing or that the post is mentioning) I figured it would be worth including in hopes that there is a way to check for failed access attempts on the backend (and if so, perhaps coordinate with Network Services to see network performance for the individual at the time of the failed attempt).

     

    Adding to this, I found the following article which could make sense with the above theory:

     

    Office 365 hybrid installation stops syncing password changes with local Active Directory.

     

    =============================================================================================

     

    “Inexplicably, sometimes clients that I have setup with a hybrid deployment that syncs local Active Directory accounts with online Office365 Exchange stops syncing.

     

    I’ve had to do this a few times when resetting the password on the local AD server doesn’t update the password on Office365.

     

    First check your Application log. It should be recording evend IDs 656 and 657 from source “Directory Synchronization” whenever you change a password and force a sync. if it doesn’t, do this:

     

        Open the registry editor (regedit) and navigate to

        HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence\PasswordSync\

        Right-click the “FullSyncRequired” key and change the value to “1”

        Restart the “Forefront Identity manager Synchronization Service” from the services applet (services.msc)

     

    That has gotten the plumbing unstuck for me a few times. Synchronization works afterwards, on schedule.

     

    (unless it breaks again)”

     

    =============================================================================================

     

     

    I also found the following article, and bolded anything I deemed related or interesting/noteworthy:

     

     

     

    =============================================================================================

     

    Microsoft says that any of the following could cause the problem:

     

            Outlook is configured to prompt you for credentials

            Incorrect password cached in credential storage

            Required Authentication Settings for outgoing server and incoming server

            Outlook Anywhere is not configured to use NTLM Authentication

            Corrupt Outlook profile

            Slow or unstable network connection

            Antivirus programs

            Shared calendars

     

    Since this is happening on several — but not all — Outlook clients, I think that random corruption of a profile or credential is unlikely. My network connections appear to be stable and fast (50Mb/s over wired Ethernet, >20 Mb/s over WiFi.).

     

    What I’ve tried:

     

    Updating Outlook 2016. In this advisory:

     


     

    Microsoft says that they’ve found and fixed a bug that causes the problem I’m seeing. I tried the update that they suggested. No change.

    *Making sure that “Always prompt for credentials” is not checked in the account settings. It wasn’t.

    Removing credentials from Control Panel > Mail > User Accounts > Manage your credentials > Windows Credentials. No joy.

    This was the solution suggested by Rackspace tech support. I didn’t think it was a likely fix, since it seemed to assume that the credential corruption that would be handled by it was random, where it appears that something is affecting multiple Outlook clients.

     

    **Resetting the network time. This isn’t one that I found on the web, but I did notice that the local network time was wrong by a few minutes. I reset the time on the server, and rebooted the clients. No difference.

     

    Rebooting the domain controllers and clients. I thought there could have been a DNS or DHCP problem. Apparently there wasn’t.

    Flushing local DNS cache. From the command line, enter: “ipconfig /flushdns”. No effect.

    Unchecking “Download Shared Folders” in Mail account settings. Nope.

    Turning off shared calendars. Didn’t help.

    Entering domain credentials into the pop-up, as opposed to Exchange server mailbox credentials. Didn’t fix the problem.

    Turning off all Norton firewall, AV, and spam blocking. Nope.

    Creating a new Outlook profile. No change.

    Starting Outlook in safe mode. Some old same old.

    Checking the SonicWALL logs for dropped packets. I set the SonicWALL packet monitoring for all packets. I started capturing, clicked OK in the pop-up window to send the stored password several times, and then turned off capturing. When I looked at the log with a filter for the client IP address, there were a few UDP multicast and broadcast packets dropped, but no other packets were dropped.

     

    I decided to try using manual control of Outlook/Exchange connection as a workaround. Setting the Outlook clients to “Work Offline” in all three cases produces the expected result: the pop-up windows stop. However, putting two of the clients back in to normal, connected, mode has caused the pop-ups to stop for more than an hour. In the third client, the Outlook 2010 one, the pop-ups came back when the client was set to normal connection mode. It’s going to be a little hard to troubleshoot this with only one client showing the problem…

     

    After five hours, the pop-up window sprang into life on one of the Outlook 2016 clients. I closed it. It did not immediately reappear. After 12 hours, it had not reappeared, nor had it reappeared on the other Outlook 2016 client.

     

    After three or four days, no more problems on the Outlook 2016 clients. Then I turned on a laptop with Outlook 2016 installed which, for a reason I don’t fully understand, had not updated its internal clock to the server’s time. Problem returned. And then it showed up on one of the formerly fixed Outlook 2016 clients. I rebooted the machine until it picked up the correct time, set it ot “work offline” mode, and dis the dame thing to the other Outlook 2016 client that had caught the disease. That fixed them both, at least so far.

     

    So I think the root cause was the wrong server clock, which caused the client’s clocks to be wrong, which caused Exchange to reject part of the automatic client login (but, strangely enough, not the whole thing). I don’t know why toggling “work offline” fixes thing, but it appears to.

     

    =============================================================================================

     

    The below is interesting to note as I’ve seen a couple of articles stating they see it more frequently with Cached Mode enabled.

     

    “Have had the same issue when our password policy kicks in. The user changes their password and can get in. Once they reboot they get prompted and if they do not enter their new password quickly enough they get locked out of AD. The fix I just found is to turn cache mode off in outlook 2016, unlock the account and then turn cache mode back on again and it goes away.”

     

    **”Same issue since Friday. Only in cached mode - online mode and OWA work OK. Password prompt pops up and the weird thing is if you click Cancel email still works. CTR-Connection in Outlook shows everything is connected.”

     

    Summary

     

    All in all based on what I’ve seen, the most logical explanation of the issue is slight delays in the network causing syncing of passwords to fail. This could either be on our end because of the slowness in some of our networks, or backend with Exchange (or a combination of the two).

     

    It could also be due to the timing on the network clocks as mentioned above, but at the same time it’s not like our clients would be getting information from different NTP sources, so that would be a stretch.

     

    Just wanted to provide an update on what I’ve found so far, hope this helps!”

     

    Regards,


    Monday, June 3, 2019 11:25 PM

All replies

  • Thanks for keeping updating this issue, hope if it could be resolved quickly. By the way, if you have any question in the meantime, please do not hesitate to open another thread to ask it.

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, June 4, 2019 2:09 AM
    Moderator