Configuring ASA (Alternate Service Account) for Kerberos authentication
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 –
·
Offline Address Book –
·
Autodiscover Services –
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
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.
