Every mailbox in an Exchange Server 2010 organization accesses the Client Access server. Because people interact directly with this server over the Internet, it’s exposed to potential attackers. Therefore, ensuring the Client Access server’s security is paramount. In previous articles I walked you through various aspects of the Client Access server role and showed you how to deploy it and load-balance it. (See the Learning Path for previous articles about the Client Access server.) In this article I discuss how to secure the Client Access server.
The term security means different things to different people. We often think of security as an ambiguous process that’s used to determine how accessible a server is. But when considering security for Client Access servers, there are three steps you can take to greatly increase security:
1. Use certificates for external services.
2. Harden the server OS.
3. Limit exposure with a reverse proxy.
Use Certificates for External Services
Clients access data through Client Access servers in various forms. For email, this access might include connecting via Outlook Web App (OWA), ActiveSync, Outlook Anywhere, Exchange Web Services (EWS), POP, IMAP, or MAPI on an Outlook client. All these methodologies and protocols, except for MAPI on an Outlook client, were designed to be used over the public Internet. You must therefore ensure that the data being transmitted over the Internet can’t be read by people who might be capturing packets on the network. In Exchange, you can accomplish this by encrypting these publicly routable connections with SSL certificates.
An SSL certificate has a pair of keys associated with it; one key is private and the other is public. These keys are used for encrypting the data passed between two parties. The server that receives the certificate (the Client Access server in this case) holds a copy of the private key. The public key is given to the clients that access the Client Access server. The data that’s encrypted with the public key can be decrypted only with the private key. This allows the client to encrypt the data it sends to the Client Access server and ensures that only the Client Access server can decrypt it. However, you also need to ensure that the data the Client Access server sends back to the client is encrypted as well. To accomplish this task, the client generates a shared key that can be used to both encrypt and decrypt the data. The client then encrypts that shared key with the public key of the Client Access server and sends it to the Client Access server. The Client Access server and the client then have a shared key that they can both use to encrypt and decrypt the data. This prevents other people, who might be capturing packets on the network, from reading the data transmitted between the client and the Client Access server. Even if someone captures the data, they need the shared key to decrypt it. And because the shared key is held only by the client and the Client Access server, they’re out of luck.
The first thing you need to do to make your data transmission secure is obtain a certificate for your Client Access servers. When you install the Client Access server, a self-signed certificate is created by default. This certificate is generated by the Client Access server itself. The problem with using a self-signed certificate is that your clients don’t trust it. If your Client Access server is using a self-signed certificate and you try to access OWA, you’ll receive an error message similar to the one in Figure 1. This doesn’t necessarily mean that your Client Access server isn’t secure; it simply means that your clients don’t trust the certificate issuer (i.e., the Client Access server). If you add the self-signed certificate to the list of trusted issuers on the client, the problem is solved. However, this is difficult to manage in a distributed environment. This is particularly true in Exchange Server 2007 because the default self-signed certificate is good only for a year. After the certificate expires, you have to renew it and redistribute it. Exchange 2010 extends the expiration period to five years. Even so, self-signed certificates aren’t an ideal solution.
A better solution is to obtain a mutually trusted certificate from a valid Certificate Authority (CA). The idea is that the Client Access server and the client both trust the certificate, so they both believe that the certificate is valid. You can obtain such a certificate from your own CA (if you have one) or you can buy a certificate from a third party, such as DigiCert, VeriSign, Entrust, or GoDaddy.
Client Access servers can use many different names to communicate. Therefore you need to ensure that all the names used to access the server are listed in the certificate when you obtain it. If not, your server will fail the identity check. Two types of certificates let you specify more than one name for a server: a Subject Alternative Name (SAN) certificate and a wildcard certificate.
Wildcard certificates can be expensive, but they let you use a wildcard character for the certificate’s subject name. Thus, any name by which the server is accessed is considered valid. SAN certificates are cheaper and more commonly used. A SAN certificate lets you list the server’s primary name in the Subject Name field and alternative names in the Subject Alternative Name field, as Figure 2 shows.
To obtain a certificate, you must generate a certificate request file on the Exchange server and give that file to the CA that will issue the certificate. When the request file is created, the private key portion of the certificate is created and stored on the server that generated the request. This keeps the private key secure because you don’t have to give it to the CA—so your server is the only party that has it. You can generate this certificate request in Exchange 2010 in one of two ways: by using Exchange Management Console’s (EMC’s) New Exchange Certificate wizard or by using Exchange Management Shell’s (EMS’s) New-ExchangeCertificate cmdlet.
To launch the New Exchange Certificate wizard in EMC, select the Client Access server you’re requesting the certificate for and select New Exchange Certificate, as Figure 3 shows. In the New Exchange Certificate wizard, you have the option of requesting certificates for some or all of the services running on the Client Access server, as Figure 4 shows.
After you complete this process, you’ll have a certificate request file that you can give to your CA. The CA uses this file to generate a certificate. After you receive the certificate from the CA, you must then import the certificate into Exchange to complete the process. To do so, start EMC and select the certificate request that you generated for the Client Access server. Select Complete Pending Request, as Figure 5 shows, to give Exchange the certificate and enable it.
A question that’s often asked is whether every Client Access server can use the same certificate. For example, in a Client Access array, every server is accessed using the same external name—so, can you import the same certificate on every server, or do you need a separate certificate for each server? The answer depends on a couple of factors. If you purchase your certificate from a publically trusted CA, such as Thawte, then you must pay for each certificate that you want to use on each Client Access server. But if you use an internal CA, you aren’t legally obligated to use multiple certificates. In this case you can use a single wildcard certificate. A typical Exchange certificate often uses multiple SANs, so if you use the same certificate for multiple Client Access servers, you should make sure that the valid names for each server are contained in the Subject Alternative Name field.
Harden the Server OS
Hardening a server involves removing extraneous services and processes that could be potential sources of vulnerability. Even if no known vulnerability exists, simply disabling components that you don’t use helps ensure protection if a security hole is found in the future. Exchange 2007 includes templates that you can use with the Windows Security Configuration Wizard (SCW) to lock down Exchange on a role-by-role basis. Exchange 2010 doesn’t include these templates because each role is locked down by default. However, this doesn’t mean the OS is locked down. Some basic steps you can take to harden Windows Server 2008 R2 or Server 2008 include the following:
- Design your organizational unit (OU) structure for role-based policies.
- Implement the security policies identified in the Enterprise Client (EC) settings or the Specialized Security – Limited Functionality (SSLF) settings.
- Audit the security logs on your server.
The primary method for hardening Client Access servers is to use Group Policy Objects (GPOs) to enforce policies on the servers. To make this process work efficiently, you need to ensure that your OU structure is configured to let you lock down your Exchange servers with a common policy and then lock down individual servers by role. When you use this method of GPO enforcement, you independently secure your Client Access role from other server roles. For example, you can disable the POP or IMAP service for all Exchange servers but enable it for Client Access servers. Figure 6 illustrates how this methodology of GPO application works. For additional information on this topic, see the TechNet article “Designing OU Structures that Work”.
After your OU structure is in place, you can implement Group Policy settings to decrease the attack surface of your servers. You’ll want to start by implementing a baseline security configuration that you can later build on. Two baselines are worth mentioning, but only one of them is reasonable to use in most situations.
The EC baseline includes some solid and well-accepted security settings. (Don’t let the name fool you; this baseline applies to Windows Server 2003 and later member servers as well as client OSs.) EC baseline security settings include disabling the guest account and disabling cached credentials.
The SSLF baseline is tightly locked down. (Note the “limited functionality” portion of its name.) SSLF goes to extremes in securing a server—so much so that you’ll likely need to troubleshoot some problems and roll back to pre-baseline policy settings. I’ve seen some odd behavior with SSLF, such as EMC connectivity experiencing intermittent failures.
I recommend using the EC baseline rather than SSLF for securing your Exchange servers. You can download this baseline, as well as documentation for implementing the settings, as part of the Microsoft Security Compliance Manager.
A final note about hardening your OS is to pay attention to the audit logs that are generated. If you use the security baselines that I recommend, then security auditing is configured on the server. But configuring auditing is just the first step. You also need a method of regularly monitoring the audit logs in order to detect intrusion attempts. Many tools are available to consolidate your servers’ security audit logs. The two most common tools I’ve seen used are Microsoft System Center Operations Manager’s Audit Collection Services (ACS) and NetIQ Security Manager. Each product has unique features, but the idea is the same—collect your security logs and pay attention to them.
Limit Exposure with a Reverse Proxy
Perhaps the most important aspect of protecting your Client Access servers is to ensure that people who aren’t part of your organization can’t break into them. Limiting exposure to your Client Access servers means keeping them within your protected environment but still making them accessible by legitimate users over the Internet. Not only is this the preferred configuration, but keeping your Client Access servers out of your demilitarized zone (DMZ) is also the only configuration that Microsoft supports. Instead of publishing your Client Access server directly to the Internet, you publish a reverse proxy server to the Internet and the reverse proxy subsequently provides connectivity to the Client Access server. Figure 7 illustrates how this scenario takes place.
Numerous reverse proxy server products are available, including Microsoft’s own Internet Security and Acceleration (ISA) Server, Forefront Threat Management Gateway (TMG—ISA Server’s 64-bit successor), Apache, Squid, various flavors of Linux with strict lockdowns, and enterprise-class hardware devices such as F5’s BIG-IP. Each reverse proxy server offers different advantages and disadvantages, but the basic concept is the same. The reverse proxy server’s job is to intelligently accept or reject connections coming from the Internet and pass them back to the Client Access server. The level of intelligence that the reverse proxy server has varies between products. Some reverse proxy servers provide access based on simple rules, whereas others have a deep knowledge of the applications they’re protecting. The advantage of these more intelligent reverse proxy servers is that they know what kind of traffic the application will or won’t accept, so they can block application requests that are malformatted or obvious hack attempts. You need to keep a few considerations in mind when configuring a reverse proxy server to protect your Client Access servers, such as how authentication is performed, how SSL connectivity is handled, and whether you’ll use the reverse proxy as a load balancer.
One of the advantages of a reverse proxy is the ability to perform preauthentication. When you configure preauthentication, you let the reverse proxy authenticate the user before the request is passed back to the Client Access server. Authentication still occurs on the Client Access server, but you can delegate that authentication so that the user doesn’t need to re-enter any credentials. For example, you can implement forms-based authentication on your reverse proxy and implement NTLM authentication on your OWA virtual directory on the Client Access server. In this case, when an Internet user accesses OWA, he or she is prompted for forms-based authentication through the preauthentication process. However, when a user that’s on your internal network accesses OWA directly on the Client Access server, his or her NTLM credentials are passed right through and the user isn’t prompted for authentication. The thing you need to be careful about with preauthentication is that it isn’t supported by all email access methods. For example, if you require preauthentication for Outlook Anywhere clients, they won’t connect because Outlook doesn’t know how to handle the preauthentication request. Also, if you’re using Exchange 2010’s federated sharing features, then you need to exclude the following paths from preauthentication:
- /EWS/exchange.asmx/wssecurity
- /autodiscover/autodiscover.svc
- /autodiscover/autodiscover.svc/wssecurity
The primary thing to keep in mind for preauthentication is that it’s good to use in scenarios in which email access will be browser based, such as in the case of OWA and the Exchange Control Panel (ECP).
When it comes to SSL connectivity, you typically have a few choices available, depending on the reverse proxy that you use. In general these options are:
- Basic firewall: Maintain the same SSL connection from the client to the Client Access server.
- SSL offloading: Terminate the SSL connection at the reverse proxy and use an unencrypted connection from the reverse proxy to the Client Access server.
- SSL bridging: Terminate the SSL connection at the reverse proxy and establish a new SSL connection from the reverse proxy to the Client Access server.
These options each have benefits. In the first option, the reverse proxy acts like a basic firewall and just passes the connection straight through to the Client Access server, in a fashion similar to port forwarding. This method tends to be the least secure because the reverse proxy doesn’t perform any content inspection. The second option, SSL offloading, lets the client establish an SSL connection with the reverse proxy, but the connection from the reverse proxy to the Client Access server is unencrypted. The advantage with this method is that because the reverse proxy performs the decryption and verification associated with the SSL connection, the Client Access server doesn’t have to. The third option, SSL bridging, is the most secure. When SSL bridging is used, the connection is terminated at the reverse proxy so that the reverse proxy can perform inspection. Then the reverse proxy reestablishes a new SSL connection back to the Client Access server in order to keep the session encrypted. In this option, the SSL termination for the client occurs at the reverse proxy and the SSL termination for the reverse proxy occurs at the Client Access server, as Figure 8 shows.
A final consideration to keep in mind is whether to configure your reverse proxy as your load balancer for your Client Access servers. This was a better option in previous versions of Exchange than in Exchange 2010 because Exchange 2010’s MAPI clients interact directly with Client Access servers. Therefore, you need to ensure that the MAPI clients connect to the load-balanced array of Client Access servers instead of an individual Client Access server. (For more information about load balancing, see “Exchange Server’s Client Access: Load Balancing Your Servers”.) You can make this scenario work, but not without some pain. You must route the connections for your internal users through the external interface and back into the network, which means you need to allow RPC connections through your reverse proxy—which isn’t a good idea.
Easier than Expected
Securing your Client Access servers isn’t as difficult a task as you might imagine. Exchange 2010’s built-in security options make the process simple; all you need to do is ensure that you have the right certificates, that your server OS is locked down, and that you’re using a reverse proxy to protect your servers from the Internet.
