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.domain.com for MAPI Over Http & Outlook Anywhere (OA).
- Autodiscover.domain.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 with admin privilege (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 “OU=ExchangeServers,DC=domain,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″}
run the command bellow to replicate the changes to all domain controllers
repadmin /syncall /ADPe
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 (SRV-Ex2019N1 in our example) and the name of the domain\ASA computer account as we have created earlier:
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer SRV-ex2019n1.domain.local -GenerateNewPasswordFor domain\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
make sure the script run successfully
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.
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer SRV-ex2019n2.domain.local -CopyFrom SRV-ex2019n1.domain.local
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:
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 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.domain.com & autodiscover.domain.com)
Setspn -F -Q http/mail.domain.com
You should get an output:
No Such SPN Found
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.domain.com domain\EXCHASA$
Setspn -S http/autodiscover.domain.com domain\EXCHASA$
Setspn -S http/mail.domain2.com domain\EXCHASA$
Setspn -S http/autodiscover.domain2.com domain\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).
- In order to run it on all Exchange servers at once, run the next command:
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate
Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalClientAuthenticationMethod Ntlm
Set-OutlookAnywhere -Identity “ZPVWMSG05\Rpc (Default Web Site)” -IISAuthenticationMethods NTLM,Negotiate
To set the MAPI Over HTTPS support for Kerberos authentication, run the following command for every Exchange server:
- 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 SRV-ex2019n1
$mapidir | Set-MapiVirtualDirectory -IISAuthenticationMethods ($mapidir.IISAuthenticationMethods +=’Negotiate’)
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:
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
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 SRV-ex2019n1 -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.domain.com domain\EXCHASA$
Setspn -D http/autodiscover.domain.com domain\EXCHASA$
In order to verify that the actions completed successfully, run the following command for every SPN you are using (in our example mail.domain.com & autodiscover.domain.com)
Setspn -F -Q http/mail.domain.com
You should get an output similar to the output in the above screenshot:
No Such SPN Found
- Although you don’t have to do this immediately, you should restart all client computers to clear the Kerberos ticket cache from the computer.