One of the most annoying Exchange-related problems for end users is when Outlook repeatedly prompts them for a password. In Outlook 2007, a bug caused this problem. But there's no known bug that causes Outlook 2013 to do this. Here are some possible causes for the persistent Outlook 2013 password prompt and some ways to fix it.
When you connect Outlook 2013 to an Exchange 2013 mailbox for the first time, Outlook will ask for a password. This is especially true in situations when Outlook is connected to a mailbox residing on Office 365. When this occurs, the password prompt dialog box contains a checkbox users can select to force Outlook to remember their credentials. If this checkbox is selected, users won't see the password prompt again until the next time they change their password. When the Outlook password prompt appears again, end users can enter the new password and once again select the checkbox to force Outlook to remember the password.
If this procedure doesn't correct the problem, the issue with the Outlook password prompt is probably related to an improper Global Catalog server registration. Before I explain how to check for and resolve this issue, I'll point out that this procedure is written for Exchange Server 2013. It can easily be adapted to earlier versions of Exchange, but depending on the Windows and Exchange versions in use, you may have to install the Windows Server Support Tools.
Exchange Server uses service principal names to identify a specific instance of a service. Kerberos authentication is impossible unless the service principal names are correctly configured. Exchange uses a number of service principal names that are correctly registered -- in most cases. However, the server to which some specific service principal names are registered must be a Global Catalog server. These service principal names will occasionally be registered to an Exchange Server. If that Exchange Server is not also a Global Catalog server --and it usually won't be -- Kerberos authentication for the corresponding services breaks down.
Fortunately, this problem is usually easy to correct. The service principal name you must examine is called ExchangeAB. There are two separate ExchangeAB listings: one is connected to your Exchange Server's host name, the other is connected to your Exchange Server's fully qualified domain name (FQDN). For example, my lab server is named Lab15E2K13.lab15.com. As such, my two ExchangeAB listings would be:
The first step in resolving the Outlook password prompt issue is to open an elevated command prompt window on your mailbox server and enter the SETSPN –L command followed by the name of your Exchange Server (Figure 1).
Use the SETSPN –L command to list the registered service principal names.
There are two things to look for in this screen: Make sure the ExchangeAB entries exist, and ensure they list the correct host name and fully qualified domain name. The exception to this would be in a clustered environment where these entries would need to reference the cluster's identity rather than specific cluster nodes.
Once you've confirmed the ExchangeAB entries, you'll have to determine the Global Catalog server name. To do so, open PowerShell on a domain controller and use the following command to determine the names of your global catalog servers (Figure 2):
Get-ADForest <forest name> | FL GlobalCatalogs
Use the Get-ADForest cmdlet to determine the names of your global catalog servers.
The last step is to remove the existing service principal name registrations and reregister them using your Global Catalog server. If the Exchange server's FQDN was Lab15E2K13.lab15.com and the Global Catalog server's FQDN was LAB15DC.lab15.com, you would use these commands to perform the deregistration:
Setspn –D exchangeAB/Lab15E2K13 Lab15E2K13
Setspn –D exchangeAB/Lab15E2K13.lab15.com Lab15E2K13
You would then reregister the servers using these commands:
Setspn –A exchangeAB/Lab15DC Lab15DC
Setspn –A exchangeAB/Lab15DC.lab15.com Lab15DC
These techniques should correct most instances when the Outlook 2013 password prompt is constant. If you continue having trouble resolving the issue, make sure your external DNS entries are correct and your AutoDiscover service is properly configured.
About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as CIO for a nationwide chain of hospitals and health care facilities, and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.