Outlook 2013 users were sometimes receiving a single pop-up prompt for credentials whenever they opened the Public Folder (we have only one). One. Single. Prompt.
Google was frustratingly unhelpful because searching for "outlook prompts for username and password when opening public folders" or something similar just resulted in a lot of folks who were always getting a pop-up that wouldn't go away. It was usually caused by an authentication failure of some sort.
However, we were in a different boat - Users got the prompt once when they first launched Outlook and opened their public folders, but after entering it they could continue - authentication worked. Next time they logged in to their PC, it would happen again. Not a show stopper, but it definitely generated its share of support calls.
After I finally stopped "troubleblasting" to think about it a bit more critically, the key pieces of this fell in to place:
- A credential prompt means that either NTLM failed and/or Basic Authentication is being used (and your password hasn't been previously saved, or isn't permitted to be).
- Outlook (and Office in general) were not 100% up-to-date with the latest non-critical/non-security patches due incompatibilities with the "old" environment.
- We use a non-persistent desktop image in our VDI environment - Credential Manager doesn't preserve saved passwords between sessions.
Because this was all internal communication, Outlook should have respected our selected internal authentication method for Outlook Anywhere: NTLM. It seemed to be ignoring it, but in actuality, it was incorrectly looking at our external authentication method: Basic.
Note: Running Get-OutlookAnywhere | fl server,*external*,*internal* should show your internal and external settings for all servers - essentially "NTLM" means integrated Windows authentication on a domain-joined PC, "Basic" means we just prompt the user with a standard pop-up for their password.
Apparently this is (or was) a bug in Outlook 2007, 2010, and 2013 (See KB2839517) where the client would correctly look at the first EXHTTP block during the autodiscover response (the internal setting) when connecting to a primary mailbox, but would then arbitrarily skip to the second EXHTTP block (the external setting) for any alternate mailboxes. Since we had migrated our public folder to Exchange 2013, it was now technically a shared (alternate) mailbox. Since we hadn't patched Outlook, the bug impacted us and thus basic authentication was used!
The final slice of the mystery (and the reason most environments would never be bothered by this) was that our desktop images in the VDI environment did not persist between login sessions - as soon as a user logs off, the machine is shut down and the image is reprovisioned during the next boot-up. User data is preserved (Documents, desktop items, etc) but not the Credential Manager store, which is where your basic authentication username/password is kept when you hit the "Remember password" option. For a normal environment, the user would have just clicked that button and never seen the prompt again, but our users were prompted every day after initial log in.
There were three possible fixes:
- Patch Outlook to ensure it is correctly looking at the internal setting.
- Configure our gold desktop image to preserve the credential store between sessions
- Adjust the external authentication method to NTLM or Negotiate
Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalClientAuthenticationMethod Negotiate
I could have also set it all to NTLM, but I wanted to ensure the highest compatibility with non-domain joined external computers running Outlook. An 'iisreset' later and we were in business - no more prompt and the Outlook Connection Status dialog showed NTLM across the board.
Incidentally, this also solved a problem with Lync 2013 throwing a credential prompt during login as well - I suspect the issue was similar and directly related, but I'm not completely sure why Lync was suffering the same problem.
Something else blew up before I could think on it more.