Configuring Mail Services on the ISA Server | The Best Damn Firewall Book Period

We get a tremendous number of questions on ISAServer.org and in the Microsoft newsgroups regarding how to configure and publish mail services on the ISA server. In the vast majority of cases we're not able to give any detailed level of information because of the number of factors you have to take into consideration when running mail services on the ISA server. We're usually able to throw out a quick tip, but not much more.

At the time of this writing, there is little or no documentation on the specific procedures you must carry out to install mail services on the ISA server. There is isolated information here and there, but nothing you can really use to create an integrated and working solution. This chapter solves this problem by giving you complete step-by-step working examples of how to carry out mail services publishing on the ISA server. You'll also learn about both common and obscure issues that might cause your mail services to perform poorly.

In this section we'll cover the following topics:

Publishing the IIS SMTP Service on the ISA server
Configuring the Message Screener on the ISA server
Publishing Exchange Server services on the ISA server
Publishing Outlook Web Access on the ISA server

If you've been wondering about the secrets of mail services publishing on the ISA server, then move ahead and see that veil of secrecy removed!

Publishing the IIS SMTP Service on the ISA Server

Many ISA Server administrators would like to take advantage of the IIS SMTP service on the ISA server for a number of reasons:

They want to use the IIS SMTP service as a plain mail relay.
They want to use the IIS SMTP service as a mail and spam-whacking relay using the ISA Server Message Screener.
They are running Web sites on the ISA server that depend on a local SMTP service.
They want to use the SMTP service on the ISA server to stop outgoing mail from containing attachments or keywords by using the SMTP Message Screener.
They want to use the SMTP service on the ISA server as your smart host to take the burden of name resolution off your internal network mail server.

Should you publish the SMTP service on the ISA server? Again, it depends on the level of security you require. There is no problem with putting the SMTP services on the ISA server if you have light security requirements. You might want to consider removing all extraneous services from the ISA server if you have high security requirements,

Configuring the SMTP Service

Let's go through the steps required for configuring the SMTP services on the ISA server. In this scenario, ISA Server is already installed on the computer. The machine is a member of the internal network domain and it sits at the edge of the network. No Windows Internet Naming Service (WINS) or Domain Name Service (DNS) services are installed on the machine. It will function as an SMTP relay for the Exchange 2000 server setting on the internal network.

Perform the following steps to configure the IIS SMTP service on the ISA server:

Open a command prompt and type netstat –na | find ":25". If socket pooling for the SMTP service is enabled, you'll see an entry for TCP 0.0.0.0:25. You'll have to disable socket pooling before you can publish the SMTP server (Figure 28.1).

Figure 28.1: Checking for SMTP Service Socket Pooling
There are two ways to disable socket pooling on the ISA server. You can use the mdutil utility or the metaedit utility. The mdutil utility can be found at the www.isaserver.org site or at ftp.tacteam.net/isaserver. The metaedit utility can be found at the Microsoft Web site (Q232068). The metaedit utility provides a nice GUI interface, and the Q article gives detailed instructions on how to use the metaedit program. We'll go over using the mdutil utility is this section because we have the most experience with this utility and know that it works flawlessly.
Stop the SMTP service. At the command prompt, type net stop smtpsvc and press Enter.
Download the mdutil utility and place it in the root of the C: drive (actually, you can put it anywhere you want; we are placing it in the root of C: to make this example easier to follow). Type the following command at the command prompt:
```
mdutil set -path smtpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1
```
Now press Enter. The /1 indicates that socket pooling is disabled for the first virtual SMTP server. In this example, we're only covering a single virtual server. If you plan to run multiple virtual SMTP servers, you'll need to repeat the command with the /2, /3, and so on.
From the Administrative Tools menu, open the Internet Services Manager. Expand your server name. Right-click on the Default SMTP Virtual Server (Stopped) entry and click Properties.
On the General tab, use the IP address drop-down list to select the address on the internal interface. Place a check mark in the Enable logging check box.

If you select the W3C Extended Log File Format option, then click Properties and click on the Extended Properties tab. We recommend selecting all options for the highest level of logging, because SMTP security issues tend to be quite common. Make sure you have plenty of disk space on the drive on which you're storing the log files, and that you archive those log files on a regular basis. You can configure where the log files are stored by clicking on the General Properties tab and changing the Log file directory entry. Leave the Log Files dialog box and click on the Access tab.
On the Access tab, click Authentication in the Access control frame. You want to allow for anonymous access because this machine is acting as an SMTP relay. Internet SMTP servers will not be able to forward mail to your SMTP relay if you force authentication.

You can force Transport Layer Security (TLS) encryption between an external SMTP client and the SMTP service by binding a certificate to the SMTP service and forcing TLS. This will not work in our current scenario, because the SMTP relay must be able to accept mail from all hosts, and most of those hosts don't support TLS sessions. The Connection control button allows you to control which hosts are able to connect to the SMTP service. Again, because this machine is configured as an SMTP relay, you can't set IP address restrictions; you want all SMTP servers on the Internet to be able to forward mail to your SMTP service. However, you do not want all servers on the Internet to use your SMTP server as an open relay. Click Relay in the Relay restrictions frame to begin solving this problem.
It's very important to tightly restrict which domains can be relayed through your SMTP service. You will be quickly blacklisted if you run an open mail relay. Unlike services such as SpamCop, legitimate Real-time Black Hole Lists (RBLs) search for open mail relays. Spammers can hijack an open mail relay and forward literally gigabytes of spam. Select the Only the list below option in the Relay Restrictions dialog box. The default setting has no entries in the list. Leave it this way so that no one is able to use the SMTP server as a generic mail relay server.

If you want to use the SMTP server as a generic outbound mail relay, you can add the IP address of your internal network's mail server to the list of addresses that can relay through the default SMTP virtual server. Click Add to add the internal network mail server. In the Computer dialog box, select the Single computer option and add the IP address of your internal network's mail server. Click OK. You'll see that the computer is granted permission to relay through the SMTP server (Figure 28.2). Note that the Allow all computers which successfully authenticate to relay, regardless of the list above option is checked. This isn't much use to us in the SMTP relay configuration we're using here. Click OK to complete the Relay Restrictions section.

Figure 28.2: Allowing the Internal Network Mail Server to Relay through the SMTP Service on the ISA Server
Click the Messages tab. Note the defaults enforced by the SMTP server. We've received many questions regarding the SMTP server "blocking" messages that were too large, or a user's mail not going out in a timely manner. The most likely reason for the problem is related to the setting in this dialog box. Review the options on this tab and make sure they fit your organizational requirements.
Click the Delivery tab. Set the Retry Intervals to a value that works best for you. We like to set a long expiration timeout, just in case something goes wrong with our SMTP server on the internal network; that way, we don't have to worry about lost mail because it's being held at the SMTP relay. Set the expiration timeout to 7 days.

We also change the Subsequent retry interval (minutes) to 60. We don't see the need to wait six hours after the third retry. Click Advanced. In the Advanced Delivery dialog box (Figure 28.3), make sure that the Fully Qualified Domain Name (FQDN) entry is resolvable by external network SMTP servers if you plan to use this server as an outbound SMTP mail relay. Many administrators perform reverse lookups at their SMTP servers, and if the name here doesn't match the reverse lookup on the primary IP address on the external interface of the ISA server, your mail might be dropped.

Figure 28.3: Configuring Advanced Delivery Options

The Smart host entry allows the SMTP server to forward mail to another mail server with the goal of offloading MX domain name resolution. You might want to configure your Internet Service Provider's (ISP's) mail server here if you have a reliable ISP that knows how to maintain quality mail servers. You can use an FQDN or IP address in the Smart host text box. If you use an FQDN, make sure that the ISA server can resolve the name by using the nslookup command. If you use an IP address, make sure you use straight brackets [ ] around the IP address. We don't recommend using the Attempt direct delivery before sending to smart host and Perform reverse DNS lookup on incoming messages options. Click OK to save the settings in the Advanced Delivery dialog box.
Click Apply, then click OK in the SMTP server's Properties dialog box.
Now you need to configure a remote domain for your own mail domain. The only mail you want to accept for inbound relay is mail destined for users in the mail domains under your administrative control. You allow this type of selective relay by using remote domains. Expand the Default SMTP Virtual Server node and right-click the Domains node. Select New | Domain.
On the Welcome to the New SMTP Domain Wizard page, select the Remote option and click Next.
On the Select Domain Name page, type in the name of the domain for which you want to receive mail. For example, if you're responsible for mail for the internal.net domain, type internal.net in the Name text box. Click Finish.
Double-click the internal.net remote domain entry in the right pane of the console. In the Properties dialog box, enable the Allow incoming mail to be relayed to this domain option. Select the Forward all mail to smart host option and enter in the IP address (surrounded by straight brackets) of your internal network SMTP server in the text box. Click Apply, then click OK. Note that relay for incoming mail is handled by the Remote Domain configuration. Outgoing mail relay is handled by the Relay configuration dialog box for the default SMTP virtual server. If you want the internal mail server to use the SMTP service on the ISA server as a relay, you need to allow the internal server to be able to relay to all mail domains.
Now restart the SMTP service. At the command prompt, type net start smtpsvc and press Enter. After the SMTP service starts, type the command netstat –na | find ":25" and press Enter . You should find that the SMTP service is now listening on the internal interface only.

Configuring the SMTP Server Publishing Rule

Now that SMTP services socket pooling is disabled, let's create the SMTP server publishing rule.

Open the ISA Management console, expand the server name, then expand the Publishing node. Right-click Server Publishing Rulesand select New | Rule.
Give the rule a name on the Welcome to the New Server Publishing Rule Wizard page and click Next.
On the Address Mapping page, use the IP address of internal server text box to enter the IP address of the internal interface on the ISA server that the SMTP service is listening on.. Click Browse and select the IP address on the external interface on which the SMTP service should receive messages. Note that if you also use this server for outbound relay, this internal IP address is not used as the source IP address for outbound messages. The primary IP address on the external interface of the ISA server is used for the source IP address for outbound messages. Click Next.
On the Protocol Settings page, select the SMTP Server protocol from the Apply the rule to this protocol drop-down list. Click Next.
On the Client Type page, select the Any request option and click Next.
Review your settings and click Finish.

Now try sending a message from a mail client on the external network to the ISA server. Make sure that you send it to a user who belongs to one of your remote domains. The ISA server publishing rule will pass the message from the external interface to the SMTP server on the internal network. The SMTP service forwards the message to the smart host you configured in the Remote Domain Properties dialog box, which in most cases is your Exchange server (although it can also be a third-party SMTP server or even another SMTP relay).

It's important to note that relay works differently for incoming and outgoing messages. Although the SMTP service doesn't really know which messages are incoming and outgoing, it does evaluate messages in terms of their relay requirements. If the message is destined for one of your remote domains, the remote domain configuration determines how the message is handled. If the message is destined for a domain other than one of your remote domains, the message is handled by the relay properties configured for the virtual server.

For example, in the previous example we configured a remote domain for internal.net and set the smart host for the internal mail server. We also configured the default SMTP virtual server to deny mail relay for all hosts except the SMTP server on the internal network. If a message is sent from any host except the SMTP server on the internal network to a domain that is not one of your remote domains, the message will be dropped. The only exception is when that message comes from the IP address of the internal server that we configured to allow relay. This prevents spammers from abusing your mail server.

