Microsoft Exchange Server 2016 Troubleshoot Authentication
Many Exchange administrators have been in a scenario where a user reports that they are getting prompted for their credentials by Outlook. Sometimes the prompting is endless, even if the correct credentials are typed in. Other times, a prompt is unexpected (such as after Outlook has been running for a while without any issues). These problems describe typical authentication problems. There are many other authentication issues, such as having the wrong authentication configured. Authentication issues whereby users are not able to authenticate to Active Directory are not covered in this section, since that is occurring outside of the Exchange environment.
To troubleshoot authentication issues, you need a high-level understand of the different authentication methods available with Exchange Server:
Kerberos. Kerberos is the preferred authentication method because it provides high performance and scalability, along with excellent security (such as mutual authentication by using cryptography). Kerberos is built into the Windows operating system and authentication services such as Active Directory Domain Services. Outlook, by default, attempts to negotiate the strongest authentication available, if it isn’t configured to connect with Outlook Anywhere. To use Kerberos for Exchange 2016, you need to use one or more alternate service accounts (ASAs). To create a new ASA, you can use the built-in RollAlternateserviceAccountCredential.ps1 script.
NT LAN Manager (NTLM). When Kerberos doesn’t work, NTLM is usually the fallback authentication method. It works well but has some scalability limits that can impact performance. It is preferable to use Kerberos but in some cases, such as non-domain joined clients are using Outlook (and not Outlook Anywhere), NTLM might be the best choice.
Integrated Windows authentication. Integrated Windows authentication is not really an authentication protocol like Kerberos or NTLM. Instead, it is a method of using an existing authentication protocol to provide “pass-through authentication”. With pass-through authentication, if you are already signed into an Active Directory domain, then the target resource can use your existing authentication to Windows to authenticate you to the resource, seamlessly. In other words, you don’t have to type your credentials in. This pass-through authentication is often used for intranet sites. While it can be used for Outlook on the Web, it isn’t advised because it reduces security and increases risks of a security incident. Outlook is one application that uses integrated Windows authentication for domain-joined clients.
Basic authentication. Basic authentication is sometimes used with web sites and often used with protocols such as POP3 and IMAP. In most cases, basic authentication is limited to secure connections, such as those using TLS or SSL. This protects credentials as they are sent across the network. Basic authentication uses a pop-up window for authentication prompts, which doesn’t provide a great end user experience.
Forms-based authentication. Forms-based authentication is authentication that relies on a web site form for authentication. In the majority of uses, such as Outlook on the Web, a user-friendly web page has a form to fill in your username and password. You click OK or Submit and authentication occurs in the background. By default, forms-based authentication is used with the Exchange Admin Center.
By default, Exchange Server 2016 has specific authentication methods configured for the default web sites and the virtual directories. If any of those authentication methods are changed, it can create issues for users or backend services. See https://technet.microsoft.com/en-us/library/gg247612(v=exchg.150).aspx for a complete listing of the default authentication settings for Exchange Server 2013 and Exchange Server 2016.
Besides looking at the configuration during troubleshooting, you should also look at the log files – the event logs and the IIS logs. Every time a user or administrator authenticates to Outlook on the Web or the Exchange Admin Center, many entries will be written to the IIS logs. For example, in the below screen capture, the highlighted log snippet shows Adatum\Administrator signing into the Exchange Admin Center.
You will also find logon logs in the Security event log, such as the entry in the screen capture below showing one of health mailboxes authenticating:
