How to Enable Kerberos Authentication for Accessing Exchange in a Resource Forest
Published Jul 14 2016 06:00 AM 43.6K 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 worldwideimporters.com as a resource forest. kerb1 Each company’s corporate identity will remain intact, so they will maintain the contoso.com and worldwideimporters.com namespaces. Following Microsoft best practices, Kerberos will be enabled for client authentication when contoso.com forest users access Exchange in worldwideimporters.com. 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 contoso.com added to the worldwideimporters.com DNS servers: kerb3 . . . and a stub zone in the contoso.com 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 autodiscover.contoso.com is added which resolves to autodiscover.worldwideimporters.com. 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 @contoso.com SMTP addresses the domain has to be added to Exchange (in worldwideimporters.com) 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/autodiscover.worldwideimporters.com WWI\EXCH2016ASA$
Setspn.exe -S http/mail.worldwideimporters.com WWI\EXCH2016ASA$

kerb10

Verification

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

Conclusion

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
7 Comments
Not applicable
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.
Not applicable
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.
Not applicable
Why not using DNS "conditional forwarders" instead of a stub zone?
Not applicable
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.
Not applicable
Quoted passage is from:

Deploy Exchange 2013 in an Exchange resource forest topology

https://technet.microsoft.com/en-us/library/aa998031(v=exchg.150).aspx

Not applicable
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.

Microsoft

I do have Exchange 2016 in the resource forest, i followed the instruction available here, i need help as on the client machine in the account forest i do not get the Exchange ticket using KLIST, yet all other verifications are successful...i rebooted the client machine couple of times,,, any hint?

Version history
Last update:
‎Jul 01 2019 04:27 PM
Updated by: