From time to time I receive emails or inquiries about environments in which Outlook frequently or even permanently asks for login information. Some users and administrators even seem to have come to believe that Outlook's constant requests for user names and passwords are normal.
The good news: The permanent user and password request is not normal. The bad news: It is sometimes not easy to find the cause.
If Outlook constantly asks for logon information, the cause is usually the configuration of the environment. However, there have also been faulty Outlook versions and a Bug in Exchange 2016 which led to Outlook permanently requesting the user name and password. Both linked problems are no longer present in the current versions, but there are many other possible causes that are not necessarily due to Exchange or Outlook.
This article is intended to provide a few approaches to get a handle on the constant request for login information.
Why does Outlook ask for user and password at all?
In some cases, it is normal and even necessary to request the user name and password from Outlook, for example if Outlook does not know the user's login information. This is the case, for example, if the user's computer is not a member of the Active Directory in which the Exchange Server is located. In this case, Outlook cannot use the local data of the logged on user to authenticate to the Exchange Server and must ask for the AD login data.
Outlook can use different protocols (MAPIoverHTTP, RPCoverHTTP, MAPI (RPC), EWS), each protocol can have different settings for the authentication method. Switching between the different authentication methods (Basic, NTLM) can also lead to the user name and password being requested.
In the internal network and within the Active Directory, Outlook does not normally query the login information. In this case, Outlook simply forwards the user's Windows login information to the Exchange server (Kerberos, NTLM).
The following points contain my top 6 causes for frequent/permanent login data queries in Outlook.
Office 365 Autodiscover
Since November 2017, Outlook 2016 has prioritized Office 365 Autodiscover. This occasionally leads to problems when Outlook incorrectly assumes that it is an Office 365 mailbox. The following screenshot shows that Outlook first performs a query against Office 365:
The request against Office 365 ends in the query of the login information, but the query against the own Exchange organization is successful. The prioritization of Office 365 can be switched off with the following registry key:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
„ExcludeExplicitO365Endpoint“=dword:00000001
The key can be set manually in the registry, via group policy or with PowerShell:
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover" -Name "ExcludeExplicitO365Endpoint" -Value 1 -Type DWORD
After the key is entered in the registry, Office 365 is no longer prioritized and the autodiscover query works again with the local organization without any problems:
Proxies / Firewalls
When Outlook constantly asks for the login information, the first thing I now ask is whether a proxy is being used. The proxy configuration and/or the configuration of the proxy on the client and/or server causes problems with Outlook authentication from time to time. The most common configuration I have seen so far is the following:
A proxy has been configured and all connections run through this proxy, depending on the proxy configuration, this may work... or not. In this case, I recommend deactivating the proxy on the client and also on the server as a test and then testing once without the proxy. If this works, you can test with the corresponding exceptions. In most cases, it is then sufficient to configure the corresponding exceptions.
Incidentally, this also applies to reverse proxies, here too there are always configurations that are problematic for Outlook Anywhere and MAPIoverHTTP connections. The most common cause is different authentication methods on the proxy and Exchange Server. If the Exchange server only allows NTLM as an authentication method, but the reverse proxy uses the Basic method and also forwards logon data using the Basic method, the user name and password are requested in Outlook.
In both cases, Outlook can use several protocols, which can also use different authentication methods. In most cases, proxies have problems with this.
Different Exchange configurations
Another cause of authentication problems is different Exchange configurations if more than one Exchange server is used. Then often in conjunction with a proxy. As already mentioned, Outlook uses different protocols that can use different authentication procedures, and these authentication procedures can also be configured differently for each Exchange server. I remember a case where one Exchange server was configured for NTLM and another for BASIC-Auth. A load balancer was connected upstream and both Exchange servers were members of a load balancing pool. Round robin was used as the load balancing mechanism, which meant that Outlook was constantly switching between Basic and NTLM. The result: permanent querying of login information. After both Exchange servers were configured to NTLM, there were no more problems.
Saved login information
Almost a classic, but still frequently encountered: Stored incorrect/old login information in the login information management:
This problem usually only affects individual users, at some point login data for Exchange was saved, then the user changes their password. The logon information is requested. Delete the logon information from the logon information management and it will work again.
Certificates
Expired or incorrectly configured certificates can also cause problems with authentication; in addition to possible certificate warnings, users and passwords may also be requested. Here, too, I have a practical example: a load balancer was used that was configured for SSL bridging. The load balancer interrupted the SSL connection and re-encrypted it to the Exchange server. The certificate of an Exchange server had expired, but the certificate on the load balancer was still valid. Due to the invalid certificate of the Exchange server, the load balancer no longer forwarded the login data, which could have been a MITM attack. Certificate warnings in Outlook did not occur due to the valid certificate on the load balancer.
Internet Explorer
As with the proxy settings, Outlook uses the zone model of Internet Explorer. Problems can also occur here, especially in connection with MAPIoverHTTP, the new Exchange standard protocol. If the Exchange URLs are not entered in the intranet zone (or the automatic detection does not work), Outlook will try to use Basic-Auth. In this case, password queries may occur again. Entering the Exchange URLs in the intranet zone of Internet Explorer usually solves this problem.
Did none of this help?
If there are still problems with the login, then you really need to dig deeper and analyze each environment individually. The various logs, above all the IIS logs, provide indications of problems.
The exclusion method can also help. For example, explicitly configuring a client to bypass the load balancer. Test NAT instead of reverse proxy. Create a new Outlook profile on a computer and deactivate all Outlook AddIns; AddIns can also cause problems. Deactivate MAPIoverHTTP for individual mailboxes as a test; firewalls may have problems with MAPIoverHTTP. The domain controllers should also be included in the analysis. Information from the user is also important: when did the problem occur? Was the user connected to a VPN? Were there problems in the network? Did the user switch between LAN and WLAN?
All of this information can be helpful in narrowing down the problem, because as mentioned at the beginning: Permanent requests for login information are not normal.