Something you need to be aware of is how the publishing rule affects the SMTP headers on the incoming messages. Look at the following example:

Received: from ISA1.internal.net ([10.0.0.1]) by CLIENTDC.internal.net      with Microsoft SMTPSVC(5.0.2195.2966);         Sat, 12 Oct 2002 14:22:40 -0500 Received: from EXTCLIENT ([127.0.0.1]) by ISA1.internal.net with Microsoft     SMTPSVC(5.0.2195.2966);         Sat, 12 Oct 2002 14:22:40 -0500 Message-ID: <001e01c27224$b4c89ab0$dc01a8c0@EXTCLIENT> From: "Bob" <john@external.com> To: <joe@internal.net> Subject: test Date: Sat, 12 Oct 2002 14:22:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative;        boundary="----=_NextPart_000_001B_01C271FA.CBE1C9D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Return-Path: john@dumbass.com X-OriginalArrivalTime: 12 Oct 2002 19:22:40.0116 (UTC) FILETIME=[BAFA7340     :01C27224]

Notice that the line for Received: shows the name of the external SMTP client sending the message and the IP address 127.0.0.1. This will always be the case when you use server publishing rules to publish services on the ISA server. The incoming message will appear to be from the loopback address instead of the actual host's IP address. We can confirm this by looking at the SMTP service log file on the ISA server:

#Software: Microsoft Internet Information Services 5.0 #Version: 1.0 #Date: 2002-10-12 22:36:18 #Fields: time c-ip cs-method cs-uri-stem sc-status  22:36:18 127.0.0.1 HELO - 250 22:36:18 127.0.0.1 MAIL - 250 22:36:18 127.0.0.1 RCPT - 250 22:36:18 127.0.0.1 DATA - 250 22:36:18 127.0.0.1 QUIT - 0 22:36:18 - - - 0 22:36:18 CLIENTDC.internal.net EHLO - 0 22:36:18 CLIENTDC.internal.net - - 0 22:36:18 CLIENTDC.internal.net MAIL - 0 22:36:18 CLIENTDC.internal.net - - 0 22:36:18 CLIENTDC.internal.net RCPT - 0 22:36:18 CLIENTDC.internal.net - - 0 22:36:18 CLIENTDC.internal.net BDAT - 0 22:36:18 CLIENTDC.internal.net - - 0 22:36:18 CLIENTDC.internal.net QUIT - 0 22:36:18 CLIENTDC.internal.net - - 0

This makes forensic analysis of e-mail headers problematic because you never get the source IP addresses for incoming messages. There is no workaround for this problem other than putting the SMTP relay on an internal network client or using packet filters to publish the SMTP service. This is just one of the many reasons why we don't recommend putting network services on the ISA server.

Message Screener on the ISA Server

The ISA Server Message Screener works together with the SMTP filter and allows you to:

Block mail from specific e-mail domains
Block mail from specific e-mail addresses
Block mail containing specific text strings in the e-mail header or body
Block mail containing specific attachments

There is nothing to prevent you from running the Message Screener on the ISA server. However, it's very important to configure the SMTP server carefully, as you could end up with an open relay that any spammer could take advantage of. If you configure the SMTP service and publish it in the way we recommended in the previous section, you'll be in good shape.

One of the advantages of installing the SMTP Message Screener on the ISA server is that you don't have to configure permissions that allow the Message Screener to contact the ISA server using the SMTPCred tool, and you don't need to configure Distributed Component Object Model (DCOM) permissions. It's okay if you aren't familiar with the SMTPCred tool and DCOM permissions; you'll learn about them later in the chapter.

The SMTP Message Screener was automatically installed if you did a full installation of ISA Server; otherwise, it may or may not be installed. If you're not sure, check the Registry to see if the service is installed (Figure 28.4). Open the Registry Editor and look for:

click to expand
Figure 28.4: Checking Registry Entries for the SMTP Message Screener

HKEY_CLASSES_ROOT\CLSID\{4F2AC0A5-300F-4DE9-821F-4D5706DC5B32}

If the Message Screener is not installed, run the Add/Remove Programs applet in the Control Panel.

The Message Screener can be used to screen both inbound and outbound messages. Most organizations are more interested in controlling inbound SMTP messages. If that describes your organization, all you need to do is configure the remote domains for your organization on the SMTP server and configure those domains to relay to your internal network's mail server.

You'll need to configure the Default SMTP Virtual Server in the Internet Services Manager to allow only the internal mail server to relay if you also want to screen outgoing SMTP messages. You saw how to configure the relay to allow only the internal server to relay in the previous section.

Configure the SMTP Message Screener after you have the SMTP service configured. Perform the following steps to configure the SMTP Message Screener:

The Message Screener depends on the SMTP Filter, which is disabled by default. Open the ISA Management console, expand the server name, then expand the Extensions node. Right-click the SMTP Filter entry and click Enable. The ISA Server Warning dialog box will appear, telling you that it needs to restart the firewall service. Select the Save the changes and restart the service(s) option and click OK.
Double-click the SMTP Filter and click the SMTP Commands tab (Figure 28.5). This part of the SMTP filter does not depend on the Message Screener. What you see here is a list of SMTP commands and the maximum length allowed for each. The goal of this list is to prevent SMTP command buffer overflow exploits. There is a small problem with some of the commands, such as the NOOP command. The size is set to 6 by default. This can cause you to see a number of spurious SMTP Filter Event warnings in the Event Viewer. Click the NOOP command, then click Edit. Change the value to 1024 and click OK.

Figure 28.5: The SMTP Commands Tab
Click the Keywords tab. Here you can create a list of keywords for the Message Screener to check. Make sure that the Enable keyword rule check box is checked and click Add. Enter a keyword in the Keyword text box (Figure 28.6). In the Apply action if keyword is found in frame, select the option that specifies where you want the Message Screener to check for keywords. It takes more processor cycles to check for the keyword in the message header or body than it takes to just check the message body. The Message Header option requires the fewest processor cycles. Select one of the following options from the Action drop-down list and click OK:

Figure 28.6: Adding a Keyword to the Message Screener
- Delete message The message will be deleted
- Hold Message The message will be saved to the \Inetpub\mailroot\Badmail folder and you can view the message later by opening it from that folder.
- Forward message to Enter an e-mail address to which the message can be forwarded. If you choose to forward the mail, make sure that you forward it to an SMTP server that the ISA server can reach. The easiest way to do this is to forward it to an SMTP server on the internal network. Make sure that the ISA server can resolve the MX record for mail domain in the e-mail address. You will need to create a packet filter allowing outbound access to TCP port 25 from any local port on the ISA server if you forward messages to an external SMTP server.
Click on the Users/Domains tab (Figure 28.7). Here you can block messages based on a user account name or an entire SMTP domain name. Enter an e-mail address in the Sender's name text box and click Add. Enter an e-mail domain name in the Domain text box and click Add. Click Apply. All mail from these users and/or mail domains will be blocked by the Message Screener.

Figure 28.7: Blocking Messages Based on an E-Mail Address or Domain Name
Click the Attachments tab (Figure 28.8). Here you can configure a list of attachments that you want the Message Screener to block. If you select the Attachment name option, you must enter the exact name of the attachment. For example, a common attachment name is joke.exe. If you enter joke.exe, the Message Screener will block messages with that attachment. If you select the Attachment extension option, you enter the name of the file extension you want blocked. For example, if you want to block all executable files, enter the .exe extension in the text box. Note that there's no option allowing you to block all attachments. If you want to block attachments over a certain size, select the Attachment size limit option and then the size in bytes. For example, if you want to limit attachments to less than 1MB, type 1024000. Click OK. The Message Screener will block the attachments you've configured in this dialog box. Click Apply to set the rule.

Figure 28.8: Blocking E-Mail Attachments
Click OK to close the SMTP Filter Properties dialog box.

Be patient when configuring the Message Screener rules. Many times, we've thought that the Message Screener wasn't doing its job because we began testing the rule too quickly. It might take a few minutes for the rule to take effect. However, if you configured the rules correctly, they will work.

Publishing Exchange Server on the ISA Server

Many people want to place their Exchange 2000 server on the ISA server. We generally recommend against this because each service you place on the ISA server provides a portal of attack for Internet criminals. However, not all users have the resources to purchase multiple Windows 2000 servers, which would allow you to put the Exchange server on a machine other than the ISA server.

You'll encounter a number of challenges when making an Exchange 2000 server work on the ISA server computer. First, you have to make the ISA server a domain controller (DC) because Exchange 2000 requires Active Directory. If you only have one Windows 2000 Server machine, that machine will also have to be a domain controller. You have to be very careful about how you configure DNS on the machine when you make the ISA server a domain controller. If DNS is not configured correctly, the machine won't work properly as an ISA server, domain controller, or mail server.

The second major challenge is socket pooling. You have to disable socket pooling for all of the Exchange Services if you want to use server publishing rules to publish the Exchange services. Socket pooling causes a service to listen on all interfaces and IP addresses, which can cause port contention when creating server publishing rules. There are two ways to get around this problem: you can disable socket pooling for the services, or you can use packet filters to make the services available to Internet users.

Packet filters are the easiest way to publish Exchange services on the ISA server. This is why the Secure SMTP Server Publishing Wizard creates packet filters instead of server publishing rules. The problem with combining publishing services with packet filters is that you can't leverage any application filters to protect the Exchange 2000 mail services.

Again, note that running a mail server (be it Exchange or any other mail server) directly on a firewall adds complexity to your firewall. You'll want to be very careful doing this and give serious consideration to running your mail server on the DMZ or on the internal network.

Note

You can't publish Exchange RPC services when the Exchange server is on the ISA server. You can't use server publishing rules because there's no way to disable socket pooling for RPC endpoint mapper (TCP port 135). You can't use packet filters because you would need to statically open the entire high port range (1024–65535) to allow the dynamic port assignment to the clients. You will have to put the Exchange server on the internal network, not on the ISA server, if you want to publish Exchange RPC services and allow external Outlook MAPI clients to connect to it.

To publish Exchange 2000 services on the ISA server:

Install Windows 2000.
Configure DNS.
Make the server a domain controller.
Install ISA Server.
Install Exchange Server 2000.
Disable socket pooling.
Configure server publishing rules for the services you want to publish.
Optional: Obtain certificates for services you want to publish, and create server publishing rules for these secure services.

Let's look at these steps in detail. Make sure you follow them closely and understand why we're performing each step. Doing so will help you troubleshoot problems if and when they occur.

Note

The procedures we cover in this chapter apply to stand-alone versions of ISA Server, Windows 2000, and Exchange 2000 Server. You might be forced to use certain wizards to install services if you have Small Business Server. However, the same principles apply to all Windows 2000, ISA, and Exchange 2000 Server installations. The only difference is that some of the steps you take to get to the same result might differ. You will be able to replicate the steps described here if you avoid the wizards and install the services and server separately.

Installing Windows 2000

The first step in publishing Exchange services on the ISA server is to install Windows 2000. You might want to consider reinstalling if you already have Windows 2000 installed. A clean installation prevents problems that might occur on a machine that has already been installed on and may have a variety of known and unknown configuration changes. Requirements for installing Windows 2000 and ISA Server for a DC are:

