Outlook Negotiate/NTLM authentication credential prompt

Question

Hello everyone,
I have been digging quite a while now for a solution to this but apparently there is not a lot of systems out there utilizing this or having problems with it. Here it comes:
We have a pure (no migration or coex) Exchange 2013 CU7 environment in production with 3 x CAS/MBX Servers (3 sites connected via WAN VPN). Inside our network our outlook clients (2013 SP1+) authenticate via Kerberos (ASA/SPN) to the Exchange Servers and
connect via MAPI over HTTP. Everything working fine!
External is a different Story: We have a Application Request Routing (ARR) machine in our perimeter network that forwards external users to the Exchange Servers and for a reason that I didn't manage to find yet I can't get it to work so that domain joined clients
(notebooks) that are outside the company's LAN would use their cached credentials to try to authenticate outlook against the Exchange Servers. Outlook always prompts the user for her/his password on start up and then connects fine. No problems after that -
PF, OoO, OAB - everything is working. If the user restarts the outlook -> password prompt once again and fine after that. Saving the credentials works but is obviously not the way NTLM/Negotiate is supposed to work.
So here is my progress on this:
I verified my virtual directory settings. Here is how the Mapi virtual directory looks like:
IISAuthenticationMethods            : {Negotiate}
InternalUrl                                    : https://mail.domain.com/mapi
InternalAuthenticationMethods    : {Negotiate}
ExternalUrl                                   : https://mail.domain.com/mapi
ExternalAuthenticationMethods   : {Negotiate}
I've set everything to Negotiate because we don't have legacy Exchange Servers nor legacy mail clients in our network. I tried setting it to NTLM only which made the problem shift. Test clients connect to exchange and are able to view/receive mails but got
the infinite credential prompt and weren't able to access PF, OoO and OAB. Setting it to NTLM and Negotiate produces the same result as Negoiate alone.
Browsing https://autodiscover.domain.com/Autodiscover/Autodiscover.xml with IE (autodiscover URL set in intranet settings) gave the expected error code 600 without prompting for credentials. Even Firefox (network.negotiate-auth.trusted-ris set to domain.com)
is utilizing cached windows credentials and is able to log on to autodiscover and OWA with windows authentication enabled.
When a client has a valid Kerberos ticket cached (cmd -> klist) Outlook uses that ticket successfully even from outside the network but as soon as the ticket is gone (sign out and sign back in) Outlook prompts for user credentials again.
"Show connection status" in Outlook and the HttpMapi log on the CAS both show that Negotiate has been used for the connection. But why the password prompt then?
I read up on IIS ARR and it seems that it just passes through the authentication information when set to "anonymous authentication" which it is.
Now how I understand the auth method Negoiate in Exchange 2013 is that Outlook and the Server try to handshake on the strongest auth mechanism available in the following order: Kerberos -> NTLM -> Password Promt (Basic/NTLM) but in my case this doesn't
apply.
Now I would apprechiate it very much if someone could educate me in how this is supposed to work and if there is a mistake in my configuration or my understanding of the authentication process correct it.
A great day to everyone!
Vasko

Answer 1

I don't have a ton experiencing using something like ARR, but we should do some testing.  The first thing I would try is to route around the ARR in the DMZ and connect directly to Exchange from externally.  This SHOULD let us know where the problem
lies.  If it succeeds (no auth prompts) then the issue is on the ARR and not Exchange.  If it fails, then the issue is with the ARR and that needs to be looked at a little more clearly.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread