Configuring, Managing, and Troubleshooting Front-end/Back-end Servers If you currently do or are planning to support users using OWA, you need to set up a secure front-end/back-end Exchange server arrangement. To achieve this goal, some of the tasks that you need to perform include, but are not limited to, the following: Configuring an Exchange server as a front-end server Configuring firewalls Implementing IPSec between front-end and back-end servers Disabling unnecessary services on front-end servers Troubleshooting front-end and back-end servers
We briefly examine each of these topics in the following sections. Configuring an Exchange Server as a Front-end Server After you've installed Exchange Server 2003 on your front-end server, you can easily configure it to act as a front-end server by changing one configuration item and then restarting it. Open the server Properties dialog box by right-clicking on the server and selecting Properties from the context menu. Select the This Is a Front-end Server check box, as shown in Figure 6.24, and click OK to close the server Properties dialog box. A warning message box appears, informing you that you need to restart the server to complete the process. In addition, the warning message box encourages you to install a server certificate to increase server security. After the server has restarted, you should install a server certificate for the HTTP virtual server and enable SSL security as previously discussed in the "Requiring Secure Inbound Connections" section of this chapter. Figure 6.24. You need only select one configuration option to configure the server as a front-end server. 
 | It is not recommended that you move the front-end server physically into the screened subnet between the internal and external firewall until you have completed all required firewall configuration. |
 | You do not need to perform any special configuration on the servers that will be the back-end servers. You must, however, ensure that they can communicate with the front-end servers over TCP port 80 for HTTP. |