Windows 2000 Server, Advanced Server, or Datacenter Server.
A generous amount of RAM. To support all these services, we recommend at least 1GB of RAM, and more would be better.
Make sure that all network interface cards (NICs) you plan to use are already installed and plugged into a hub or switch. Domain controllers will run into problems if you multi-home them after you run dcpromo.
Do not plug the external interface into the Internet during installation. Many ISA server administrators have been successfully hacked either during installation or after installation but before ISA Server is installed.

Keep in mind that you should use hardware that is on the hardware compatibility list (HCL), or that at least has Windows 2000 drivers.

Boot the from the installation CD-ROM. Format the partitions if required and perform the remaining steps in the text mode phase. There are no special installation requirements to make a DC work during the text mode phase of the installation.
Reboot in GUI mode. On the Regional Settings page, make any required changes and click Next.
On the Personalize Your Software page, enter your Name and Organization and click Next.
Enter your key on the Your Product Key page and click Next.
On the Licensing Mode page, select the appropriate licensing mode for your server and click Next.
On the Computer Name and Administrator password page, enter the computer (NetBIOS) name for your computer and a complex password for the administrator account. You might want to rename the administrator account after installation is complete. If you do, make sure to do it immediately after installation. You might run into problems with ISA Server or Exchange Server if you rename the administrator account after installing those services. Click Next.
On the Windows Components page, double-click the Internet Information Services entry. If you need to support File Transfer Protocol (FTP) and Network New Transfer Protocol (NNTP), make the appropriate selections on the Internet Information Services page. We recommend that you minimize the number of IIS servers running on the ISA server, but since this is your only Windows 2000 server, you'll need to put all the services you require on this machine. Click OK.
Back in the Windows 2000 Components page, double-click the Management and Monitoring Tools node and select the Network Monitor Tools option. Click OK in the Management and Monitoring Tools dialog box.

Double-click the Networking Services entry. At the very least, you need to install DNS and WINS. Scroll through the list of networking services and make those selections. Then, click OK in the Network Services dialog box.

Note

If you install WINS, you must disable NetBIOS on the external interface of the ISA/DC computer. If you don't disable NetBIOS, the external IP address of the ISA/DC will be registered for all sorts of things that you don't want registered in WINS. Don't disable NetBIOS until you're finished with everything. Before disabling NetBIOS, check out the entries in the WINS database for the external IP address of the ISA/DC computer, and delete any you find. Make sure that you don't enter a WINS address in the TCP/IP Properties of the external interface. If you do install a WINS server on the ISA server, make sure you delete any entries in the WINS database that match the IP address of the ISA server's external interface. It is imperative that no external IP addresses are in the WINS database when you run dcpromo and afterward. Note that WINS is not required, but it is helpful for administrators who are still learning the details of DNS.

Double-click the Terminal Services option. Select the Client Creator Files option if you need to install the client, then click OK. Click Next.
On the Date and Time Settings page, set the correct date, time, and time zone. Click Next.
On the Terminal Services Setup page, select the Remote administration mode option and click Next.
On the Networking Settings page, select the Custom Settings option. Click Next.

On the Networking Components page, you are presented with the Configuration Settings dialog box for the external interface of the ISA server. We refer to this adapter as the external interface because this interface should be listed as second on the list of adapters in the advanced network adapter settings. If you don't want this to be the external interface, you'll have to manually change the adapter's priority after completing the installation. Remove the check marks for the Client for Microsoft Networks and File and Printer Sharing options. Double-click the Internet Protocol (TCP/IP) entry and enter the IP addressing information appropriate for your external interface. If you don't want to configure your own DNS server to resolve Internet host names, enter your ISP's DNS server address in the Preferred DNS server text. DNS server configuration is explained later in this section. If you will be using your DNS server to resolve Internet host names, enter the internal IP address of the ISA/DC/Exchange server in this text box. The Default gateway will either be assigned by your ISP or it will be the LAN interface of the upstream Internet connection device. Click Advanced, then click the DNS tab. Disable the Append parent suffixes of the primary DNS suffix option; there is no reason for your external interface to resolve queries. Disable the Register this connection's addresses in DNS option; you do not want this interface to register with the DNS server installed on this computer. Click OK. You will see an informational message telling you that your WINS address is empty. Click Yes. Click OK to close the Internet Protocol (TCP/IP) Properties dialog box, then click Next in the Network Components page.

Note

After the Windows 2000 installation is complete, you should rename the interfaces to make them easier to work with. Give them names like InternalNIC and ExternalNIC. Do not use names like internal and external, because the name internal is also used by the RRAS console to represent an interface created and used by RRAS only, so it could cause some confusion.

Here you see the Networking Components page for the internal interface of the ISA/DC/Exchange computer. Double-click the Internet Protocol (TCP/IP) entry and enter the internal IP address and subnet mask. Make sure you make the Preferred DNS server the IP address of the internal interface. This is vitally important because this machine is the DNS server for your Active Directory domain and you want clients to identify the domain controller using the internal IP address. Click Advanced. Click the WINS tab, then click Add. and add the IP address of the internal interface of this ISA/DC/Exchange computer. You want this IP address to register with WINS. You do not want the external interface to register with WINS. Click OK in the Advanced TCP/IP Settings dialog box after you have added the WINS server address. Click OK in the Internet Protocol (TCP/IP) Properties dialog box and click Next on the Networking Components page.
Click Next on the Workgroup or Computer Domain page.

The Installation Wizard now installs and configures the services you selected. Click Finish to restart the computer when the wizard tells you to do so.

Warning

You should disable NetBIOS on the external interface of the DC/ISA Server computer to prevent problems with the browser service and prevent browser announcements from trying leave the external interface. All they will do is fill up your logs because later you will enable packet filtering to block NetBIOS communications on the external interface. Leave this until the very last step—disable NetBIOS after you've installed Service Pack 3.

After the system restarts, confirm that the NIC binding order is correct. You want the internal interface to be at the top of the list, and the external interface to be under the internal interface. Right-click My Network Places and select Properties. In the Network and dial-up Connections window, select Advanced | Advanced Settings. In the Connections frame, ensure the internal interface is at the top o the list and that the Remote Access connections option is at the bottom.
After confirming that the interface order is correct, install Service Pack 3.

Configuring DNS Server Forward and Reverse Lookup Zones

Configuring the DNS server properly before you run dcpromo is important because you want the Active Directory to dynamically register Active Directory-related resource records into the DNS. Many ISA Server administrators unwittingly sabotage themselves because they've promoted the machine to a domain controller before configuring DNS.

Perform the following steps to configure your DNS server:

Select Start | Administrative Tools | DNS.
Expand all the nodes in the left pane. Right click Forward Lookup Zone and select View | Advanced.
Right-click Reverse Look Zone and select New Zone. Click Next on the Welcome page.
On the Zone Type page, select the Standard Primary option and click Next.
On the Reverse Lookup Zone page, type in the network ID for the segment connected to the internal interface of this DC/ISA Server computer. You might have to create additional reverse lookup zones if you have multiple network IDs on your internal network, but you need at least this first network to get started. You want to be able to create a Pointer resource record for the internal IP address of this ISA/DC computer. Click Next.
On the Zone file page, accept the default name for the DNS zone file and click Next.
On the Completing the New Zone Wizard page, click Finish.
In the left pane of the console, right-click the reverse lookup zone you just created and click Properties.
In the reverse lookup zone Properties dialog box, click the General tab. Select Yes in the Allow dynamic updates drop-down list box. Click Apply, then click OK.

The next step is to configure the forward lookup zone:

Right-click the Forward Lookup Zone node and click New Zone. Click Next on the Welcome page.
On the Zone Type page, select Standard Primary and click Next.
On the Zone Name page (Figure 28.9), type in the name you want to use for your Active Directory domain. In this example, the internal network's domain name is internal.net, so we'll type in internal.net in the Name text box. Click Next.

Figure 28.9: Entering Your Active Directory Domain Name
On the Zone File page, accept the default name for the DNS zone file and click Next.
Click Finish on the Completing the New Zone Wizard page.
Right-click on the zone you just created and select the New Host command.
In the New Host dialog box, type in the host name of this computer, the IP address of the internal interface, and select Create associated pointer (PTR) record. Click Add Host. An information message appears telling you the record was created. Click OK. Click Done in the New Host dialog box.
Check both the forward and reverse lookup zones to confirm that the records were created for this computer. Click Refresh if you don't see the records. Make sure the Host (A) and Pointer (PTR) records are there before you promote the machine to a domain controller. The domain controller requires these records to properly populate the DNS with Active Directory related entries.

Now configure the DNS server and the forward lookup zone properties:

Right-click you're the DNS server name in the left pane of the DNS console and click Properties.
In the server Properties dialog box, click the Interfaces tab. Select the Only the following IP addresses option. Click on the external IP address of this computer and click Remove, then click Apply. The goal here is to remove the external IP address from the list to prevent the DNS server from listening on the external IP address. You want the DNS server to listen only on the internal IP address of this computer.
Click the Root Hints tab and confirm that the Root Hints file has been primed. You should see addresses and names for the Internet root servers there. Click OK.
Right-click the forward lookup zone you just created for your domain and click Properties.
Click the General tab. Change the Allow Dynamic Updates setting to Yes.
Click the WINS tab. Select the Use WINS forward lookup option.
Type in the IP address of the internal interface of this computer and click Add.
Click the Zone Transfers tab. Disable the Allow zone transfers option; There is no reason to allow zone transfers, because this is the only domain controller and authoritative DNS server in your domain.
Click the Name Servers tab. If the IP address of this server is listed as unknown, select your computer name and click Edit. Click Browse in the Edit Record dialog box. Double-click your computer name, double-click Forward Lookup Zones, then double-click your forward lookup zone. Double-click your computer name. Click OK and then click Apply. Click OK to close the Properties dialog box.
Right-click the server name in the left pane of the console and select Tasks | Restart. Close the DNS console after restarting the DNS server service.

Promoting the Machine to a Domain Controller

Now you're ready to promote the machine to a domain controller. This should go smoothly if the interfaces are configured correctly and you have the DNS server set up properly. If you run into problems, first make sure that DNS is configured correctly. If it looks right to you, check the interface configuration. Make sure that the IP addressing information is correct and that the interface order has the internal interface on top.

On the Windows desktop, select Start | Run.
Type dcpromo in the Open text box and click OK.
Click Next on the Welcome page.
Select the Domain Controller for a new domain option and click Next.
Select Create a new domain tree and click Next.
Select Create a new forest of domain trees and click Next.
In the New Domain Name text box, enter the full domain name. For example, if your domain name is internal.net, type internal.net in the text box. Remember that this is the same domain name that you just configured on the DNS server. Click Next.
On the NetBIOS Domain Name page, select Next to keep the default settings. Note that if you made your domain name too long, the NetBIOS name might be truncated. If so, you should change your domain name to one with 15 characters or less. This character limit only applies to the leftmost label and not to the top-level domain.
On the Database and Log Locations page, make any required changes and click Next.
On the Shared System Volume page, make any required changes and click Next.
You might see an information dialog box informing you that the wizard can't contact a server authoritative for the Active Directory domain. That's okay; click OK to continue.
On the Configure DNS page, select No, I will install and configure DNS myself. Don't allow the Active Directory DNS Wizard to configure the DNS because you've already created the zone. Click Next.
Select the appropriate permissions for your environment. Since this is the only domain controller and Windows 2000 server on your network, you should select the Permissions compatible only with Windows 2000 Servers option and click Next.
Enter your Directory Services Restore Mode password and confirm. Click Next.
Review your settings to make sure everything is correct, then click Next.
It should take less than five minutes to complete the Active Directory configuration if everything is configured correctly,. If the DNS zone wasn't configured correctly or if the interface IP addressing information wasn't entered correctly, it can take a very long time for Active Directory to be configured. When Active Directory creation and configuration is complete, click Finish on the Completing the Active Directory Installation Wizard page.
In the Active Directory Installation Wizard dialog box, select Restart Now.
It might take awhile before you can log on to the server after the restart because it's populating the DNS server zone file with Active Directory-related records and doing some last-minute configuration and cleanup tasks. Log on to the domain when the logon dialog box becomes available.
Wait about five minutes, then open the DNS console. Expand the forward lookup zone for your domain and you should see the Active Directory-related records. If you see the external IP address listed with a Host (A) address record, remove it by right-clicking the record with the external IP address and clicking Delete.

