When deploying or migrating Microsoft Exchange Server, one critical yet often overlooked component is the Alternate Service Account (ASA). The ASA is used by Exchange to support Kerberos authentication for services such as Outlook Anywhere and MAPI over HTTP, providing a secure and efficient alternative to NTLM. Without a properly configured ASA, Exchange falls back to NTLM. NTLM is an older protocol with known security weaknesses and performance limitations. Neglecting ASA planning during a migration or new deployment can result in authentication failures, inconsistent client logons, and increased exposure to legacy authentication risks. This post will examine the purpose of the Alternate Service Account, its role in Exchange authentication, and why it must be carefully planned and validated as part of any Exchange implementation or upgrade project.
Note that ASA has been a thing for a long time. This goes back to when support was added in Exchange 2010 SP1, and the legendary Ross Smith IV released this post
Recommendation: Enabling Kerberos Authentication for MAPI Clients. When Exchange Server 2010 was released there was an architectural change with the Client Access Server (CAS) role. In Exchange 2007, client connections (like Outlook, ActiveSync, OWA) were ultimately handled directly by the mailbox server or a single front-end role. But in Exchange 2010, Microsoft added the CAS array, a group of CAS servers that could be load balanced to provide high availability and scalability for MAPI, Outlook Anywhere, and other protocols. This mean that the Outlook client would connect to the CAS array object and was unable to achieve Kerberos authentication as there was no shared secret by default.
And that's where the problem arose:
- Kerberos authentication depends on service principal names (SPNs) that are tied to a specific computer account in Active Directory
- In Exchange 2010, each CAS server had its own machine account (e.g., EXCAS01$, EXCAS02$), each with its own Kerberos identity
- When Outlook connected through a load balancer using a shared namespace (like mail.tailspintoys.ca), Kerberos couldn’t work properly because the client’s authentication ticket was valid for one SPN, but the connection might land on a different CAS
Outlook would fall back to NTLM authentication, which did not have SPN restrictions but was less secure and more resource intensive, and more prone to bottleneck issues. This was a particular issue as back then Windows Server 2003 DCs were still popular. In the early builds of Windows Server 2003 there were multiple issues:
- The original release version of Windows Server 2003 did not not include Netlogon performance counters to help identify and troubleshoot NTLM issues. You needed to install a hotfix
- Early 2003 builds would only have two channels to authenticate using NTLM. Under load caused by Exchange and SharePoint in large environments this caused issues
- If there was a slow trust relationship, that would hog one of those channels leaving only one other. That really exacerbated the issue
- In some cases Exchange was running just fine, until the customer introduced SharePoint and the SharePoint team failed to configure Kerberos. Then everything went sideways
- Support was added to monitor semaphore timeouts and also increase the MaxConcurrentApi on updated builds and versions of Windows Server
- The default value of MaxConcurrentApi was also increased over time, but ideally Kerberos should be used anyway
For the details on NTLM performance issues please see KB2688798.
To fix the problem, Microsoft introduced the Alternate Service Account (ASA) feature in Exchange Server 2010 SP1. The ASA allowed all CAS servers in an array to share one common service account credential (with the same SPNs), enabling Kerberos authentication to function consistently across load-balanced servers.
The above outlines why the ASA is critical. What happens if you forget about the ASA during a migration to a new version of Exchange or deploy a new CAS server and forget to configure the ASA for that newly built server?
In short, nothing good.
Outlook Authentication Popup
The authentication popup in Outlook is the typical indicator that something has gone wrong with authentication.
In the below screenshot, Outlook was started and it fails to connect to the Exchange server.
Note thought that OWA is fine.
OK, Outlook can not connect to Outlook Anywhere or MAPI/HTTP. Does Autodiscover work?
Let's initiate an Autodiscover test? Nope. Same issue.
Let's take a look at the overall configuration to understand what went wrong.
CAS Configuration
All of the CAS namespaces were checked. OWA, EAS, MAPI etc. All of the URLS were correct and set as per the design, for example:
Get-OutlookAnywhere | Select Server, *Host*, *auth*
Get-MapiVirtualDirectory | Select Server, *URL*, *auth*
Let's go look in the IIS logs to see what the connections looked like to Autodiscover.
IIS Logs
Looking at the front end IIS logs we can see the connections to Autodiscover. But there was an issue.
All of the connections failed with a 401 error code. None succeeded.
2022-02-05 20:57:34 10.0.0.30 POST /autodiscover/autodiscover.xml &CorrelationID=<empty>;&cafeReqId=7957e737-02c9-44e4-8ef8-efb92fbecba6; 443 - 10.0.0.23 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.14527;+Pro) - 401 1 2148074254 30
2022-02-05 20:57:34 10.0.0.30 POST /autodiscover/autodiscover.xml &CorrelationID=<empty>;&cafeReqId=b4fa2cea-0493-49e9-aa36-f69bc3c96ae2; 443 - 10.0.0.23 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.14527;+Pro) - 401 1 2148074254 11
Proceed to start head scratching. Maybe mild panic if this is in the middle of the work day.
Next up, what's in the EventLogs?
System EventLog
Oh - there are multiple errors in the system event log. The errors stated that a Kerberos client was unable to authenticate to this Exchange server. The client wanted to connect to Autodiscover, but there was a SPN issue.
For the search engines, this is the full text from the error message:
Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 2/5/2022 8:10:46 PM
Event ID: 4
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: Win-10-1.Tailspintoys.ca
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server exch-2019$. The target name used was HTTP/autodiscover.tailspintoys.ca. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (TAILSPINTOYS.CA) is different from the client domain (TAILSPINTOYS.CA), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
At this point there is mention of Kerberos, SPNs and accounts. That should be enough to remember that an ASA credential was configured and the new server was NOT correctly enabled for the ASA. Or we set the client auth method to Negotiate, which expects to see Kerberos, and again the corresponding ASA was not deployed.
Check ASA Deployment & Rollout
We can look at the state of ASA deployment for all of the CAS servers. Note that the newer version of the cmdlet is being used. Get-ClientAccessService Vs Get-ClientAccessServer.
Get-ClientAccessService -IncludeAlternateServiceAccountCredentialStatus | Format-List Name, AlternateServiceAccountConfiguration
Notice that the new server does not have any ASA information set.
Yup - That will break it…
Check SPNs Registered To The ASA
We must ensure that all of the expected CAS namespaces are present on the ASA. SetSPN.exe with the List option can do that easily.
setspn.exe -L E15ASA$
Deploying ASA to New Server
In this case there are only Exchange 2016 and 2019 servers present, and both can share the same SPN. We can use the existing ASA credential on the new server by simply telling it to copy from an existing server. This is documented in:
Configure Kerberos authentication for load-balanced Client Access services | Microsoft Docs
.\RollAlternateServiceAccountPassword.ps1 –ToSpecificServer newserver.contoso.com –CopyFrom originalserver.contoso.com
In this example:
.\RollAlternateServiceAccountPassword.ps1 –ToSpecificServer Exch-2019.tailspintoys.ca –CopyFrom Exch-2016.tailspintoys.ca
The command will take a few seconds to complete.
When it is done, you should see a success screen like below:
Previously we saw that there was no ASA configuration present on the new Exchange 2019 server.
Below we now see that Exchange 2019 has the same ASA credential as the existing Exchange 2016 server. This is highlighted by the yellow arrow.
Test for search engines:
Identity AlternateServiceAccountConfiguration
-------- ------------------------------------
Exch-2019 Latest: 2/5/2022 9:14:19 PM, Tailspintoys\E15ASA$
Previous: <Not set>
Verify ASA Deployment
Now that the ASA was deployed, time to test. First up, check that Outlook is able to connect to Outlook Anywhere or MAPI/HTTP. This will depend on your environment and it's configuration.
Then we should review the HTTP log file entries.
Verify that Kerberos is working correctly by using the HttpProxy log file
In a text editor, browse to the folder where the HttpProxy log is stored. By default, the log is stored in the following folder:
For MAPI over HTTP connections: %ExchangeInstallPath%\Logging\HttpProxy\Mapi
For Outlook Anywhere connections: %ExchangeInstallPath%\Logging\HttpProxy\RpcHttp
Cheers,
Rhoderick
