How to Enable Kerberos Authentication for Accessing Exchange in a Resource Forest
Published Jul 14 2016 06:00 AM 44.8K Views

Consider a hypothetical scenario where Contoso merges with World Wide Importers, and the two combine each others resources. World Wide Importers has Exchange 2016 deployed, so it’s decided that users from Contoso will link their accounts to mailboxes in as a resource forest. kerb1 Each company’s corporate identity will remain intact, so they will maintain the and namespaces. Following Microsoft best practices, Kerberos will be enabled for client authentication when forest users access Exchange in To set up Kerberos in this topology the resource forest’s namespace will be used as the realm for issuing tickets to users requesting access. So clients requesting tickets from this realm will need a few extra considerations to get this all working: kerb2

Preparing DNS

For the scenario to work each forest’s namespaces and domains need to be resolvable by mutual name lookups. That means each namespace will be added to the other forest’s DNS solution. When using Windows Server DNS this can (for example) be achieved with a stub zone called added to the DNS servers: kerb3 . . . and a stub zone in the forest: kerb4 Autodiscover name records, or an SCP, must be added to the authentication forest so that queries for mailbox information based on a user’s primary SMTP domain get directed to Exchange with the new namespace. In this example, a CNAME record for is added which resolves to kerb5

Preparing Active Directory

For a resource forest deployment we recommend a forest trust between the authentication and resource forests. At a minimum, it should be a one-way outgoing trust, where the Exchange forest trusts the authentication forest. kerb6 For information on deploying Exchange in a resource forest topology visit, Deploy Exchange 2013 in an Exchange resource forest topology.

Preparing Exchange

Since Contoso users will keep their SMTP addresses the domain has to be added to Exchange (in as an accepted domain: kerb7

Configuring and Enabling Kerberos

With DNS and Active Directory prepared it is now possible to configure Kerberos according to readily available guidance. First, an Alternative Service Account (ASA) must be added to Active Directory in the resource forest, using this format:

New-ADComputer -Name <CAName> -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName <CAName>
Set-ADComputer <CAName> -add @{"msDS-SupportedEncryptionTypes"="28"}

So for our scenario:

New-ADComputer -Name EXCH2016ASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCH2016ASA
Set-ADComputer EXCH2016ASA -add @{"msDS-SupportedEncryptionTypes"="28"}

kerb8 Next, the new ASA must be configured on each Mailbox server in the organization with RollAlternativeServiceAccountPassword.ps1:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer <ExchangeServer> -GenerateNewPasswordFor <Domain\CAName$>

For this scenario:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer wwiex1 -GenerateNewPasswordFor WWI\EXCH2016ASA$

kerb9 After that we can register the SPNs for Exchange services:

Setspn.exe -S http/<AutodiscoverServiceHostname> <Domain\CAName$>
Setspn.exe -S http/<ExchangeServicesHostname> <Domain\CAName$>

For the scenario:

Setspn.exe -S http/ WWI\EXCH2016ASA$
Setspn.exe -S http/ WWI\EXCH2016ASA$



Outlook Anywhere RPC/HTTPS: verify Kerberos is in use by following the section in the Technet article referenced above called “Validate Kerberos from the Client Access server”. As described the HttpProxy\RpcHttp logging will show a user’s connection with the “Negotiate” authentication protocol only. This ensures Kerberos is working for that user: kerb11 If for some reason the client is not able to authenticate with Kerberos it should fall back to NTLM authentication. In that case, the log will show either “NTLM” or “Negotiate+NTLM”. MAPI/HTTPS: The HttpProxy log for MAPI always shows “Negotiate” if it’s configured as an available authentication method, so the method to verify Kerberos authentication described for Outlook Anywhere won’t be reliable. Instead, running KLIST.EXE can reveal whether the logged in user has received a ticket for the Exchange SPN. kerb12


Complex organizations with diverse Active Directory deployments may need to consolidate services under a simplified namespace. This necessitates additional steps for enabling Kerberos for authenticating user forest clients to access Exchange in a resource forest. With the concepts and examples presented here it should be straightforward to adapt them to a production deployment for a fully-supported, best-practice-compliant Exchange solution. Jesse Tedoff Senior Premier Field Engineer
Version history
Last update:
‎Jul 01 2019 04:27 PM
Updated by: