Exchange Server

In this blog, I will review the configuration needed in order to activate Kerberos authentication with Exchange 2019 servers.

General

Kerberos authentication for Exchange’s is not configured by default when using a commonly shared namespace for more than one Exchange server.
The reason is that the shared namespace URL, for example, mail.contoso.com is not “attached” to a valid computer account.
The shared namespace is usually just an A record in DNS that represents one of the two:

Load balancing entity (Software / Hardware).
Many Exchange servers that represented by a shared namespace, for example, 2 DNS records named mail.contoso.com, each one of them is configured with a different IP address (one of every Exchange server).

For Kerberos authentication implementation, we must use an Alternate Service Account (ASA) for the shared namespace URL we are publishing for all Exchange services.
In our example we are going to use the following:

mail.contoso.com for MAPI Over Http & Outlook Anywhere (OA).
Autodiscover.contoso.com for Autodiscover services.

There are 2 main reasons for using Kerberos authentication:

Better Security: When using Kerberos authentication, the user who logged into the domain, gets a Ticket Granting Ticket / TGT and use it for up to 10 hours in order to access the domain’s resources.
This mechanism considered as a highly secured login option.
Reduce loads on Exchange servers: In large scale deployments,
You might encounter NTLM scalability issues, such as direct MAPI connectivity causing intermittent NTLM failures and authentication failures (Password POPUPs when using Outlook).
Kerberos authentication, reduces the loads on Exchange and Domain Controllers by eliminating the need for reauthenticate every time the client opens Outlook since he already has a TGT for authentication.

Alternate Service Account creation in AD:

ASA is a computer account or a user account object in the same Active Directory forest where Exchange servers are installed.
According to Microsoft’s recommendation you should create a computer account instead of a user account, since a computer account doesn’t allow interactive logon and may have simpler security policies than a user account. when creating a computer account, the account’s password doesn’t expire, but the recommendation is to update the password from time to time.
The computer account name is not limited to a specific name, but must be within the maximum of 15 characters.

In order to create the ASA computer account, run the following command from PowerShell (don’t forget to load the Active Directory module first):

New-ADComputer -Name EXCHASA -AccountPassword (Read-Host ‘Enter password’ -AsSecureString) -Description ‘ASA for Exchange — DO NOT DELETE’ -Enabled:$True -SamAccountName EXCHASA -Path “CN=Computers,DC=Contoso,DC=com”

Get-ADComputer EXCHASA

After the computer account (ASA) was created, we need to enable AES 256 encryption in order to support Kerberos:

Set-ADComputer EXCHASA -add @{“msDS-SupportedEncryptionTypes”=”28″}

In case that you are working in multiple AD sites, run the following command from one of your domain controllers, in order to verify that the newly created ASA account was replicated to all AD domain controllers:

repadmin /syncall /ADPe

ASA and Service Principle Name (SPN)

Now, we need to associate Exchange Service Principal Names (SPNs) with the ASA that we have just created.
The SPNs list is actually the list of URLs that are being used for the different Exchange services:

mail.contoso.com for Outlook Anywhere, MAPI over HTTP, Exchange Web Services, and Offline Address Book.
Autodiscover.contoso.com for Autodiscover services.

The SPN values must match the service name on the network load balancer (or DNS names as in our example), instead of on individual servers.

Please consider that the example in our blog is based on a scenario where all the Exchange servers are located in one AD site with 2 namespaces: mail.contoso.com & Autodiscover.contoso.com
In case you are having multiple AD sites and you are using multiple namespaces for Exchange’s services, you will have to add the rest of name spaces you are using to the ASA.
For example, in case that you are using NY-Mail.contoso.com & NY-Autodiscover.contoso.com, you should add those names spaces as well while running the SETSPN -S command (as describes later on) in addition to the mail.contoso.com & Autodiscover.contoso.com name spaces.

Configure ASA credential on all Mailbox servers

The core pillar that allows Exchange to work with Kerberos authentication since Exchange 2010 SP1, is the Microsoft Exchange Service Host service that runs on every mailbox server.
The only supported way to configure ASA credentials for Kerberos authentication with Exchange servers is running the RollAlternateServiceAcountPassword.ps1 script on every mailbox server.
The script updates the ASA credentials and distributes it to the relevant mailbox server, which contains the Client Access Service.