Right-click the forward look zone for your domain and click Properties. Click the General tab. Change the Allow dynamic updates setting to No. This prevents the external interface from registering with the DNS. It's interesting that even when you configure the external interface to not register with the DNS, it continues to do so anyway. Disabling dynamic updates should not pose a problem for a small network that has a single Windows 2000 server and domain controller. You will need to manually enter the names of your internal network clients in the DNS because dynamic update is now disabled. Click Apply | OK.

Note

While disabling dynamic updates causes few problems for small networks with a single domain controller, it can be a big problem on larger networks. Dynamic DNS (DDNS) is a powerful tool and it allows DNS to pick up where WINS leaves off. Multi-homed domain controllers cause quite a few problems related to name resolution and DDNS. There are several Microsoft Q articles you should refer to if you must enable DDNS. The first is Q292822, which deals with name resolution issues on Windows domain controllers with DDNS and RRAS installed (which is what your ISA server will be if you allow inbound Virtual Private Network [VPN] connections). The second is Q289735, which deals with similar issues and contains a registry entry to prevent VPN clients from shutting down Internet access for your internal network users.

At this point, decide if you want to use a forwarder to resolve Internet host names. As mentioned earlier, you don't need to use a forwarder; the DNS server can use the root hints file and perform recursion. However, you might want to consider using your ISP's DNS server as a forwarder if you have a good ISP that maintains its DNS servers. Perform the following steps if you have a lot of confidence in your ISP's DNS servers:

Right-click the server name and click Properties.
Select the Forwarders tab.
Select the Enable forwarders option. Enter the IP address(es) of your ISP's DNS server(s) and click Add. Enable the Do not use recursion option—this improves performance significantly. Click Apply | OK.
Right-click you're the server name and select All Tasks | Restart. This will restart the DNS server service and force the DNS server to use the forwarder.

You should test the DNS server now that it's configured to use a forwarder. The tests should include queries for local and Internet domains. Perform the following steps to complete the tests:

In the DNS console, right-click you're the server name and select Properties.
Select the Monitoring tab.
Enable the A simple query against a DNS server option and click Test Now. You should see a PASS entry in the Simple Query column. This indicates that the DNS server was able to query itself and resolve a name in one of its authoritative domains. In this case, the domain for which this DNS server is authoritative is your Active Directory domain.
Disable the A simple query against this DNS server option and enable the A recursive query to other DNS servers option. Click Test Now. You should see a PASS in the Recursive Query column. This indicates that the DNS server was able to accept a recursive query and respond with a definitive answer. In this case, the query was for a domain for which this DNS was not authoritative.

Installing ISA Server

The next step is to install the ISA Server software. We're often asked whether you should install the ISA Server or the Exchange Server first. From our experience, it doesn't seem to make much difference. Some people say that you should install Microsoft Server applications in the order in which they were released. If that was true, then you should install Exchange 2000 first and ISA Server second. However, Service Pack 3 for Exchange came out after Service Pack 1 for ISA Server.

There aren't any special steps required when installing ISA Server on the domain controller. However, we'll go through the procedure just to be thorough:

Put the ISA Server CD-ROM into the tray and when the autoplay dialog box appears, click the Install ISA Server button.
On the Welcome page, click Continue.
On the CD Key page, enter your CD Key and click OK. Click OK on the Product ID page.
Click I Agree on the license agreement page.
Click Full Installation on the setup page to install all features. Later on, you can disable services you don't plan to use, and by performing the full installation, you ensure that you won't have to come back to install other services that you do decide to use.
Since we haven't initialized the Active Directory, we can't join an array. If you're running SBS, you probably have a single server, so this isn't an issue. In this example, we'll run a stand-alone ISA server. Click Yes in the dialog box that appears.
On the Mode page, select the Integrated mode option and click Continue.
Click OK in the dialog box informing you that IIS services will be stopped. Note that the dialog box says that you will need to uninstall IIS or reconfigure the WWW service so it does not use TCP port 80. The reason for this is that the Outgoing Web Requests listener uses TCP port 8080 on the internal interface, and Autodiscovery information is published on TCP port 80 (also on the internal interface). You don't have to worry about ISA Server using TCP port 80 on the internal interface if you won't be publishing Autodiscovery information. However, the Incoming Web Requests listener will use TCP port 80 if you decide to configure Web publishing rules. We'll go into more detail on this issue when we configure IIS to publish Outlook Web Access.
On the Cache Size page, set the cache size and click Set. Remember, the cache must be placed on an NTFS drive. Optimal cache size varies–we generally start with 100MB and add 10MB per user. Click OK after setting the cache size.
On the LAT configuration page, click Construct Table. Note how we've configured the options in the Local Address Table dialog box (Figure 28.10). Disable the Add the following private ranges option and enable the Add address ranges based on the Windows 2000 Routing Table option. Enable the NIC connected to the internal network. Click OK. Click OK in the dialog box that warns you that your LAT is based on the routing table. Click OK, then click OK again.

Figure 28.10: Configuring the LAT
When the setup is finished, click OK to open the ISA Management console. Click OK again to finish.
Right-click the Servers and Arrays node and select View | Advanced. The advanced view provides you with a cleaner interface and makes it much easier to work with the ISA Server console.
Install ISA Server Service Pack 1 or later as soon as you complete the basic ISA Server installation. Restart the server after installing the ISA Server Service Pack.

Packet filtering is enabled by default. You don't need to worry about DNS query problems because there is a preconfigured DNS packet filter. You can run the DNS query tests again to confirm that the DNS server is still working.

Installing Exchange Server

The next step is to install Exchange Server 2000. It might be possible to install Exchange Server 5.5 on the ISA server, but there is no documentation on this issue and we've never been called upon to do this type of installation. A compelling reason to use Exchange Server 2000 instead of Exchange 5.5 is that Microsoft plans to stop supporting Exchange 5.5 in the near future. This probably explains why there is no documentation on how to make Exchange 5.5 work on an ISA server machine.

The good news is that installing Exchange 2000 on the ISA server is very easy. It's even easier when the Exchange server is installed on the only domain controller in the domain. You should refer to a good Exchange server book for documentation on how to install and configure Exchange 2000 if you have other Exchange servers or domain controllers in your organization. We won't go into the details of more advanced installation considerations in this discussion because we assume that you are installing Exchange on the ISA server because you don't have any other Windows 2000 servers on the network. .

Perform the following steps to install Exchange 2000 on the ISA server/domain controller:

Put the Exchange 2000 server CD-ROM into the tray. In the Setup dialog box, click the Exchange Server Setup icon.
Click Next on the Welcome to the Microsoft Exchange 2000 Installation Wizard page.
Select the I agree option and click Next.
Enter the CD key and click Next.
On the Component Selection page, set the Action to Typical for the Microsoft Exchange 2000 component. If you need other services, you can install them later. Select Change Folder and select different drive to install to. Click Next. Select the Create a new Exchange Organization option and click Next.
On the Organization Name page, enter an organization name for your Exchange server organization. In this example, we have only one server, so we'll keep the default name, First Organization. Click Next.
Select I agree that I have read and agree to be bound by the license agreement for this product and click Next.
Review your choices on the Component Summary page and click Next. This begins the very long Exchange Server installation process. Once the installation finishes, click Finish.
Click the Exit link on the Exchange 2000 installation page and restart the server.
After the server restarts, install Exchange Server Service Pack 3. 15.Restart the server after the service pack is installed.

Disabling Socket Pooling for the Exchange Services

As you've probably realized by this time, socket pooling is the bane of the ISA Server administrator's existence. This is especially true when you want to install Exchange 2000 on the ISA Server computer and publish the Exchange 2000 Server services. The good news is that although it takes a little work, you can disable socket pooling for almost all of the Exchange 2000 services.

You will need the mdutil utility to disable socket pooling. If you don't have it, you can download it ftp.tacteam.net/isaserver. After you download the utility, move it to the root directory of the C: drive (it doesn't have to be placed there, it's just a convenient place to put it).

Perform the following steps to disable socket pooling for all of the Exchange services that we'll be publishing:

Stop the mail services before disabling socket pooling. Open a command prompt and enter the following commands:
```
net stop w3svc net stop msftpsvc net stop smtpsvc net stop nntpsvc net stop pop3svc net stop imap4svc
```
We can get to the work of disabling socket pooling now that the mail services are stopped. As you learned earlier, there are two methods used to disable socket pooling: scripts and the mdutil utility. To stop the WWW service, access a command prompt and go to the \Inetpub\AdminScripts directory. Once in that directory, run the following command:
```
cscript adsutil.vbs set w3svc/disablesocketpooling true 
```

To disable the FTP service, run the following command:

cscript adsutil.vbs set msftpsvc/disablesocketpooling true

While still in the command prompt window, change the focus to the C: drive. Then, run the following commands:

mdutil set -path smtpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1 mdutil set -path nntpsvc/1 -value 1 -dtype 1 -prop 1029 -attrib 1 mdutil set -path pop3svc/1 -value 1 -dtype 1 -prop 1029 -attrib 1 mdutil set -path imap4svc/1 -value 1 -dtype 1 -prop 1029 -attrib 1

The last service you need to disable socket pooling for is secure Web services (SSL listener). Go to the \Inetpub\Adminscripts folder and run the following command:
```
adsutil set w3svc/1/securebindings "" 
```
You will see a dialog box that says "This script does not work with Wscript". Click OK.
The next dialog box will ask if you want to register CScript as your default host for VBscript. Click Yes.
Click OK in the Successfully registered CScript dialog box.
Now run the adsutil set w3svc/1/securebindings "" script again.

The services continue to run on all interfaces and all IP addresses, even though we have disabled socket pooling. The reason is that the services' default configuration is to listen on all interfaces. We need to change those default settings in the Internet Services Manager and the Exchange System Manager.

Perform the following steps to configure the listeners for the WWW and FTP services:

Select Internet Services Manager from the Administrative Tools menu.
Right-click the Default FTP Site entry in the left pane of the console and click Properties.
Change the IP Address from (All Unassigned) to the IP address on the internal interface of the ISA server. Click Apply, then click OK.
Right-click the Default Web Site entry in the left pane of the console and click Properties.
Change the IP address from (All Unassigned) to the IP address on the internal interface of the ISA server. Click Apply, then OK.
Click the Administration Web Site entry in the left pane of the console and click Properties.
Change the IP Address from (All Unassigned) to the internal IP address on the ISA server. Click Apply, then OK.

That takes care of the FTP and Web sites. If you want to run other Web sites, make sure that when you create the new Web site that it listens only on the internal interface of the ISA server.

We also need to configure the NNTP, SMTP, POP3, and Internet Message Access Protocol (IMAP)4 services. These services are configured in the Exchange System Manager. Remember that you won't be able to publish Exchange RPC services because you can't disable socket pooling for the RPC endpoint mapper.

Perform the following steps to configure the remainder of the Exchange services:

On the Windows desktop, select Start | Programs | Microsoft Exchange | System Manager.
Expand the Servers node, the server name, the Protocols node and the IMAP4 node. Right-click the entry and click Properties.
In the Default IMAP4 Virtual Server Properties dialog box, change the IP Address from (All Unassigned) to the IP address of the internal interface of the ISA server. Click Apply, then click OK.
Expand the NNTP node in the left pane of the console. Right-click the Default NNTP Virtual Server entry and click Properties.
In the Default NNTP Virtual Server Properties dialog box, change the IP address from (All Unassigned) to the IP address on the internal interface of the ISA server. Click Apply, then OK.
Expand the POP3 node. Right-click the Default POP3 Virtual Server entry and click the Properties command.
Change the IP address from (All Unassigned) to the internal IP address on the ISA server. Click Apply, then OK.
Expand the SMTP node. Right-click on the Default SMTP Virtual Server entry and click the Properties command.
In the Default SMTP Virtual Server Properties dialog box, change the IP address from (All Unassigned) to the internal IP address on the ISA server. Click Apply, then OK.

All the services are now configured to listen only on the internal interface. From the command prompt, run each of the following commands to restart all the services:

Net start w3svc Net start msftpsvc Net start nntpsvc Net start smtpsvc Net start pop3svc Net start imap4svc

To confirm that the services are listening only on the internal interface, run the following commands:

Netstat –na | find ":21" Netstat –na | find ":25" Netstat –na | find ":80" Netstat –na | find ":110" Netstat –na | find ":119" Netstat –na | find "143"

Configure Server Publishing Rules to Publish the Exchange Services

With socket pooling disabled and the services configured to listen only on the internal interface, you're now ready to create the server publishing rules. The following services on the ISA server are candidates for publishing:

FTP server
Web server
POP3 server
SMTP server
NNTP server
IMAP4 server

This chapter doesn't cover FTP server publishing, since it has nothing to do with Exchange mail services. Web server publishing is covered later, in the section "Publishing Outlook Web Access on the ISA Server". That leaves POP3, SMTP, NNTP, and IMAP4 publishing. Let's go through the procedure for publishing each of these services.

SMTP Server Publishing Rule

Publishing the Exchange 2000 SMTP server works the same as publishing the IIS 5.0 SMTP server discussed earlier in this chapter. You need to configure remote domains for the mail domains under your administrative control, and you need to configure the relay characteristics so that you're not running an open relay. Make sure you review the material on publishing the IIS 5.0 SMTP earlier in this chapter before publishing the Exchange 2000 SMTP service.

Perform the following steps to publish the Exchange 2000 SMTP service:

Open the ISA Management console, expand you're the server name, and expand the Publishing node. Right-click Server Publishing Rules, and select New | Rule.
On the Welcome to the New Server Publishing Rule Wizard page, enter a name for the rule. Click Next.
Enter the IP address of the internal interface of the ISA server in the IP address of internal server text box. Click Browse and select the external IP address on the ISA server on which you want to accept SMTP requests. Click Next.
Select the SMTP Server protocol definition and click Next.
Select the client type you want to support. The typical selection is Any request, since anonymous SMTP servers on the Internet will need to forward mail to your mail domains. Make your selection and click Next.
Review you settings on the Complete the New Server Publishing Rule Wizard page and click Finish.

We always like to do a quick check on our server publishing rules by using Telnet from an external network client. If you have a Windows 2000 client on the external network, access a command prompt and type telnet <IP_Address> 25. You should see an output similar to that in Figure 28.11. Type help to see the list of commands supported by the SMTP server and type quit to exit the Telnet session.

click to expand
Figure 28.11: Telnet to the Publishing SMTP Server

POP3 Server Publishing Rule

The POP3 server publishing rule allows external network users access to the Exchange 2000 server's POP3 Server component. This is useful when external users need to get e-mail from their message store and they don't have access to an Outlook Message Application Programming Interface (MAPI) connection. Users can configure Outlook 2000/XP, Outlook Express, or any other e-mail client to access POP mail services on the Exchange 2000 server.

There are some disadvantages to using POP3 to receive e-mail. The POP3 client will pull all mail out of the Inbox store if the POP3 client isn't configured to leave the mail on the server. We've seen many occasions where the user was shocked when he returned to the office and found that there was no mail in his inbox after opening Outlook 2000/XP. Another consideration is that username and password information is passed as clear text. You can resolve this problem by requiring Secure Socket Layer (SSL) to connect to the POP3 server.

Perform the following steps to publish the POP3 server:

Open the ISA Management console, expand you the server name, then expand the Publishing node. Right-click Server Publishing Rules and select New | Rule.
Enter a name for the rule and click Next.
Enter the IP address of the internal interface of the ISA server in the text box. Click Browse and select the external IP address on the ISA server on which you want to accept POP3 requests. Click Next.
Select the POP3 Server protocol definition and click Next.
Select the client type you want to support. The typical selection is Any request, since you usually can't tell where the external users are located in advance. Make your selection and click Next.
Review your settings on the Complete the New Server Publishing Rule Wizard page and click Finish.

Use Telnet to ensure that the server publishing rule worked.

NNTP Server Publishing Rule

The Exchange NNTP server can be used to host your organization's newsgroups. While the NNTP service provided by Exchange 2000 isn't a full-featured NNTP server, it does provide an excellent platform for sharing information in a threaded environment. Newsgroups are fast and they're easy to search. While many sites now offer newsgroup-like features in a Web-based format, they'll never be as fast or as efficient as the traditional News server.

Perform the following steps to publish the NNTP service:

Open the ISA Management console, expand the server name, then expand the Publishing node. Right-click Server Publishing Rules and select New | Rule.
Enter a name for the rule and click Next.
Enter the IP address of the internal interface of the ISA server in the IP address of internal server text box. Click Browse and select the external IP address on the ISA server on which you want to accept NNTP requests. Click Next.
Select the NNTP Server protocol definition and click Next.
Select the client type you want to support. The typical selection is Any request, since you probably don't know the IP addresses of your NNTP clients. Make your selection and click Next.
Review your settings on the Complete the New Server Publishing Rule Wizard page and click Finish.

Use Telnet to confirm that the server publishing rule worked.

IMAP4 Server Publishing Rule

The IMAP4 service allows you to connect IMAP4 clients to the Exchange 2000 message store. IMAP4 clients can download a list of mail headers without downloading the entire e-mail message. This is an ideal solution for users with low bandwidth connections. Another advantage of IMAP is that if you use Outlook 2000/XP to create subfolders off the main Inbox folder, you can use the IMAP4 protocol to access information in those folders. This is a great advantage over POP3 access because POP3 clients can only download mail contained in the Inbox; POP3 clients cannot download mail contained in subfolders under the main Inbox folder. If you use filtering rules to move mail automatically from the Inbox to subfolders, the POP3 client will not be able to retrieve sorted mail. Outlook Express provides basic IMAP4 support.

Perform the following steps to publish the IMAP4 service:

Open the ISA Management console, expand the server name, then expand the Publishing node. Right-click Server Publishing Rules and select New | Rule.
Enter a name for the rule and click Next.
Enter the IP address of the internal interface of the ISA server in the IP address of internal server text box. Click Browse and select the external IP address on the ISA server on which you want to accept IMAP4 requests. Click Next.
Select the IMAP4 Server protocol definition and click Next.
Select the client type you want to support. The typical selection is Any request, since it's unlikely that you'll know the IP addresses of your IMAP4 clients in advance. Make your selection and click Next.
Review your settings on the Complete the New Server Publishing Rule Wizard page and click Finish.

Use Telnet to confirm that the server publishing rule worked.

Secure Services Publishing

The publishing rules we created so far work fine, but they all suffer from the same major drawback: all information is sent "in the clear." When users access NNTP, IMAP4, SMTP, and POP3 resources, anyone with a packet sniffer will be able to see the contents of the communications. You won't want to allow this if you keep secure information on your Exchange server.

You can solve this problem by allowing only secure communications with the POP3, NNTP, and IMAP4 services. You could even configure SMTP access to be secure, but if you're publishing your SMTP server to allow Internet SMTP servers to send mail for your mail domains, you won't be able to enforce secure communications. Internet mail servers aren't configured to enforce secure communications, so any attempt to secure SMTP communications at the mail server level will fail for anonymously accessible SMTP servers. However, if you create a second SMTP virtual server for your employees to send mail to, you can enforce secure communications on that server. You can enforce secure communications with the SMTP server when you have administrative control over the users. .

We'll assume that you've secured your perimeter, so you don't have to worry about someone planting a packet sniffer there. What about your remote users? Suppose your salespeople call the mail server to retrieve mail via POP3 or SMTP from a hotel room that has broadband access. Or maybe they need to obtain private company information from your NNTP server. While your own perimeter might be secure, you have no assurances that the networks external users are connecting from are secure.

You'll need to assign certificates to the services you want to make secure. You can create your own certificates or use a third-party certificate provider. Since the services are meant for your own employees and not for Internet users at large, in most cases you'll want to create your own certificates.

You can install the Microsoft Certificate Server in enterprise or stand-alone mode. One of the advantages of enterprise mode is you can use the MMC to obtain certificates from the certificate server. The disadvantage is that not all certificate templates are available via the Web-based enrollment site. The stand-alone Certificate Server supports all templates, but you can't use the Microsoft Management Console (MMC) to obtain certificates.

We are assuming that you have a single Windows 2000 server, since you're installing Exchange 2000 on the ISA server. In this case, you'll need to install the certificate server on the ISA/Exchange server. Perform the following steps to install the enterprise root certificate server on the ISA server computer:

Access the Windows Control Panel and open the Add/Remove Programs applet.
Click Add/Remove Windows Components.
Enable the Certificate Services option. Click Yes in the dialog box that informs you that you can't change the name of the server while certificate services is installed. Click Next.
Select the Remote Administration mode option and click Next.
Select the Enterprise root CA option and click Next.
On the CA Identifying Information page (Figure 28.12), enter the necessary information for each field. While only the CA name field is required, you should enter valid information in each field just in case you want to perform certificate mapping based on this certificate in the future. Click Next.

Figure 28.12: The CA Identifying Information Page
On the Data Storage Location page, leave the default settings as they are unless you have a compelling reason to change them. One reason to do so would be that your C: drive is lacking in space. Click Next to continue.
Click OK in the dialog box informing you that IIS must be stopped.
You might be asked for the Windows 2000 CD. If so, put the CD into the drive and follow the installer's instructions.
Click Finish. Restart the server after installing certificate services.

Assign Certificates to the Exchange Services

