Update – January 8th 2018: After upgrading from Exchange 2016 CU7 to Exchange 2016 CU8 and restarting the server, the password prompt was occurring again on internal/external domain joined computers. Stay posted for more information.
Update – January 13th 2018: If you upgrade to any new CU versions (CU8 or higher), I would recommend resetting all your virtual directories to REVERSE the configuration advised below. On CU8, new issues arose and were resolved by fully resetting (restoring to default) the virtualdirectory configuration, and then re configuring them with the appropriate URL values. The fix below was NOT applied and is NOT needed on CU8 or later.
Update – January 14th 2018: If you still receive password prompts, you Outlook 2016 client may be trying to autoconfigure with Office365 instead of your on-premise Exchange deployment. This is due to the autodiscover order being skewed on a new Outlook 2016 update. Please see https://www.stephenwagner.com/2018/01/14/cannot-create-exchange-2016-account-office-2016-due-repeated-password-prompts/ for more information and a fix for this.
Original Article:
Today I came across an issue that I experienced with Microsoft Exchange 2013, and Microsoft Exchange 2016. The issue relates to using MAPI over HTTP with Microsoft Outlook 2016 (however I’m sure this affects earlier versions) clients.
MAPI over HTTP is used standard on Exchange 2016, or can be enabled manually on Exchange 2013 via running the command:
Set-OrganizationConfig -MapiHttpEnabled $true
You’ll notice that when domain joined computers are internal to the LAN, they will work fine and there will not be any password prompts coming from Microsoft Outlook. However, when a domain joined user leaves the LAN and is external to the network, they will start to receive password prompts like below:
After spending hours, I found this fix resolves the situation and applies to both Exchange 2013, and Exchange 2016:
Open up Exchange PowerShell and change the authentication methods on the MAPI virtual directory. We will be removing the negotiate authentication mechanism. Use the command below:
Set-MapiVirtualDirectory -Identity “YOURSERVERNAME\mapi (Default Web Site)” -ExternalURL https://YOURSERVERNAME.YOURDOMAIN.com/mapi -IISAuthenticationMethods NTLM,OAuth
We now need to modify the Authentication settings inside of IIS to remove Negotiate from both the mapi and EWS directories. The command above may have removed it from mapi, but it’s still good to confirm and we still need to change it for EWS. Open IIS Manager, Expand “Default Web Site”. Select “EWS” on the left hand side, and then select “Authentication” on the Right side as shown below:
Select Windows Authentication and then click “Providers” on the right Action Pane. Now remove “Neogiate” from the list so that only NTLM remains, as shown below:
Repeat for the mapi on the left as well (Select “Default Web Site”, select “mapi” on the left hand side, and then select “Authentication” on the right side), and confirm that only NTLM is in the list of providers.
Open up command prompt and type “IISRESET” to reload IIS, or restart your Exchange Server!
Any update on this issue? We have reset everything based on your findings and implemented the registry key. External user still receive the password prompt. Even my laptop works fine on the domain, off network, I get password prompts. Maybe a bug in CU8?
Hi Josh,
If you’re experiencing the exact issue specified in this document, it should be fully resolved if you took all the steps specified in this document, as well as any of the updated links inside of this post.
Please note, you could be experiencing another different issue, as all sorts of problems, issues, and misconfigurations can cause password prompts.
If the solution I proposed isn’t working for you, I’d recommend doing some additional troubleshooting. These issues could be caused by incorrectly configured virtual directories, incorrectly configured SSL settings, as well as settings on the Exchange server, incorrectly configured autodiscovery, as well as an issue where usernames don’t match UPNs.
Please take a look at this blog post and let me know if it applies to your scenario: https://www.stephenwagner.com/2016/09/23/outlook-2016-exchange-2013-password-prompts-upn-and-samaccountname-troubles/
Thanks,
Stephen
Hello Stephen, thanks for this great article. i was experiencing this in my staging exchange environment. I am testing have Outlook use MAPI over HTTP via NTLM, instead of RPC over HTTP via NTLM. when i made the change in staging exchange, the outlooks were able to connect when on vpn connection. but if they were not connected to vpn, their outlook would prompt for credentials when opening it each time.
after making the changes you recommended above, it has seems to improve. Outlook without VPN connection connects successfully with out cred prompts when user opens outlook, HOWEVER, after a few seconds, they start receiving pass prompts again. also, if you just hit cancel, and update the folder in Outlook, it connects again by itself. but cred prompt appear again. Any idea what could be pushing this? Please let me know.
also, FYI, my staging exchange 2013 is on CU18. but using the steps above in your article does seem to have improved it. However, Outlook still prompts for creds after a few seconds, but now we can simply update the folder and it will reconnect itself. Outlook was not able to do this before implementing this change. it was using MAPI over HTTP via nego*, and would demand a password be entered in cred prompt, otherwise Outlook would not connect. I would like to find out why after applying these steps, Outlook still promps for creds after a few seconds.
Hi Mohsan,
When you press+hold Ctrl and right click on the Outlook icon, and select “Connection Status”, is there anything showing a failed or connecting attempt in the General Tab? Is anything pending in the “Local Mailbox” tab?
I can’t comment too much on Exchange 2013, as this article was for Exchange 2016, but I’m wondering if there’s an mis-configuration for authentication settings for a Global Address List (we need to confirm if it’s having trouble syncing this, and that’s what’s causing the password prompt).
Just out of curiosity. Do you user UPN’s match their e-mail addresses? This could be a number of different issues.
Cheers,
Stephen
Hello Stephen, thanks for the quick reply. there was nothing showing as failed or connecting. What I did to resolve the issue was, I also had to remove ‘negotiate’ from the providers for Windows authentication, in IIS authentication for the Autodiscover virtual directory. So i made this change in Autodiscover virtual directory, EWS virtual directory, and MAPI virtual directory, then all Outlook clients are able to successfully connect via MAPI over HTTP with NTLM auth without a prompt for credentials? is making all these changes normal for implementing MAPI?
I did this in my staging env, and due to removing negotiate as a provider of windows authentication in IIS authentication for the EWS virtual directory…this resulted in O365 no longer being able to communicate with our MRS Proxy (CAS server), so cannot perform any migrations. I did some troubleshooting, and it seems that on the EWS virtual directory, Basic authentication, and Windows authentication need to be enabled, so O365 can connect to the MRS proxy, and due migrations.
I wanted to get your feedback regarding this. It seems if i re-add negotiate to EWS windows authentication provider, then O365 migrations work, but external Outlook user is prompted for credentials each time they open their Outlook, otherwise, won’t be able to do any migrations.
I’m also wondering if Microsoft has released any hotfix for this?, as i am on CU18, but still facing issue that was raised by the community on CU14.
Look forward to hearing back you. Thank you in advance.
this is my output when i run command: get-webservicesvirtualdirectory with a few paramaters:
InternalURI: https://address/ews/exchange.asmx
externalURI: https://address/ews/exchange.asmx
MRSProxyEnabled : True
WSSecurityAuthentication : True
BasicAuthentication : True
DigestAuthentication : False
WindowsAuthentication : False
OAuthAuthentication : True
ExternalAuthenticationMethods : {Basic, WSSecurity, OAuth}
Server : server name
if i re-add negotiate to windows authentication in IIS authentication for EWS virtual directoy, then the output for parameter ‘ExternalAuthenticationMethods’ becomes: {Basic, NTLM, WindowsIntegrated, WSSecurity, OAuth}
then O365 is able to communicate with my MRSProxy server. but then that effects external Outlook connections as mentioned in above post.
Hi Mohsan,
This problem is more complicated than the authentication mechanism’s I believe.
I’m just curious, do users UPNs match their e-mail addresses? Are all Outlook clients externally getting prompted, or just a specific version of Outlook that is prompting?
This problem in your environment is more complex, and needs to be properly troubleshooted. It’s difficult to troubleshoot just from comments left on this post.
Without having more information, all I can recommend at this point is to upgrade to CU20 to see if the issues are resolved, reverting the virtual directories to their default configuration, and finally re configuring the virtual directories from scratch.
Is anything else in the Exchange environment not working or having issues?
Stephen
Hello Stephen,
the users attribute for servicePrincipleName is not set. all outlook clients externally getting prompted each time they open their Outlook. only the clients that are enabled for MAPIHttpEnabled. the accounts that are not enabled for MAPIHTTP are connecting via RPC over HTTP with NTLM auth without any prompt for credentials, weather internally or externally.
I have raised a ticket with Microsoft regarding this. will let you know of the results.
and no, no other issues have been brought up, or that we’ve noticed. all seems to be working perfectly fine.
Hi Mohsan,
My apologies, I meant to say UPN (I incorrectly typed SPN). Does the UPN match the user’s email address?
Also, I would recommend upgrading to the latest CU available if possible.
Cheers,
Stephen
Hi,
Have the same problem on several Exchange 2013/2016 installations.
The problem wth this solution is that kerberos authentication would not be available
for internal clients and is not a viable workaround.
Mohsan,
Hope you can post what MS says/find out about your case.
Roy
Please confirm that this is the problem. Password prompts can occur for a number of reasons.
In my situation, this was finally resolved by installed the latest Exchange 2016 CU version.
Cheers
Hi,
Have the latest Exchange 2016 CU 9 and latest Windows patches.
Problem is as above:
When using Oulook Anywhere all is working without auth.prompt internal and external.
With MAPI HTTP internal is ok but with external (domain joined machines) you get
auth prompt.
Using only NTLM for both internal and external is not an option.
Is this a bug or is it “by design”
Interesting to se what MS answhere to Mohsan will bee !
Roy
Hi,
Any update on this problem ?
Mohsan,
Have you received any answhere form Microsoft ?
Roy
Hi Roy,
Have you checked to make sure the user UPNs match their email address, and have you checked this article? https://www.stephenwagner.com/2018/01/14/cannot-create-exchange-2016-account-office-2016-due-repeated-password-prompts/ not only does the issue in that link cover account creation, but also when users change from internal to external and vice versa…
This issue was corrected, so I think it’s something else that’s causing the password prompts. There’s a million things that can cause this if misconfigueation is the issue.
Stephen
Hi Stephen,
Yes, UPN=Primary mail address.
With NTLM only it is working in my config to.
I will post the answhere here if I ever find the solution 🙂
Roy
Hi all,
I recommend that you proof the ASA account. If not set create an ASA Account and Outlook stop prompting the cred.
Karsten L.
I recommend that you proof the ASA account. If not set create an ASA Account and Outlook stop prompting the cred.
Could you explain what really does it mean? “proof the ASA account” ? What does it mean?
Thanks for sharing this but unfortunately it didn’t work for me, even though I followed your instructions to the letter. I still get prompted, the only difference being that it’s much later in the Outlook connection sequence.
Hi Andy,
Sorry it didn’t help, but your issue could be caused by other regularly seen issues. This article was actually designed for an issue particularly associated with a certain CU version.
I recommend doing a search on my site (or clicking on the link in the article) to see if they can help you. It could be that you need an Office365 Exclusion registry key (like herehttps://www.stephenwagner.com/2018/01/14/cannot-create-exchange-2016-account-office-2016-due-repeated-password-prompts/), or you have UPN mismatches.
Cheers,
Stephen
I wanted to further this with my experience. Even with 2016 CU13 installed, if I have NTLM and Negotiate enabled in my providers for Mapi and EWS, my Outlook 2010 clients will get password prompts if they reboot while off network and try to connect.
If I look at Credential Manager, it sets credentials with persistence of Logon Session only. This is why if they reboot while off network, the credential is lost and Outlook will prompt. If they are on network or connected through VPN, they can connect fine and no credentials get saved to cred manager at all.
However, if I remove Negotiate as a provider, all will work as expected with no prompts, and credentials get saved as Enterprise persistance and last across reboots. Go figure?
I have yet to test this with Outlook 2016 clients but will shortly.
So in short, if you still have legacy clients connecting off network, you may want to keep Negotiate provider removed from Mapi and EWS virtual directories.
Hi All,
I have a fresh install of Exchange 2016 CU 13 like others have mentioned. If i have Negotiate enabled for the EWS,OAB or MAPI directories my domain joined external users get a password prompt upon opening outlook 2016. When I remove Negotiate and set to NTLM no password prompt externally. I’ve got UPN set properly for all of my users.
Problem with removing Negotiate for me is that it breaks the integration with Mimecast’s outlook addon.
Hi Stephen,
thanks alot!!!!
I was nearly giving up on this issue. After I changed from Negotiate and NTLM to only Ntlm the issue with the Credential Pop-Up for Mapi over HTTP users was gone away and another issue I had with RPC (Users with RPC could not open calendars from other people and not open out of office assistant) was also gone.
I had tested a lot of other things and this was the only solution that worked for me.
Best regards
Andreas
I can confirm that the issue is still happening in Exchange 2016 CU15 with Outlook 2016 and newer on Windows 10.
Have a DAG with 2 Nodes
Turning off Negotiate for the VS (Default Website):
Autodiscover (this is required, otherwise, you will still get sporadic password prompts)
EWS
MAPI
Fixes the password prompts.
The reason is, Outlook tries Kerberos authentication first when offline the corporate network and will not switch over to NTLM for whatever reason. This is because Negotiate is enabled by default on the Exchange server. If the server does not provide Kerberos (Negotiate), Outlook will use NTLM first and only.
Stephen, thanks a lot!!!
Been pulling hair with my friend (migrating EX2016 to 2019) and Outlook’s been showing credential prompt. After removing this provider, Outlook started connecting just fine! Of course now Outlook doesn’t show HTTP/Nego in connection status but at least we know where to look.
It’s me again 🙂
Actually we fixed the problem with Exchange consultant’s help! Turns out someone added SPN to old Exchange server. That SPN matched all URLs used (http/mail.company.com). That consultant used clever trick of changing URLs on the new server and updating HOSTS file on our test computer.
After removing that SPN, doing IISRESET and waiting for few minutes, familiar HTTP/Nego* popped up in Outlook’s connection status box.
No idea who added it and why (there’s no load balancer or reverse proxy YET) – it’s not needed yet. Hope it’ll help some people.
Can you add more specific resolution steps. Some added SPN, clever tricks which has been used is not very usefull 🙂 cheers
Hello,
I have EX2019 and after removing this provider Outlook started connecting just fine!, But now i cannot move any mailbox to Exchange Online. if i re-add negotiate to windows authentication in IIS authentication for EWS virtual directory, office365 migrations work but outlook prompt password when i’m outside the company and with VPN off.
Do you know if this issue have some updates?
Thanks
I think that found the solution.
When I migrate Exchange 2010 to EX2016 and now to EX2019 Outlook Anywhere stays Auth NTLM.
I change this for Negotiated and re-add negotiate to windows authentication in IIS authentication for EWS, MAPI, autodiscover virtual directory
For now solved my problem
The issue described in this article was exactly the problem I encountered with a client after migrating mailbox from Exch2010 to Exch2016.
After enabling mapi over http, updating the URLs and modifying the Authentication settings inside of IIS to remove Negotiate from both the mapi and EWS directories the problem still persisted
Only after removing Negotiate from Autodiscover VS (same steps as MAPI and EWS) did the problem go away.
Thank you Stephen Wagner and Lutz for the advise.
Thanx for this!
Really helped me get NGINX reverse proxy (free version so no rpc proxy) going by enabling MAPI over HTTP – which was giving me issues with login prompts before (Had it disabled due to this, and was using RPC over HTTPS before) I read your article.
I just wanted to say thanks — this is exactly what I needed to get my 2019 environment running.