Running the script on the First Mailbox Server:

To run the script on the first Mailbox server, open Exchange Management Shell (EMS).
In case that you are running on Windows 2019 Core Server, type LaunchEMS from CMD.
Now navigate to the Exchange’s scripts directory by running the next command from EMS:

cd $exscripts

Now run the script with the name of the first Mailbox server (Con-Ex2019N1 in our example) and the name of the domain\ASA computer account as we have created earlier:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer con-ex2019n1.contoso.com -GenerateNewPasswordFor Contoso\EXCHASA$

In case that asked to “Continue an and make changes”- press Y
In case that asked to “Change password for ASA in AD”- press Y

You can ignore the error in RED in case you get a similar output.
Just verify that get a GREEN output saying the message: “The Script Has Succeeded”.
Running the script on ALL other Mailbox Server:

It is very important to understand that the first command that we ran for the First Mailbox server, is different than the command we will going to run for all other Mailbox servers in the organization.
The thing is that running the command on the first Mailbox server will create and change the password for the ASA computer account.
All other servers will go to use the password that already was set using the script, copy the configuration from the first Mailbox server and therefore, the commands will be different.

To run the script on the second and other Mailbox servers rather than the first one, open Exchange Management Shell (EMS) and navigate to the scripts directory as you did at the first server. It must be from Exchange 2019 Mailbox server only, but it could be the first, second or any other Exchange 2019 server, it doesn’t matter.

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer con-ex2019n2.contoso.com -CopyFrom con-ex2019n1.contoso.com

Verify that you get a GREEN output saying the message: “The Script Has Succeeded”.

In case you have more Mailbox servers that need to be configured with Kerberos Authentication (for example Con-Ex2019N3), just run the last command with the name of the other Exchange 2019 server:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer con-ex2019n3.contoso.com -CopyFrom con-ex2019n1.contoso.com

In case you have completed running the scripts on all your Exchange 2019 servers, you can continue to the next step.

Verify all servers are configured with ASA credentials:

In order to verify that a specific server is configured correctly with ASA credentials, run the next command and check that AlternateServiceAccountConfiguration is updated with the ASA computer account:

Get-ClientAccessService con-ex2019-n1 -IncludeAlternateServiceAccountCredentialStatus | fl Name, AlternateServiceAccountConfiguration

In case you would like to verify ASA configuration on all servers at once, run the following command:

Get-ClientAccessService -IncludeAlternateServiceAccountCredentialStatus | fl Name, AlternateServiceAccountConfiguration

Associating SPNs with the ASA computer account

Important!
Before associating SPNs with the ASA computer account, verify that all Mailbox servers were updated with the ASA credentials, which means that the RollAlternateServiceAcountPassword.ps1 script ran against all server.
In case only part of the servers was configured with Kerberos authentication, you will experience continuing password POPUPs while trying to access your mailbox or by accessing the Autodiscover service.
In addition, verify that the SPNs that you are using for Exchange services, are not associate with other ASA computer account.
In order to do so, run the following command for every SPN you are using (in our example mail.contoso.com & autodiscover.contoso.com)

Setspn -F -Q http/mail.contoso.com

You should get an output similar to the output in the above screenshot:
No Such SPN Found

Associate SPNs with ASA credentials:

One of the last steps before completing the Kerberos configuration is running the commands for SPNs association used by the Exchange services with the ASA computer account:

Setspn -S http/mail.contoso.com contoso\EXCHASA$

Setspn -S http/autodiscover.contoso.com contoso\EXCHASA$

In case you are using more SPNs, for multiple AD sites (paragraph ASA and Service Principle Name (SPN)), just run the additional names of the SPNs.
Verify the SPNs Association with the ASA credentials:

In order to verify that the SPNs were associate accordingly with the ASA, run the next command:

Setspn -L contoso\EXCHASA$

Enable Kerberos authentication for Outlook clients

The last step for Kerberos authentication enablement is the authentication methods for Outlook connectivity by MAPI Over HTTPS & Outlook Anywhere (RPC Over HTTPS / OA).

To set the Outlook Anywhere support for Kerberos authentication, run the following command for every Exchange server:

Get-OutlookAnywhere -Server Con-ex2019n1 | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate

In order to run it on all Exchange servers at once, run the next command:

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate

