Installing Exchange 2013 : Namespace planning

When you install Exchange 2013 on a server, Exchange automatically creates three self-signed certificates (Figure 1) to enable the server to communicate with other servers and clients within the organization. However, only other Exchange servers in the organization automatically trust the self-signed certificates presented by a server. Self-signed certificates that Exchange creates include the server name and its FDQN in the Subject Alternate Name field and last for five years. The biggest advantage of a self-signed certificate is that it is free, but aside from providing the basis for testing inside an organization, that is its only advantage.

Figure 1. Viewing the self-signed certificates on an Exchange 2013 server

Some companies have deployed self-signed certificates into production because they want to avoid the cost of buying certificates signed by an external vendor. This is a regrettably short-sighted step because saving the relatively low cost of the certificate cannot justify the security exposure that a self-signed certificate can create. Indeed, an Australian researcher reported in July 2012 how Android and Apple iOS devices might fall victim to a man-in-the-middle attack by using ActiveSync when self-signed certificates were used. The attack could result in wiping out device contents. All Exchange 2013 deployments that offer services through the Internet should buy and install the certificates necessary to secure the services.

Security alert: Limitations with self-signed certificates

A self-signed certificate can be used with all Exchange communications within the firewall and supports some external connections (Outlook Web App and ActiveSync) after the certificate has been copied into the trusted root certificate store on the client computer. Some mobile devices don’t permit this, so you can’t use these devices with self-signed certificates. However, you cannot use these certificates to secure Outlook Anywhere connections. Microsoft Outlook 2007 accepts self-signed certificates used for internal communications quietly in that it doesn’t display any errors when they connect to an Exchange 2010 server. Outlook 2010 and Outlook 2013 are more cautious and signal a potential problem to a user (Figure 2).

Figure 2. Outlook 2013 flagging a problem with a self-signed certificate

In most cases, because of the limitations imposed on the supported functionality and the difficulty of managing the certificates over time, self-signed certificates are used for test deployments or deployments that do not support external client connectivity only.

If you run Exchange 2007 or Exchange 2010 today and want to introduce Exchange 2013 at some point in the future, you must bring Exchange 2013 CAS servers into operation. The recommended approach is to have the Exchange 2013 CAS take over the namespace (for example, mail.contoso.com) for the organization so that it then works with its Exchange 2007 or Exchange 2010 counterparts to route incoming client connections to the correct mailbox servers. The Exchange 2007 and Exchange 2010 servers must first be updated to enable them to coexist with Exchange 2013 inside the organization.

In many companies, the usual approach to handle incoming connections is to deploy a load balancer in front of the CAS. (For the purposes of this section, “CAS” means either an individual CAS or a member of a CAS array in an Internet-facing site.) It doesn’t matter whether the load balancer operates at layer 4 (now supported by Exchange 2013) or layer 7. What does matter is that the load balancer will pass incoming client connections to the CAS.

At this point, the CAS has to decide where to direct the connection. The location of the destination mailbox determines how processing proceeds. If the mailbox is on an Exchange 2013 Mailbox server, the CAS can proxy the connection direct to that Mailbox server without any problems. However, if the mailbox is on an Exchange 2007 or Exchange 2010 server, the CAS has to use an HTTP proxy or redirection to transfer the connection to an Exchange 2007 or Exchange 2010 CAS, which then takes responsibility for making the final connection to the mailbox.

The proxy from the Exchange 2013 CAS uses Kerberos to communicate with its earlier counterparts, and the destination is the RPCproxy or Outlook Anywhere endpoint (the /rpc virtual directory in Internet Information Services [IIS]), which requires secured connections. If you configure Basic Authentication for Outlook Anywhere, IIS enables only Basic Authentication on the /rpc virtual directory. For this reason, IIS has to be updated to support Integrated Windows Authentication (IWA—previously known as NTLM) connections; otherwise, Kerberos won’t work. However, if you were to modify IIS to support IWA, Exchange would overwrite it and incur the side effect of changing the authentication mechanism that clients use to connect to the CAS, which is probably not what you want to happen.

The workaround is reasonably simple—you run the Set-OutlookAnywhere cmdlet in the Exchange Management Shell to update IIS on all your older CAS servers so that internal (between CAS) connections are authenticated with Kerberos, and external (client) connections continue to use BASIC. The command is as follows:

Set-OutlookAnywhere –Name ExCAS01 –ClientAuthenticationMethod Basic –IISAuthenticationMethods Basic, NTLM

If you’ve already decided to enable NTLM for Outlook Anywhere, you don’t need to make any changes to IIS. However, even if this is the case, you still need to consider how the Exchange 2013 CAS proxies connections to other CAS servers located in internal or non-Internet-facing sites (that is, without a direct connection to the Internet through a firewall and so on).

This requirement does not exist for previous versions of Exchange, so it’s unlikely that Outlook Anywhere is enabled on CAS servers in non-Internet-facing sites because they do not expect to process incoming Outlook Anywhere connections. However, if the Exchange 2013 CAS has to proxy an incoming connection because the target mailbox is on a server in an internal site, the proxy is to the Outlook Anywhere endpoint. It therefore follows that the CAS servers in these sites need to be updated by running the Enable-OutlookAnywhere cmdlet so that they can accept the incoming proxy to their Outlook Anywhere endpoint with NTLM authentication enabled.

Perhaps the Exchange developers were unaware of the law of unintended consequences when they decided to change the Exchange load-balancing requirement from layer 7 to layer 4 of the network stack. In most situations, the change is good. For some, especially those responsible for deployments that have to cater to large numbers of incoming client connections, it creates an interesting question about protocol handling that deserves some attention during the planning for the implementation of Exchange 2013.

Anyone dealing with high-end deployments based on Exchange 2007 and Exchange 2010 is very aware of the need to manage incoming connections carefully. Typically, the solution involved a hardware-based load balancer (running on physical or virtual hardware) that terminated the incoming SSL connection and then sent it on to one of an array of CAS servers that then processed the connection and directed it to the correct mailbox server. Usually, this worked, albeit at the expense of having a load balancer and some complexity in ensuring proper client connection affinity.

Exchange 2013 greatly simplifies matters. You still need to deploy hardware-based load balancers when high availability for client connections is required, but Exchange 2013 supports solutions such as Windows NLB and round-robin balancing to handle lower-end deployments. All this is because the Exchange 2013 CAS doesn’t do the rendering and protocol handling that its predecessors did. Instead, the Exchange 2013 CAS simply proxies connections to the appropriate mailbox server, which does all the real work. The idea is to break the version linkage that previously existed between CAS and mailbox insofar as you couldn’t upgrade one without the other. Version independence is a big theme for future versions of Exchange, and if all goes well, you’ll be able to upgrade different parts of the infrastructure in the knowledge that the new components won’t break anything running on the old bits.

Simplification is always good in computer technology because complexity invariably leads to additional cost, confusion, and potentially poorer results. However, any change has consequences, and one consequence that flows from the move to L4 is the loss of protocol awareness. When a load balancer terminates an incoming SSL connection at L7, it can sniff the packets and discover the protocol to which the connection is directed. Exchange offers a rich set of protocols and services, including Exchange Web Services (EWS), Outlook Web App, ActiveSync (EAS), the Offline Address Book (OAB), and Exchange Administration (ECP), each of whose endpoint is represented as an IIS virtual directory. However, when an L4 load balancer handles a connection, it sees it going to TCP port 443 and the IP address for the external connectivity point (such as mail.contoso.com). Later, the CAS will sort out the connection and get it to the right place, but that’s too late to have any notion of protocol.