Front-end Back-end Exchange Server Trihomed DMZ Network Scenario

The Exchange Server Front End/Back End configuration distributes Exchange related tasks between front-end and back end Exchange Servers. This task distribution has many advantages over the back-end only Exchange configuration. Some of these advantages include:

A single namespace

The key advantage of a front-end and back-end server configuration is the ability to use a single namespace for multiple Exchange servers. You can define a namespace that users can use to connect to their mailboxes (for example, http://owa.internal.net for Outlook Web Access). Without a front-end/back-end configuration, each user must know the name of the specific server that stores his or her mailbox.

Distribution of processing tasks among multiple servers

You can configure your OWA sites to use Secure Sockets Layer (SSL) traffic between the client and the server to protect the traffic from Internet intruders. However, encryption consumes a large number of processor cycles and can degrade performance. The front-end and back-end server setup allows the front-end servers to handle all SSL encryption and decryption tasks. This offloads the encryption responsibilities from the back end Exchange Servers and improves overall performance.

Improved IMAP4 access to public folders

The IMAP4 protocol allows a server to refer IMAP4 clients to another server. Exchange supports this referral functionality when a public folder stored on a particular server doesn’t contain the requested content. When a non referral-enabled IMAP4 client connects through a front-end server, the client can access the entire public folder hierarchy. The front-end server automatically handles any referral response that is passed back when attempting to access a folder that is not available on the back-end server. These referrals are transparent to the client.

You can make secure Outlook Web Access (OWA), secure POP3 and secure IMAP4 services available to remote users by publishing the front-end Exchange Server. ISA Server Web and Server Publishing Rules allow remote users secure inbound access to these vital services.

In addition, users will never need to change configuration settings on their email client computers when you correctly configure a split DNS infrastructure to support remote access clients.

In this document, we will go over detailed procedures required to configure Microsoft Exchange Servers and the ISA Server 2004 firewall to support the front-end Exchange Server on a DMZ segment and the back-end Exchange Server on the Internal network.

You will perform the following to publish the front-end Exchange Server using an ISA Server 2004 firewall:

• Define the DMZ Network in the ISA Server 2004 Management console
• Create the Network Rules to define the routing relationship between the DMZ and Internal and External networks
• Create the Access Rules for front-end/back-end (FE/BE) Exchange Server traffic
• Create Access Rules for FE and BE for SMTP and DNS
• Create the Server Publishing Rules Allowing Inbound Access for HTTP, POP3 and IMAP4 to the FE Server
• Join the FE Exchange Server to the Domain
• Install Exchange Server on the FE Machine
• Configure the OWA, POP3 and IMAP Services on the Back-end Server
• Create a Registry Entry to Limit RPC Ports on the BE Server
• Request a Web Site Certificate to be used by OWA/RPC/HTTP Web, POP3 and IMAP Services on the FE Server
• Export the OWA/RPC/HTTP Web Site Certificate to a File and Copy it to the ISA Server 2004 Firewall
• Configure the OWA, POP3 and IMAP Services on the Back-end Server
• Import the OWA/RPC/HTTP Web Site Certificate into the ISA Server 2004 Firewall’s Machine Certificate Store
• Create a HOSTS File Entry and Creating the Server Publishing Rule Allowing Inbound Access to the Front-end Exchange Server
• Publish the Web Enrollment Site at the Main Office network
• Issue a CA Certificate to the Web Client
• Configure the Public DNS to Resolve the Names of the OWA, POP3 and IMAP4 Sites
• Creating HOSTS File Entries on the External E-mail Client (to simulate public DNS name resolution)
• Making the OWA, POP3 and IMAP4 connection

The figure below shows the network topology used in this article. Note that the DMZ segment is a private address DMZ segment directly connected to a trihomed ISA Server 2004 firewall. You have the option to use a public address DMZ segment, but you should consider conserving your public addresses for other purposes; public addresses are not required to publish Web servers or the services discussed in this article.

Note that the EXCHANGE2003BE machine on the Internal network also hosts DHCP, DNS, WINS, IAS and Certificate Services. The EXCHANGE2003BE is also a domain controller and the ISA Server 2004 firewall and EXCHANGE2003FE machines are all members of this domain. Not all these services are required in this scenario. Only DNS and Certificate services are required. The Certificate Server is installed in enterprise mode ( in contrast to standalone CA mode, which does not allow you to use the Certificates MMC or the IIS Certificate Request Wizard).

The figure above also shows the routing relationships between the DMZ, the External network and the Internal network. ISA Server 2004 allows you to control how communications are routed between any two networks via its “multinetworking” capabilities. Note that “multinetworking” has nothing to do with allowing multiple external interfaces on the ISA Server 2004 firewall. You still need RainConnect (www.rainfinity.com) or a third party hardware device to enable this capability.

In the current example the DMZ has a NAT relationship with the External network and a Route relationship with the Internal network. This provides a good level of security and functionality. The NAT relationship between the DMZ and the External network allows server addresses on the DMZ to be hidden, while at the same time allowing the full range of Internet protocols to be used between the DMZ and the Internal network (not all applications work correctly when there is a NAT relationship, as we have painfully learned form our ISA Server 2000 experiences.

The figure below shows one of the functions of the FE Exchange Server. The FE Exchange Server must be able to provide relay for authenticated users. In the past this wasn’t so much of an issue because users typically dialed into an ISP and used the ISP’s SMTP server to send outbound SMTP mail. However, most external users now connect to a broadband network that supplies them with Internet access, but no SMTP server. We solve this problem by allowing uses who authenticate access to the FE Exchange Server’s SMTP service from which they can relay mail to domains not under your administrator control.

The figure below shows what happens when mail is sent to domains hosted by your Exchange Server organization. In this case, Internet SMTP servers can relay mail to your domains without authenticating. This is required because there is no mechanism is place that would enable Internet SMTP servers the ability to authenticate with the FE Exchange Server. The Internet SMTP server forwards SMTP messages to the FE Exchange Server and the FE Exchange Server forwards mail to the Exchange Server(s) on the Internal network. External SMTP clients can also forward mail to your domain using either authenticated or unauthenticated SMTP connections.

However, you may prefer to require all your external users to not only authenticate, but to use SSL/TLS encryption on the SMTP connections to secure the outgoing SMTP messages; the assures that information will not intercepted when SMTP mail is sent from your clients to the FE SMTP server.

Note that this is only one scenario out of many possible scenarios for a front-end/back-end Exchange Server setup. There are a number of documents on the Microsoft Exchange Server Web site that recommend placing the FE Exchange Server in a DMZ segment and then “opening ports” on a back end firewall to allow the required intradomain communications through to the BE Exchange Server. While we won’t “open ports” (the term “open port” is meaningless and should be banished from the firewall literature), we will create Access Rules that allow the required communications between the FE Exchange Server in the DMZ segment and the BE Exchange Server on the Internal network.

The advantage of this approach is that external systems which are completely out of your control are never in direct contact with the BE Exchange Server. The downside of such an approach is that the Internal network security zone is extended into a DMZ segment, which violates the integrity of the Internal network’s security zone.

However, since the machines on the DMZ segment are under your administrative control, you can harden them and configure alerts to let you know when something is awry on these machines. In addition, the ISA Server 2004 firewall goes a long way at protecting the FE Exchange Server in the DMZ segment. Finally, authentication and SSL/TLS is required for machines that wish to relay to non-corporate domains (domains that you do not host in your organization.

Finally, there is the issue of outbound SMTP. In order to keep things simple, we will configure the ISA Server 2004 firewall to allow outbound SMTP from the BE Exchange Server. This allows messages arriving at the BE Exchange Server to be forwarded to external Internet SMTP domains. However, I typically configure the FE Exchange Server, or the ISA Server 2004 firewall itself, to perform outbound SMTP relay. This protects the BE Exchange Server by allowing it to never be in direct communications with an Internet SMTP server; all messages, both inbound and outbound, are mediated by an SMTP relay.

In the figure below, the BLUE arrow indicates the configuration we will adopt in this article. A more secure configuration is shown by the GREEN arrows, where the BE Exchange Server forwards outbound SMTP messages to the FE Exchange Server and the FE Exchange Server acts as an outbound SMTP relay for mail destined to external Internet SMTP domains.

One final note: this is a very long article, so you might want to skim it first and when you get serious about making it happen, put together a lab network and replicate the network used in this article. That way, you’ll understand the processes and procedures and you’ll get first hand experience at making the whole thing work correctly before rolling it out on your production network.

Defining the DMZ Network

The first step is to create a DMZ network definition on the ISA Server 2004 firewall. The ISA Server 2004 firewall is configured with three network interfaces. The network interface on network ID 172.16.0.0/16 will be used as a DMZ network. You should define this network as a DMZ Network, because otherwise the firewall will consider it to be an External Network, as all networks that are not defined are considered External.

Perform the following steps on the ISA Server 2004 firewall machine to define the DMZ Network:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then expand the Configuration node. Click the Networks node.
2. In the Details Pane, click the Networks tab. Click the Tasks tab on the Task Pane. Click the Create a New Network link.
3. On the Welcome to the New Network Wizard page, enter a name for the new network in the Network name text box. In this example, we will name the Network DMZ. Click Next.
4. On the Network Type page, select the DMZ Network option. Click Next.

5. On the Network Addresses page, click the Add Adapter button.
6. In the Select Network Adapters dialog box, put a checkmark in the checkbox next to the DMZ network adapter. In this example, the network adapter is named DMZ. Click OK.
7. Click Next on the Network Addresses page.
8. Click Finish on the Completing the New Network Wizard page.

Creating the Network Rules

Network Rules define the routing relationship between two networks. You can define a Route relationship or a NAT relationship. The Route relationship simply routes packets between networks (if the connection is allowed by firewall policy). The NAT relationship performs network address translation between two networks. In the case of the NAT relationship, the source IP address is replaced with the IP address on the ISA Server adapter that the packet leaves.

For example, the default relationship between the Internal and External network is NAT; when a connection from an Internal Network host is made to an External network host, the source IP address the External host sees is the primary IP address on the External interface of the ISA Server 2004 firewall.

In our current scenario, both the DMZ Network and the Internal Network use private IP addresses. For this reason, we can use the Route network relationship between the Internal and DMZ Networks. Note that you cannot use a Route relationship between public address networks and private address networks.

Perform the following steps to create the Route relationship between the Internal Network and the DMZ Network:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then expand the Configuration node. Click the Networks node.
2. On the Networks node, click the Network Rules node in the Details Pane.
3. In the Details Pane, click the Tasks tab on the Task Pane. Click the Create a New Network Rule link.
4. On the Welcome to the New Network Rule Wizard page, enter a name for the rule in the Network rule name text box. We will name the rule Internalß à DMZ. Click Next.
5. On the Network Traffic Sources page, click the Add button.
6. In the Add Network Entities dialog box, click the Networks folder and then double click the Internal entry. Click Close.
7. On the Network Traffic Sources page, click Next.
8. On the Network Traffic Destinations page, click the Add button.
9. In the Add Network Entities dialog box, click the Networks folder and then double click the DMZ entry. Click Close.
10. Click Next on the Network Traffic Destinations page.
11. On the Network Relationship page, select the Route option. Click Next.

12. Click Finish on the Completing the New Network Rule Wizard page.

The next Network Rule creates a NAT relationship between the DMZ and External Networks:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then expand the Configuration node. Click the Networks node.
2. On the Networks node, click the Network Rules node in the Details Pane.
3. In the Details Pane, click the Tasks tab on the Task Pane. Click the Create a New Network Rule link.
4. On the Welcome to the New Network Rule Wizard page, enter a name for the rule in the Network rule name text box. We will name the rule Externalß à DMZ. Click Next.
5. On the Network Traffic Sources page, click the Add button.
6. In the Add Network Entities dialog box, click the Networks folder and then double click the DMZ entry. Click Close.
7. On the Network Traffic Sources page, click Next.
8. On the Network Traffic Destinations page, click the Add button.
9. In the Add Network Entities dialog box, click the Networks folder and then double click the External entry. Click Close.
10. Click Next on the Network Traffic Destinations page.
11. On the Network Relationship page, select the NAT option. Click Next.
12. Click Finish on the Completing the New Network Rule Wizard page.

Creating the Access Rules for Front-end/Back-end Traffic

Now that the DMZ Network is created and there is a Network Rule defining the routing relationship between the Internal and DMZ Networks, we can create Access Rules controlling traffic between the Internal and DMZ Networks. Table 1 below describes the Access Rule allowing the required traffic between the front-end Exchange Server in the DMZ network and the back-end Exchange Server on the Internal Network.

Table 1 FE/BE Exchange Access Rule

* User defined protocols
* User defined network objects

ADLogon/DirRep:
Primary Connection: 1600 TCP Outbound (requires RPC key set on the back-end Exchange Server)

Direct Access:
Primary Connection: 445 TCP Outbound

FEBE/LinkState:
Primary Connection 691 TCP Outbound

We also need to create an Access Rule allowing all traffic to move between the DMZ Network and the Internal Network. This is a temporary rule that is required to issue Web site certificates to the Exchange Services on the DMZ Network. We will disable this rule after the Web site certificates are bound to the front-end Exchange Server’s services.

Table 2 All Open from DMZ to Internal

** User defined Network Objects

Perform the following steps to create the Access Rule controlling traffic between the front-end and back-end Exchange Servers:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click the Firewall Policy node.
2. In the Firewall Policy node, click the Tasks tab on the Task Pane. Click the Create a New Access Rule link.
3. On the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we will call the rule FEß à BE Connection. Click Next.
4. On the Rule Action page, select the Allow option and click Next.
5. In the This rule applies to list, select the Selected protocols option. Click the Add button.
6. In the Add Protocols dialog box, click the All Protocols folder. Double click the following protocols:DNS
   HTTP
   IMAP4
   POP3
   SMTP
   Kerberos-Adm (UDP)
   Kerberos-Sec (TCP)
   Kerberos-Sec (UDP)
   LDAP
   LDAP (UDP)
   LDAP GC (Global Catalog)
   RPC (All Interfaces)
   NTP (UDP)
   Ping
7. Click the New menu and click Protocol.
8. On the Welcome to the New Protocol Definition Wizard page, enter ADLogon/DirRep in the Protocol Definition name text box. Click Next.
9. On the Primary Connection Information page, click New.
10. On the New/Edit Protocol Connection page, select TCP in the Protocol type list. Select Outbound in the Direction list. In the Port Range frame, enter 1600 in the From and To text boxes. Click OK.

11. Click Next on the Primary Connection Information page.
12. Select the No option on the Secondary Connections page.
13. Click Finish on the Completing the New Protocol Definition Wizard page.
14. Click the New menu and click Protocol.
15. On the Welcome to the New Protocol Definition Wizard page, enter Direct Access in the Protocol Definition name text box. Click Next.
16. On the Primary Connection Information page, click New.
17. On the New/Edit Protocol Connection page, select TCP in the Protocol type list. Select Outbound in the Direction list. In the Port Range frame, enter 445 in the From and To text boxes. Click OK.
18. Click Next on the Primary Connection Information page.
19. Select the No option on the Secondary Connections page.
20. Click Finish on the Completing the New Protocol Definition Wizard page.
21. Click the New menu and click Protocol.
22. On the Welcome to the New Protocol Definition Wizard page, enter FEBE/LinkState in the Protocol Definition name text box. Click Next.
23. On the Primary Connection Information page, click New.
24. On the New/Edit Protocol Connection page, select TCP in the Protocol type list. Select Outbound in the Direction list. In the Port Range frame, enter 691 in the From and To text boxes. Click OK.
25. Click Next on the Primary Connection Information page.
26. Select the No option on the Secondary Connections page.
27. Click Finish on the Completing the New Protocol Definition Wizard page.
28. In the Add Protocols dialog box, click the User-Defined folder. Double click the ADLogon/DirRep, Direct Access and FEBE/LinkState protocols. Click Close.
29. Click Next on the Protocols page.
30. On the Access Rule Sources page, click Add.
31. In the Add Network Entities dialog box, click the New menu. Click Computer.
32. In the New Computer Rule Element dialog box, enter Front-end Exchange in the Name text box. Enter 172.16.0.2 in the Computer IP Address text box. Click OK.

33. In the Add Network Entities dialog box, click the New menu. Click Computer.
34. In the New Computer Rule Element dialog box, enter Back-end Exchange in the Name text box. Enter 10.0.0.2 in the Computer IP Address text box. Click OK.
35. In the Add Network Entities dialog box, click the Computers folder. Double click the Back-end Exchange and Front-end Exchange entries. Click Close.
36. Click Next on the Access Rule Sources page.
37. On the Access Rule Destinations page, click Add.
38. In the Add Network Entities dialog box, click the Computers folder. Double click the Back-end Exchange and Front-end Exchange entries. Click Close.
39. Click Next on the Access Rule Destinations page.
40. On the User Sets page, accept the default entry, All Users, and click Next.
41. Review the settings on the Completing the New Access Rule Wizard page and click Finish.

The next step is to create the “all open” rule that we will use for issuing certificates to the front-end Exchange Server. This rule will be disabled after the certificates are issued. Perform the following steps to create the rule:

1. Click the Create New Access Rule link on the Tasks tab.
2. On the Welcome to the New Access Rule Wizard page, enter (Temp) All Open DMZ<->Internal in the Access Rule name text box. Click Next.
3. On the Rule Action page, select the Allow option and click Next.
4. On the Protocols page, accept the default selection, All outbound traffic, on the This rule applies to list and click Next.
5. On the Access Rule Sources page, click Add.
6. In the Add Network Entities dialog box, click the Computers folder. Double click the Back-end Exchange and Front-end Exchange entries. Click Close.
7. Click Next on the Access Rule Sources page.
8. On the Access Rule Destinations page, click Add.
9. In the Add Network Entities dialog box, click the Computers folder. Double click the Back-end Exchange and Front-end Exchange entries. Click Close.
10. Click Next on the Access Rule Destinations page.
11. On the User Sets page, select the default entry, All Users, and click Next.
12. Review the settings on the Completing the New Access Rule Wizard page and click Finish.

We will now disable the RPC filter. This is required to allow the Certificates MMC snap-in to work properly so that a certificate an be obtained via RPC. Perform the following steps to disable the ISA Server 2004 RPC filter:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then expand the Configuration node. Click the Add-ins node.
2. At the Add-ins node, right click the RPC Filter entry in the Details Pane and click Disable.

3. Click Apply to save the changes and update the firewall policy.
4. In the ISA Server Warning dialog box, select the Save the changes and restart the services option and click OK.

Creating Access Rules for FE and BE for SMTP and DNS

Both the front-end and back-end Exchange Servers need to send outbound SMTP messages. The front-end Exchange Server must be able to relay mail for authenticated users to domains that are not under your administrative control, and the back-end Exchange Server must be able to send mail it receives from Internal network users to domains not under your administrative control. To accomplish this, you need to create an Access Rule allowing these machines outbound access to the SMTP and DNS protocols.

Perform the following steps to create this Access Rule:

1. Click the Tasks tab while in the Firewall Policy node. Click the Create a New Access Rule link.
2. In the Welcome to the New Access Rule Wizard page, enter a name for the rule in the Access Rule name text box. In this example, we will name the rule FE/BE Outbound SMTP/DNS and click Next.
3. On the Rule Action page, select the Allow option and click Next.
4. On the Protocols page, select the Selected protocols option in the This rule applies to list. Click the Add button.
5. In the Add Protocols dialog box, click the Common Protocols folder. Double click the DNS and SMTP protocols. Click Close.
6. Click Next on the Protocols page.
7. On the Access Rule Sources page, click the Add button.
8. In the Add Network Entities dialog box, click the Computers folder. Double click the Back-end Exchange and Front-end Exchange entries. Click Close.

9. Click Next on the Access Rule Sources page.
10. On the Access Rule Destinations page, click the Add button.
11. In the Add Network Entities dialog box, click the Networks folder. Double click the External entry. Click Close.
12. Click Next on the Access Rule Destinations page.
13. On the User Sets page, accept the default entry, All Users, and click Next.
14. On the Completing the New Access Rule Wizard page, review the settings and click Finish.
15. Click Apply to save the changes and update the firewall policy.
16. Click OK in the Apply New Configuration dialog box.

Joining the Front-end Exchange Server to the Domain

The Access Rules are now in place to provide the necessary communication channels required to join the front-end machine in the DMZ network to the domain. We will install Microsoft Exchange 2003 on the front-end machine on the DMZ network after joining the domain.

Perform the following steps to join the front-end Exchange Server to the domain:

1. On the EXCHANGE2003FE machine, right click the My Computer icon on the desktop and click Properties.
2. In the System Properties dialog box, click the Computer Name tab.
3. On the Computer Name tab, click the Change button.
4. In the Computer Name Changes dialog box, select the Domain option and enter msfirewall.org in the text box underneath. Click OK.
5. In the Computer Name Changes dialog box, enter Administrator in the User name text box and the Administrator’s password in the Password text box. Click OK.
6. Click OK in the Computer Name Changes dialog box that welcomes you to the domain.
7. Click OK in the Computer Name Changes dialog box informing you that you must restart the computer for the change to take effect.
8. Click OK in the System Properties dialog box.
9. Click Yes in the System Settings Change dialog box.
10. Log on as Domain Administrator after the computer restarts. Ensure that you log on to the domain, and not the local machine.

Installing Exchange Server on the FE Machine

Now that the DMZ network machine is a member of the domain, Exchange Server 2003 can be installed on it. We will configure the machine as a front-end Exchange Server after installation is complete. However, before installing Exchange Server 2003 on the front-end machine, we must install the required IIS services.

Perform the following steps to install the required IIS services:

1. Click Start, point to Control Panel and click Add or Remove Programs.
2. In the Add or Remove Programs window, click the Add/Remove Windows Components button on the left side of the window.
3. On the Windows Components page, select the Application Server entry in the Components list and click Details.
4. In the Application Server dialog box, put a checkmark in the checkbox next to ASP.NET. Then, select the Internet Information Services (IIS) entry and click Details.
5. In the Internet Information Services (IIS) dialog box, put checkmarks in the checkboxes for NNTP Service, SMTP Service and World Wide Web service. Click OK.
6. Click OK in the Application Server dialog box.
7. On the Windows Components page, click the Networking Services entry in the Components list and click Details.
8. In the Networking Services dialog box, put a checkmark in the RPC over HTTP Proxy checkbox. Click OK.
9. Click Next on the Windows Components page.
10. Click OK in the Insert Disk dialog box.
11. Enter the path to the Windows Server 2003 i386 folder in the Copy files from text box on the Files Needed dialog box. Click OK.
12. Click Finish on the Completing the Windows Components Wizard page.

Perform the following steps to install Exchange Server 2003:

1. Place the Exchange Server 2003 CD into the CD-ROM drive. In the Exchange Server 2003 autorun menu, click the Exchange Deployment Tools link.
2. In the Exchange Deployment Tools window, click the Install Exchange 2003 on additional servers link.
3. Scroll down to the bottom of the Install Exchange 2003 on Additional Servers page. Click the Run Setup now link.
4. Click Next on the Welcome to the Microsoft Exchange Installation Wizard page.
5. Select the I agree option on the License Agreement page.
6. Click Next on the Component Selection page.
7. On the Licensing Agreement page, select the I agree that I have read and will be bound by the license agreements for this product option and click Next.
8. Click Next on the Installation Summary page.
9. Click Finish on the Completing the Microsoft Exchange Wizard page when installation is completed.
10. Click Exit on the Microsoft Exchange Server 2003 page.
11. Close the Exchange Server Deployment Tools window.

Perform the following steps to make the new Exchange Server a front-end Server:

1. Click Start, point to All Programs and point to Microsoft Exchange. Click System Manager.
2. In the Exchange System Manager, expand the Servers node and right click the EXHCANGE2003FE entry in the left pane of the console. Click Properties.
3. In the EXCHANGE2003FE Properties dialog box, click the General tab.
4. On the General tab, put a checkmark in the This is a front-end server checkbox.

5. Click Apply and then click OK.
6. Restart the front-end server machine.

Configuring the OWA, POP3 and IMAP Services on the Back-end Server

The back-end Exchange Server is configured to allow both SSL and non-SSL connections. The reason for this is that you cannot use SSL to connect the front-end Exchange Server to the back-end Exchange Server. If you wish to secure the connection between the front-end and back-end servers, consider using IPSec to secure front-end to back-end communications. Details on how to configure IPSec are included at the end of this document.

The first step is to enable the POP3 and IMAP4 services. Perform the following steps on the back-end Exchange Server to enable the POP3 and IMAP4 services:

1. Click Start and point to Administrative Tools. Click the Services entry.
2. In the Services window, find the Microsoft Exchange IMAP4 entry and double click on it.
3. In the Microsoft Exchange IMAP4 Properties (Local Computer) dialog box, change the startup type to Automatic, and then click Apply.
4. Click the Start button to start the IMAP4 service.
5. Click OK in the Microsoft Exchange IMAP4 Properties (Local Computer) dialog box.
6. In the Services window, find the Microsoft Exchange POP3 entry and double click it.
7. In the Microsoft Exchange POP3 Properties (Local Computer) dialog box, change the startup type to Automatic, and then click Apply.
8. Click the Start button to start the IMAP4 service.
9. Click OK in the Microsoft Exchange POP3 Properties (Local Computer) dialog box.

10. Close the Services console.

We can now begin configuring the HTTP, POP3 and IMAP4 services on the back-end Exchange Server. We will begin with the IMAP4 service. Perform the following steps to configure the back-end Exchange Server’s IMAP4 and POP3 services:

1. Click Start, point to All Programs and point to Microsoft Exchange. Click System Manager.
2. In the Exchange System Manager, expand the Servers node and then expand the EXCHANGE2003BE node. Expand the Protocols node and then expand the IMAP4 node.
3. Click Default IMAP4 Virtual Server and then right click it. Click Properties.
4. On the General tab, select the IP address 10.0.0.2 from the IP address list. Click Apply.
5. Click the Access tab. On the Access tab, click the Authentication button.
6. In the Authentication dialog box, remove the checkmark from the Simple Authentication and Security Layer checkbox. Confirm that there is no checkmark in the Requires SSL/TLS encryption checkbox. Confirm that there is a checkmark in the Basic authentication (password is sent in clear text) checkbox. Click OK.
7. Click Apply and then click OK in the Default IMAP4 Virtual Server Properties dialog box.
8. Expand the POP3 node in the left pane of the console. Click Default POP3 Virtual Server and then right click it. Click Properties.
9. On the General tab, select the IP address 10.0.0.2 from the IP address list. Click Apply.
10. Click the Access tab. On the Access tab, click the Authentication button.
11. In the Authentication dialog box, remove the checkmark from the Simple Authentication and Security Layer checkbox. Confirm that there is no checkmark in the Requires SSL/TLS encryption checkbox. Confirm that there is a checkmark in the Basic authentication (password is sent in clear text) checkbox. Click OK.

12. Click Apply and then click OK in the Default POP3 Virtual Server Properties dialog box.
13. Close the Exchange System Manager.

Now we can configure the Outlook Web Access and RPC over HTTP Web folders. Perform the following steps to configure the Web site:

1. Click Start and point to Administrative Tools. Click Internet Information Services (IIS) Manager.
2. In the Internet Information Services (IIS) Manager console, expand the Web Sites node in the left pane of the console and then expand the Default Web Site.
3. Click the Exchange folder and then right click on it. Click Properties.
4. Click the Directory Security tab. On the Directory Security tab, click the Edit button in the Authentication and access control frame.
5. In the Authentication Methods dialog box, remove checkmarks from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. If this is not already enabled, enable it now. Click Yes in the IIS Manager dialog box that informs you that the passwords are sent in clear text. Enter MSFIREWALL in the Default domain text box. Click OK.

6. Click OK in the Exchange Properties dialog box.
7. Click the ExchWeb folder and then right click it. Click Properties.
8. Click the Directory Security tab. On the Directory Security tab, click the Edit button in the Authentication and access control frame.
9. In the Authentication Methods dialog box, remove checkmarks from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. If this is not already enabled, enable it now. Click Yes in the IIS Manager dialog box that informs you that the passwords are sent in clear text. Enter MSFIREWALL in the Default domain text box. Click OK.
10. Click OK in the ExchWeb Properties dialog box. Click Select All in the Inheritance Override dialog box and click OK.
11. Click OK in the ExchWeb Properties dialog box.
12. Click the Public folder and then right click it. Click Properties.
13. Click the Directory Security tab. On the Directory Security tab, click the Edit button in the Authentication and access control frame.
14. In the Authentication Methods dialog box, remove checkmarks from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. If this is not already enabled, enable it now. Click Yes in the IIS Manager dialog box that informs you that the passwords are sent in clear text. Enter MSFIREWALL in the Default domain text box. Click OK.
15. Click OK in the Public Properties dialog box.
16. Click the RPC folder and then right click it. Click Properties.
17. Click the Directory Security tab. On the Directory Security tab, click the Edit button in the Authentication and access control frame.
18. In the Authentication Methods dialog box, remove checkmarks from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. If this is not already enabled, enable it now. Click Yes in the IIS Manager dialog box that informs you that the passwords are sent in clear text. Enter MSFIREWALL in the Default domain text box. Click OK.
19. Click OK in the RPC Properties dialog box. Click Select All in the Inheritance Override dialog box and click OK.
20. Click OK in the RPC Properties dialog box.
21. Right click the Default Web Site node in the left pane and click Properties.
22. On the Web Site tab, select 10.0.0.2 from the IP address list. Click Apply and then click OK.

Creating a Registry Entry to Limit RPC Ports on the Back-end Server

If you want access to features requiring Remote Procedure Calls, such as authentication or implicit logon, but do not want to open the wide range of ports above 1024, you can configure your domain controllers, global catalog servers, and all other back-end servers to use a single known port for all RPC traffic.

In order to authenticate clients, the registry key must be set on all servers the front-end server may contact via RPC (for example, your global catalog server). This can be any port not already in use. In the following example we will set the following registry key to a specific port, such as 1600:

HKEY_LOCAL_MACHINE\CurrentControlSet\Services\NTDS\Parameters

Registry Value: TCP/IP Port Value Type: REG_DWORD Value Data: (available port)

We will configure the back-end Exchange Server to use TCP port 1600 for RPC connections.

Perform the following steps to create the Registry value on the back-end Exchange Server:

1. Click Start and then click Run.
2. In the Run dialog box, enter regedit in the Open text box and click OK.
3. In the Registry Editor, navigate to:

HKEY_LOCAL_MACHINE\CurrentControlSet\Services\NTDS\Parameters

4. Click Edit, point to New and click DWORD Value.
5. Change the name of New Value #1 to TCP/IP Port and press ENTER.
6. Double click the TCP/IP Port value.
7. In the Edit DWORD Value dialog box, select the Decimal option. In the Value data text box, enter 1600. Click OK.
8. Close the Registry Editor.

8. Restart the back-end Exchange Server

Requesting a Web Site Certificate to be used by OWA/RPC/HTTP Web, POP3 and IMAP Services on the FE Server

Remote users will establish secure connections to the front-end Exchange Server using SSL/TLS encryption. To accomplish this, the front-end Web, POP3 and IMAP servers need Web site certificates bound to them. We can use the integrated Web Site Certificate Wizard included with IIS 6.0 to request these certificates directly from the online certification authority on the Internal network.

To use the integrated Web site Certificate Request Wizard, we must use the “all open” Access Rule that we created earlier. We will disable this “all open” rule after we obtain the required certificates to increase the level of security between the DMZ and Internal Networks.

Perform the following steps on the front-end Exchange Server to obtain the Web site certificate for the OWA service:

1. Click Start and point to Administrative Tools. Click Internet Information Services (IIS) Manager.
2. In the Internet Information Services (IIS) Manager console, expand the Web Sites node in the left pane of the console. Click the Default Web Site and then right click it. Click Properties.
3. In the Default Web Site Properties dialog box, click the Directory Security tab.
4. On the Directory Security tab, click the Server Certificate button.
5. On the Welcome to the Web Server Certificate Wizard page, click Next.
6. On the Server Certificate page, select the Create a new certificate option and click Next.
7. On the Delayed or Immediate Request page, select the Send the request immediately to an online certification authority option. Click Next.
8. On the Name and Security Settings page, accept the default values and click Next.
9. On the Organization name page, enter an Organization name and Organizational unit name in the text boxes. You can enter any value you like. Click Next.
10. On the Your Site’s Common Name page, enter a common name that will be included in the certificate. This is an extremely important setting. The name you specify here is the name that the external client must use to connect to the POP3 server, and this name must resolve to the external address on the ISA Server 2004 firewall that is used by the Server Publishing Rules for the POP3 Server. In this example, we will use owa.msfirewall.org as the common name. This address will resolve (for external clients) to 192.168.1.70, which is the address we will use for the listener in the POP3 Server Publishing Rule. Click Next.
11. On the Geographical Information page, enter your State/province and City/locality in the text boxes. Click Next.
12. Accept the default SSL port on the SSL Port page. Click Next.
13. On the Choose a Certification Authority page, accept the default CA listed in the Certification authorities list. Click Next.
14. On the Certificate Request Submission page, review your settings and click Next.
15. Click Finish on the Completing the Web Server Certificate Wizard page.
16. Click OK in the Default Web Site Properties dialog box.

The next step is to enable the IMAP4 and POP3 services on the front-end Exchange Server. We must enable these services before we can request the certificate. Perform the following step to enable the IMAP4 and POP3 services on the front-end Exchange Server:

1. Click Start and point to Administrative Tools. Click the Services entry.
2. In the Services window, find the Microsoft Exchange IMAP4 entry and double click it.
3. In the Microsoft Exchange IMAP4 Properties (Local Computer) dialog box, change the startup type to Automatic, and then click Apply.
4. Click the Start button to start the IMAP4 service.
5. Click OK in the Microsoft Exchange IMAP4 Properties (Local Computer) dialog box.
6. In the Services window, find the Microsoft Exchange POP3 entry and double click it.
7. In the Microsoft Exchange POP3 Properties (Local Computer) dialog box, change the startup type to Automatic, and then click Apply.
8. Click the Start button to start the IMAP4 service.
9. Click OK in the Microsoft Exchange POP3 Properties (Local Computer) dialog box.
10. Close the Services console.

Perform the following steps to request a Web site certificate for the IMAP4 service:

1. Open the Exchange System Manager, expand the organization name and then expand the Servers node. Expand your server name and then expand the Protocols node. Expand the IMAP4 node and click the Default IMAP4 Virtual Server node. Right click the Default IMAP4 Virtual Server node and click the Properties command.
2. Click the Access tab and click the Authentication button in the Access control frame.
3. Read the information on the Welcome to the Web Server Certificate Wizard page and click Next.
4. On the Server Certificate page, select the Create a new certificate option and click Next.
5. On the Delayed or Immediate Request page, select the Send the request immediately to an online certification authority option. You can use this option because you have an enterprise CA and the machine from which you’re requesting the certificate is a member of the same domain as the enterprise CA. If you did not have an enterprise CA, or if you used a standalone CA instead of an enterprise CA, you would have to use an offline request and send the request file to the CA later. Click Next.

6. On the Name and Security Settings page, accept the default options and click Next.
7. On the Organizational Information page, enter the name of your organization in the Organization text box and enter the name of your organizational unit in the Organizational Unit text box. In this example, we enter MSFirewall Org as the Organization and Texas as the Organizational Unit. Click Next.
8. On the Your Site’s Common Name page, enter the name of the site in the Common name text box. This is an extremely important setting! The name that you enter here must be the name that the internal and external hosts use to access the site. In our current example, we will use the common name mail.msfirewall.org. Internal hosts must be able to resolve this name to the Internal address of the Exchange Server using this certificate, and external hosts must be able to resolve this name to the IP address on the external interface of the ISA Server 2004 firewall that is listening for the incoming IMAP4 connections. This is why it’s critical that you create a split DNS infrastructure to support both your internal and your remote users. Enter mail.msfirewall.org into the Common name text box and click Next.

9. On the Geographical Information page, enter your Country/Region, State/province and City/locality. You can enter any valid information you like, or enter the information as seen in the figure below. Click Next.
10. On the Choose a Certification Authority page, accept the default enterprise CA that appears in the Certification authorities list. Click Next.
11. Review the information on the Certificate Request Submission page and click Next.
12. Click Finish on the Completing the Web Server Certificate Wizard page.
13. The Communication button in the Secure communication frame becomes available after the certificate is installed. You will use this button later to force TLS security on IMAP4 connections with this IMAP4 server

14. Click Apply and then click OK in the Default IMAP4 Virtual Server Properties dialog box.

Perform the following steps to bind a certificate to the POP3 service:

1. In the Exchange System Manager, expand the POP3 node in the left pane of the console. Click on the Default POP3 Server node and then right click it. Click Properties.
2. In the Default POP3 Virtual Server Properties dialog box, click the Access tab.
3. On the Access tab, click the Certificate button.
4. Click Next on the Welcome to the Web Server Certificate Wizard page.
5. On the Server Certificate page, select the Assign an existing certificate option and click Next.
6. On the Available Certificates page, select the mail.msfirewall.org certificate in the Select a certificate list. Click Next.
7. On the Certificate Summary page, click Next.
8. Click Finish on the Completing the Web Server Certificate Wizard page.
9. Click Apply and then click OK on the Default POP3 Virtual Server Properties dialog box.

We now need to enable the RPC filter and disable the (Temp) All Open DMZ ß à Internal Access Rule. Perform the following steps on the ISA Server 2004 firewall machine to accomplish both these tasks:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then expand the Configuration node in the left pane of the console. Click the Add-ins node.
2. At the Add-ins node, click the Application Filters tab in the Details Pane. Right click the RPC Filter and click Enable.
3. Click the Firewall Policy node in the left pane of the console.
4. At the Firewall Policy node, right click the (Temp) All Open DMZ ß à Internal rule in the Details Pane. Click Disable.
5. Click Apply to save the changes and update the firewall policy.
6. In the ISA Server Warning dialog box, select the Save the changes and restart the services option and click OK.
7. Click OK in the Apply New Configuration dialog box.

Exporting the OWA/RPC/HTTP Web Site Certificate to a File and Copying it to the ISA Server 2004 Firewall

The ISA Server 2004 firewall impersonates the front-end Exchange Server when the remote OWA client connects to the ISA Server 2004 firewall to access the front-end Exchange Server. The mechanism of this impersonation is the Web site certificate that was initially installed on the Web site. The Web site certificate contains the common name of the Web site and the OWA client recognizes the ISA Server 2004 firewall as the Web server because this common name matches the server name included in the OWA client’s request URL.

We must export the Web site certificate from the OWA Web site and then copy that certificate to the ISA Server 2004 firewall. Later, we will import this certificate into the ISA Server 2004 firewall’s machine certificate store and bind it to the Web listener that accepts incoming requests for the front-end server.

Perform the following steps to export the Web site certificate with its private key to a file:

1. In the Internet Information Services (IIS) Manager console, expand the Web Sites node in the left pane of the console and then click the Default Web Site. Right click the Default Web Site and click Properties.
2. In the Default Web Site Properties dialog box, click the Directory Security tab.
3. On the Directory Security tab, click the View Certificate button in the Secure communications frame.
4. In the Certificate dialog box, click the Details tab. On the Details tab, click the Copy to File button.

5. Click Next on the Welcome to the Certificate Export Wizard page.
6. On the Export Private Key page, select the Yes, export the private key option and click Next.

7. On the Export File Format page, select the Personal Information Exchange – PKCS #12 (.PFX) option. Put a checkmark in the Include all certificates in the certification path if possible option and remove the checkmark from the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) option. Click Next.

8. On the Password page, enter a Password and Confirm Password. Click Next.
9. On the File to Export page, enter c:\owacert in the File name text box. Click Next.
10. Click Finish on the Completing the Certificate Export Wizard page.
11. Click OK on the Certificate dialog box.
12. Click OK on the Default Web Site Properties dialog box.

Copy the owacert.pfx file to the root of the C:\ drive on the ISA Server 2004 firewall machine.

Configuring the OWA, POP3 and IMAP Services on the Front-end Server

The front-end Exchange Server will be configured to support secure SSL/TLS connections to the OWA/RPC/HTTP Web site and the POP3/IMAP4 server sites. SSL is required because these sites will be configured to use only Basic authentication. The SSL link encryption will protect the user credentials from being intercepted by intruders.

Perform the following steps to configure the front-end Exchange Server’s IMAP4 and POP3 services:

1. Click Start, point to All Programs and point to Microsoft Exchange. Click System Manager.
2. In the Exchange System Manager, expand the Servers node and then expand the EXCHANGE2003FE node. Expand the Protocols node and then expand the IMAP4 node.
3. Click the Default IMAP4 Virtual Server and then right click it. Click Properties.
4. On the General tab, select the IP address 172.16.0.2 from the IP address list. Click Apply.
5. Click the Access tab. On the Access tab, click the Authentication button.
6. In the Authentication dialog box, remove the checkmark from the Simple Authentication and Security Layer checkbox. Place a checkmark in the Requires SSL/TLS encryption checkbox. Confirm that there is a checkmark in the Basic authentication (password is sent in clear text) checkbox. Click OK.
7. On the Access tab, click the Communication button. In the Security dialog box, place a checkmark in the Require secure channel checkbox. Place a checkmark in the Require 128-encryption checkbox. Click OK.
8. Click Apply and then click OK in the Default IMAP4 Virtual Server Properties dialog box.
9. Expand the POP3 node in the left pane of the console. Click the Default POP3 Virtual Server and then right click it. Click Properties.
10. On the General tab, select the IP address 172.16.0.2 from the IP address list. Click Apply.
11. Click the Access tab. On the Access tab, click the Authentication button.
12. In the Authentication dialog box, remove the checkmark from the Simple Authentication and Security Layer checkbox. Place a checkmark in the Requires SSL/TLS encryption checkbox. Confirm that there is a checkmark in the Basic authentication (password is sent in clear text) checkbox. Click OK.
13. On the Access tab, click the Communication button. In the Security dialog box, place a checkmark in the Require secure channel checkbox. Place a checkmark in the Require 128-encryption checkbox. Click OK.
14. Click Apply and then click OK in the Default POP3 Virtual Server Properties dialog box.
15. Close the Exchange System Manager.

Now we can configure the Outlook Web Access and RPC over HTTP Web folders. Perform the following steps to configure the Web site:

1. Click Start and point to Administrative Tools. Click Internet Information Services (IIS) Manager.
2. In the Internet Information Services (IIS) Manager console, expand the Web Sites node in the left pane of the console and then expand the Default Web Site.
3. Click the Exchange folder and then right click it. Click Properties.
4. Click the Directory Security tab. On the Directory Security tab, click the Edit button in the Authentication and access control frame.
5. In the Authentication Methods dialog box, remove checkmarks from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. If this is not already enabled, enable it now. Click Yes in the IIS Manager dialog box that informs you that the passwords are sent in clear text. Enter MSFIREWALL in the Default domain text box. Click OK.
6. In the Exchange Properties dialog box, click the Edit button in the Secure Communications frame.
7. In the Secure Communications dialog box, put a checkmark in the Require secure channel (SSL) checkbox. Put a checkmark in the Require 128-bit encryption checkbox. Click OK.
8. Click Apply and then click OK in the Exchange Properties dialog box.
9. Click the ExchWeb folder and then right click it. Click Properties.
10. Click the Directory Security tab. On the Directory Security tab, click the Edit button in the Authentication and access control frame.
11. In the Authentication Methods dialog box, remove checkmarks from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. If this is not already enabled, enable it now. Click Yes in the IIS Manager dialog box that informs you that the passwords are sent in clear text. Enter MSFIREWALL in the Default domain text box. Click OK.
12. In the ExchWeb Properties dialog box, click the Edit button in the Secure Communications frame.
13. In the Secure Communications dialog box, put a checkmark in the Require secure channel (SSL) checkbox. Put a checkmark in the Require 128-bit encryption checkbox. Click OK.
14. Click Apply in the ExchWeb Properties dialog box. Click Select All in the Inheritance Override dialog box and click OK.
15. Click OK in the ExchWeb Properties dialog box.
16. Click the Public folder and then right click it. Click Properties.
17. Click the Directory Security tab. On the Directory Security tab, click the Edit button in the Authentication and access control frame.
18. In the Authentication Methods dialog box, remove checkmarks from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. If this is not already enabled, enable it now. Click Yes in the IIS Manager dialog box that informs you that the passwords are sent in clear text. Enter MSFIREWALL in the Default domain text box. Click OK.
19. In the Public Properties dialog box, click the Edit button in the Secure Communications frame.
20. In the Secure Communications dialog box, put a checkmark in the Require secure channel (SSL) checkbox. Put a checkmark in the Require 128-bit encryption checkbox. Click OK.
21. Click Apply and OK in the Public Properties dialog box.
22. Click the RPC folder and then right click it. Click Properties.
23. Click the Directory Security tab. On the Directory Security tab, click the Edit button in the Authentication and access control frame.
24. In the Authentication Methods dialog box, remove checkmarks from all checkboxes except the Basic authentication (password is sent in clear text) checkbox. If this is not already enabled, enable it now. Click Yes in the IIS Manager dialog box that informs you that the passwords are sent in clear text. Enter MSFIREWALL in the Default domain text box. Click OK.
25. In the RPC Properties dialog box, click the Edit button in the Secure Communications frame.
26. In the Secure Communications dialog box, put a checkmark in the Require secure channel (SSL) checkbox. Put a checkmark in the Require 128-bit encryption checkbox. Click OK.
27. Click OK in the RPC Properties dialog box. Click Select All in the Inheritance Override dialog box and click OK.
28. Click OK in the RPC Properties dialog box.
29. Right click the Default Web Site node in the left pane and click Properties.
30. On the Web Site tab, select 172.16.0.2 from the IP address list. Click Apply and then click OK.

Importing the OWA/RPC/HTTP Web Site Certificate into the ISA Server 2004 Firewall’s Machine Certificate Store

The Web site certificate must be imported into the ISA Server 2004 firewall’s machine certificate store before it can be bound to the Web Listener. Only after the Web site certificate (along with its private key) is imported into the firewall’s machine certificate store will the certificate be available for binding.

Perform the following steps to import the OWA server’s Web site certificate into the ISA Server’s machine certificate store (note that this single certificate can be used for all services on the FE Exchange Server):

1. At the ISA Server 2004 firewall machine, click Start and click the Run command. Enter mmc in the Open text box and click OK. In the Console 1 console, click the File menu and click the Add/Remove Snap-in command.
2. Click the Add button in the Add/Remove Snap-in dialog box.
3. Click the Certificates entry in the Available Standalone Snap-in list on the Add Standalone Snap-in dialog box. Click Add.
4. Select the Computer account option on the Certificates snap-in page. Click Next.
5. On the Select Computer page, select the Local computer: (the computer this console is running on) option and click Finish.
6. Click Close on the Add Standalone Snap-in page.
7. Click OK in the Add/Remove Snap-in dialog box.
8. Right click the Personal node in the left pane of the console, point to All Tasks and click Import.
9. Click Next on the Welcome to the Certificate Import Wizard.
10. Click the Browse button and locate the certificate file. Click Next after the file path and name appear in the File name text box.
11. On the Password page, enter the password for the file. Do not put a checkmark in the checkbox labeled Mark this key as exportable. This will allow you to back up or transport you keys at a late time. You should not select this option because this machine is a bastion host with an interface in a DMZ network or on the Internet and may be compromised. The compromiser might be able to steal the private key from this machine if it is marked as exportable. Click Next.
12. On the Certificate Store page, confirm that the Place all certificate in the follow store option is selected and that it says Personal in the Certificate store box. Click Next.
13. Review the settings on the Completing the Certificate Import page and click Finish.
14. Click OK on the Certificate Import Wizard dialog box informing you the import was successful.
15. You will see the Web site certificate and the CA certificate in the right pane of the console. The Web site certificate has the FQDN assigned to the Web site. This is the name external users use to access the OWA site. The CA certificate must be placed into the Trusted Root Certification Authorities\Certificates store so that this machine will trust the Web site certificate installed on it. Double click the Web site certificate in the right pane of the console.

16. Expand the Trusted Root Certification Authorities node in the left pane of the console and scroll down to the CA certificate of the enterprise CA that issued the Web site certificate. Note that the enterprise CA certificate automatically appears in the Trusted Root Certification Authorities because we have an enterprise CA and the ISA Server 2004 firewall belongs to the same domain as the enterprise CA machine. If you used a standalone CA, or if the ISA Server 2004 firewall did not belong to the same domain as the enterprise CA, you would need to copy the enterprise CA’s certificate into the Trusted Root Certification Authorities\Certificates node.

Creating a HOSTS file Entry and Creating the Server Publishing Rules Allowing Inbound Access for HTTP, POP3, SMTP and IMAP4 to the Front-end Server on the ISA Server 2004 Firewall

In a production environment you should create a split DNS infrastructure that enables hosts on the Internal and External networks to properly resolve the name of the OWA Web site. We have not configured a split DNS infrastructure in our current example, so we will use a HOSTS file on the ISA Server 2004 firewall machine that enables the firewall to resolve the name of the OWA and RPC over HTTP Web site to the site’s Internal IP address.

Perform the following steps to create the HOSTS file entry mapping the OWA site to its Internal address on the ISA Server 2004 firewall machine:

1. Open Windows Explorer and navigate to \WINDOWS\system32\drivers\etc directory and open the hosts file.
2. In the Open With dialog box, select Notepad and click OK.
3. The HOSTS file is opened in Notepad. Add a line at the end of the hosts file that resolves the name in the redirect to the IP address that can reach the OWA server on the internal network. For example, if the firewall in front of the OWA server on the internal network is performing reverse NAT to publish the internal OWA site and the redirect is owa.msfirewall.org, you would add the following entry:

172.16.0.2 owa.msfirewall.org
172.16.0.2 mail.msfirewall.org

“172.16.0.2” is the IP address of the front-end Exchange server machine on the DMZ network. Ensure that you press ENTER after you add this line to the hosts file so that there is an empty line at the end of the file.

4. Close Notepad and click Yes to save the changes made to the file.

Now we’re ready to create the OWA and RPC over HTTP Web Publishing Rule on the ISA Server 2004 firewall machine. Perform the following steps to securely publish the Exchange OWA Web site:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and click the Firewall Policy node. Click the Tasks tab in the Task Pane. Click the Publish a Mail Server link.
2. On the Welcome to the New Mail Server Publishing Rule Wizard page, enter a name for the rule in the Mail Server Publishing Rule name text box. In this example, we will call it Publish OWA and RPC/HTTP Web Site. Click Next.
3. On the Select Access Type page, select the Web client access (Outlook Web Access (OWA), Outlook Mobile Access, Exchange Server ActiveSync option and click Next.

4. On the Select Services page, put a checkmark in the Outlook Web Access checkbox. Confirm that there is a checkmark in the Enable high bit characters used by non-English character sets. This option allows OWA users to access mail using non-English character sets. Click Next.

5. On the Bridging Mode page, select the Secure connection to clients and mail server option and click Next. This option creates a Web Publishing Rule that ensures a secure SSL connection from the client to the OWA Web site. This prevents the traffic from moving in the clear, where an intruder can sniff the traffic and intercept valuable information. The external client that makes an SSL connection expects that traffic to be secure from end to end.

6. On the Specify the Web Mail Server page, enter the name for the Internal OWA Web site in the Web mail server text box. In this example, we will use the name owa.msfirewall.org. Note that this is the name used for the Exchange Server site on the internal network and this is the common name on the OWA Web site’s certificate. You could use an IP address, but that would create problems with the SSL connection between the internal interface of the ISA Server 2004 firewall and the Exchange OWA site. You can use either a split DNS or a HOSTS file entry on the ISA Server 2004 firewall machine to resolve this name to the IP address used by the Exchange Server on the internal network. Click Next.

7. On the Public Name Details page, select the This domain name (type below) option in the Accept requests for list. Enter the name external users will use to access the OWA Web site in the Public name text box. In this example, the external users will use the name owa.msfirewall.org. Again, this is the name the external user uses when accessing the Web site, and this is also the common name on the Web site certificate. This is the name the user enters into his browser in the browser’s Address bar. Click Next.

8. On the Select Web Listener page, click the New button. The Web listener works like the Web listener in ISA Server 2000, but with ISA Server 2004, you have more options. For example, you can create a separate Web listener for SSL and non-SSL connections on the same IP address. In addition, the Web listener settings are no longer global, and you can configure separate settings for each listener based on the number of addresses bound to the external interface of the ISA Server 2004 firewall.
9. On the Welcome to the New Web Listener Wizard page, enter a name for the listener in the Web listener name text box. In this example, we will use the name OWA/RPC SSL Listener. Click Next.
10. On the IP Addresses page, put a checkmark in the External checkbox. Click the Address button.
11. In the External Network Listener IP Selection dialog box, select the Specified IP addresses on the ISA Server computer in the select network option. Click the external IP address on the ISA Server 2004 firewall on which you want to listen for incoming requests to the OWA site in the Available IP Addresses list. In this example, we select the 192.168.1.70 entry. Click Add. The IP address now appears in the Selected IP Addresses list. Click OK.
12. Click Next on the IP Addresses page.
13. On the Port Specification page, remove the checkmark from the Enable HTTP checkbox. Place a checkmark in the Enable SSL checkbox. Leave the SSL port number at 443. After configuring this listener to use only SSL, you can configure a second listener with different settings that is dedicated for non-SSL connections.

14. Click the Select button. In the Select Certificate dialog box, click the OWA Web site certificate that you imported into the ISA Server 2004 firewall’s machine certificate store and click OK. Note that this certificate will appear in this dialog box only after you have installed the Web site certificate into the ISA Server 2004 firewall’s machine certificate store. In addition, the certificate must contain the private key. If the private key is not included, the certificate will not appear in this list.

15. Click Next on the Port Specification page.
16. Click Finish on the Completing the New Web Listener page.
17. The details of the Web listener now appear on the Select Web Listener page. Click Edit.
18. In the OWA SSL Listener Properties dialog box, click the Preferences tab.
19. On the Preferences tab, click the Authentication button.
20. In the Authentication dialog box, remove the checkmark from the Integrated checkbox. Click OK in the Microsoft Internet Security and Acceleration Server 2004 dialog box warning that no authentication methods are currently configured.
21. Place a checkmark in the OWA Forms-Based authentication checkbox. The OWA Forms-based authentication feature is very useful and enhances the security the ISA Server 2004 firewall provides for your OWA site. The firewall generates the log on form and then forwards the credentials sent by the user to the OWA site for authentication. Only after the user is successfully authenticated is the connection request forwarded to the OWA site. This prevents unauthenticated users from connecting to the OWA site and eliminates the risks inherent in unauthenticated users accessing the OWA site. Note that you must not enable forms-based authentication at the Exchange Server’s OWA site. Forms-based authentication should be enabled only at the ISA Server 2004 firewall. Note that this option does not have any influence on the RPC over HTTP connection. Click the Configure button.

16. On the OWA Forms-Based Authentication dialog box, put checkmarks in the Clients on public machines, Clients on private machines and Log off OWA when the user leaves OWA site checkboxes. These settings enhance security for your OWA site. Note that you also have the option to set the session times-outs for clients on both public and private machines. It is important to note that the user decides if the machine should be recognized as public or private. Because it is not good security policy to let the user determine the level of security applied to a connection, you should force the same policy on all users. Click OK.

17. Click OK in the Authentication dialog box.
18. Click Apply and then click OK in the OWA/RPC SSL Listener Properties dialog box.
19. Click Next on the Select Web Listener page.
20. On the User Sets page, accept the default entry, All Users, and then click Next. Note that this does not mean that all users will be able to access the OWA site. Only users who can authenticate successfully will be able to access the site. The actual authentication is done by the OWA site, using the credentials that the ISA Server 2004 firewall forwards to it. You cannot have the ISA Server 2004 firewall itself and the OWA or RPC over HTTP site authenticate the user. This means you must allow All Users access to the rule. An exception to this rule is when users authenticate to the ISA Server 2004 firewall itself, using client certificate authentication.
21. Click Finish on the Completing the New Mail Server Publishing Rule Wizard page.
22. Right click the Publish OWA and RPC/HTTP Web site rule in the Details pane of the console and click Properties.
23. In the Publish OWA and RPC/HTTP Web Site Properties dialog box, click the Paths tab. On the Paths tab, click the Add button.
24. In the Path mapping dialog box, enter /rpc/* in the Specify the folder on the Web site that you want to publish. To publish the entire Web site, leave this field blank text box. Click OK.
25. The new path now appears on the Path mapping dialog box.

26. In the OWA Web site Properties dialog box, click the To tab. On the To tab, select the Requests appear to come from the original client option. This option allows the OWA Web and RPC over HTTP Web site to receive the actual IP address of the external client. This feature enables Web logging add-ons installed on the OWA Web site to use this information when creating reports.

27. Click Apply and then click OK.
28. Click Apply to save the changes and update the firewall policy.
29. Click OK in the Apply New Configuration dialog box.

The POP3, IMAP4 and SMTP services can all be published using the Mail Server Publishing Wizard. The saves time, as we do not need to publish these services separately. Perform the following steps to publish these three services:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and click the Firewall Policy node.
2. In the Firewall Policy node, click the Tasks tab in the Task Pane. Click the Publish a Mail Server link.
3. On the Welcome to the New Mail Server Publishing Rule Wizard page, enter Publish POP3/IMAP4/SMTP in the Mail Server Publishing Rule name text box. Click Next.
4. On the Select Access Type page, select the Client access: RPC, IMAP, POP3, SMTP option. Click Next.
5. On the Select Services page, put checkmarks in the Secure ports column for the POP3 and IMAP4 options. Put a checkmark in the Standard ports column for the SMTP option. Note that Microsoft Exchange Server receives both secure and non-secure connections on the same port (TCP port 25). Click Next.
6. On the Select Server page, enter 172.16.0.2 into the Server IP Address text box. Click Next.
7. On the IP Addresses page, put a checkmark in the External checkbox and click the Address button.
8. On the External Network Listener IP Selection page, select the Specified IP addresses on the ISA Server computer in the selected network option. Click 192.168.1.70 in the Available IP Addresses list. Click Add. The address is moved to the Selected IP Addresses section. Click OK.
9. Click Next on the IP Addresses page.
10. Click Finish on the Completing the New Mail Server Publishing Rule Wizard page.
11. Click Apply to save the changes and update the firewall policy.
12. Click OK in the Apply New Configuration dialog box.

Publish the Web Enrollment Site

The OWA and RPC over HTTP client requires the CA certificate of the enterprise CA that issued the Web site certificate to the RPC over HTTP Web site. This allows the OWA and RPC over HTTP client to trust the Web site, which is required for the connection to be established. The RPC over HTTP, POP3, IMAP4 and SMTP clients do not provide a mechanism whereby the user can choose to proceed when the local host computer does not trust the CA that issued the Web site certificate.

Perform the following steps to publish the enterprise CA’s Web enrollment site:

1. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and then click the Firewall Policy node.
2. In the Task Pane, click the Tasks tab. On the Tasks tab, click the Publish a Web Server link.
3. Enter a name for the Web Publishing Rule the Welcome to the New Web Publishing Rule Wizard page. In this example, we will enter the name Publish Web Enrollment Site in the Web publishing rule name text box. Click Next.
4. Select the Allow option on the Select Rule Action page.
5. On the Define Website to Publish page, enter the IP address of the enterprise CA’s Web site in the Computer name or IP address text box. In this example, the IP address is 10.0.0.2, so we will enter that value into the text box. In the Path text box, enter /certsrv/*. Click Next.

6. On the Public Name Details page, select the This domain name (type below) option in the Accept request for list box. In the Public name text box, enter the IP address on the external interface of the firewall. In this example, the main office ISA Server 2004 firewall’s external address is 192.168.1.70, so we will enter that value into the text box. Enter /certsrv/* into the Path (optional) text box. Click Next.

7. On the Select Web Listener page, click the New button.
8. On the Welcome to the New Web Listener page, enter a name for the rule in the Web listener name text box. In this example, we will name the listener Listener70, to indicate the IP address on which the listener is listening. Click Next.
9. On the IP addresses page, put a checkmark in the External checkbox and click Next.
10. On the Port Specification page, accept the default settings. Confirm that there is a checkmark in the Enable HTTP checkbox and that the value 80 is in the HTTP port text box. Click Next.

11. Click Finish on the Completing the New Web Listener Wizard page.
12. Click Next on the Select Web Listener page.
13. Accept the default setting, All Users, on the User Sets page and click Next.
14. Click Finish on the Completing the New Web Publishing Rule Wizard page.
15. Right click the Publish Web Enrollment Site rule and click Properties.
16. In the Publish Web Enrollment Site Properties dialog box, click the Paths tab.
17. On the Paths tab, click Add.
18. In the Path mapping dialog box, enter /CertControl/* in the Specify the folder on the Web site that you want to publish. To publish the entire Web site, leave this field blank. Click OK.
19. Click Apply and then OK in the Publish Web Enrollment Site Properties dialog box.
20. Click Apply to save the changes and update the firewall policy.
21. Click OK in the Apply New Configuration dialog box.

Issuing a CA Certificate to the Web Client

We now need to obtain the CA certificate from the enterprise CA on the internal network. We can connect to the Web enrollment site to obtain the CA certificate. Perform the following steps to obtain the CA certificate an install it on the Outlook Express client computer:

1. On the Outlook e-mail client computer, enter http://192.168.1.70/certsrv in the Address bar and press ENTER.
2. In the Connect to dialog box, enter Administrator in the User name text box and the Administrator’s password in the Password text box. Click OK.
3. On the Welcome page of the Microsoft Certificate Services site, click the Download a CA certificate, certificate chain, or CRL link.
4. On the Download a CA Certificate, Certificate Chain, or CRL page, click the Install this CA certificate chain link.
5. Click Yes in the Security Warning dialog box asking if you want to install the Microsoft Certificate Enrollment Control.
6. Click Yes in the Potential Scripting Violation dialog box informing you that the Web site will add a certificate to the machine.
7. Click Yes in the Root Certificate Store dialog box asking if you want to add the CA certificate.

Close the browser after you see the CA Certificate Installation page that informs you that The CA certificate chain has been successfully installed.

Configuring the Public DNS to Resolve the Names of the OWA, POP3 and IMAP4 Sites

Correct DNS host name resolution is critical in the design of a remote access solution. The ideal DNS configuration allows users who move between the internal and external network to be able to resolve host names to the correct addresses regardless of where they are currently located.

The ideal DNS configuration is the split DNS. A split DNS infrastructure consists of two zones that serve the zone domain and subdomains:

• An internal zone that is used only by internal network hosts
• An external zone that is used only by external network hosts

Internal network hosts who need to resolve names query an internal network zone and receive the internal network IP address of the host to which they want to connect. External network hosts query the external network zone and receive a public IP address to which they can connect. The destination machine may be the same for the external and internal hosts; they just take different routes to arrive at their common destination.

For example, your internal network domain to which the Exchange Servers belong to is domain.com. You publish the POP3, IMAP4 and OWA sites of the front-end server to the Internet using ISA Server 2000 and the ISA Server is using the IP address 131.107.0.1 to listen for incoming requests for those services. The front-end Exchange Server on the internal network has the IP address 10.0.0.3.

Your goal is to allow all hosts, regardless of their locations, to access the front-end Exchange Server using the FQDNs owa.domain.com, pop3.domain.com and imap4.domain.com. You want hosts on the internal network to connect directly to the front-end Exchange Server using the IP address 10.0.0.3 and you want remote hosts connecting from the Internet to use IP address 131.107.0.1 to access the front-end Exchange server.

The solution is to create entries on a publicly available DNS server for the domain.com domain. You can have a third party host your DNS services, or you can host them yourself. Regardless of who hosts these addresses, the DNS resource records for the domain.com domain on this publicly available DNS server contain the public addresses you want users to use to access resources. In the case of the published resources on the front-end Exchange Server, you should create three Host (A) records: one for owa.domain.com, one for pop3.domain.com and the last one for imap4.domain.com and all three of these should map to the IP address 131.107.0.1.

You should then create a second DNS server on the internal network behind the ISA Server firewall. The internal network DNS server also hosts a zone for the domain.com domain. You should create three Host (A) resource records on the internal network DNS server within the domain.com zone: one for owa.domain.com, one for pop3.domain.com and the last one for imap4.domain.com. The difference is that this time you map these three entries to 10.0.0.3.

External network hosts are assigned DNS server addresses that allow them to resolve names to public addresses. How these external hosts are assigned an IP address depends on where they are located. You usually have no control over the specific DNS server addresses that are assigned to your remote hosts. However, this is not a problem if you have registered your domain.com with an Internet Registrar and indicated the correct address for the publicly available authoritative DNS server for your domain; external hosts will have no problems resolving your public addresses correctly.

Internal network hosts can be assigned a correct DNS server address using DHCP. When a remote host moves into the internal network, it will receive new IP addressing information, including a DNS server address, from your DHCP server. When the host receives the IP address of your internal DNS server, it will be able to resolve the names associated with the front-end Exchange Server to its internal address.

Creating HOSTS File Entries on the External E-mail Client

The external e-mail client machine must be able to resolve the name of the front-end Exchange server to the name that is on the server’s Web site certificates. The name we assigned to the Web site certificate on the Web server is owa.msfirewall.org and the name on the POP3 and IMAP4 servers is mail.msfirewall.org. The e-mail client must be able to resolve these names to the IP address on the external interface of the ISA Server 2004 firewall that listens for incoming requests to the front-end Exchange server. In our current example, this is 192.168.1.70.

In a production environment, you should have a split DNS infrastructure that correctly resolves names for both internal and external network clients. We have not created a split DNS infrastructure in our example, so we will use a HOSTS file to resolve owa.msfirewall.org and mail.msfirewall.org to the correct IP address.

Perform the following steps to create the HOSTS file entry on the e-mail client machine:

1. Right click Start and click Explore.
2. Navigate to <system_root>\system32\drivers\etc and open the HOSTS file in Notepad.
3. In the HOSTS file, enter the following lines under the localhost entry:192.168.1.70 owa.msfirewall.org
   192.168.1.70 exchange2003be.msfirewall.org
4. Ensure that you press ENTER after you complete the line so that the insertion point is under the new line. Otherwise, the new entry won’t be recognized.

Close the HOSTS file and save the changes

Making the OWA, POP3 and IMAP4 connection

At this point, you are ready to configure the e-mail client to connect to the OWA Web site, and the Exchange Server’s POP3, IMAP4 and SMTP services. In each case, except the SMTP service connection, you will be able to create an SSL secured link. The SMTP connection can also be secured using SSL; however, we did not go through those procedures in this walkthrough.

You can obtain detailed step-by-step instructions on how to configure the Outlook Express E-mail clients by reviewing the client configuration information in client configuration chapters of the ISA Server 2000/Exchange Deployment Kit.

1. Configuring Outlook Express http://www.isaserver.org/img/upl/exchangekit/clientoe/clientoe.htm
   This article goes over all the details, step by step, on how to configure the Outlook Express email client to use secure and non-secure forms of SMTP, POP3 and IMAP4 to connect to the Exchange Server published behind the ISA Server firewall.
2. Configuring Outlook 2000 http://www.isaserver.org/img/upl/exchangekit/client2000/client2000.htm
   This article goes over all the details on how to configure the Outlook 2000 client to connect to the Exchange Server using secure and non-secure forms of SMTP and POP3. In addition, this document covers the unique configuration issues that must be addressed to allow a successful connection via secure Exchange RPC publishing.
3. Configuring Outlook 2002 http://www.isaserver.org/img/upl/exchangekit/client2002/client2002.htm
   In this article we discuss how to configure the Outlook 2002 clients to connect to the Exchange Server through ISA Server publishing rules. The discussion includes connecting the Outlook 2002 client to create secure and non-secure connections to the Exchange Server using the SMTP/POP3/IMAP4 and secure Exchange RPC protocols. Each procedure includes all the step by step details required to create the connection.
4. Configuring Outlook 2003 http://www.isaserver.org/img/upl/exchangekit/client2003/client2003.htm
   This article covers all the details, step by step, that you need to configure the Outlook 2003 client to create secure and non-secure SMTP/POP3/IMAP4/RPC and RPC over HTTP connections. Special attention goes into the details on how to configure the Outlook 2003 client to create the new RPC over HTTP connection to the Exchange 2003 server in a highly secure fashion.

Conclusion

In this document, we discussed the procedures required to publish a secure Microsoft Exchange RPC over HTTP Web site and provision the RPC over HTTP Web client for a secure connection. We also examined issues related to a split DNS infrastructure and how a split DNS infrastructure supports RPC over HTTP clients who move between the Internal and External networks.