Exchange 2013 external access authentication

Hi Experts,

some quick facts about my environment:
Exchange 2013 deployment that has been made accessible from the internet through an IIS ARR server in the DMZ.
The Exchange 2013 system allows RPC over HTTPS and MAPI over HTTPS access.
Clients are Outlook 2013 SP1 and Outlook 2010 (January 2015 update - MAPI enabled).
MAPI virtual directory is configured with for internalURL and externalURL as well as "Negotiate" for InternalAuthentication, ExternalAuthentication and IISAuthenticationMethods

Question: When clients start Outlook outside the corporate network it prompts them for their password once. After they supplied the correct password everything is working fine until Outlook is restarted. Now my understanding of "Negotiate" would be that Outlook tries to do Kerberos authentication and when it can't reach a KDC it falls back to NTLM and when falling back to NTLM it takes the users cached credentials from windows sign in and sends hashes of them to the Exchange server for validation which should make the user not having to input a password.

Is my assumption correct? If no - can someone educate me? If yes - why does Outlook prompt for a password then?

Best regards,
Vasko OreelyAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

hassan afzalIT Commented:
is this for all users or selective?
Vasko OreelyAuthor Commented:
All 3 Users I tested so far have that "problem" - sniffing the traffic with wireshark yielded unclear results because everything except DNS and certificate checks are encrypted and can't be read using wireshark
hassan afzalIT Commented:
Think your complicating things too much - is outlook setting set to "always ask for credential" when opening up ?
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

hassan afzalIT Commented:
are the credentials for the old exch server still on the machines?
Vasko OreelyAuthor Commented:
The checkbox is not checked and there is no "old exchange server". This deployment was born as Exhange 2013 only. I tested it setting up a new VM, joining it to the domain, configuring outlook using auto discover, syncing mailbox, taking VM out of network, opening outlook -> password prompt
hassan afzalIT Commented:
try changing outlook anywhere  authentication to basic and enable allow ssl offloading on the exchange server
Vasko OreelyAuthor Commented:
Will try! Could you please explain your thoughts behind your suggestion so that I can understand the changes?
IvanSystem EngineerCommented:

if im not wrong Outlook 2010 does not support MAPI over HTTP, only 2013 SP1. Those clients are 2013sp1 or 2010?

PS: There are no Outlook Anywhere settings if Outlook is using MAPI over HTTP??
Once the account is created successfully outlook will ask for credentials.  This credentials should be input in the "domainname\username" and password format, select to save the credentials and it should not ask for them again.
Vasko OreelyAuthor Commented:
@spriggan: Outlook 2010 supports Mapi over HTTPS since the December 2014 update. Microsoft pulled that update because of complications and republished it in the January 2015 update. So yes Outlook 2010 supports MAPI over HTTPS now

@hecgomrec: The problem is not the format of the entered credentials, it's the credential pop up in the first place that I want to get rid of - preferably not by "cheating" and saving the credentials in the credential manager (this creates problems with password change policies anyway).
Entering the credentials in form of DOMAIN\User works and always has. On a non domain joined machine this may be an acceptable behavior. But on a domain joined machine it is not.

Our network only has up to date Oulook 2010 and 2013 clients that all can handle Negotiate authentication. So the expected behaviour would be:

Autodiscover -> server presents auth: Negotiate -> Outlook tries kerberos -> success

Autodiscover -> server presents auth: Negotiate -> Outlook tries kerberos -> fails -> falls back to NTLM with cached domain credentials -> success

Which brings me back to my initial question if someone could confirm my understanding of the "Negotiate/NTLM" authentication in Exchange 2013 and if I'm wrong then educate me on how they are supposed to work respectively point out alternatives. Basic is a bad alternative to NTLM and Negotiate. I tried setting everything to NTLM but it still prompts for the password once on startup.

Thank you all for your efforts!
Vasko OreelyAuthor Commented:
Hi guys,

I did some more testing:

SSL Offloading and Basic auth did not help
Setting the MAPI virtual Directory IISAuthenticationMethod to NTLM made the Password prompt go away (woohoo) and Outlook shows "NTLM" in the connection overview. It is interesting that in the MAPI virtual Directory you can't set the internal and external authentication methods. You can only set the IISAuthenticationMethods which sets internal/external authentication methods to the exact same value(s) thus disabling Negotiate (and therefore Kerberos) for the internal Clients which is not what I want.
Setting the MAPI virtual directory IISAuthenticationMethod to "NTLM,Negotiate" made the Password prompt return because Outlook chooses the strongest auth method offered by autodiscover which is Negotiate. It doesn't matter if I put NTLM first in the "Windows Authentiication" Provider list in IIS - Outlook still picks "Negotiate". Which would be good if the NTLM part of the Negotiate provider would be working as I am expecting it to work

