Outlook keeps prompting for a password with Exchange Server: the usual causes and fixes

Outlook asking for a password again and again, even when the password is right, is one of the most common Exchange tickets. The prompt is only Outlook's fallback when silent Windows authentication to one of Exchange's endpoints fails, so the fix depends on which endpoint fails and why. In this post I'll show how to narrow it down and fix the usual causes on Exchange Server SE and 2019.

Symptoms#

• Outlook repeatedly prompts for credentials: the Windows Security prompt keeps coming back, typing the correct password doesn't stop it, and the status bar keeps asking for a password.
• It appears at a particular moment: at startup (Autodiscover or MAPI), when opening a shared calendar, Automatic Replies or the Scheduling Assistant (EWS), or during the address book download (OAB).
• Only some users, some PCs or only outside the office are affected, often since a change: a new server, load balancer or certificate, Extended Protection, or the move from RPC over HTTP to MAPI over HTTP.
• The Exchange IIS logs show runs of HTTP 401 on /mapi/emsmdb, /EWS/Exchange.asmx or /Autodiscover with no 200 after them, and the client's System log may have Event ID 4 (Security-Kerberos):

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server <server>.
The target name used was HTTP/mail.contoso.com. This indicates that the target server failed to decrypt
the ticket provided by the client.

Why it happens#

Outlook talks to several endpoints that authenticate separately: Autodiscover, MAPI over HTTP (/mapi/emsmdb and /mapi/nspi), EWS and the OAB. Normally Windows signs in silently with Kerberos or NTLM through Negotiate, or with an OAuth token when modern auth is in use. When that fails for any endpoint, Outlook asks the user, and asking again doesn't help because the password was never the problem. The usual reasons are stale cached credentials, Autodiscover sending Outlook to the wrong place, inconsistent virtual directory authentication, Kerberos failing behind a load balancer, Extended Protection rejecting authentication, and half-configured modern auth.

How to fix it#

1. Narrow it down#

On an affected PC, Ctrl + right-click the Outlook icon in the notification area. Connection Status lists every connection with its server and an Authn column (Nego* for Kerberos or NTLM, Bearer* for OAuth). Test E-mail AutoConfiguration, with the two Guessmart boxes cleared, shows on its Log tab every Autodiscover URL Outlook tried. A prompt that follows a URL you don't own points to step 3; a prompt tied to one feature points to that virtual directory in step 4.

2. Clear cached credentials and rule out the account#

• In Control Panel › User Accounts › Credential Manager › Windows Credentials, remove entries that start with MicrosoftOffice16_Data:SSPI and any saved for your Exchange host names, then restart Outlook. Microsoft documents this fix for prompts after a move to MAPI over HTTP.
• Under File › Account Settings › Account Settings, select the account, then Change › More Settings › Security, and clear Always prompt for logon credentials.
• If Group Policy sets Outlook's Authentication with Exchange Server, MAPI over HTTP needs Kerberos/NTLM Password Authentication.
• Check for an expired password, "must change password at next logon", or lockouts from an old phone; Event ID 4740 in a domain controller's Security log names the caller computer.

3. Fix Autodiscover#

Get-ClientAccessService | Format-Table Name, AutoDiscoverServiceInternalUri -AutoSize

Each service connection point should use a name that resolves to your current servers, such as https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml, and long-gone servers shouldn't still have one. Externally, autodiscover.contoso.com must reach Exchange. If your public website answers https://contoso.com/autodiscover/autodiscover.xml with an authentication challenge, set the DWORD ExcludeHttpsRootDomain = 1 under HKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover. If your domain also exists in a Microsoft 365 tenant, Outlook may try Microsoft 365 first; ExcludeExplicitO365Endpoint = 1 stops that for on-premises mailboxes.

4. Make virtual directory authentication consistent#

Get-MapiVirtualDirectory | Format-List Server, *auth*
Get-WebServicesVirtualDirectory | Format-List Server, *auth*
Get-OabVirtualDirectory | Format-List Server, *auth*
Get-AutodiscoverVirtualDirectory | Format-List Server, *auth*
Get-OutlookAnywhere | Format-List Server, *auth*, SSLOffloading

Every server behind the same namespace should return the same values, with Windows authentication present. The MAPI default is {Ntlm, OAuth, Negotiate}: Kerberos needs Negotiate, and leave OAuth in place because modern auth and hybrid rely on it. Fix any outlier, for example:

Get-MapiVirtualDirectory -Server EX02 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,OAuth,Negotiate

5. Check Kerberos and the alternate service account#

With Kerberos on a load-balanced namespace, each SPN must exist exactly once, on the alternate service account (ASA), and every server behind the namespace needs the same ASA credential. A server added later without it can't decrypt tickets, so clients the load balancer sends there get KRB_AP_ERR_MODIFIED and a prompt.

setspn -F -Q http/mail.contoso.com
Get-ClientAccessService -IncludeAlternateServiceAccountCredentialStatus | Format-List Name, AlternateServiceAccountConfiguration
# From %ExchangeInstallPath%Scripts, copy the credential to a server that's missing it
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer ex03.contoso.com -CopyFrom ex01.contoso.com

The Microsoft Exchange Service Host service manages the ASA, so it must be running. Microsoft recommends A records rather than CNAMEs for the shared names. Run klist purge on affected clients after a fix.

6. Look at Extended Protection#

Extended Protection binds Windows authentication to the TLS session. If a load balancer offloads SSL or re-encrypts with a different certificate, or a proxy inspects TLS, authentication fails and Outlook prompts; clients still negotiating NTLMv1 can fail too. Keep the same certificate end to end, exclude Exchange from TLS inspection and keep SSLOffloading at False. Details are in Extended Protection on Exchange Server.

7. Check modern auth end to end#

With Hybrid Modern Authentication or AD FS modern auth, a working client shows Bearer*. If enabled users keep getting prompts, check the client build and settings first, then Get-OrganizationConfig | Format-List OAuth2ClientProfileEnabled, DefaultAuthenticationPolicy, the user's authentication policy and the Auth certificate's expiry. See Hybrid Modern Authentication and AD FS modern authentication without hybrid.

Verify the fix#

• After restarting Outlook, Connection Status shows every connection as Established with Nego* (or Bearer*), and no prompt appears through a working day that includes a shared calendar, Automatic Replies and an OAB download.
• In the IIS logs, each new connection shows a 401 followed by a 200, which is the normal challenge, rather than a run of 401s.
• The HttpProxy log in %ExchangeInstallPath%Logging\HttpProxy\Mapi shows the expected AuthenticationType, such as Negotiate when Kerberos works.
• No new KRB_AP_ERR_MODIFIED events on clients.

Key takeaways#

• Find the endpoint that prompts before changing anything; recreating the profile only hides the cause.
• Keep authentication settings identical on every server behind a namespace, and deploy the ASA before a new server joins the load balancer.
• Don't terminate or inspect TLS in front of Exchange when Extended Protection is on.

References#

• Outlook repeatedly prompts for credentials when using MAPI over HTTP (Microsoft Learn)
• Configure Kerberos authentication for load-balanced Client Access services (Microsoft Learn)
• Kerberos Service Principal Name on wrong account (Microsoft Learn)