0

I'm not sure this is an Exchange problem but since for now it only pops up with webmail, I will post it here and hope that anyone has a clue...

Scenario: single Exchange 2016 environment. Split DNS in place for webmail.domain.com. Basic authentication is used for OWA. Clients are all domain joined and on the internal network. Browsers used are Internet Explorer 11, Edge and Chrome.

Symptom: when a user tries to open webmail.domain.com then a credential popup appears that keeps popping up, whether correct credentials are provided or not and no access to the mailbox is given. There are 2 workarounds for this issue:

  • opening autodiscover.domain.com/owa => this also gives a credential popup but login is possible and successful. Note that autodiscover.domain.com points to the exact same IP address as webmail.domain.com, namely the internal IP address of the Exchange server. Connecting on IP address also works.

  • opening webmail.domain.com with Chrome => this also works without problems

I have been completely stumped as to what could cause this but I have the feeling it has something to do with identity/authentication. Why?

When I open internet explorer on the Exchange server and I open webmail.domain.com then I also get a credential popup but the user ID is already filled in by the system and it is not the user ID with which I am logged in on the Exchange server. In this specific case it was filled in with the "archive" account, which is a functional account used for the journaling mailbox/archive application. So it seems that the connection to the website is being made with the wrong user instance. When I try to open autodiscover.domain.com from the Exchange server, I get an empty credential popup (no user ID is filled in) and this is how it should be I believe.

It's not the first time that I come across an issue like this: at another customer internet was blocked for most users by means of a proxy/firewall. Internet access was permitted on a per user basis. The user I used on the Exchange server had permissions to go on internet, however, sometimes my internet was still blocked and the blocking page indicated the following: "Application blocked for user "domain.local\HealthMailbox04ca435d49044cf4b4f41c48dg52641"

So here as well, access to sites was seemingly initiated by the wrong user instance. I don't know if those 2 problems are exactly the same but they do look very alike in any case.

Has anyone experienced something like this? Does anyone have an idea in which direction I can look to solve this problem or in which forum I should post this kind of issue?

Additional info: if the client computer is taken out of the domain then the problem disappears. If it is joined to the domain again, the problem appears again. Anybody an idea in which direction I need to look?

Thanks and kind regards

  • When you say "a user" do you mean this problem is connected to a specific user, or do you mean "any user". If it's a specific user, is it specific to a particular device? – Rob Moir Sep 9 '17 at 11:50
  • I had a similar issue and i managed to find some clues from testconnectivity.microsoft.com (remote connectivity analyzer) + then google. just a clue – Aravinda Sep 9 '17 at 14:17
  • It's not specific to one device and not to one user. I will troubleshoot with the connectivity analyzer from Microsoft tomorrow. Thanks for the tip. – Jozef Woo Sep 10 '17 at 18:13
2

First question - why aren't you use Forms Based Authentication? That is the default and the most secure way of accessing OWA.

My instinct points at the proxy getting in the way, and trying to access using cached information. You need to ensure that you are using HTTPS only, so things aren't cached, forms based authentication for the maximum security and if you are using a proxy internally, the Exchange URLs are excluded so the client connects directly.

Almost positive this isn't an issue with Exchange, unless something has gone very wrong with the authentication settings for OWA.

  • Hi Sembee, thanks for the input. I'm not using FBA because we have Forefront TMG doing FBA already and we don't want to have 2 prompts for the users. – Jozef Woo Sep 10 '17 at 18:14
  • There is no proxy in the environment according to the security guys. We are only using HTTPS. HTTP is not accessible on Exchange and there is no redirection configured. – Jozef Woo Sep 10 '17 at 18:15
  • There are actually 2 issues; one is that the user suggested by the initial credential popup is not the logged on user. Second issue is that when changing the user ID to the one of the logged on user, you still cannot logon. The password prompt just appears again. – Jozef Woo Sep 10 '17 at 18:17
  • I checked with Wireshark & even though I'm not good at interpreting those results, I found some Kerberos related errors. I did not implement Kerberos auth for Exchange so I don't know if I'm supposed to see that or not but I thought not. So this led me to check the auth on the OWA virtual directory in IIS. There I saw that Basic and Windows Auth are enabled. The latter has 2 providers; Negotiate & NTLM. I moved NTLM to the top and now the second problem seems to be resolved: the credential prompt is still with the wrong user but I can at least log in if I change it to the correct one. – Jozef Woo Sep 10 '17 at 18:20
  • I don't know if this workaround solves the second problem for all clients or if it solves the problem with Outlook but I will verify extensively with several users and clients tomorrow. The first problem (showing a different user ID than the logged on user) is not helped by this change though so there I'm still stumped. – Jozef Woo Sep 10 '17 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.