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.
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:
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:
. . . and a stub zone in the contoso.com 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 autodiscover.contoso.com is added which resolves to autodiscover.worldwideimporters.com.
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 @contoso.com SMTP addresses the domain has to be added to Exchange (in worldwideimporters.com) 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"}
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$>
Setspn.exe -S http/autodiscover.worldwideimporters.com WWI\EXCH2016ASA$
Setspn.exe -S http/mail.worldwideimporters.com WWI\EXCH2016ASA$
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:
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.
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. Senior Premier Field Engineer
Microsoft
