Looks like this is somehow an ongoing task:
Narrow down Outlook prompts for credentials. And it seems a new root cause comes into play each time. So like in the latest issue after I upgraded to Click-to-Run Office 2016. After my upgrade and on the first start I got immediately prompted for credentials. First thought was this is related to my machine or account. But my co-worker also got it and we could reproduce it constantly everytime you logon to the machine after a complete logoff.
Update June, 2017:
Good news that this particular issue is also fixed for Outlook 2013 already in October, 2016. Somehow I missed this one, but here it is:
You need to apply KB3118367.
Update September, 2016:
This issue is fixed and currently available in the September update in the First Released for Deferred channel:
https://technet.microsoft.com/en-us/office/mt465751
“Fix an issue where, when connecting to Exchange Server 2013 that is enabled for MAPI/HTTP, the user is prompted for credentials instead of being silently logged in with the user’s desktop credentials.”
The good news is that this is related to 2 consecutive failed requests. The bad news is, I found the same issue in Outlook 2013.
This was confirmed by the Outlook team and currently work on a fix for Outlook 2013 is ongoing.
We started analyzing the issue and tried to do a repro with Outlook 2013, but we couldn’t. Thus the question came up what is the difference between those version? ADAL was the first what came into my mind.
ADAL is enabled by default for Office 2016, while for Office 2013 you need to enable it by adding a registry key. You can find more information here:
- How modern authentication works for Office 2013 and Office 2016 client apps
- Enable Modern Authentication for Office 2013 on Windows devices
Even with ADAL enabled on Office 2013 we didn’t get the prompt. But when we disabled ADAL on Office 2016 the issues was solved.
Fiddler
The next step was to take some traces with Fiddler in order to find the requests causing the prompt. We could see that there are two specific requests, which causes the prompt:
When Outlook 2016 starts it gathers the settings for Groups. What are Unified Groups? I encourage you to get information from fellow MVP Justin Harris (@ntexcellence) here:
- podcast with Paul Cunningham
- video about latest changes in Office 365 Groups
- Office 365 Groups administration
As you can see Outlook sends directly an ADAL token to the on-premises Exchange server within those requests. As the on-premises Exchange server doesn’t support this authentication method an authtentication error occurs.
To be really on the safe side we added a little rule in Fiddler, which returns an error 404 on HTTP level in the area of OnBeforeResponse of FiddlerScript:
if (oSession.uriContains("exchange.asmx")) { var oBody = System.Text.Encoding.UTF8.GetString(oSession.requestBodyBytes); if (oBody.Contains("GetUnifiedGroupsSettings")) { oSession.responseCode = "404"; oSession["ui-color"] = "blue"; } }
And for sure no prompt occured!
Conclusion
We filed a case and the Outlook team confirmed that there is an issue. A hotfix is on the way. This was experienced with Outlook 2016 version 16.0.6001.1068.
As the scenarios and also the features are more and more complex there could be some unforeseen circumstances, which lead into user unfriendly experience.
Take this article maybe more as a How-To for analyzing issues like this with tools like Fiddler and mybe you suffer the same issue, which saves you some time of troubleshooting.
Thanks for this post.
LikeLike
Do you have the version of Office 2013 you were using when you did not see the issue with ADAL enabled?
LikeLike
Hi Mark,
the version was 15.0.4783.1000.
Ciao,
Ingo
LikeLike
is there is an hotfix for Office 2016 yet?
LikeLike
Hi Rika,
not yet. I’ll update the post as soon as the issue is fixed.
Ciao,
Ingo
LikeLiked by 1 person
Same issue for Client : Office 365 ProPlus Ver: 16.0.6965.2058, hope this version is also considering.
LikeLike
Pingback: Unexpected Authentication Prompts in Outlook
Thanks really Thanks ❤
LikeLike
Is any KB is available for Outlook 2016?
LikeLike
Hi Tobias,
MSI could be found here:
https://support.microsoft.com/kb/3118293
For the C2R follow this link https://technet.microsoft.com/en-us/office/mt465751 and filter for September, Outlook and “First Release for Deferred” channel.
Ciao,
Ingo
LikeLike
Thanks a lot, Ingo!
LikeLike
Was a fix ever released for Outlook 2013? I still do not see one listed here: https://technet.microsoft.com/en-us/office/mt465751
LikeLike
Hi Brad, afaik not yet.
LikeLike
Looks like still nothing….
LikeLike
Hi Rob, I missed the update for OL 2013. I updated the post with the KB, which fixes this. Sorry for missing this information.
LikeLike
Does/did this problem only affected Office 365 ProPlus or also Office 2016?
The build numbers are very different and I’m not sure if we have the hotfix installed or not.
LikeLike
Hi,
this affected both versions MSI and C2R were affected. But for both a fix is available. For the MSI check this link https://support.microsoft.com/kb/3118293
LikeLike
Pingback: Fiddler the allrounder for troubleshooting | The clueless guy
Hi all!
What about this old problem, when domain user is on external network and only when on external they get credential popup?
Here: https://social.technet.microsoft.com/Forums/office/en-US/fe3ea09f-15d7-407c-910a-90331a5b60e9/mapi-over-http-password-prompt?forum=exchangesvrclients
This is also related to mapihttp and Negotiate auth mechanism.
When we set Exchange to use mapihttp with NTLM only no prompts. Or if I cut away WWW-Authenticate: Negotiate header via haproxy also no prompts for external users.
Can someone confirm this is a bug? MS and forums are not helpful…
Thanks!
LikeLike
Hi Grega,
are you sure you get the prompt because the MAPI and not due to Autodiscover request? Have you tried doing a Fiddler trace? There you can see what is used and also which VDir causing this.
Ciao,
Ingo
LikeLike
Hi!
Yes it`s MAPI over http… See my previous post somebody posted why it is happening and I will post here too:
”
The problem originates in the LSASS (local security authority) of the client machine. It is asked to provide an NTLM hash for the purpose of authenticating to the MAPI HTTP end-point; however due to the state of the authentication engine (Kerberos is not available because DC is no longer available), it is considered to be a downgrade attack. That is, an attempt to force the less secure NTLM hash to be used when it shouldn’t.
This downgrade protection was introduced a long time ago in Windows and it is unfortunate that it is causing inconvenience in a new scenario (i.e. re-enter credentials once to access email, when resuming work whilst away from the corporate network/Domain Controller).
All told, in a world that demands more information security, we believe it is acceptable that when moving to a new, more secure platform (MAPI over HTTP versus Outlook Anywhere), some compromises need to be made. It has always been, and still is a bit of a dilemma with increased security and usability. Entering a password to reconnect to Email when away from the corporate network seems a small price to pay for improved security.
To simplify it a bit, but the reason Outlook Anywhere is working is because first of all we are using a different protocol that works differently, and that the client would be able to instruct the underlaying communication layer to use NTLM, that is not feasible the same way when using MAPIHTTP.
“
LikeLike
I get same issue in Outlook 2019 and Exchange 2016, how can help, thank you!
LikeLike
Hi Tiger Xu,
there could be many reasons for. I would recommend taking a Fiddler trace and check on which calls you receive a 401. You know how to do this?
Ciao,
Ingo
LikeLike