The only conclusion that makes sense for me is that the fallback NTLM - that is part of the Negotiate Provider - works differently from the pure NTLM Provider. Can someone back this theory up?
Vasko OreelyAuthor Commented:
Alright guys - I did some more digging because I really want to crack this:

I've setup wireshark to be able to decrypt SSL traffic between my client and the server. Unfortunately that does only work for web browser traffic because exchange traffic is TLSv1.2 Diffie Hellman encrypted which can only be decrypted by knowing the session keys. Browsers have a technology (google for SSLKEYLOGFILE) to log those session keys and wireshark can use that logfile and its session keys together with the web certs private key to decrypt the traffic. So it doesn't work for Outlook traffic because there is no way (that I found) to make outlook log it's session keys.

Anyway since the autodiscover virtual directory also is using Negotiate as the primary provider I started logging with wireshark and set firefox "network.negotiate-auth.trusted-uris" setting in about:config to After that I browsed and wireshark showed the plain HTTP traffic (yay!).

Unfortunately the traffic just confirms what I have been thinking already: Outlook is f*cking sh*t up! Here is the process:

1. Server and Client do their cipher match and key exchange
2. Browser requests: GET /Autodiscover/Autodiscover.xml
3. Server responds: Anonymous request disallowed and sends www-Authenticate: Negotiate and www-Authenticate: NTLM
4. Browser can't reach a KDC and has no Tickets so he falls back to NTLMSSP_NEGOTIATE (the NEGOTIATE part is the proof that it doesn't use the also offered NTLM provider but the NTLM fallback of the Negotiate provider) and he takes the current logged on Username and sends it to the server (NOT displaying a credential prompt)
5. Server responds with NTLM challenge
6. Browser sends challenge response
7. Server sends 200 OK
8. Browser shows XML

I think this should prove that the server config is fine and Outlook is the one to blame here when even a simple browser can do what he is asked and Outlook can not ;)

Man I have way too much fun in this ...
Vasko OreelyAuthor Commented:
Just for verification I did the same test for and it turns out that when you have only Negotiate enabled in the MAPI virtual directory even the browsers can't fallback to NTLM so enabling NTLM and Negotiate on the MAPI virtual directory made the process work like it did with autodiscover.
Nevertheless Outlook is still bitching arround and prompting for credentials which the browsers are not.
hassan afzalIT Commented:
maybe try switching to rpc config ?
Vasko OreelyAuthor Commented:
RPC has the same phänomenon ... NTLM works without prompt (non interactive) and Negotiate always gives the prompt (interactive)
hassan afzalIT Commented:
ah sorry Vasko didnt read the part where u said its working ! been a long day :(
Vasko OreelyAuthor Commented:
Well the only thing that works is setting everything to NTLM which is neither what I want nor what Microsoft recommends ... it's still the question if Outlook has a special behavior when using Negoiate which makes it prompt for passwords instead of using windows session credentials. Maybe there is a registry setting or GPO or something that I missed.

I hoped that someone here could either confirm this as a bug or as working as intended with the corresponding sources.
Simon Butler (Sembee)ConsultantCommented:
This has been a problem since Exchange 2003 and the first version of RPC over HTTPS.
The only cause I have found is the firewall. Nothing to do with Exchange, as I have it working elsewhere exactly as designed. Switching the firewall for another one as a test, the problem went away.

Basic authentication always works, because that is in effect plain text (even over SSL). The others have different kinds of encryption which firewalls seem to break.

If it works correctly internally, then that points the finger at the firewall.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Vasko OreelyAuthor Commented:
Hi Simon,

that sounds promising. Do you have resources on this? Are we talking about the corporate firewall or the clients windows firewall?

Thanks and regards,
Simon Butler (Sembee)ConsultantCommented:
Not the Windows firewall. The physical firewall/router you have on your network. I haven't turned off the Windows firewall on any system I have managed since Windows 2008 was released.

I have nothing to share other than my experience with numerous clients. The more sophisticated the firewall (so something that does more than just port blocking) the bigger the problem is.

Vasko OreelyAuthor Commented:
Well this leaves room for a lot of testing but anyway thanks for sharing your experience.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.