You can enforce secure communications with the SMTP, POP3, Web, and IMAP4 services. You can't enforce secure communications with the FTP service using server publishing rules (although you can do so using Web publishing rules and then using protocol redirection within those rules). You'll need to assign certificates to each of the services to allow secure links with the external clients.

The Web server is assigned a certificate via the Internet Information Services console. The remaining services are assigned certificates via the Exchange Management console. Let's start with assigning a certificate to the Web site. You'll use this Web site certificate later when configuring secure access to the Outlook Web Access (OWA) site.

Select Internet Services Manager from the Administrative Tools menu.
In the Internet Information Services console, expand the server name. Right-click Default Web Site and click Properties.
Select the Directory Security tab. In the Secure Communications frame, click Server Certificate.
Read the text on the Welcome to the Web Server Certificate Wizard page and click Next.
Select the Create a new certificate option and click Next.
Select the Send the request immediately to an online certification authority option and click Next. You have the option to send the request immediately to an online certificate authority because you have an enterprise root certificate server in your domain. You would not have this option if your only certificate server was a stand-alone certificate server.
Enter a "friendly" name for the Web site certificate in the Name text box and click Next. The default name is good to use here, and it will set this certificate apart from other Web sites you configure on this server. The bit length is set to 512 by default. Leave the default unless you have reasons to enforce a higher level of encryption.
Enter your Organization name and Organizational unit name.
Enter the name that external users will use to access your Web site. If you don't type in the exact name, error dialog boxes will appear when clients attempt to access the site. Type in the name for your Web site and click Next.
Select your Country/Region, and then type in your State/province and City/locally in the text boxes. Click Next.
Your certificate authority will appear in the drop-down list on the Choose a Certification Authority page. Click Next.
Review the settings on the Certificate Request Submission page and click Next.
Read the text on the Completing the Web Server Certificate Wizard page and click Finish.
When you return to the Default Web Site Properties page, you'll see that the View Certificate and Edit buttons are available. This confirms that the certificate has been assigned to the Web site. Click OK to close the dialog box.

The remainder of the services are assigned certificates via the Exchange System Manager. Assign certificates for the IMAP4, NNTP, POP3, and SMTP services here.

Perform the following steps to install a certificate on to the IMAP4 service:

Open the Exchange System Manager. Expand the server name, then expand the IMAP4 node. Right-click the Default IMAP4 Virtual Server and select Properties.
Select the Access tab, then click Certificate in the Secure communication frame.
Read the text on the Welcome to the Web Server Certificate Wizard page and click Next.
Select create a new certificate and click Next. . You have the option to assign an existing certificate, but you have more options available to you if you assign each service a separate certificate. There's no negative effect on the clients, since they'll all have the same certificate authority in their trust list.
Select the Send the request immediately to an online certificate authority option and click Next.
Enter a friendly name for the IMAP4 server certificate or accept the default settings. The default setting should work fine if you're running a single IMAP4 server on this machine. Click Next.
On the Organization Information page, the settings that you entered during the Web site certificate enrollment will be displayed. You can keep this information unless you have a reason to do otherwise. Click Next.
On the Your Site's Common Name page, type in the name of the site. For example, here we'll use the name imap4.internal.net. After entering the name of the site, click Next. The site's name is important. You need to configure the IMAP4 clients to use the common name of the IMAP4 server and not the IP address. You will see an error on the IMAP4 client if you configure the client to use the IP address of the server in the Client Configuration dialog box. You need to use an FQDN that is the same as the common name you enter on this page.
On the Geographical Information page, the information you entered during Web site enrollment is already entered. To keep this information, click Next.
Your certificate server will appear on the Choose a Certificate Authority page. Click Next.
Review the settings on the Certificate Request Submission page, and click Next.
Click Finish.
Click OK.

Repeat these steps to obtain certificates for the default NNTP, POP3, and SMTP virtual servers.

While you can obtain a certificate for the default SMTP virtual server, you should not use the certificate for that server if it is being used to accept incoming messages from public SMTP servers. However, you might want to use an SMTP service certificate to create a second SMTP virtual server on the Exchange server for your external users to use for their outbound mail server.

All of these Exchange service certificates are stored in the ISA/Exchange server's machine certificate store. You can open a Certificates MMC for the local machine store and you'll see all of the Exchange service certificates there.

Creating Server Publishing Rules for Secure Communications with Exchange Services

You can configure secure communications with the Exchange services after the certificates are installed. The default settings on the services allow both secure and non-secure communications. You can configure the services to force SSL connections. It 'is good practice to force secure communications at the server; if you don't, you're leaving it up to the clients to force the secure channel.

You can force a secure channel for the POP3, SMTP, and IMAP4 services. The NNTP service allows secure communications, but you cannot force a secure channel at the server. You have to depend on the client to use a secure channel.

Perform the following steps to force a secure channel with the Exchange POP3 server:

Open the Exchange System Manager. Expand the Servers node, then expand your server name. Expand the Protocols node, then expand the POP3 node. Right-click the Default POP3 Virtual Server node and click Properties.
Click the Access tab.
Click Communication in the Secure communication frame.
In the Security dialog box (Figure 28.13), enable the Require secure channel option. Enable Require 128-bit encryption if your clients support 128-bit encryption.

Figure 28.13: Forcing a Secure Channel to the POP3 Service
Click OK.
Click Apply, then click OK in the Default POP3 Virtual Server Properties dialog box.

Follow the same procedure for the default IMAP4 and SMTP virtual servers. You don't have the option to force a secure channel with the NNTP server. However, you can create a server publishing rule that only allows access via the secure channel. If users try to connect to the server via an open channel (i.e., non-SSL), the connection attempt will fail because there won't be a server publishing rule to support it. .

Warning

Secure SMTP server publishing does not require a separate server publishing rule. If you have a regular SMTP server publishing rule enabled, external network clients will be able to use that rule for both open and secure SMTP communications. The Exchange 2000 SMTP service employs an in-band security subsystem, allowing it to service SSL connections at the default SMTP service port, TCP 25. All other Exchange services (HTTP, POP3, NNTP, and IMAP4) require a dedicated port for SSL communications. Create only secure server publishing rules for those protocols you want to use secure communications only. For example, if you want to allow only secure POP3 access, do not create a server publishing rule that allows non-secure POP3 access.

Configure Services "Publishing" with Packet Filters

You can also publish Exchange Server services on the ISA server by using packet filters instead of server publishing rules. The advantage of using packet filters is that you don't have to disable socket pooling; the only requirement is a simple packet filter. The disadvantage of packet filters is that you can't leverage features provided by application filters. This lessens the security provided by publishing servers, since the ISA server does not examine the incoming packets for anything more than source and destination IP address and port number.

Create the packet filters listed in Table 28.1 on the ISA/Exchange server to support Exchange Server services publishing if you want to avoid creating server publishing rules.

Table 28.1: Packet Filters for Exchange Services Publishing
Protocol	IP ProtocolNumber	Protocol	Direction	Local PortNumber	Local Port	Remote Port
NNTP	TCP	6	Inbound	119	Fixed Port	All ports
IMAP4	TCP	6	Inbound	143	Fixed Port	All ports
SMTP	TCP	6	Inbound	25	Fixed Port	All ports
POP3	TCP	6	Inbound	110	Fixed Port	All ports
Secure NNTP	TCP	6	Inbound	563	Fixed Port	All ports
Secure POP3	TCP	6	Inbound	995	Fixed Port	All ports
Secure IMAP	TCP	6	Inbound	993	Fixed Port	All ports

Although you can use packet filters, we recommend that you use the server publishing rule method. Server publishing rules work, and they provide a higher level of security—and isn't a higher level of security the reason why you purchased ISA Server?

Note

You don't have manually create all of these packet filters. The Secure Mail Publishing Wizard will automatically create all of these packet filters for you. You need to tell the wizard that the server is on the ISA server. The server creates packet filters instead of server publishing rules when it knows that the Exchange server is on the ISA server.

Publishing Outlook Web Access on the ISA Server

If there's one issue that generates questions regarding ISA Server configuration, it's how to configure Outlook Web Access to work on the ISA server. The fact is that it's not that hard to get OWA to work; the problem is that there are many details to take care of in order to make it work correctly.

Many of the problems people have with OWA on the ISA server are related to issues with the Exchange server prior to Exchange Service Pack 3. Once you install Exchange Service Pack 3, the procedure is straightforward.

You need to address the following issues when publishing OWA:

Assign a certificate to the Web site
Configure the SSL listening port on the default Web site
Configure authentication properties on the OWA folders
Force a secure channel on the OWA folders
Create the OWA Web publishing rule that forces a secure connection
Configure user rights on the domain controller

We already assigned a certificate to the Web site when we ran the Web Publishing Wizard for the default Web site. Let's look at the rest of the OWA Web publishing details:

Configure the SSL Listening Port on the Default Web Site

The default Web site has a certificate. The problem is that you won't be able to use that certificate for secure communications until you configure the Web site with a port number to listen for secure requests. Perform the following steps to create the secure services listening port:

Select Internet Services Manager from the Administrative Tools menu.
In the Internet Information Services console, expand the server name. Right-click the Default Web Site and select Properties.
In the Default Web Site Properties dialog box, type 443 in the SSL Port text box. Click Apply, then click OK.

Now access a command prompt and type netstat –na | find ":443". You should see that only the internal interface is listening on TCP port 443. The incoming Web Requests listener will need to use TCP 443 on the external interface.

Configure Authentication Methods on the OWA Folders

You can use either basic or integrated authentication to authenticate against the OWA Web site. The problem with integrated authentication is that Internet Explorer 5.0x cannot use integrated authentication when accessing Web sites through the ISA server, and there are various problems with pre-SP1 versions of Internet Explorer 6.0. There might be reasons why your organization wants to run Internet Explorer 5.0x and pre-Service Pack 1 Internet Explorer 6.0. You could go ahead and upgrade all the browsers in your organization to Internet Explorer 6.0 Service Pack 1, or you can forego integrated authentication and use basic authentication instead.

The primary concern with basic authentication is that username and password information is sent in the clear. We can get around that problem by using secure SSL links. The secure channel is created before any credentials are sent over the wire when you force SSL connections to the OWA site. This obviates the security weakness inherent in using basic authentication over a public network.

Perform the following steps to configure authentication for the OWA sites:

Return to the Internet Information Services console. Make sure that the server name and the Default Web Site are expanded. The first thing you might notice is that several of the folders have red STOP signs on them. For some reason, the Exchange virtual folders don't initialize properly during system startup. We'll leave that to the Exchange gurus to explain why this happens, but all we're concerned with is getting them to work.
Click Stop in the MMC button bar and then click Start.
Click Refresh. You will see the STOP signs change into virtual directory icons.
Right-click the Exchweb virtual directory and select Properties.
Click Edit in the Anonymous access and authentication control frame.
Disable the Anonymous access option.
Disable the Integrated Windows authentication Option.
Enable the Basic authentication (password is sent in clear text) option.
Click Yes in the dialog box explaining that usernames and passwords are passed in clear text if you don't use SSL.
Click Edit.
In the Basic Authentication Domain dialog box, click Browse.
In the Browse for Folder dialog box, expand the Entire Network entry and the Microsoft Windows Network icon.
Click the Domain name for your domain and click OK.
Click OK in the Basic Authentication Domain dialog box.
Click OK in the Authentication Methods dialog box.
Click Apply in the Exchweb Properties dialog box.
In the Inheritance Overrides dialog box, click Select All, then click OK.
Click OK in the Exchweb Properties dialog box.

