Designing DNS to Support Remote Outlook MAPI Client Access to Exchange via Secure Exchange RPC Publishing

What do you think is the killer app that makes ISA Server 2000 the must have firewall for your network? Some of the things on my list would include:

It’s the last feature, the secure Exchange RPC publishing, that is my killer app. I don’t travel a lot, but when I do, I always make sure that I get a “unfirewalled” connection to the Internet. I’ll turn on the Windows XP Interface Connection Firewall and then start Outlook. No VPN, no pseudo “SSL VPN”, no nothing. Just start Outlook and it works just like it does on the internal network. On a broadband hotel network, its just like being in the office – quick, responsive, and just like the “in office” experience.

Creating a secure Exchange RPC Publishing Rule is easy. All you need to do is create a Server Publishing Rule using the Exchange RPC filter. The details on how to do this are included in my article on secure Exchange RPC publishing over at http://www.msexchange.org/tutorials/2003exchangerpc.html. The problematic issues with getting this to work are:

Ever since the recent outbreaks of RPC exploits against unpatched Windows machines, firewall administrators have dedicated to help alleviate the problem by blocking outbound access to TCP 135, which is the RPC endpoint mapper that these exploits take advantage of to spread themselves. While I consider it ridiculous to permanently close a particular TCP or UDP port to stop exploits (with that type of thinking, you should close TCP 21, 80, 110, 119 and 443 because those ports also commonly carry exploits), most firewall admins aren’t aware that ISA Server firewalls completely protect networks from these exploits, so they just leave the ports closed.

I’ve had more than a few knock down drag outs with recalcitrant firewall admins, but they all relent and then my Outlook “just works” again. My hats off to those firewall admins who actually installed an ISA Server firewall to protect their network from inbound and outbound RPC attacks!

The DNS issues are more common and represent the number one cause, in my experience, of why ISA firewall admins end up giving up on secure Exchange RPC publishing. Outlook DNS name resolution just never seems to work right, and when they try to solve the problem, very strange, inexplicable things happen. They finally throw up their hands in defeat after visiting the Microsoft Web site and TechNet and find no information on how Exchange and Outlook deal with name resolution issues.

So we all agree that one of the most difficult aspects of setting up remote access for the Outlook 2000 client is configuring DNS support for the remote MAPI client access. The Outlook client must be able to do the following:

When configuring the Outlook MAPI client, you must enter the name of the Exchange Server into the Microsoft Exchange server text box as seen in the figure below. Notice in this example that I have entered mail.internal.net in the text box. I entered this name because the POP3, IMAP4 and SMTP sites can all be accessed via the name mail.internal.net. So, to be consistent, I enter the same name for the Microsoft Exchange server. The user name is entered in the Mailbox text box.

You might have noticed that strange things happen after you click the Check Name button. In this example the mail.internal.net entry in the Microsoft Exchange server text box changed to BEEXCHANGE2003. The name, BEEXCHANGE2003 is the actual computer name (or NetBIOS name), of the Exchange Server on the internal network. When the Outlook MAPI client connects to the Exchange Server (either while on the internal network or via the secure Exchange RPC filter), the computer/NetBIOS name is returned to the client.

From this point onward, the client must be able to resolve the computer/NetBIOS name of the Exchange Server, regardless of the location of the Outlook MAPI client. The reason is that the client longer uses the original entry you put into the Microsoft Exchange server text box; it uses the name returned by the Exchange Server.

For example, you saw in the figure above that the original entry mail.internal.net was changed to BEEXCHANGE2003. From this point forward, the Outlook 2000 MAPI client will not be concerned with the name mail.internal.net, the client will need to be able to correctly resolve the name BEEXCHANGE2003.

Perform the following steps to determine the primary DNS suffix of the machine:

1. Right click on the My Computer icon on the desktop and click the Properties command. In the System Properties dialog box, click the Network Identification tab. On the Network Identification tab, click the Properties button.

Notice on the Network Identification tab shows the Domain name as internal.net. This is the name that will be appended to unqualified requests. In our example above, BEEXCHANGE2003 would be fully qualified to BEEXCHANGE2003.internal.net and then the request will be send to the DNS server for name resolution.

On the Identification Changes dialog box, you have the option to add or remove the computer from a Windows domain. The primary DNS name of the client is the same as the domain the machine belongs to (by default). If the machine belongs to a workgroup, there will be NO default primary domain name assigned to the client.

Click the More button on the Identification Changes dialog box.

2. The DNS Suffix and NetBIOS Computer Name dialog box appears.

