How to Enable Kerberos Authentication for Accessing Exchange in a Resource Forest

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.


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:


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:


. . . and a stub zone in the forest:


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


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.


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:


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"}


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$


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:


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.



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

Comments (6)
  1. Julien gm says:

    Good article. But do you think it’s viable solution in the real life ? Where ntlm use pass through from exchange server, kerberos requires that each client should be able to reach dc from exchange forest, in your scénario of merge it could be a real pb.

    1. Jesse Tedoff says:

      Thanks for your comment. It’s absolutely viable, and has advantages over NTLM in performance and security. If DCs between forests have enough open to use NTLM it shouldn’t take too much more to allow client connectivity to each DC within the organization’s private network. Indeed, the inspiration for this post is a real-world deployment for one of my customers who sought our guidance on implementing this very architecture. They are a huge organization with strict security requirements, and this is the model they chose.

  2. Tyler H. says:

    Why not using DNS “conditional forwarders” instead of a stub zone?

    1. Jesse Tedoff says:

      Quite right, why not? I use stub zones out of habit, but conditional forwarders are perfectly good. The requirement is that, “You have correctly configured Domain Name System (DNS) for name resolution across forests in your organization.” So, again, the stub zone model here is one example among many.

      1. Jesse Tedoff says:

        Quoted passage is from:
        Deploy Exchange 2013 in an Exchange resource forest topology

  3. Benoit Boudeville says:

    Juste a quick note on the main guidance, which tells:
    Get-MapiVirtualDirectory -Server CAS-1 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm, Negotiate

    The default IISAuthenticationMethods with Exchange 2016 is Ntlm, OAuth, Negotiate.
    Yet, most people don’t need to leave OAuth enabled but this may break some usages where OAuth might become required at some point.

Comments are closed.

Skip to main content