Perform steps 2 and 3 above for the following virtual directories:

Public
Exchange
Exadmin

A very common problem is the inability to change passwords via the OWA browser interface, the reason being that this feature is not enabled by default when you install Exchange 2000. In order to change passwords, you need to create a virtual directory for the IISADMPWD physical directory. Another requirement is that all communications with the IISADMPWD virtual directory must be done using SSL. We'll take care of those issues by forcing the Web Proxy service to use SSL to connect to all virtual folders.

Perform the following steps to create the virtual directory:

Right-click the Default Web Site and select New | Virtual Directory.
Click Next on the Welcome to the Virtual Directory Creation Wizard page.
Enter IISADMPWD in the Alias text box and click Next.
On the Web Site Content Directory page, enter the path DRIVE:\SYSTEMROOT\system32\inetsrv\iisadmpwd. Replace DRIVE with the drive your system root directory is located on, and replace SYSTEMROOT with the name of the root directory for your system files. The default for Windows 2000 is WINNT. Click Next.
On the Access Permissions page, enable the following options: Read, Run scripts (such as ASP), and Execute (such as ISAPI applications or CGI). Click Next.
Click Finish on the You have successfully completed the Virtual Directory Creation Wizard page.
Change the authentication method for this virtual directory to match the permissions you set on the other OWA directories.

Force a Secure Channel to the OWA Folders

You don't have to force a secure channel to all of the OWA Web folders. The only folder requiring a secure channel from the Web Proxy service to the Web site is the IISADMPWD virtual directory. Access to the other OWA directories can be bridged as HyperText Transfer Protocol (HTTP). The steps are the same for each virtual directory.

Perform the following steps to force a secure channel to the IISADMPWD virtual directory:

Right-click the IISADMPWD folder and select Properties.
Click the Directory Security tab in the IISADMPWD Properties dialog box.
Click Edit in the Secure Communications frame.
Enable the Require secure channel (SSL) option.
Click OK in the Secure Communications dialog box.
Click Apply, then click OK in the IISADMPWD dialog box.

You can use the same procedure to enforce secure communications with other OWA virtual directories. You might want to do this when the OWA site is on the internal network and you don't completely trust your internal network. We'll cover that scenario later in the chapter.

Configuring the Incoming Web Requests Listener and the Web Publishing Rule

We want to use an SSL link to the Incoming Web Requests listener on the external interface of the ISA server in order to ensure a high level of security. The first thing you need to do is bind the Web server certificate to the Incoming Web Requests listener. This allows the listener to impersonate the Web site and create a secure channel with the browser client.

Perform the following steps to create the Incoming Web Requests listener and bind the certificate to the listener:

Open the ISA Management console
Right-click the server name and select Properties.
Click on the Incoming Web Requests listener tab.
Select the Configure listeners individually per IP address option and click Add.
Select the server name from the Server drop-down list.
Select the external IP address on the ISA server in the IP Address drop-down list.
Enable the Use a server certificate to authenticate to web clients option.
Click Select. You'll see a number of certificates in the Select Certificate dialog box if you obtained certificates for several of the Exchange mail services.
Select the certificate that you created for the Web site and click OK.
Click OK in the Add/Edit Listeners dialog box.
Enable the Enable SSL listeners option and click OK.
Click Apply in the server Properties dialog box.
Select the Save the changes and restart the services(s) option and click OK.
Click OK in the server Properties dialog box.

Access a command prompt and enter netstat –na | find ":443". You'll find that now both internal and external IP addresses are listening on TCP port 443 (Figure 28.14). Note that this is not the same as socket pooling; different sockets are being used by the listener and the Web site.

click to expand
Figure 28.14: Internal and External IP Addresses Listen for Secure Communications

You can create the secure Web Publishing rule now that the Incoming Web Requests listener is configured. The first decision you have to make before creating the rule is what type of destination set you want to use. The easiest approach is to create a destination set for the FQDN of the server and apply this destination set to the OWA Web publishing rule. This destination set does not use paths.

A destination set without any paths works fine if you don't plan on publishing any other Web sites on the same server. However, if you want to make other content available on the same server, and you do not want to require an SSL connection to that content, then this approach won't work. In that scenario, you'll have to create a destination set for OWA that contains only the OWA directories.

If you want to create a destination set that applies only to the OWA directories, the destination set includes your FQDN and the following paths:

