Exchange

Exchange 2013 coexistence with legacy Exchange versions and Kerberos authentication

If you would like to use Kerberos authentication during coexistence between Exchange 2010 and Exchange 2013 SP1 to remove the NTLM authentication bottlenecks in large Exchange environments, you have to consider some important things.

Kerberos is not enabled by default in Exchange 2013 SP1 and needs some manual configuration tasks.

Note: Exchange 2013 SP1 proxies connections to Exchange 2007 and Exchange 2010 resources utilizing NTLM authentication.

First of all you have to consider to re-use the existing Exchange 2010 ASA with new human-know credentials or create a new ASA for the Exchange 2013 SP1 organization.

If you consider to re-use the existing Exchange 2010 ASA:

  • Advantage: One ASA for both Exchange 2010 and Exchange 2013 SP1 servers
  • Disadvantage: You have to use human-know credentials instead of machine-generated credentials

If you consider to create a new ASA for the Exchange 2013 SP1 organization:

  • Advantage: You can use the .\RollAlternateServiceAccountPassword.ps1 script against Exchange 2013 SP1 multi-role servers.
  • Disadvantage: The Service Principal Names (SPN) must be moved from the existing Exchange 2010 ASA to the new Exchange 2013 SP1 ASA for any hostname you will be moving from Exchange 2010 to Exchange 2013 SP1

With the current Exchange 2013 Cumulative Update 4 (CU4) or SP1 there are a couple caveats to be aware of:

  • The .\RollAlternateServiceAccontPassword.ps1 script can be used to create a new ASA on multi-role Exchange 2013 SP1 servers
  • The .\RollAlternateServcieAccountPassword.ps1 script cannot be used to create a new ASA on Exchange 2013 SP1 CAS servers (CAS only)
  • The .\RollAlternateServiceAccountPassword.ps1 script cannot be used to copy the ASA credentials from Exchange 2010 CAS to Exchange 2013 SP1 CAS
  • The Set-ClientAccessServer –AlternateServiceAccountCredential cmdlet only works on Exchange 2013 SP1 multi-role servers
  • If you enable Kerberos authentication for your coexistence environment there is no access to legacy public folders possible, except you are deploying Exchange 2013 CU5 or use Exchange 2013 SP1 mapi/http.

The OAB virtual directories must not be converted as it was in Exchange 2010. Also no longer necessary are “exchangeAB”, “exchangeRFR”, or “exchangeMDB” SPNs for an Exchange 2013 SP1 ASA. You only have to configure you http-SPNs correctly.

Conclusion:

  • If you configure Kerberos for a native Exchange 2013 SP1 environment – Outlook Anywhere (RPC/HTTP) + (MAPI/HTTP) – everything works fine.
  • If you configure Kerberos for Exchange 2010 and Exchange 2013 SP1 – Outlook Anywhere (RPC/HTTP) – during coexistence, you have no access to legacy public folders.
  • If you configure Kerberos for Exchange 2010 and Exchange 2013 SP1 – Outlook Anywhere (MAPI/HTTP) – during coexistence, you have access to legacy public folders.
  • If you configure Kerberos for Exchange 2010 and Exchange 2013 CU5 – Outlook Anywhere (RPC/HTTP) – during coexistence, you have access to legacy public folders

If you configure Kerberos for Exchange 2010 and Exchange 2013 CU5 – Outlook Anywhere (MAPI/HTTP) – during coexistence, you have access to legacy public folders.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s