Configuring ASA (Alternate Service Account) for Kerberos authentication on all of the CAS servers
We will setup ASA (Alternate Service Account) for Kerberos authentication on all CAS servers in kkishoreblog.com resource forest. By default, clients that attempt to negotiate authentication will fail Kerberos authentication when a CAS array is configured thus falling back to NTLM. This will cause a lot of unnecessary NTLM authentication traffic. By Default, the Kerberos should be used by domain joined clients for authentication but the reason Kerberos authentication fails is because the authentication request is sent using the FQDN (mail.kkishoreblog.com) of the CAS array which does not match the SPN (Service Principal Names) value on the CAS. To address this issue we must create an appropriate SPN value for the CAS array within Active Directory. We also cannot configure the same SPN value on multiple objects in Active Directory. To work around this we created a method called ASA. The ASA can be either a computer account or user account. Then we can associate the SPNs we want for the CAS array to the ASA.
NTLM Authentication Concerns
Why is using NTLM authentication for Outlook and other MAPI clients a concern? Let’s take a look at the authentication process:
- The user launches Outlook.
- The user’s computer sends traffic to the server (load-balanced namespace) specified in the Outlook profile. This traffic includes the user’s integrated authentication information (in other words, NTLM authentication).
- The load balancer directs the traffic to a specific CAS member within the load-balanced array.
- The CAS member needs to verify the user’s credentials. It does this by sending traffic to a specific domain controller, the one which it has an associated secure channel binding, requesting a verification of the user’s credentials.
- The domain controller responds to the CAS member with the information on the user’s credentials.
- The CAS member generates an access token and services the request.
The problem here is that each connection from the client must follow this same process. Therefore, as the number of connections increase, there is potential for a bottleneck in terms of handling the NTLM authentication. The bottleneck is a result of the following two issues:
- The CAS member only uses a single domain controller for all authentication requests. In addition, there is no load distribution mechanism across the CAS members in the load balanced array to ensure that each CAS is using a different domain controller for its secure channel binding.
- Windows limits the number of concurrent secure channel calls. There are a specific number of threads that can handle NTLM authentication (controlled by MaxConcurrentAPI value, with default equaling 2).
Each MaxConcurrentAPI thread can only deal with one authentication request at a time. However, attributes like network latency, the number of hops the authentication requests have to go through, and the volume of requests can introduce a bottleneck in the authentication process, resulting in some of these transactions waiting longer than a remote client can tolerate. If you have a heavy load, you are more than likely going to hit that limit when these clients authenticate via NTLM.
Windows Server does have a means to increase the number of concurrent secure channel calls up to 150 when you deploy KB 975363. However, increasing the number of concurrent secure channel calls up as far as 150 is also not recommended, as it can have adverse effects on domain controller performance.
The solution here is to leverage an alternate service account (ASA) credential mechanism to enable Kerberos authentication.
Kerberos authentication is efficient and faster
With NTLM authentication, an application server must connect to a domain controller in order to authenticate each client. With the Kerberos V5 authentication protocol, on the other hand, the server is not required to go to a domain controller. Instead, the server can authenticate the client by examining credentials presented by the client. Clients can obtain credentials for a particular server once and then reuse those credentials throughout a network logon session. Renewable session tickets replace pass-through authentication.
When a resource server gets Kerberos authentication information (in Kerberos speak “tickets” and “authenticators”) from a client, the resource server has enough information to authenticate the client. The NTLM authentication protocol requires resource servers that aren’t domain controllers (DCs), to contact a DC to validate a user’s authentication request. This process is known as pass-through authentication.
Leveraging an alternate service account (ASA) Credential Type
We can create a computer account or a user account for the alternate service account. Because a computer account doesn’t allow interactive logon, it may have simpler security policies than a user account and therefore is the preferred solution for the ASA credential. If you create a computer account, the password doesn’t actually expire, but we still recommend updating the password periodically. Local group policy can specify a maximum account age for computer accounts and there might be scripts scheduled to periodically delete computer accounts that do not meet current policies. Periodically updating the password for computer accounts will ensure that your computer accounts aren’t deleted for not meeting local policy. Your local security policy will determine when the password needs to be changed.
Credential Name
There are no particular requirements for the name of the ASA credential. You can use any name that conforms to your naming scheme.
Groups and Roles
The ASA credential doesn’t need special security privileges. If you are deploying a computer account for the ASA credential this means that the account only needs to be a member of the Domain Computers security group. If you are deploying a user account for the ASA credential, this means that the account only needs to be a member of the Domain Users security group.
Password
The password you provide when you create the account will never actually be used. Instead, the script will reset the password. So when you create the account, you can use any password that conforms to your organization’s password requirements.
All computers within the Client Access server array must share the same service account. In addition, any Client Access servers that may be called on in a datacenter activation scenario must also share the same service account.
We will create a single ASA and will share the same with all CAS array (mail.kkishoreblog.com)
Creating the alternate service account (ASA)
Open Active Directory Users and Computers and create a computer account.
Setting the ASA to the CAS servers
Verify that CASARRAY-ASA computer account is replication to all Domain Controllers in all active directory sites.
To set ASA to the CAS servers we have to run AlternateServiceAccount credential script in the Exchange Management Shell “RollAlternateserviceAccountPassword.ps1 “
Syntax
.\RollAlternateserviceAccountPassword.ps1 –ToArrayMembers {CAS array name}-GenerateNewPasswordFor {Domain}\{ASA}” –Verbose
.\RollAlternateserviceAccountPassword.ps1 -ToEntireForest -GenerateNewPasswordFor “kkishoreblog\CASARRAY-ASA$” -Verbose
The script will ask if we want to change the password on the ASA. In this case we will say Yes.
With the -verbose flag it should indicate what script operations were successful. To confirm that the Client Access servers were updated, you can verify the last modified time stamp on the ASA credential.
Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialstatus |Fl Name, AlternateServiceAccountConfiguration
Once the credential is set we need to set the correct SPNs to the ASA
Setting the correct SPNs to the ASA
Identifying the Service Principal Names That Should Be Associated with the Alternate Service Account Credential
After creating the alternate service account, we must determine the Exchange service principal names (SPNs) that will be associated with the ASA credentials. Below is the list of Exchange SPNs –
- http Use this SPN for Exchange Web Services, Offline Address Book downloads, and the Autodiscover service.
- exchangeMDB Use this SPN for RPC Client Access.
- exchangeRFR Use this SPN for the Address Book service.
- exchangeAB Use this SPN for the Address Book service.
The SPN values must be configured to match the service name being used on the network load balancer, rather than on individual servers.
Client Access server member in array are configured with following internal and external URL setting
CAS Array FQDN mail.kkishoreblog.com
- Exchange Web Services –
https://mail.kkishore.com/ews/exchange.asmx
- Offline Address Book –
https:// mail.kkishore.com /oab
- Autodiscover Services –
https://mail.kkishore.com /autodiscover/autodiscover.xml
Based on the fully qualified domain names that are used by the Outlook clients the following SPNs would need to be deployed on the ASA credential:
- http/ mail.kkishore.com
- exchangeMDB/ mail.kkishore.com
- exchangeRFR/ mail.kkishore.com
- exchangeAB/ mail.kkishore.com
Associating Service Principal Names with the Alternate Service Account Credential
Some MAPI applications that interact with Exchange may need to use the Array’s short name or NetBIOS. We will set NetBIOS and FQDN for each SPN.
Open CMD and run the below commands
setspn -s exchangeMDB/mail CASARRAY-ASA$
setspn -s exchangeMDB/ mail.kkishore.com CASARRAY-ASA$
setspn -s exchangeRFR/ mail.kkishore.com CASARRAY-ASA$
setspn -s exchangeAB/ mail.kkishore.com CASARRAY-ASA$
setspn -s http/ mail.kkishore.com CASARRAY-ASA$
When you’ve set the SPNs, verify that they’ve been added by using the following command.
Setspn -L kkishoreblog\CASARRAY-ASA$
Convert the Offline Address Book Virtual Directory to an Application
The Offline Address Book virtual directory isn’t a Web application, so it isn’t controlled by the Microsoft Exchange Service Host service. Therefore, Kerberos authentication requests to the Offline Address Book virtual directory can’t be decrypted by the ASA credential.
To convert the Offline Address Book virtual directory to a Web application, run the ConvertOABDir.ps1 script on each Client Access server member. The script will also create a new application pool for the Offline Address Book virtual directory
Open the power shell and locate the script in scripts folder.
D:\Program Files\Exchsrvr\scripts>.\ConvertOABVDir.ps1
Once the script completes restart the MSExchangeOAB & MSExchangeRPC on all the CAS servers in the configured array:
Get-Service MSExchangeAB,MSExchangeRPC | Restart-Service
After this user joined to these domain should be able authenticate with Kerberos protocol.
Roll back Plan
To revert the Client Access server array so that it doesn’t use Kerberos, remove the SPNs from the shared service account.
setspn -d exchangeMDB/mail CASARRAY-ASA$
setspn -d exchangeMDB/ mail.kkishore.com CASARRAY-ASA$
setspn -d exchangeRFR/ mail.kkishore.com CASARRAY-ASA$
setspn -d exchangeAB/ mail.kkishore.com CASARRAY-ASA$
setspn -d http/ mail.kkishore.com CASARRAY-ASA$
If the SPNs are removed, Kerberos authentication won’t be attempted by your clients, and clients configured to use Negotiate authentication will use NTLM. Clients configured to use only Kerberos will be unable to connect. Once the SPNs are removed you should also delete the shared service account.
You can use the maintenance script to clean out credentials from all Client Access server array members by using the toEntireForest parameter and using the -copy from server parameter to specify a server that does not have any Kerberos credentials. In addition, you should eventually restart all client computers to clear the Kerberos ticket cache.