To set the MAPI Over HTTPS support for Kerberos authentication, run the following command for every Exchange server:

Get-MapiVirtualDirectory -Server Con-ex2019n1 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate

In order to run it on all Exchange servers at once, run the next command:

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate

In hybrid environments with Exchange Online or if you use OAuth internally, run the following commands on your Exchange 2019 Mailbox servers:

$mapidir = Get-MapiVirtualDirectory -Server Con-ex2019n1
$mapidir | Set-MapiVirtualDirectory -IISAuthenticationMethods ($mapidir.IISAuthenticationMethods +=’Negotiate’)

Testing clients with Kerberos authentication

After we configured the list of tasks above and every step completed successfully, we can apparently start testing the client’s connectivity with Kerberos authentication.
Basically, it is possible, but we have to remember that the authentication settings for Outlook Anywhere and MAPI Over HTTPS were changed. These settings MUST be updated to Outlook clients as soon as possible.
In addition, the most important service which responsible for Kerberos authentication at the Exchange servers is the MSExchangeServiceHost service, which is started by default.
If this service is stopped, Kerberos authentication will not work.

In order to speed up the time Outlook will be updated with the new authentication settings, we need to run 2 tasks against all Mailbox servers that are responsible to publish Autodiscover configuration:

Restart (Recycle) the MSExchangeAutodiscoverAppPool application pool.
Restart the MSExchangeServiceHost service and verify it is running.

To restart the MSExchangeAutodiscoverAppPool application pool on all Mailbox servers (which are running the Client Access service), use the following commands from Exchange Management Shell (EMS) on one of the Exchange servers:

$cas=Get-ClientAccessService

$cas.name | % {Invoke-Command -ComputerName $_ -ScriptBlock {Restart-WebAppPool -Name MSExchangeAutodiscoverAppPool}}

To restart the MSExchangeServiceHost service on all Mailbox servers, run the following commands:

$cas=Get-ClientAccessService

$cas.name | % {Invoke-Command -ComputerName $_ -ScriptBlock {Restart-Service MSExchangeServiceHost -Force}}

To verify that the MSExchangeServiceHost service is at Running state on all Mailbox servers, run the next command:

$cas.name | % {Get-Service MSExchangeServiceHost}

Verify Outlook connectivity using Kerberos:

There are a few ways to verify that Outlook is connected using Kerberos authentication.
As a first step, we can use the Klist, which Displays a list of currently cached Kerberos tickets.
From CMD or PowerShell, run the Klist command:

We can see that there are 2 tickets (in our example), one for each SPN that was associated with the ASA computer account:

http/mail.contoso.com
http/autodiscover.contoso.com

This is only part of the testing and not necessarily can verify that Outlook will be able to connect.
We need to verify that Outlook was really connected using Negotiate authentication (Kerberos).

To so do, we should examine the HttpProxy logs on every Mailbox server and search for Negotiate.
The HttpProxy logs are located at the Exchange’s installation path, by default it would be located at:
C:\Program files\Microsoft\Exchange Server\V15\Logging\HttpProxy

In the next example, we will examine the Mapi protocol logging directory:

Searching the log for Negotiate, will show that Administrator was logged to his mailbox using Negotiate authentication:

In the next example, we will examine the Autodiscover logging directory:

In the next example, we will examine the OAB (Offline Address Book) logging directory:

Rollback / Turn off Kerberos authentication

In case that from some reason Kerberos authentication needs to be turned off, There are simple steps that need to be done:

Remove the ASA credentials from the Mailbox servers.
Remove the SPNs used by Exchange, from the ASA computer account.

Remove the ASA credentials from the Mailbox servers by running the following command:

Set-ClientAccessService con-ex2019-n1 -RemoveAlternateServiceAccountCredentials

In order to remove the ASA credentials from all Mailbox servers, run the next command:

Get-ClientAccessService | Set-ClientAccessService -RemoveAlternateServiceAccountCredentials

Remove the SPNs used by Exchange from the ASA computer account can be done by running the following commands, for every SPN that was registered with the ASA:

Setspn -D http/mail.contoso.com contoso\EXCHASA$

Setspn -D http/autodiscover.contoso.com contoso\EXCHASA$

In order to verify that the actions completed successfully, run the following command for every SPN you are using (in our example mail.contoso.com & autodiscover.contoso.com)