Configuring Firewalls As we saw previously in the "Introduction to Front-end/Back-end Arrangements" section of this chapter, you need to ensure that selected ports are made available on both the external and internal firewalls to ensure that your front-end/back-end OWA solution functions properly. In addition to the ports we discussed previously, you need to open additional ports to support other Exchange services. (We only examined those ports used specifically for the sample front-end/back-end OWA implementation.) As we discussed previously in the "Introduction to Virtual Servers" section of this chapter, several other ports must be made available for other Exchange services to function properly. As a review, Table 6.4 presents the common ports that you need to enable on your internal and external firewalls for Exchange. Table 6.4. Common Exchange PortsPort | Function | External Firewall | Internal Firewall |
|---|
110 | POP3 | Open * | Open * | 995 | POP3 over SSL | Open * | Open * | 143 | IMAP4 | Open * | Open * | 993 | IMAP4 over SSL | Open * | Open * | 25 | SMTP | Open * | Open * | 119 | NNTP | Open * | Open * | 563 | NNTP over SSL | Open * | Open * | 80 | HTTP | Open * | Open * | 443 | HTTP over SSL | Open * | Open * | 389 | LDAP to domain controller | Closed | Open | 3268 | LDAP to global catalog | Closed | Open | 88 | Kerberos authentication | Closed | Open | 53 | DNS | Open | Open | 135 | RPC port mapping | Closed | Open | 1024 65535 | RPC service ports (can be manually assigned to a specific port using a Registry modification) | Closed | Open |
| Items marked with an asterisk (*) in Table 6.4 need only be open if the service is being used. In addition, you need only open the non-SSL port if SSL is not being used to secure that connection type. It is always recommended to use SSL security for inbound connections at the external firewall. In regard to DNS, it is recommended that you place a DNS server with a secondary zone in the screened subnet for name resolution and configure one DNS server in your protected internal network as the only DNS server allowed to forward queries from the internal network outside to the Internet. |
Implementing IPSec Between Front-end and Back-end Servers One of the single greatest things you can do to increase security of the communications between your front-end and back-end Exchange servers is to secure the communications between them using IPSec. This security, however, comes at the price of increased system utilization, as you might expect. A common mistake that is made when configuring IPSec for use in this situation is to attempt to use the Secure Server (Require Security) policy. By applying this policy to a computer, you are telling that computer that it is not allowed to create or accept any communications with other computers that are not also using IPSec and have matching encryption and authentication settings configured. The net result of this mistake in configuration is that your front-end and back-end servers will be able to communicate with each other, but not with any other hosts, including Internet clients (for the front-end servers) and domain controllers (for the back-end servers). Of course, you can also create a custom IPSec policy for your servers if you want. In any case, the Secure Server (Request Security) IPSec policy can be used (with minor modifications) to provide a secure communications tunnel between the front-end and back-end Exchange servers through the internal firewall. You should also give consideration to implementing IPSec security between your front-end servers and your domain controllers and global catalog servers as well after all, the communications between these servers are juicy pieces of information that attackers might like to get hold of as well. But what exactly is an IPSec policy? An IPSec policy is a set of rules that defines how and when communication is secured between two endpoints. This is done through the configuration of various rules. Each rule contains a collection of actions and filters that begin when they encounter endpoints that match. Policies allow you to quickly and easily configure IPSec based on the settings required within your organization. Windows Server 2003 comes with the following three preconfigured IPSec policies that might or might not meet your needs: Client (Respond Only) This policy requires IPSec-provided security only when another computer requests it. This policy allows the computer to attempt unsecured communications first and switch to IPSec-secured communications if requested. This policy contains the default response rule, which creates dynamic IPSec filters for inbound and outbound traffic based on the requested protocol and port traffic for the communication that is being secured. This policy, which can be used on workstations and servers alike, provides the minimum amount of IPSec security. Server (Request Security) This policy requests security from the other computer and allows unsecured communication with non-IPSec-aware computers. The computer accepts inbound unsecured traffic, but always attempts to secure further communications by requesting IPSec security from the sending computer. If the other computer is not IPSec-enabled, the entire communication is allowed to be unsecured. This policy, which can be used on workstations and servers alike, provides a medium level of IPSec security. Secure Server (Require Security) This policy is implemented on computers that require highly secure communications, such as servers transmitting sensitive data. The filters in this policy require all outbound communication to be secured, allowing only the initial inbound communication request to be unsecured. This policy has a rule to require security for all IP traffic, a rule to permit ICMP traffic, and the default response rule to respond to requests for security from other computers. This policy, typically used only on servers, provides the highest level of IPSec security on a network. This policy can also be used on workstation computers if you want. Non-IPSec-enabled computers cannot establish any communications with computers using this policy.
Before you start working with IPSec, you should understand a few key features of its implementation in Windows Server 2003: IPSec in Windows Server 2003 is policy-based. It cannot be configured without an IPSec policy being in place, allowing an administrator to more easily apply settings to groups of objects, such as computers or users. IPSec on Windows Server 2003 can use Kerberos v5, a digital certificate, or a shared secret (string) for user authentication. IPSec mutually authenticates computers prior to any data being exchanged. IPSec establishes a security association (SA) between the two host computers involved in the data transfer. An SA is the collection of a policy and keys, which defines the rules for security settings. IPSec encrypts data using Data Encryption Standard (DES) or Triple DES (3DES). IPSec uses the MD5 or SHA1 algorithm for data hashing. IPSec is invisible to users. IPSec operates at the Network level of the Open Systems Interconnect (OSI) model; therefore, users and applications do not directly interact with the protocol. After an IPSec tunnel has been created, users can connect to applications and services as if they were on the local network and not on the other side of a public network.
| To learn more about IPSec, including how to implement and configure it to use custom policies, be certain to read MCSE 70-293 Training Guide: Planning and Maintaining a Windows Server 2003 Network Infrastructure by Will Schmied and Rob Shimonski, Que Publishing, 2003. |
Looking back at our sample front-end/back-end configuration after we've applied IPSec, you can see how traffic flows in Figure 6.25. Remember that all traffic travels over the same physical network; the different paths simply represent different protocols or secured and unsecured traffic. Figure 6.25. You need to implement IPSec between your front-end servers and your back-end servers, domain controllers, and global catalog servers to increase security. 
Disabling Unnecessary Services on Front-end Servers It only stands to reason that if you're configuring a server for the sole purpose of providing a front-end for OWA, you don't need to have all of the installed Exchange services running. The practice of disabling unnecessary services is known as reducing your attack vector and is done in many other situations besides configuring servers for OWA. | You might want to consider configuring increased security on your front-end servers by using a security template that imposes a stricter configuration on the server. The Windows Server 2003 Security Guide, located at www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch00.asp, contains some very good information in Chapter 11 about hardening bastion hosts (those computers in the DMZ), along with some preconfigured security templates. |
To increase the security of your front-end servers, you need to disable the following services: Microsoft Exchange Management, Microsoft Exchange MTA Stacks, and Microsoft Exchange Routing Engine. However, you cannot simply disable these services you need to start several services first, then disable these services, and, finally, restart some services that are still needed. To disable unnecessary services on your front-end server, perform the following steps: - Open the Services console.
- Stop the following services:
Microsoft Exchange Information Store Microsoft Exchange Management Microsoft MTA Stacks Microsoft Routing Engine Microsoft Exchange System Attendant World Wide Web Publishing Service
- Configure the following services with a Startup Type of Disabled:
- Start the following services again to restore functionality to the front-end server:
Microsoft Exchange Information Store Microsoft Exchange System Attendant World Wide Web Publishing Service
Troubleshooting Front-end and Back-end Servers When troubleshooting front-end/back-end servers, you are looking at four basic items: Are the required services in operation? By checking the event logs and the Services console, you can quickly determine the status of required services and perhaps gain some insight into why they might not be working correctly. Are the required ports open on the applicable firewall? A firewall misconfiguration manifests itself quite easily by the inability to pass traffic through the firewall on desired ports. Does basic network connectivity exist across the firewall between the front- end and back-end servers? Troubleshooting basic network connectivity across the firewall between the front-end and back-end servers can be done very easily by using the ping command. If IPSec is being used, is it working properly? IPSec troubleshooting is more involved than any of the other troubleshooting items we've looked at and, thus, we examine it in more detail following this list.
If you have problems with IPSec, you should first verify that any routers or firewalls you might be passing through are configured to support IPSec traffic. You need to allow the following traffic: Following are some other basic troubleshooting tips for IPSec: You are not able to establish any communications with a computer In this case, you should first verify that basic network connectivity exists between the computers in question. Ensure also that all required network services, such as Dynamic Host Configuration Protocol (DHCP) and DNS, are operating properly for both computers. This might also be the result of a computer that has been removed from the domain, which causes IPSec communications to fail. Communications are occurring, but not as expected Ensure that you have the correct (and compatible) IPSec policies assigned on both computers. No hard associations are being formed If soft associations are currently in place, a hard association is not formed. You need to completely stop all communications between the computers for about 5 10 minutes to allow the soft associations to time out. The easiest way to do this is to disable the network connection. After you have allowed the soft association to time out, you can check to see that a hard association has been formed. If a hard association still has not been formed, you need to examine your IPSec policy to verify that unsecured communications are not allowed. IPSec communications are failing after configuring a digital certificate for authentication You must make certain that the required digital certificate is installed on the computers attempting to communicate using that IPSec policy. This can also be the result of specifying an incorrect certificate authority (CA). Some computers can create IPSec connections and some cannot This situation is most likely caused by not having the same IPSec policy applied to all your computers. If you are intentionally using different policies, ensure that they share at least one common authentication and security method.
|