The entry in the Primary DNS suffix of this computer text box contains primary domain name of this machine. This is the name this machine will append to unqualified requests. Therefore, in our example above, a request for BEEXCHANGE2003 will be fully qualified by appending the internal.net domain and a request to resolve BEEXCHANGE2003.internal.net will be sent to the DNS server for name resolution.

Note the Change primary DNS suffix when domain membership changes checkbox is enabled by default. This allows the machine to fully qualify unqualified names using the domain name of the domain the machine belongs to. If the machine is a member of a workgroup, then there will be no default entry in the Primary DNS suffix of this computer text box.

If the computer is a member of a workgroup, you can manually add the domain name you want the client to append to the unqualified request in this Primary DNS suffix of this computer text box. This will allow your client to append the correct domain name to the computer/NetBIOS name of the Exchange Server.

3. You will need to restart the computer after making changes to the machine’s primary domain name membership.

You can simplify the assignment of a primary DNS suffix by configuring the DHCP server’s scope to assign clients a primary DNS suffix. While this option isn’t available to you when you don’t have control of the remote DHCP server, it is very useful when the Outlook client that is not a member of the correct domain needs to connect to the Exchange Server on the internal network.

For example, suppose the machine is a member of a workgroup called workgroup and no one has configured a Primary DNS Suffix for the computer. The machine will not be able to fully qualify the Exchange Server’s computer/NetBIOS name and the DNS name resolution request will fail.

You can solve this problem for your internal network clients by configuring them to use DHCP and configuring the DHCP server with the DHCP option that issues a primary domain name to the DHCP clients. Now the Outlook client will be able to fully resolve the computer/NetBIOS name of the Exchange Server, as well as now being able to resolve the computer/NetBIOS name of the Global Catalog Server if you entered only the computer/NetBIOS name (you do have the option of entering a FQDN for the Global Catalog Server in the Registry).

Perform the following steps to configure the network interface to support DNS suffix assignment via DHCP:

1. Right click on the My Network Places icon on the desktop and click the Properties command. In the Network and Dial-up Connections window, right click on the network connection and click the Properties command.

2. In the connection’s Properties dialog box, select the Internet Protocol (TCP/IP) entry in the list of Components checked are used by this connection dialog box and click the Properties button.

3. Click the Advanced button in the Internet Protocol (TCP/IP) Properties dialog box.

3. In the Advanced TCP/IP Settings dialog box, click the DNS tab.

The default setting on the network interface is Append primary and connection specific DNS suffixes and Append parent suffixes of the primary DNS suffix. The Append primary and connection specific DNS suffixes option allows the machine to fully qualify an unqualified name by appending the primary DNS suffix to the unqualified name and appending a connection specific DNS suffix to the name.

This option allows the machine to be assigned a connection specific DNS suffix via DHCP. Note that if you do not have a DHCP server to assign a connection specific DNS suffix, or if you want to override the DHCP server’s connection specific DNS suffix, you can enter a DNS suffix in the DNS suffix for this connection text box.

The Append parent suffixes fo the primary DNS suffix checkbox allows the client to append the primary DNS suffix and parent domains of the suffix. For example, suppose the Exchange Server is named BEEXCHANGE2003 and the machine belongs to the dev.internal.net domain. The Exchange Server’s name will be fully qualified in two ways: the first way using the complete primary domain name BEEXCHANGE2003.dev.internal.net and the second way using the parent of the primary DNS suffix BEEXCHANGE2003.internal.net. This increases the probability of resolving the name of the Exchange Server because the Exchange Server can belong to the parent domain without the client belonging to the parent domain.

4. You will not need to restart the machine if you change these settings. Just click OK on the dialog boxes and return to the Network and Dial-up Connections window.

Another way to fully qualify unqualified requests is to append a list DNS suffixes that the client can use.

1. Right click on the My Network Places icon on the desktop and click the Properties command. In the Network and Dial-up Connections window, right click on the network connection and click the Properties command.

2. In the connection’s Properties dialog box, select the Internet Protocol (TCP/IP) entry in the list of Components checked are used by this connection dialog box and click the Properties button.

3. Click the Advanced button in the Internet Protocol (TCP/IP) Properties dialog box.

3. In the Advanced TCP/IP Settings dialog box, click on the DNS tab.

Select the Append these DNS suffixes (in order) option. You can enter a DNS suffix by clicking the Add button and entering it into the TCP/IP Domain Suffix dialog box (not pictured). These DNS suffixes will override the primary DNS suffix assigned to this computer, as well as any hard coded or DHCP assigned connection specific DNS suffix.

