ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
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. 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 frontend/back-end configuration, each user must know the name of the server that stores their
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. 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 client to another server. Exchange
supports this referral functionality when a public folder store on specific 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 to 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.
One of the putative advantages of the front-end/back-end configuration is that you can put the
front-end Exchange Server in a DMZ segment. I do not recommend this configuration because
the front-end Exchange Server must be a member of the internal network domain. A DMZ
segment typically represents a separate and distinct security partition. The integrity of the internal
network security partition is violated when extended into a DMZ segment. DMZ segments are
generally reserved for bastion host machines that are at relatively high risk of attack. Internal
network domain member computers do not typically fit into this category.
I recommend that you put both the front-end and back-end Exchange Servers on the internal
network and leverage the layer 7 security features provided by ISA Server 2000 and ISA Server
2000 Feature Pack 1.
You can make Outlook Web Access (OWA), secure POP3 and secure IMAP4 services available
to external network users (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.
The following procedures are required to allow your remote users to access Exchange email
services via the ISA Server 2000 firewall:
1 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration

















Install the Front End and Back End Exchange Servers
Install an enterprise CA on the internal network
Issue and bind certificates for the OWA, POP3 and IMAP4 sites
Export the OWA site certificate to a file
Configure the front end OWA site to force SSL encryption and basic authentication
Configure the OWA site to require a client certificate
Issue machine certificates to the front end and back end computer for IPSec security
Install Windows Server 2003 on the firewall computer
Install ISA Server 2000 on the firewall computer
Import the OWA site certificate on the ISA Server firewall computer’s machine certificate
store
Run the Outlook Web Access Publishing Wizard and create the HOSTS file entry
Review the Settings on the Incoming Web Requests listener and OWA Web Publishing
Rule
Install the URLScan filter on the ISA Server firewall computer
Configure the POP3 and IMAP4 sites to force SSL and create the secure POP3 and
IMAP4 Server Publishing Rules
Configure IPSec Policy to secure all communications between the front end and back
end servers
Configure the public DNS to resolve the names of the OWA, POP3 and IMAP4 sites
Install CA certificates on the OWA clients
While it might seem like there is an unwieldy number of steps, the entire procedure can be carried
out in just a couple hours.
The remainder of the ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document
discusses these procedures in detail.
Install the Front End and Back End Exchange Servers
The details of the front-end/back-end configuration are beyond the scope of this ISA Server 2000
Exchange Server 2000/2003 Deployment Kit document. Please refer to Microsoft Exchange
2000 Server Front-End and Back-End Topology for a detailed discussion of Exchange frontend/back-end deployments.
Configuring a machine to be a front-end server is quite easy. Open the Exchange System
Manager and expand the Servers node in the left pane of the console. Right click on your frontend server’s name and click the Properties command. On the General tag of the front-end
server’s Properties dialog box, put a checkmark on the This is front-end server checkbox
(figure 1).
Figure 1 (fig1)
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
2
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
Install an Enterprise CA on the Internal Network
An enterprise Certificate Authority (CA or Certificate Server) has several advantages over a
standalone CA. Two of the primary advantages of using an enterprise CA are that you can use
autoenrollment to automatically deploy machine and user certificates to all domain members. In
addition, you can use the Certificates MMC stand-alone snap-in to request and install a
certificate from an online enterprise CA.
You can install an enterprise CA on a domain member in the same domain as the front-end
Exchange Server and the ISA Server 2000 firewall. This configuration allows you to request Web
site certificates for the OWA, POP3 and IMAP4 sites from an online certificate authority and
install them immediately.
In addition, all Exchange Servers and the ISA Server 2000 firewall can request certificates from
the online enterprise CA and install them immediately. This simplifies the task of creating the SSL
link between the ISA Server 2000 firewall and the front-end Exchange Server as well as making it
easier to create a working IPSec Policy based on certificate authentication to secure the
communications between the front-end and back-end Exchange Servers.
Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document
Creating the enterprise CA for more information on how to create an enterprise CA and ISA
3 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
Server 2000 Exchange Server 2000/2003 Deployment Kit documents Issuing certificates via
the MMC snap-in and Issuing certificates via autoenrollment
Issue and Bind Site Certificates to the OWA, POP3 and IMAP4 Sites
Your goal is to provide secure remote access for remote OWA, POP3 and IMAP4 clients. You
can provide secure access by requiring clients to use SSL/TLS encryption when connecting to the
front-end Exchange Server. All communications moving through the secure channel are protected
by TLS encryption (including basic authentication credentials.)
Each published service requests a Web site certificate. The Web site certificate is placed in the
front-end server’s machine certificate store and bound to the Exchange Service its meant to
protect.
I recommend that you obtain a Web site certificate for the OWA site, and separate Web site
certificates for the POP3 and IMAP4 sites. For example, the OWA site certificate can use the
common name (CN) of owa.domain.com and your POP3 and IMAP4 certificates can use the CN
mail.domain.com. You can even use the mail.domain.com certificate to secure SMTP connection
if you wish to use the SMTP service on the front-end Exchange Server as an SMTP relay.
Note:
You can obtain an even higher level of control over the security of your secure sites by using
a different certificate for each site. For example, owa.internal.net, pop3.internal.net,
imap.internal.net and smtp.internal.net.
Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document
How to Obtain a Web Site Certificate for details on how to obtain, install and bind the Web site
certificate to the Exchange services you wish to publish.
Note:
It is critically important that the common name on the certificates is the same as the name the
external email client applications use to access the service. For example, remote browsers
must use the FQDN owa.domain.com when connecting to the OWA Web site when the name
on the certificate is owa.domain.com. External SMTP, POP3 and IMAP4 applications must be
configured with the name on the certificate used by those services. For example, if these
services use a certificate with the name mail.domain.com, then the SMTP, POP3 and IMAP4
clients must be configured to access the server using mail.domain.com; they can not use the
IP address of the published server or the IP address used by the external interface of the ISA
Server firewall that is used to publish the internal Exchange Server service.
Export the OWA Site Certificate to a File
The ISA Server 2000 firewall computer performs SSL to SSL bridging to provide from end to end
protection for the connection between the remote OWA client and front-end server on the internal
network. This end to end protection is important because the implicit assumption made by the
remote host is that if the initial connection requires a secure link, then the entire transaction is
protected.
SSL to SSL bridging allows the external Web browser to create an encrypted SSL link with the
external interface of the ISA Server 2000 firewall. The ISA Server firewall decrypts the packets
and inspects them for validity and drops all invalid packets. The ISA Server firewall then
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
4
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
establishes a second SSL session between its own internal interface and the front-end Exchange
Server and re-encrypts the packets and forwards them to the front-end Exchange server.
You can not use SSL to protect the communications between the front-end Exchange Server and
the back end servers. However, you can use IPSec transport mode connections to protect all
data moving between the front-end and back-end Exchange Servers. This meets the implicit
requirement for an end to end encrypted link.
The ISA Server 2000 firewall impersonates the front-end OWA Web site by presenting the OWA
Web site’s certificate to the remote OWA client. The name of the OWA Web site is contained in
the certificate; this is the mechanism of impersonation.
Perform the following steps to export the Web site certificate from the OWA server:
1. Click Start, point to Administrative Tools and click on Internet Information Services.
In the Internet Information Services (IIS) Manager console (figure 2), expand the Web
Sites node and click on the Default Web Site entry. Right click on Default Web Site and
click Properties.
Figure 2
2. Click on the Directory Security tab in the Default Web Site Properties dialog box
(figure 3). Click on the View Certificate button.
Figure 3
5 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
3. In the Certificate dialog box, click on the Details tab (figure 4). Click on the Copy to File
button.
Figure 4
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
6
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
4. Click Next on the Welcome to the Certificate Export Wizard page (figure 5).
Figure 5
7 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
5. Select the Yes, export the private key option on the Export Private Key page (figure
6). Click Next.
Figure 6
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
8
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
6. On the Export File Format page (figure 7), select the Personal Information Exchange
– PKCS #12 (.PFX) option. Put a checkmark in the Include all certificate in the
certification path if possible checkbox. Remove the checkmarks from the Enable
strong protection (requires IE 5.0, NT 4.0 SP4 or above) and Delete the private key
if the export is successful checkboxes.
The enable strong protection option requires user intervention before the certificate can
be used to establish a connection. The server on which the certificate is installed cannot
perform the required actions. That is why you must not select that option. You do not
want to delete the private key from the OWA site, because you want to keep the key
there for backup.
Click Next.
Figure 7
9 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
7. On the Password page, type a password and then confirm the password. This password
protects the private key from being stolen by anyone who might be able to obtain the
exported file (figure 8).
Figure 8
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
10
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
8. On the File to Export page (figure 9), type in a path and file name for the certificate file.
Remember where you store the file because you need to copy it to the ISA Server
machine in the DMZ. Click Next.
Figure 9
11 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
9. Review your settings on the Completing the Certificate Export Wizard page (figure 10)
and click Finish.
Figure 10
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
12
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
10. Click OK on the Certificate Export Wizard dialog box that informs you the export was
successful (figure 11).
Figure 11
13 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
11. Close the Certificate dialog box (figure 12).
Figure 12
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
14
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
12. Close the Default Web Site Properties dialog box (figure 13).
Figure 13
15 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
Configure the Front End OWA Site to Force SSL Encryption and Basic Authentication
The front-end server’s OWA Web site supports SSL connections as soon as the certificate is
bound to the site. However, users still have the option to connect to the site using a non-secure
connection. You can force both the ISA Server and internal users to use an SSL connection to
the OWA Web site directories by configuring those directories to require successfully negotiation
of an SSL link.
In addition, we want to force basic authentication on all OWA directories that the ISA Server will
make accessible to external users. This will allow you to take advantage of the ISA Server 2000
Feature Pack 1 feature that allows it to relay basic authentication credentials to the OWA site.
This prevents all non-authenticated communications from every reaching the OWA Web site and
significantly improves the level of security.
Perform the following steps to force an SSL connection to the OWA Web site directories:
1. Click Start, point to Administrative Tools and click on Internet Information Services.
In the Internet Information Services (IIS) Manager (figure 14), expand your server
name and then expand the Default Web Site node in the left pane of the console.
The three OWA Web site directories that you will make accessible to remote users are:
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
16
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
/Exchange
/ExchWeb
/Public
We want the ISA Server for always negotiate an SSL connection when proxying
communications between these directories and the remote OWA client.
Start by clicking on the Exchange directory so that it is highlighted and then right click on
an empty area in the right pane of the console. Click the Properties command.
Figure 14
2. Click on the Directory Security tab (figure 15). In the Authentication and access
control frame, click on the Edit button.
Figure 15
17 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
3. In the Authentication Methods dialog box (figure 16), remove the checkmark from all
checkboxes except for the Basic authentication (password is sent in clear text)
checkbox. Place a checkmark in the Basic authentication checkbox. Click Yes in the
dialog box that warns you that the credentials should be protected by SSL. Type in your
domain name in the Default domain text box.
Click OK.
Figure 16
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
18
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
4. Click Apply and then click OK in the Exchange Properties dialog box (figure 17).
Figure 17
19 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
5. Repeat these steps with the Exchweb and Public directories found in the left pane after
the console. Close the Internet Information Services (IIS) Manager console (figure 18)
when you have forced basic authentication on the Exchange, Exchweb and Public
folders.
Figure 18
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
20
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
The next step is to force the ISA Server’s Web Proxy service to use SSL when connecting to the
OWA directories. Perform the following steps to force all connections to the OWA directories to
successfully negotiate an SSL connection:
1. Click Start, point to Administrative Tools and click on Internet Information Services.
In the Internet Information Services (IIS) Manager (figure 19), expand your server
name and then expand the Default Web Site node in the left pane of the console.
Now you will force an SSL connection on the directories the remote OWA users will
access though the ISA Server. These directories are:
/Exchange
/Exchweb
/Public
Click on the Exchange node in the left pane of the console to highlight it. Right click on
an empty area in the right pane of the console and click the Properties command.
Figure 19
21 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
2. Click on the Directory Security tab in the Exchange Properties dialog box (figure 20).
Click the Edit button in Secure communications frame.
Figure 20
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
22
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
3. In the Secure Communications dialog box (figure 21), put a checkmark in the Require
secure channel (SSL) checkbox. Put a checkmark in the Require 128-bit encryption
checkbox. Click OK.
Figure 21
23 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
4. Click Apply and then click OK on the Exchange Properties dialog box (figure 22).
Figure 22
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
24
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
5. Repeat the procedure to force an SSL connection on the Exchweb and Public
directories in the left pane of the console. Close the Internet Information Services (IIS)
Manager console after forcing SSL on the Exchange, Exchweb and Public directories.
Configure the OWA Site to Require a Client Certificate (optional)
You can further enhance the security provided to the connections clients make to the OWA
directories by requiring a client certificate to connect to the OWA directories. The OWA client not
only must provide user credentials via basic authentication, but must also present a client
certificate to the front-end server. If you have internal network clients that must access the frontend server via OWA, you can assign these internal network clients user certificates via group
policy.
The ISA Server does not have a logged on user that presents a certificate to the OWA Web site
directories. Instead, you obtain a certificate for the Web Proxy service and then import that
certificate into the ISA Server 2000 Web Proxy service’s Personal\Certificates certificate store.
You then configure the OWA Web Publishing Rule to present a client certificate to the OWA Web
site after the certificate is imported into the Web Proxy service’s certificate store.
Please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document
Increasing OWA Security by Configuring the ISA Server to Present a Client Certificate to
an OWA Web site for detailed information on how to configure the OWA Web site to require a
25 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
user certificate and how to configure the ISA Server’s Web Proxy service to present a user
certificate to the OWA site.
Issue Machine Certificates to the Front End and Back End Exchange Servers for IPSec
Security
Remote OWA clients that establish a secure SSL link with the ISA Server have the implicit
expectation that the connection is secure from end to end. While the connections between the
OWA client and ISA Server, and the ISA Server and the front-end server, are secured with SSL
encryption, the connections between the front-end server and the back-end servers cannot be
secured with SSL.
You can set up IPSec Policies that create a secure transport mode IPSec connection between
the front-end and back-end Exchange Servers. Assign these machines certificates to confer a
higher level of authentication security. You can use either Group Policy-based autoenrollment to
assign the front-end and back-end Exchange Server’s machine certificates, or you can use the
Certificates mmc standalone snap-in.
Please review ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents
Issuing Certificates via the MMC Snap-in and Issuing certificates via autoenrollment for
detailed information on how to assign machine certificates via autoenrollment and the
Certificates mmc snap-in.
Install Windows Server 2003 on the Firewall Computer
The computer that will become the ISA Server 2000 firewall relay must meet the following
minimum requirements:






A personal computer with a 1.5 MHz or higher Intel/AMD-compatible CPU
For the operating system, Windows 2000 Service Pack 4 or Windows Server 2003
256 MB of memory (RAM)
20 MB of available hard disk space for program files
Two network adapters that is compatible with Windows 2000 or Windows Server 2003 ,
for communication with the internal and external networks
One local hard disk partition that is formatted with the NTFS file system for log files and
Web caching (if you wish to run the ISA Server firewall’s Web caching facilities)
The ISA Server firewall and Web caching components work very well on modest hardware. This
is true even when the SMTP filter is enabled and protecting the published SMTP servers.
However, if you run decide to use the SMTP Message Screener on the firewall, or if you use SSL
to protect Web Published Web site, or if you use the ISA Server firewall as a VPN server, you
need to increase the minimum requirements to support encryption services.
Install ISA Server 2000 on the Firewall Computer
Install ISA Server 2000 after installing Windows Server 2003 onto the firewall computers. You
must go through some specific procedures outside of the standard ISA Server 2000 installation
when installing the firewall software onto a Windows Server 2003 computer. Please refer to ISA
Server 2000 Exchange Server 2000/2003 Deployment Kit document Installing ISA Server
2000 on Windows Server 2003.
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
26
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
Import the OWA Web Site Certificate into the ISA Server Firewall’s Machine Certificate
Store
Now that the ISA Server software is installed, you’re ready to copy the Web site certificate file
from the front-end Exchange server to the ISA Server computer. This certificate is imported into
the ISA Server’s machine certificate store and then bound to the Incoming Web Requests
listener.
Perform the following steps to import the OWA server’s Web site certificate into the ISA Server’s
machine certificate store:
1. Click Start and click on the Run command. Type 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 (figure 23).
Figure 23
2. Click the Add button in the Add/Remove Snap-in dialog box (figure 24).
Figure 24
27 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
3. Click on the Certificates entry in the Available Standalone Snap-in list on the Add
Standalone Snap-in dialog box (figure 25). Click Add.
Figure 25
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
28
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
4. Select the Computer account option on the Certificates snap-in page (figure 26). Click
Next.
Figure 26
29 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
5. On the Select Computer page, select the Local computer: (the computer this
console is running on) option and click Finish (figure 27).
Figure 27
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
30
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
6. Click Close on the Add Standalone Snap-in page (figure 28).
Figure 28
31 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
7. Click OK on the Add/Remove Snap-in dialog box (figure 29).
Figure 29
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
32
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
8. Right click on the Personal node in the left pane of the console, point to All Tasks and
click Import (figure 30).
Figure 30
33 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
9. Click Next on the Welcome to the Certificate Import Wizard (figure 31).
Figure 31
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
34
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
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 (figure 32).
Figure 32
35 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
11. On the Password page, type in the password for the file (figure 33). Do not put a
checkmark in the Mark this key as exportable. This will allow you to back up or
transport you keys at a late time checkbox. The reason is that this machine is a bastion
host with an interface in a DMZ or on the Internet and may be compromised. The
compromiser may be able to steal the private key from this machine if it is marked as
exportable.
Click Next.
Figure 33
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
36
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
12. On the Certificate Store page (figure 34), confirm that the Place all certificate in the
follow store option is select and that is says Personal in the Certificate store box. Click
Next.
Figure 34
37 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
13. Review the settings on the Completing the Certificate Import page and click Finish
(figure 35).
Figure 35
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
38
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
14. Click OK on the Certificate Import Wizard dialog box informing you the import was
successful (figure 36).
Figure 36
39 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
15. You will see the Web site certificate an the CA certificate in the right pane of the console.
The Web site certificate has the FQDN that is assigned to the Web site. This is the name
external users will 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 on the Web site certificate in the right pane of the console (figure 37).
Figure 37
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
40
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
16. Click on the Certification Path tab on the Certificate dialog box (figure 38). Notice the
red “x” on the CA certificate node. This indicates that this machine does not trust the CA
that issued the Web site certificate. In order to use this certificate to perform SSL to SSL
bridging, this machine must trust the CA that issued the Web site certificate.
Close the Certificate dialog box.
Figure 38
41 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
17. Right click on the CA certificate in the right pane of the console and click the Copy
command (figure 39).
Figure 39
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
42
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
18. Expand the Trusted Root Certification Authorities node and click the Certificates
node (figure 40). Right click on the Certificates node and click the Paste command. This
pastes the CA certificate into the Trusted Root Certificate Authorities\Certificates
store and allows this machine to trust certificates issued by this CA.
Figure 40
43 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
19. Press F5 to refresh the display. You should see the certificate appear in the right pane of
the console (figure 41). If you do not see the CA certificate in the right pane of the
console, repeat the procedure
Figure 41
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
44
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
20. Return to the Personal\Certificates node in the left pane of the console and double click
on the Web site certificate. In the Web site certificate’s Certificate dialog box, click on the
Certification Path tab (figure 42). Notice that the red “x” no longer appears on the CA
certificate. Click OK on the Certificate dialog box.
Figure 42
45 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
21. Close the mmc console (figure 43). You may want to save this console with the name of
certificates and store it in the Administrative Tools menu.
Figure 43
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
46
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
Run the Outlook Web Access Web Publishing Wizard and Create a HOSTS File Entry
One of the very nice improvements ISA Server Feature Pack 1 adds is the Outlook Web Access
Publishing Wizard. The OWA Publishing Wizard does most of the work required to publish an
OWA site on the internal network. In fact, the OWA Publishing Wizard can configure the
Incoming Web Requests listener to use the Web site certificate. We went through that process
manually so that you have a better idea of how it works, which will aid in troubleshooting SSL
related problems if they occur.
Perform the following steps to create the OWA Web Publishing Rule:
1. Open the ISA Management console (figure 44). Expand the Server and Arrays node
and then expand your server name. Expand the Publishing node and click on the Web
Publishing Rules node. Right click on the Web Publishing Rules node, point to New
and click Publish Outlook Web Access Server.
Figure 44
47 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
2. Type in a name for the rule in the Outlook Web Access Server rule name text box on
the Welcome to the Outlook Web Access Publishing Wizard page (figure 45). Click
Next.
Figure 45
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
48
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
3. On the Name of Published Server page (figure 46), type in the FQDN of the OWA site
in the Internal name or IP address of the Outlook Web Access Server. This
information is used to forward the incoming request to the internal OWA server. You can
use the IP address of the internal server, or the IP address of the external interface of the
firewall protecting the internal OWA server if you are using reverse NAT to publish the
OWA server.
I prefer to use the actual FQDN that the external user uses to connect to the site. This
makes the Web Proxy logs easier to interpret. You can create a HOSTS file entry on the
ISA Server that resolves this name to the IP address you want the incoming request
forwarded to.
Put a checkmark in the Use an SSL connection from the ISA Server to the Outlook
Web Access Server checkbox. This forces the ISA Server to establish an SSL link
between itself and the OWA server. All communications between the ISA Server and the
OWA server are protected by SSL.
Click Next.
Figure 46
49 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
4. On the Listeners page (figure 47), enter the URL that the external users will use to
connect to the OWA site. Because we are forcing an SSL connection between the
external client and the ISA Server, we use the URL https://owa.internal.net.
Click Next.
Figure 47
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
50
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
5. On the Secure Connection from Client page (figure 48), put a checkmark in the Enable
SSL. Client must use SSL to connect to the ISA Server checkbox. Click the Select
button.
Select the Web site certificate in the Select Certificate dialog box. Click OK.
Figure 48
51 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
6. The Web site certificate appears in the Certificate frame (figure 49). Click Next.
Figure 49
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
52
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
7. Review the settings on the Completing the Outlook Web page and click Finish (figure
50).
Figure 50
53 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
8. Select the Save the changes and restart the service(s) option on the ISA Server
Warning dialog box (figure 51), and click Finish.
Figure 51
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
54
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
Review the Settings on the Incoming Web Requests Listener and the OWA Web Publishing
Rule
Let’s now examine the changes the OWA Web Publishing Rule Wizard made to the Incoming
Web Requests listener and the details of the Web Publishing Rule.
Perform the following steps to review the changes to the Incoming Web Requests listener:
1. Open the ISA Management console and expand the Servers and Arrays node (figure
52). Right click on your server name and click the Properties command.
Figure 52
55 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
2. In the server’s Properties dialog box (figure 53), click on the Incoming Web Requests
tab. Notice that the Configure listeners individually per IP address has been selected.
This option allows the Incoming Web Requests listener to listen on a specific IP
address instead of all addresses bound to the external interface of the ISA Server.
The Enable SSL listeners checkbox has been enabled. This allows the Incoming Web
Requests listener to accept inbound SSL connection requests. The SSL port is set for
TCP port 443.
Select the listener entry and click the Edit button.
Figure 53
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
56
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
3. The Outlook Web Access Publishing Wizard has configured the listener to use the
primary address bound to the external interface on the ISA Server. Integrated
authentication is enabled by default. The Use a server certificate to authenticate to
web clients option is selected and the OWA Web site’s certificate is bound to the
listener.
The remote OWA client will use only basic authentication when communicating with the
ISA Server. Put a checkmark in the Basic with this domain checkbox (figure 54).
Figure 54
57 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
4. Click Yes on the ISA Server Configuration dialog box warning you that basic
credentials are sent in the clear (figure 55).
Figure 55
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
58
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
5. Enter the name of your domain in the Domain Name text box on the Select Domain
dialog box (figure 56) and click OK.
Figure 56
59 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
6. Remove the checkmark from the Integrated checkbox. You want the remote OWA
clients to use only basic authentication and not try to negotiate integrated authentication
(figure 57). Click OK.
Figure 57
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
60
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
7. Select the Save the changes and restart the service(s) option and click OK (figure 58).
Figure 58
61 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
8. Click OK in the server’s Properties dialog box (figure 59).
Figure 59
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
62
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
The Outlook Web Access Web Publishing Wizard created a Web Publishing Rule allowing the
ISA Server to forward incoming requests to owa.internal.net to the OWA server on the internal
network. Note that the FQDN in the request is critical. The FQDN must match exactly the name
on the Web site certificate. The client will not be able to establish an SSL link to the Incoming
Web Requests listener if there is a mismatch between the FQDN the client uses to access the
OWA server, the FQDN of the server in the Destination Set and the name of the OWA server on
the certificate.
Let’s look at some of the details of the Web Publishing Rule created by the Wizard and tune it up
a bit:
1. In the ISA Management console (figure 60), expand your Servers and Arrays node and
expand your server name. Expand the Publishing node and click on the Web
Publishing Rules node. Double click on the OWA Web publishing rule you created.
Figure 60 (fig60)
63 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
2. Click on the Destinations tab (figure 61). Notice that the This rule applies to option is
set to Selected destination set. The name of the Destination Set is listed in the Name
drop down list. The specific destinations included in this Destination Set are seen in the
Destinations included in set list.
These destinations include the FQDN of the OWA server and the directories that external
users are allowed to access. These path entries are:
/exchweb*
/public*
/exchange*
The wildcard entry at the end of the path indicates that the external client can access all
files and folders under the exchweb, public and exchange folders.
Figure 61
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
64
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
3. Click on the Action tab. Notice that the Redirect the request to this internal Web
server (name or IP address) option is selected (figure 62). The FQDN of the OWA site
is entered into the text box under this option. This FQDN must resolve to an IP address
that can accept incoming requests to the OWA site. We will create a HOSTS file entry
later that insures that the requests are forwarded correctly.
The Send the original host header to the publishing server instead of the actual
one (specified above) check is enabled. Do not disable this checkbox.
Put a checkmark in the Allow delegation of basic authentication credentials
checkbox. This allows the ISA Server to forward the basic authentication credentials to
the OWA site on the internal network. This allows only authenticated connections to be
made to the OWA site. If the client is not authenticated, no packets are forwarded to the
internal site.
Figure 62
65 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
4. Click on the Bridging tab (figure 63). In the Redirect HTTP requests as frame has the
SSL requests (establish a secure channel to the site) option select. This setting will
be ignored because all connections must be SSL; no non-SSL connections will be
accepted.
The SSL requests (establish a new secure channel to this site) option is select in the
Redirect SSL requests as) frame. This setting insures that SSL requests are bridged as
SSL requests (SSL to SSL bridging). The external client establishes an SSL connection
with the ISA Server, then the ISA Server establishes a new SSL connection with the
OWA site on the internal network.
Put a checkmark in the Require secure channel (SSL) for published site checkbox.
This setting forces the external client to successfully negotiate an SSL connection. If the
client cannot negotiate an SSL link, the connection is dropped. Put a checkmark in the
Require 128-bit encryption checkbox if you know that all your OWA clients support 128bit (almost all Microsoft clients now support 128-bit encryption).
You do not need to select the Use a certificate to authenticate to the SSL Web server
checkbox. This is only required if you want to require the ISA Server to use a client
certificate to authenticate to the OWA web site. This feature increases security by forcing
the ISA Server to present a client certificate to the OWA server before it can connect to it.
We will not cover this procedure in this ISA Server 2000 Exchange Server 2000/2003
Deployment Kit document.
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
66
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
Figure 63
Notice that the Web Publishing Rule uses the name of the OWA server, owa.internal.net, in the
redirect. This FQDN must resolve to an IP address that can reach the OWA server. If you are
routing between the DMZ and the internal network, the FQDN must resolve to the actual IP
address of the OWA server. If you are performed reverse NAT between the OWA server and the
DMZ (such as a Server Publishing Rule in ISA Server 2000), then the FQDN must resolve to the
address of the external interface of the firewall on the edge of the private network.
You can configure a DNS server to support DMZ hosts, or you can use a HOSTS file on the Web
ISA Server to forward the requests to the correct IP address.
Perform the following steps to create the HOSTS file on the ISA Server:
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 the Notepad entry and click OK.
3. The hosts file is opened in Notepad. Put 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.internal.net, then you would put in the following entry:
131.107.0.2
owa.internal.net
67 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
Where “131.107.0.2” is the IP address on the external interface of the internal network
firewall that is publishing the internal network OWA site, and owa.internal.net is the entry
in the Web Publishing Rule for the redirection. Make sure you press ENTER after you put
this line into the hosts file so that there is an empty line at the end of the file.
4. Close Notepad and click OK to save the changes made to the file.
Install the URLScan Filter on the ISA Server 2000 Firewall Computer
The URLScan filter is an optional component of the ISA Server 2000 Feature Pack 1. This
version of URLScan installs directly on the ISA Server 2000 firewall computer. Like the version of
URLScan that installs on the Web server, the Feature Pack 1 version of URLScan examines
incoming HTTP connections for invalid commands and requests. Validity is determined by the
settings in the urlscan.ini file.
You can download the ISA Server 2000 Feature Pack 1 version of URLScan from the ISA Server
2000 Feature Pack 1 Web site. Download the isafp1ur.exe file from the site and run the
installation program. Follow the onscreen instructions. If you are not familiar with the URLScan
tool, review the readme file before installing.
Be sure to installing URLScan on the ISA Server 2000 firewall using the OWA template. The
installation Wizard will ask you to make this decision during the course of installation.
Configure the POP3 and IMAP4 Sites to Force SSL and Create the Secure POP3 and IMAP4
Server Publishing Rules
Remote users can access the front-end Exchange server using POP3 and IMAP4 email clients.
While this email clients don’t offer the same rich experience provided by OWA or the full MAPI
Outlook client, POP3 and IMAP4 allow users almost universal access to their messages.
The challenge to POP3 and IMAP4 remote access is that it needs to be done securely. You can
force secure communications between the POP3/IMAP4 client and the front-end Exchange
server by forcing SSL/TLS security on the connection. The security protects both the user’s log
on credentials an the data moving through the secure channel.
For a detailed explanation on how to create and publish secure POP3 and IMAP4 sites, please
refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit documents
Exchange 2003 POP3/Secure POP3 publishing and Secure Exchange 2003 IMAP4/IMAP4
publishing
Configure IPSec Policy to Secure All Communications Between the Front End and Back
End Servers
The link between the OWA client and the external interface of the ISA Server firewall is protected
by SSL encryption. In addition, the link between the internal interface of the ISA Server firewall
and the front-end Exchange Server is protected by SSL encryption. The problem is that the link
between the front-end and back-end Exchange Server is not protected by SSL encryption. You
can not use SSL between the front-end and back-end Exchange servers.
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
68
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
You can solve this problem by creating IPSec Policies to force a secure, encrypted link between
the front-end and back-end Exchange servers. The IPSec encrypted link protects the messages
moving between the front-end and back-end and provides the end to end encryption the OWA
client implicitly expects when it creates the secure link with the external interface of the ISA
Server.
There are several ways you can implement IPSec Policies. The two most popular methods are to
create a Group Policy-based security policy and deploy IPSec Policies via domain group policy.
Another method available to you is to use local security policy on the front-end and back-end
Exchange servers.
There are several ways to enforce authentication between the front-end and back-end Exchange
Servers when they establish their IPSec links. In this following example we assume that the frontend and back-end Exchange Servers have received machine certificates from the same CA. We
will use certificate authentication as the preferred authentication method when establishing the
IPSec Policy.
Perform the following steps to create the IPSec transport mode secure connection between the
front-end and back-end Exchange Servers:
1. Go to the front-end Exchange Server, click Start, point to Administrative Tools and click
on Local Security Settings. In the Local Security Settings console, click on the IP
Security Policies on Local Computer node in the left pane of the console. Right click
on an empty area in the right pane of the console and click the Create IP Security
Policy command (figure 64).
Figure 64
69 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
2. Click Next on the Welcome to the IP Security Policy Wizard page (figure 65).
Figure 65
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
70
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
3. On the IP Security Policy Name page (figure 66), give the policy a name in the Name
text box. Enter an optional description for the policy in the Description text box. Click
Next.
Figure 66
71 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
4. On the Requests for Secure Communication page (figure 67), remove the checkmark
from the Activate the default response rule checkbox and click Next.
Figure 67
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
72
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
5. On the Completing the IP Security Policy Wizard page (figure 68), put a checkmark in
the Edit properties checkbox and click Finish.
Figure 68
73 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
6. The Properties dialog box for the policy appears (figure 69). Keep in mind that a security
policy consists of a set of rules. If any of the conditions we set in any of the rules matches
a connection, then the settings of the rule are triggered. The only rule included in the
policy at this point is the default response rule, but it is not selected and we will not select
it. Instead, we will add our own rule. Make sure that there is a checkmark in the Use Add
Wizard checkbox and click the Add button.
Figure 69
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
74
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
7. Click Next on the Welcome to the Create IP Security Rule Wizard page (figure 70).
Figure 70
75 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
8. We are creating a transport mode connection between the front-end and back-end
Exchange Servers. Therefore, on the Tunnel Endpoint page select the This rule does
not specify a tunnel option (figure 71).
Figure 71
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
76
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
9. Select the All network connections option on the Network Type page (figure 72). Click
Next.
Figure 72
77 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
10. An IP filter list contains IP addresses, computer names, or network IDs and protocol
information. When a connection matches a connection specified in the IP filter list, then a
filter action is applied. In this example we will create an IP filter list that contains the
source IP address being the back-end Exchange Server and the destination IP address
being the front-end Exchange Server. We will also configure the IP filter list to match all
protocol connections inbound from the back-end Exchange Server to the front-end
Exchange Server.
On the IP Filter List page, click the Add button (figure 73). In the IP Filter List dialog
box, type a name for the filter list in the Name text box. Type an optional description in
the Description text box. To add filters to the list, make sure there is a checkmark in the
Use Add Wizard checkbox and click the Add button.
Figure 73
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
78
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
11. Click Next on the Welcome to the IP Filter Wizard page (figure 74).
Figure 74
79 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
12. On the IP Filter Description and Mirrored property page (figure 75), type in a
description of the filter in the Description text box. You should enter information about
the nature of the filter, such as the source and destination addresses and the protocols.
In our example, we have a single front-end and back-end Exchange Server, so we’ll just
call it OWA.
Put a checkmark in the Mirrored. Match packets with the exact opposite source and
destination addresses option. This will allow the trigging of the filter action when
packets moving in the opposite direction as specified in the filter as detected by the
IPSec Policy Agent.
Figure 75
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
80
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
13. On the IP Traffic Source page (figure 76), select the A specific IP Address option in
the Source address drop down list. In the IP Address text box, type in the IP address of
the back-end Exchange Server. You will have to repeat the step if you have multiple
back-end Exchange Servers. Click Next.
Figure 76
81 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
14. On the IP Traffic Destination page (figure 77), select the My IP Address option from the
Destination address drop down list. Click Next.
Figure 77
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
82
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
15. On the IP Protocol Type page (figure 78), left the default setting of Any in the Select a
protocol type drop down list. We want to match all packets moving between the frontend and back-end Exchange Servers, so we match all protocols with this filter list entry.
Click Next.
Figure 78
83 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
16. Do not put a checkmark in the Edit properties checkbox, then click Finish on the
Completing the IP Filter Wizard page (figure 79).
Figure 79
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
84
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
17. The IP filter that matches all protocols for communications between the front-end and
back-end Exchange Server. You have completed the configuration of the IP filter list that
matches the packets moving between the front-end and back-end Exchange Server.
Click OK to continue create the rule that secures the connection between the front-end
and back-end Exchange Servers (figure 80).
Figure 80
85 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
18. On the IP Filter List page (figure 81), select the IP filter list you created in the IP Filter
lists box. Click Next.
Figure 81
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
86
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
19. On the Filter Action page (figure 82), select the Require Security option from the Filter
Actions list.
When a packet matches the source and destination, as well as protocol included in the
filter list, then a Filter Action is triggered. We are creating a rule that includes a filter list
we created that matches all protocol packets between the front-end and back-end
Exchange Servers. When packets match these conditions, then the Filter Action is
applied. The Require Security filter action will require that all packets moving between
the front-end and back-end Exchange Server are security with IPSec encryption.
Click Next.
Figure 82
87 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
20. On the Authentication Method page (figure 83), you can choose from Active Directory
default (Kerberos V5 protocol), Use a certificate from this certification authority
(CA) and Use this string to protect the key exchange (preshared key) options.
You and use the Active Directory default option if the front-end and back-end machines
belong to the same domain. You can enhance security by using the Use a certificate
from this certification authority (CA) option. The front-end and back-end Exchange
Server must have machine certificates from the same CA (or in a more complex
environment, trust the CAs that issued each other’s machine certificates).
In the current example, we have already deployed machine certificates to both the frontend and back-end Exchange Servers, so select the Use a certificate form this
certification authority (CA) and click Browse.
Figure 83
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
88
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
21. On the Select Certificate dialog box (figure 84), find the CA certificate for your root CA
on the internal network and select it. Then click OK.
Figure 84
89 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
22. The CA information appears in the text box. Click Next.
Figure 85
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
90
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
23. Put a checkmark in the Completing the Security Rule Wizard checkbox and click
Finish.
Figure 86
91 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
24. Click OK on the New Rule Properties dialog box (figure 87).
Figure 87
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
92
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
25. On the Properties dialog box for the policy, click the General tab. You can change the
Name and the Description for this rule on this tab (figure 88). You can click the Settings
button and change core characteristic of the how key exchange is performed. Click OK.
Note:
Details of IPSec negotiation and policy as beyond the scope of this ISA Server 2000 Exchange
Server 2000/2003 Deployment Kit document. Please refer to Deploying IPSec on the Microsoft
TechNet site.
Figure 88
93 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
26. You will need to repeat the procedure on the back-end Exchange Servers. The only
difference between the policy you created on the front-end Exchange Sever and the
back-end Exchange Servers is few settings in the IP Filter. Figure 89 shows the IP
Traffic Source page of the IP Filter Wizard. On the back-end Exchange Servers, make
sure you use the back-end Exchange Server’s address in the source address text box.
Figure 89
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
94
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
27. The Destination address on the back-end Exchange Servers is set for My IP address
(figure 90).
Figure 90
95 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
28. The protocol type on the back-end Exchange Server’s is Any. Again, the same as what
we did with the front-end Exchange Servers (figure 91).
Figure 91
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
96
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
29. After the IPSec Policies are created on the front-end and back-end Exchange Servers,
right click on the policy you created to secure communications between the front-end and
back-end Exchange Servers and click the Assign command (figure 92).
Figure 92
97 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
30. When the policy is assigned, you will see a Yes entry in the Policy Assigned column
(figure 93).
Figure 93
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
98
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
31. You can test the policy by opening a command prompt and typing the command:
ping –t w.x.y.z
where w.x.y.z is the IP address of another Exchange Server included in the IP filter list.
You will see the ping command report that it is negotiating IP Security and then you will
see ping replies. You can see details of the IPSec negotiation and packet exchange by
using the IP Security Monitor standalone mmc console snap-in (figure 91).
Figure 91
99 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
Configure the Public DNS to Resolve the Names of the OWA, POP3 and IMAP4 Sites
Correct DNS host name resolution is critical when designing 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 address 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 queries an internal network zone and receive
the internal network IP address of the host they want to connect to. External network hosts query
the external network zone and receive a public IP address they can connect to. 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. Your 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
Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration
100
ISA SERVER 2000 EXCHANGE 2000/2003 DEPLOYMENT KIT
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 location, 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 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 a 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 your want users to use to access
resources. In the case of the published resources on the front-end Exchange Server, you would
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 map to the IP address 131.107.0.1.
You then create a second DNS server, this one being on the internal network behind the ISA
Server firewall. The internal network DNS server also hosts a zone for the domain.com domain.
You 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 a DNS server address that allows 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 address that’s 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, then 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, then it will be able to resolve the names associated with the front-end
Exchange Server to its internal address.
Install the CA Certificate on the OWA, POP3 and IMAP4 Clients
You must install the root CA certificate of the certificate authority that assigned the front-end
Exchange Server’s services their certificates onto the remote OWA, POP3 and IMAP4 clients.
There are a number of ways to do this. Please refer to the ISA Server 2000 Exchange Server
2000/2003 Deployment Kit document How to Import the Root CA Certificate into Email
Client Certificate Stores
.
101 Publishing Secure Outlook Web Access, POP3 and IMAP4 Services in an Exchange Front
End/Back End Configuration