/exchweb/*
/exchange/*
/public/*
/iisadmpwd*
/_AuthChangeUrl*

The /_AuthChangeUrl* entry allows you to change your password via the OWA interface. Note that there is no slash at the end of the path, as there are a number of characters after this string. This isn't a virtual directory, so don't worry about trying to find it. It is something that appears in the Web Proxy logs, so you need to allow access to it. If you just include the /_AuthChangeUrl* entry with an asterisk, it will allow us to access files used for OWA online password changes.

Perform the following steps to create the destination set:

In the ISA Management console, expand the server name and the Policy Elements node.
Right-click Destination Sets and select New | Set.
Type OWA for the name of the destination set and click Add.
In the Add/Edit Destination dialog box, select the Destination option. Enter the FQDN for your site in the text box. In the Path text box, type /exchweb*.
Click OK. Repeat steps 3 and 4 four more times, adding the /exchange*, /public*, /iisadmpwd*, and /_AuthChangeUrl* paths, respectively.
Click OK in the New Destination Set dialog box.

You can create Web publishing rules now that you have the destination set:

In the ISA Management console, expand the server name and the Publishing Rule node. Right-click Web Publishing Rules and select New | Rule.
On the Welcome to the New Web Publishing Rule Wizard page, type in the name of the rule and click Next.
Select the Specified destination set option from the Apply this rule to drop-down list and select the OWA destination set from the Name drop-down list box. Click Next.
Select Any request. Users will authenticate with the Web site, so you don't need to authenticate against the Incoming Web Requests listener as well. In fact, it will not work if you try to authenticate with both the Incoming Web Requests listener and the Web site. Click Next.
On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address) option.
Enter the name of the Web site in available text box. You must use the same name the user uses to access the site. If you have your DNS servers set up to handle this FQDN, you can allow the ISA server to resolve the name. If you don't, you must put the FQDN for the site in the HOSTS file and match it up with the IP address of the internal interface of the ISA server. For example, in this rule, the external user types in the FQDN www.internal.net. We'll also put www.internal.net in the text box for the redirection. Then we'll create a HOSTS file entry for www.internal.net that resolves to the internal IP address of the ISA server.
Enable the original host header option and click Next.
Click OK.
Double-click the Web publishing rule you just created.
In the rule's Properties dialog box, click the Bridging tab.
Enable the Require secure channel (SSL) for published site option.
Enable the Require 128-bit encryption option if all of your clients support 128-bit encryption.
Click Apply, then click OK.
Return to the Internet Information Services console and restart the default Web site.

Configuring User Rights on the Domain Controller

You might wonder why we need to cover the issue of user rights in a discussion of OWA. Can't all users access the OWA machine? In most cases, you don't have to address this issue because the users can access OWA as soon as you complete the Web publishing rules. We run into problems when the OWA machine is also a domain controller. Not all users are allowed to log on to a domain controller.

A user should have the log on locally right to access resources on a Web site. Usually, the IUSR_MACHINE account has the log on locally right required to access any Web site. The problem is that you're not depending on the IUSR account; your users need to log on with their own user accounts. The default domain controller security policy does not allow all users to log on locally. If the OWA user can't log on locally, he or she will not be able to access the OWA site on the ISA Server machine.

Note

There is conflicting documentation regarding whether the log on locally right is required to access Exchange 2000 OWA sites. Article Q319888 "Access Is Denied Error Message Logging On to OWA" indicates that you must assign users who intend to connect to OWA sites the log on locally right. However, Q311422 "Log On Locally Right Not Required for Exchange 2000 OWA" says that you only need to allow users the access this computer from the network right. There are some variables that Q311422 doesn't take into account, so we recommend allowing OWA users the log on locally right. It is important to point out that it is not good general security practice to allow non-administrative users the log on locally right to the domain controller. However, in our "all but the kitchen sink on the ISA server" scenario, we have to deal with a number of security compromises.

You can fix this problem by changing the domain controller security policy. It's usually not a good idea to allow everyone to log on to a domain controller. Under normal circumstances, only administrators should be able to log on locally to a domain controller. When OWA is installed on the DC, you don't have a choice; the users must be able to log on locally. You can give all domain users permissions to log on locally, or you can create a separate group of users who need access to OWA, and grant that group the right to log on locally.

Perform the following steps to grant the log on locally right:

Select Active Directory Users and Computers from the Administrative Tools menu.

Expand the domain name. Right-click the node and select Properties.
Click the Group Policy tab.
Click the Default Domain Controllers Policy and click Edit.
Expand the Computer Configuration node and the Windows Settings node.
Expand the Security Settings node and the Local Policies node.
Click the User Rights Assignment node.
In the right pane of the User Rights Assignment node, find the Log on Locally right.
Double-click Log on Locally.
In the Security Policy Setting dialog box, click Add.
Enter the Group name in the Add user or group dialog box, or click Browse to find the user or group. Once the user or group is entered, click OK.
Click OK in the Security Policy Setting dialog box.
Close the Group Policy window.
Click OK in the Domain Controllers Properties dialog box and close the Active Directory Users and Computers window.
Access a command prompt and type secedit /refreshpolicy machine_policy and press Enter. You will see a message telling you that there will be a slight delay before machine security policy is updated.
At the command prompt, type secedit /refreshpolicy user_policy and press Enter. This will update the user policy.
Close the command prompt window.

That's it! Your configuration is now complete. The next step will test the configuration to see if it works.

Connecting to the OWA Site

The moment of truth is when you test the OWA site; it's so easy to miss just a single step. You're never sure if every configuration step has been done correctly. However, if you followed each step, and understood the reason for carrying out each step, chances are that everything will work nicely.

One thing you can do to speed up your OWA connections from Internet Explorer is to install a client certificate on the OWA client machines. This adds your CA to the Trusted Root Authorities on the client. This speeds up certificate processing quite a bit. You will also avoid an error dialog box on connecting, saying that your computer doesn't trust the CA that granted the server certificate.

Open Internet Explorer and type access the URL https://FQDN/exchange. It will take a few moments to establish the link. Type in your username and password. Note that you do not need to type in a domain name when you log in because you've configured a default domain name in the OWA folder's Authentication Properties dialog boxes. You should not be presented with a second or third dialog box; if you configured everything correctly, you will see only one.

If you received a Certificate Warning dialog box, it's probably because the name on the certificate doesn't match the FQDN you used to access the Web site. The other reason why you might get a Certificate Error dialog box is that your machine doesn't trust your certificate server's root authority. Just install a client certificate on the client and you'll fix that problem right away.

The OWA connection should not be slow if you have a decent speed link. If you're using a client with a 56K modem, performance will not be good, no matter what you do. If you find you have to wait several minutes to get a connection, or if the connection does not work at all, make sure that you have disabled integrated authentication on all of the OWA folders. If you're using the wrong version of Internet Explorer, you'll waste a lot of time trying to negotiate integrated authentication, and that won't work! You only need to support basic authentication as long as SSL is working correctly.

OWA users can change their passwords using the OWA interface; However, they must have permission to do so. If the user account properties do not allow the user to change his password, he will not be able to change his password via the OWA interface. Remember that you must also configure the /IISADMPWD directory to force SSL on connections to it by the Web Proxy service.

Troubleshooting Notes on Publishing OWA on the ISA Server

Are you having problems with your OWA configuration? There are so many steps, so many details, it's easy to miss a click here or there. Here's a list of things you should check for if you're having problems getting OWA to work:

Make sure that the OWA folders are using basic authentication only. Sometimes the permissions on the folders change when you restart the server. If you restart the server, recheck all of the OWA folders and make sure only basic authentication is enabled.
Install client certificates on the OWA clients. This is not required, but it will speed up communications a lot during the SSL negotiation phase.
Make sure you configure a default domain in the Authentication Properties dialog box for each OWA folder.
Remember to configure an SSL listener on the default Web site; IIS does not automatically enter the port for you.
Make sure you configure an Incoming Web Requests listener and bind the Web site certificate to the listener; make sure that you haven't mistakenly used the ISA server's machine certificate.
If you don't need to publish Web sites outside of the OWA site, you should just use the FQDN in the OWA destination set.

Message Screener on the ISA Server and Exchange Server

You can install the SMTP Message Screener on the ISA/Exchange/DC machine and filter both incoming and outgoing messages. The installation and configuration routine is almost the same as when you install the Message Screener on the ISA server using just the IIS 5.0 SMTP service (without Exchange Server installed). The primary difference is how messages arrive and are processed by the SMTP service.

When the Exchange server isn't installed, the IIS 5.0 SMTP service acts only as an intermediary relay server in the SMTP communication. The IIS 5.0 SMTP service always forwards the message to another SMTP server. This isn't the case when you install Exchange on the ISA server. While it's true that the Exchange server uses the IIS 5.0 SMTP service to send and receive SMTP messages, the situation is different because the Exchange server is the endpoint of the SMTP communications for incoming SMTP message. The Exchange SMTP server doesn't forward the message to another SMTP server.

The difference is subtle, but it does have practical importance. For example, if you use an SMTP client (remember that other SMTP can be SMTP clients) to send messages to the Exchange server's SMTP service, the messages will be exposed to the Message Screener. Therefore, if an SMTP server on the external network or Outlook Express on the external network tries to send an SMTP message to the Exchange server's SMTP service, the message would be exposed to the SMTP Message Screener and be filtered according to the rules you've configured for the Message Screener.

However, not all Exchange clients use SMTP to send messages to the Exchange server. Outlook 2000/XP uses MAPI to communicate with the Exchange server. When the Outlook 2000/XP client sends a message to the Exchange server, the message is not exposed to the SMTP Message Screener because SMTP was not used to send the message.

What if the message the Outlook user sent to the Exchange server is destined for an e-mail address on the Internet? For example, suppose we're using Outlook XP to connect to our Exchange 2000 server and we send an e-mail message to tshinder@isaserver.org. The Exchange server must use SMTP to send an outbound message to the SMTP server responsible for isaserver.org mail. You would expect that the outgoing messages would be exposed to the SMTP Message Screener on the way out.

The fact is that the messages are only sometimes exposed to the Message Screener when they leave the Exchange SMTP service. During our testing, it turned out that only the keyword rule on top of the list was triggered, and even then it didn't appear to be a consistent finding. It's clear that the SMTP message filter was not designed to be used in this way.

The solution to this problem is to create a second SMTP virtual server on the Exchange server machine. After you create the second virtual SMTP virtual server, configure the default SMTP virtual server to relay to the new virtual SMTP virtual server. When the message is relayed to the second SMTP virtual server, it is formatted as an SMTP message and exposes the message to the SMTP Message Screener. At this point, the outgoing messages will be filtered according to the rules you configured in the SMTP Application Filter dialog box.

The configuration is somewhat complex, but doable. You need to perform the following steps:

Disable the SMTP service.
Disable the ISA Server services.
Configure the new SMTP virtual server.
Configure the default SMTP virtual server to use the new SMTP virtual server as its smart host.
Restart the ISA Server services.
Restart the SMTP service.

Let's look at the details of this configuration:

Disable the SMTP Service

Perform the following steps to disable the SMTP service:

Access a command prompt. Type net stop smtpsvc and press Enter.
At the command prompt, type netstat –na | find ":25" and press Enter. You should see no data returned after issuing the command.

Disable the ISA Server Services

Perform the following steps to disable the ISA Server services:

Make sure that the ISA server is disconnected from the Internet before disabling the ISA Server services. Your machine is unprotected during this period and is open to Internet criminals while the ISA Server services are disabled.
At the command prompt, type net stop mspfltex and press Enter. The command will return information regarding the services that will be stopped. Press Y and press Enter.
At the command prompt, type net stop ipnat and press Enter. The command will return information telling you that the IPNAT service will be disabled. Press Y and press Enter.

Configure the New SMTP Virtual Server

Now that the ISA Server and SMTP services are disabled, the next step is to create the new SMTP virtual server. Perform the following steps to create the new SMTP virtual server:

You will need to add a second IP address on the internal interface of the ISA server. You will then bind the second SMTP virtual server to this second IP address. Right-click the My Network Places icon on the desktop and click Properties.
Right-click the internal interface and click Properties.
In the internal interface's Properties dialog box, select the Internet Protocol (TCP/IP) entry and click Properties.
In the Internet Protocol (TCP/IP) Properties dialog box, click Advanced.
In the Advanced TCP/IP Settings dialog box, click Add.
Enter a valid IP address for the internal network in the IP Address text box.
Enter a valid subnet mask in the Subnet mask text box.
Click Add.
Click OK.
Click OK in the Internet Protocol (TCP/IP) Properties dialog box and in the internal interface's Properties dialog box.
Open the Exchange System Manager. Expand the organization name and the Servers node. Expand the server name and the Protocols node. Expand the SMTP node.
You should see a red "x" on the Default SMTP virtual server entry, which is there because you disabled the SMTP service. If you don't see the red "x", click Refresh in the MMC button bar.
Right-click the SMTP node and select New | SMTP Virtual Server.
On the Welcome to the New SMTP Virtual Server Wizard page, enter a name for the SMTP virtual server. In this example we'll call it Relay. Click Next.
On the Select IP Address page, use the drop-down list to select the new internal IP address you previously configured. Click Finish.
The Relay virtual server will have a question mark on its icon. This will go away after you restart the SMTP service on the ISA/Exchange server. Right-click the new virtual SMTP server's icon and select Properties.
Click the Access tab. In the Relay restrictions frame, click Relay.
In the Relay Restrictions dialog box, select the All except the list below option. The reason why you want to select this option is that this virtual SMTP server is used by internal network clients to send outgoing mail. If you don't allow this virtual server to relay to all domains, outgoing mail to the Internet won't be relayed, and the mail won't be forwarded. External SMTP clients and servers won't be able to use this server as an open relay, because this server is not published via server publishing rules and therefore isn't directly available to external network hosts.
Click OK in the Relay Restrictions dialog box.
Click the Delivery tab.
On the Delivery tab, click Advanced.
Enter the IP address (surround by straight brackets) or the FQDN of your ISP's SMTP server in the Smart host text box. You should use your ISP's SMTP server because your machine is already overloaded running Exchange and ISA Server. There's no reason to add the burden of name resolution to your machine. Let your ISP's SMTP server handle name resolution by configuring it to be your Smart host.
Click OK.
Click Apply, then click OK in the SMTP virtual server's Properties dialog box.
Now we need to configure the Default SMTP Virtual Server. Right-click the Default SMTP Virtual Server and select Properties.
In the Default SMTP Virtual Server Properties dialog box, click the Delivery tab.
On the Delivery tab, click Advanced.
In the Advanced Delivery dialog box, enter the IP address of the new SMTP virtual server in the Smart host text box. Make sure that the IP address is surrounded by straight brackets!
Click OK in the Advanced Delivery dialog box.
Click Apply, then click OK in the Default SMTP Virtual Server Properties dialog box.

Restart the ISA Server Services

Perform the following steps to restart the ISA Server services:

Access a command prompt. Type net start IPNAT and press Enter. You will see that the IP Network Address Translator service was started successfully.
At the command prompt, type net start mspfltex and press Enter. You will either see the service start successfully, or you will see that the service has already been started.
At the command prompt, type net start isactrl and press Enter. You will either see that that the service was started successfully, or that the service has already been started.
Open the ISA Management console, expand the server name, then expand the Monitoring node. Click the Services node. Right-click the Web Proxy service and click Start. Repeat step #5 for the Firewall and Scheduled Content Download services.

Restart the SMTP Service

Perform the following steps to restart the SMTP service:

At the command prompt, type net start smtpsvc and press Enter.

At the command prompt, type in the following command:

mdutil set -path smtpsvc/2 -value 1 -dtype 1 -prop 1029 -attrib 1

The mdutil command has to be entered a second time in order to disable socket pooling for the second SMTP virtual server.
Return to the Exchange System Manager. Stop, then start the Default SMTP Virtual Server and the new SMTP virtual server using the Stop and Start buttons in the MMC console.

Notes on the SMTP Message Screener on the Exchange Server Configuration

Getting the SMTP Message Screener to work on the Exchange server takes a lot of steps, but it does work, and it works nicely with your Outlook 2000/XP clients on the internal network as well. We think you'll be very pleased with the results.

There are a couple of issues of which you do need to be aware. At the time of this writing, the SMTP application filter has a couple of flaws in it. First, you cannot send an AUTH command to the SMTP service through the SMTP application filter. This prevents users from authenticating with your SMTP service. This can and does pose a real problem for organizations that want to make their SMTP servers available to external users, but also want to prevent their servers from becoming open relays.

For example, the way we have the Exchange SMTP server set up now allows external users to send e-mail to users configured on the Exchange server. However, if the external user wants to send mail to a user outside of your Exchange organization, it won't work because the SMTP service needs to be able to relay the SMTP message to another SMTP server to deliver the message. You do not want to open your published SMTP server as an open relay, so there is no way around this problem if the user must send SMTP messages to the published Exchange SMTP server and the SMTP application filter is enabled (which it must be if you want the SMTP Message Screener to work properly). The only way around this is to send mail via another protocol. You can use OWA to send mail to outside mail domains, but you won't be able to use applications such as Outlook Express to send SMTP messages to outside domains. You could also use Exchange RPC publishing rules to solve this problem too, but these rules do not work when the Exchange server is on the ISA server.

The good news is that it's likely that the SMTP application filter will be fixed by the time you read this book. Make sure to check the news page at www.isaserver.org/shinder for details on an updated SMTP application filter.

The other problem with the SMTP application filter is that it does not support the STARTTLS command. This command is sent by SMTP clients when they negotiate a secure SSL connection with the SMTP server. This is an issue if you want to publish an SMTP server for external network users to use to send mail to a published SMTP server. Again, an updated SMTP application filter might be available by the time you read this book, so be sure to check www.isaserver.org/shinder early and often!

Finally, we encourage you to be patient with your configuration. There are a great number of steps to perform. There's a good chance that things won't work if you miss any of the details of the configuration. We know that this can become extremely frustrating! However, if you persevere and check and recheck your configuration, we can assure you that it works consistently and reliably.