Publishing MAPI RPCs with ISA Server

Microsoft Internet Security and Acceleration (ISA) Server product is a software- based firewall. As such, Microsoft had to come up with some way to distinguish it from inexpensive firewall appliances like the SonicWALL SOHO/3 and Symantec’s Internet Security Appliance. Their solution was to add some integrated features that make ISA work better with other Microsoft products. Accordingly, ISA integrates with Active Directory, it includes a slick firewall client that lets you restrict access by protocol and by user, and so forth. For Exchange administrators, ISA offers some key features beyond the other Windows integration features. First is the ability to publish Exchange servers to the Internet. This doesn’t sound like a big deal in and of itself, because even a $75 router can perform port forwarding. However, ISA goes beyond port forwarding by allowing you to proxy IMAP, POP, and SMTP traffic (optionally screening it for content) to an Exchange server—which can be a front end. You’ll learn more about publishing Internet protocols with ISA in Chapter 14. However, the other primary ISA bonus is its ability to accept and inspect Microsoft RPC traffic—meaning that you can publish your Exchange server so that Microsoft Outlook clients can connect directly across the Internet without VPN, dial-in, or Outlook Web Access—just pure Outlook. Users love this feature, because it makes Outlook available to any user who can get connected to the Internet— mobile users get all the benefits of Outlook’s roaming user support.

Before you can use ISA Server to publish Messaging Application Programming Interface (MAPI) RPCs, you’ll have to get ISA installed and configured—a relatively straightforward task that is nonetheless outside the scope of this book. However, the basic steps you’ll need to follow are well-documented in the ISA documentation and at http://www.isaserver.org. You’ll need to do the following:

1. Prepare your ISA server’s hardware. Normally, this means you’ll set up a computer with two network interface cards (NICs) in its own workgroup, not your production domain.

2. Install ISA (either Enterprise or Standard Edition) in integrated or firewall mode—in caching-only mode, ISA can’t publish Exchange.

3. Set up your DNS infrastructure so that outside clients can correctly resolve the DNS name of your Exchange server. For example, if your Exchange server is named CYCLONE, and your domain is fabrikam.com, you’ll need to make sure that cyclone.fabrikam.com has a valid address record—Exchange returns the client name to Outlook, and it needs to match the name Outlook is using.

Once you can successfully resolve the IP address of your Exchange server, you’re ready to proceed with the ISA and client configuration.

Creating the Publishing Rules

When you’re publishing a server with ISA, the normal practice is to use the server publishing interface (look in the ISA Management console under the Server Publishing Rules node). However, because most Exchange administrators want to publish multiple protocols on their servers, ISA includes the Mail Server Security Wizard, by far the easiest way to publish your server. (Note that to publish Outlook Web Access, you’ll need to follow the instructions in Chapter 14, which revolve around the conventional server publishing tools in ISA.)

Begin by launching the ISA Management application, expanding your ISA server in the left-hand node, and navigating through the Publishing node to the Server Publishing Rules container. Right-click that container and select Secure Mail Server; that launches the wizard. The first interesting page in the wizard is the Mail Services Selection page, shown in Figure 11-17. The layout of this page is pretty straightforward: you can choose whether to publish the standard and SSL-secured versions of the IMAP, POP, Network News Transfer Protocol (NNTP), and SMTP protocols. For SMTP, you can choose to publish inbound or outbound protocols independently of one another, and you can turn on SMTP content filtering. The key item for our purposes is the Incoming Microsoft Exchange/Outlook check box, which tells the wizard to create an RPC publishing rule when selected. Make sure it’s selected, then click Next.

Figure 11-17: Pick the mail protocols that you want to publish.

The next page asks you for the external address of the ISA server. This, of course, is the IP address of the external interface that outside clients will connect to. Type it, then click Next to move to the Internal Mail Server page. In this page, you specify the internal LAN IP address of the server that you’re publishing. Once you’ve done so, that’s it for the server publication! You can verify that the services you wanted got published by checking the Publishing list (look in the Publishing | Server Publishing Rules container).

Allowing the Exchange Server to Proxy Authentication Traffic

During normal network operations, when a Microsoft Outlook 2000 or later client connects to an Exchange 2000 server, the server returns a referral record that tells the client to contact an Active Directory server. This approach works great on LANs, but with ISA it can be problematic unless you’ve taken care to publish all of the authentication-related services. There’s an easier shortcut, which is to tell the Exchange server not to issue referrals—when you add the right registry key, the Exchange server performs directory lookups and authentications on behalf of the client and return the results over the RPC connection—just like it would for Microsoft Outlook 97, OpenMail, the Mac version of Outlook, or any other non- Active Directory–aware MAPI client.

To make this work, you’ll need to add a DWORD value named No RFR Service to the system attendant’s key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters and set the value to 1. After adding the key, restart the Microsoft Exchange System Attendant service (and its dependent, the Microsoft Exchange Information Store service). Be forewarned that adding this key puts some additional load on your Exchange server, because you’re making it do the authentication itself.

Configuring Outlook

Of course, you’ll have to configure Outlook to use the server. If your Exchange server and the address record that clients use to resolve it have the same name, you’re in good shape; if not, you’ll need to provide a way for the client to resolve it. For example, let’s say that your Exchange server’s NetBIOS name is mailman, and that its FQDN is mailman.contoso.local. If the public name is also mailman, you have no worries. When the client contacts the server, and the server returns the NetBIOS name, the client will be able to use it. If, however, the name the client provides in the profile creation dialog box is different, you’ll need to do one of two things: put a HOSTS file on the client that ties the name the client knows back to the public IP address of the NIC on the ISA server, or create an address record on your public DNS server with the appropriate name.

Once that’s done, setting up Outlook is straightforward: the process is identical to creating a new profile and mail account for use on a LAN, except that you plug in the FQDN of the Exchange server (or its public IP address) instead of just the NetBIOS name.

What About New Mail Notification?

Exchange and Outlook use a dynamically chosen UDP port to send new mail notification messages. You’ve probably noticed that if you’re behind a firewall or network address translation (NAT) device your mail notifications don’t appear unless you press F5 or F9; that’s because the client either doesn’t know what port to listen on or traffic on that port is blocked.

How can you solve this problem? The easiest way is to tell ISA to open up ports 1024 through 65535 outbound from the Exchange server to the Internet. To do this, create a protocol definition for TCP port 135 outbound, plus TCP ports 1024 through 65535 as secondary outbound ports. This might be somewhat more permissive than you’d prefer. If you don’t want to open those ports, you can use Outlook’s scheduled send/receive feature to force the client to update every five minutes or so—this gives you the effect of the new mail notification feature without opening so many ports.