4. You will not need to restart the machine after adding a DNS suffix search list. Just click OK in the dialog boxes and return to the Network and Dial-up Connections window. The changes take place immediately.

The Importance of the Split DNS and an Example

Keep in mind that the Outlook 2000 client must be able to resolve both the Exchange Server’s actual computer/NetBIOS name and the hard coded Global Catalog server you configured in the Registry. The computer must be able to do this regardless of its location so that users have a “Outlook Just Works” experience.

Regardless of the version of Outlook you use, you need to make sure that the Outlook clients can connect automatically regardless of their location. You do this with the help of a split DNS infrastructure. When the Outlook client is connected to the internal network, behind the ISA Server firewall, the client will use an internal DNS server that resolves the Exchange Server’s name to the machines internal IP address. On the other hand, when the Outlook client is connected to an external network, the Exchange Server and the Global Catalog server names must resolve to the IP address on the ISA Server firewall that you used in your secure Exchange RPC Server Publishing Rule.

The DNS infrastructure is referred to as a “split” DNS because the same domain name is used on the internal and external network. The only difference is the content of the zone files containing those domains.

For example, you can use the domain name domain.com on the internal network and domain.com to host Web and mail services accessible to hosts on remote networks and the Internet. The internal and external network hosts access the same server, the only difference is the path they take. The internal network client directly connects to the resource located on the internal network, while the remote client connected via the secure Exchange RPC Server Publishing Rule using the public address on the ISA Server firewall.

The split DNS allows users to move between remote and internal networks completely transparently; Outlook Just Works because the users don’t have to reconfigure the Outlook client application when the change between internal and external networks. On the other hand, if you use different domain names for resources located on the internal network and resources accessible from an external location, the probability of frustrating client application reconfiguration issues increases geometrically. That’s why I recommend that you use the same domain name internally and externally.

Let’s take one final look at the example we saw above. We’ll look at the Outlook 2000 client in this example, since it’s the most problematic. The Outlook 2000 client is configured with a new profile and we configure the client to use the Global Catalog server GlobalCatalog in the Registry. We then create a new Outlook 2000 profile and enter the name mail.internal.net in the Microsoft Exchange server text box and a user name in the account text box. We click Check name and the computer/NetBIOS name of the Exchange Server appears in the Microsoft Exchange server text box, which is in this case is BEEXCHANGE2003.

The machine is a laptop that one of our sales staff uses when connected to the corporate network and when traveling around the country. While you want to join all the machines to the corporate domain to enhance administrative control and network security, you haven’t been able to do so yet. However, you have configured your DHCP server to assign a primary domain name to DHCP clients. In addition, you have hard coded the domain name internal.net in the adapter’s DNS suffix for this connections text box.

You have a DNS server on the internal network on which you have created a zone containing the internal.net domain. In the internal.net domain you have created a Host (A) resource record for BEEXCHANGE2003 so that the name BEEXCHANGE2003.internal.net resolves to the IP address 10.0.0.2. You have also created a second Host (A) address record for GlobalCatalog so that the name GlobalCatalog.internal.net resolves to 10.0.0.3 (which is the IP address of the Global Catalog server).

You have a second physical DNS server that has a zone containing the internal.net domain. This DNS server can be located on your internal network and be published by the ISA Server firewall so that its accessible to Internet hosts, or you can allow a third party, such as your ISP, host this external DNS zone responsible for the internal.net domain. In this externally accessible internal.net domain you have created a Host (A) resource record for BEEXCHANGE2003 so that the name BEEXCHANGE2003.internal.net resolves to the IP address 131.107.0.1. You have also created a second Host (A) address record for GlobalCatalog so that the name GlobalCatalog.internal.net resolves to 131.107.0.1. This IP address, 131.107.0.1, is the IP address on the external interface of the ISA Server firewall that you used in the secure Exchange RPC Publishing Rule.

Now the elements are all in place to support the Outlook 2000 clients regardless of their location. If the Outlook 2000 client is on the internal network, it will be able to query the internal DNS server for the names of the Exchange Server and the Global Catalog server. When the Outlook 2000 client is connected to an external network, it will be able to query the externally accessible DNS server (either the DNS server you published with ISA Server firewall Server Publishing Rules or one located on your ISP) and receive the public address on the external interface of the ISA Server firewall that you used in your secure Exchange RPC Server Publishing Rule.

As you can see, the split DNS infrastructure creates an “Outlook Just Works” situation. Your users just need to turn on their computers, open Outlook 2000, and connect to their message store. It just works because you designed and configured your DNS smartly.