Publishing OWA and Outlook RPC/HTTP with ISA Server 2006 EE Firewalls using Forms-based Authentication (Single Member Array without NLB): Part 2: DNS and Certificate Deployment Issues

If you would like to read the other parts in this article series please go to:

In the first part of this series on how to publish OWA and RPC/HTTP using ISA Server 2006 firewalls, I went over the design goals of the article series and explained the scenario and lab environment on which the configuration and testing is done.

In this, part 2 of the series, I’ll discuss two key issues that plague ISA firewall admins: DNS considerations and certificate deployment issues. These two areas of ISA firewall and network security design are responsible for the vast majority of configuration errors and frustrations experienced by ISA firewall admins. I know that you want to get into the meat of how to configure the ISA firewall to publish OWA and RPC/HTTP sites, but I can’t stress strongly enough how important these issues are and that you must have a good understanding of DNS and certificate related issues before you begin your ISA firewall Web services publishing trek.

NOTE:
If you are already well acquainted with DNS and certificate related issues in configuring secure Web Publishing Rules with ISA firewalls, then you can skip this article and wait until next week for part 3, where we get into the meaty details of configuring the ISA firewall.

In particular we’ll focus on the following issues:

  • The value of a split DNS infrastructure
  • The split DNS infrastructure in this article series
  • The importance of certificate naming conventions

The Value of a split DNS Infrastructure

Of all the issues in ISA firewall networking, the one that most commonly disturbs people are those that center around discussions of a split DNS. I’ve never been able to figure out why ISA firewall admins are so resistant to the split DNS infrastructure. However, if I had to guess, it might be related to one of more of the following misconceptions:

  • They believe they need to rename their internal network domains – patently false
  • They think there is an adverse security impact – unabashedly false
  • They think DNS is so difficult to understand that the idea of further complicating the issue puts them over the edge – might be true for some people

The truth is that a split DNS can make your life and your user’s lives much simpler. When you have a split DNS infrastructure in place you achieve the following:

  • Users never need to remember to use different names based on the user’s current location. The same name is used when the user is located on the corporate network and when the user is located somewhere on the Internet or a partner site
  • Client applications never need to be reconfigured based on the users current location. Outlook MAPI clients, SMTP clients, POP3 clients, IMAP4 clients, browser Web clients, FTP clients, and more never need to be reconfigured. The same server name settings on the corporate network are used when the user is located outside the corpnet.
  • Internal hosts never need to loop back through the corporate firewall to access resources located on the corporate network. One of the bests ways to reduce the ISA firewall’s performance is to allow hosts on ISA firewall Protected Network to loop back through the ISA firewall to access servers on the corporate network. The split DNS insures that you never make this performance draining error.
  • You can keep your current Active Directory domain name. The split DNS doesn’t require you to rename your internal domain(s). You can add new DNS domains that are used to exclusively support your split DNS infrastructure without disturbing your Active Directory related DNS. 
  • All versions of the full Outlook MAPI client (97/98/200/2002/2003) will “just work”. A user can be in the corporate office, suspend his laptop, and then open the laptop in a hotel room 5000 miles away and Outlook automatically connects to the Exchange Server on the corporate network. The user never has to reconfigure the Outlook client and his current location is totally transparent when it comes to application access to corporate network resources

How the Split DNS Infrastructure Makes Life Better for all ISA Firewall Admins

A split DNS makes resources you want accessible to both internal and external users location independent. The location independence makes it possible for users to use the same name to access corporate information resources regardless of location. The user never needs to remember separate URLs or server names for when the user is located on the corpnet or when connecting from somewhere on the Internet.

Let’s take a look at an example. A user is located on the corporate network and needs to access a SharePoint Portal Server using the URL https://sps.domain.com. Using a split DNS infrastructure the user will be able to use https://sps.domain.com when connecting to the same SharePoint Portal Server from a location somewhere on the Internet.

Another important example is for Outlook Web Access (OWA). When the user is on the corpnet he uses the URL https://owa.domain.com/exchange to access the OWA Web site. Using a split DNS infrastructure the user will be able to access the OWA Web site from the Internet using the same URL, https://owa.domain.com/exchange.

The split DNS infrastructure works because there are two or more DNS servers hosting zones authoritative for the same domain name. One or more of the DNS servers is responsible for name resolution for hosts located on the corporate network, and one or more DNS servers is responsible for name resolution for hosts located on the Internet.

ATTENTION:
This is a key distinction – DNS servers that resolve names for external hosts are never accessible to internal hosts. DNS servers that resolve names for internal hosts are never accessible to external hosts. They are completely separate of internal and external DNS servers and zones is what enables the split DNS to provide the application location transparency we desire.

The DNS server responsible for name resolution on the corporate network (the internal DNS server and zone) contains DNS resource records mapping server names to their internal network IP addresses, which are typically the actual addresses used by the servers on the corporate network. I say “typically” because there may be internal NAT devices in the path. The DNS server responsible for name resolution for Internet users resolves names to a public IP address allowing inbound access to the corporate resource. This public IP address could be bound to the external interface of the ISA firewall and used by a Web or Server Publishing Rule or could be bound to a NAT device located in front of the ISA firewall.

Some resources that might be accessible to both internal and external network users include:

  • Outlook Web Access Web sites Users want to use the same URL when connecting to OWA regardless of whether they are on the corpnet or somewhere on the Internet.
  • Sharepoint Portal Server Web sites Users want to use the same URL when connecting to SharePoint Portal Service sites regardless if they’re located on the corpnet or somewhere on the Internet.
  • Generic Web sites hosting corporate information The same applies here – users don’t want to remember different names based on their current locations. They want to use the same names no matter where they are.
  • Exchange MAPI client access Split DNS is critical for secure Exchange RPC publishing. Without a well designed split DNS, you won’t be able to fully leverage the security, mobility and transparency provided by Secure Exchange RPC publishing.
  • POP3 servers There are a lot of people who continue to provide POP3 access. POP3 client configuration can be complex for the average users. How much would you save in Help Desk calls if the user never had to reconfigure his POP3 client based on his current location?
  • SMTP servers Many companies provide SMTP server access to both internal and external users. Think about how much your Help Desk could save if they didn’t have to waste time helping users reconfigure their SMTP server settings whenever they leave the office?
  • IMAP4 servers A lot of companies use IMAP4 clients. You’ll see that the split DNS infrastructure provides the same benefits as those found with the POP3 clients. No more Help Desk calls for changing IMAP4 server settings when those users leave the office.
  • NNTP servers Same goes here. No NNTP client reconfiguration issues when the users leave the office.
  • Terminal Servers Remote access to terminal services is increasingly popular. While you can provide your users with an IP address to use when they’re connected to the corporate network and another address to use when on the Internet, how about providing them a simple FQDN that works regardless if they located at work or on the Internet?
  • SSL VPN gateways SSL VPN is a hot topic and getting hotter by the day now that Microsoft has bought Whale. A split DNS is going to be your key to success for any and all SSL VPN deployments you participate in.

Details of a Split DNS Deployment

Let’s look more at our split DNS infrastructure design for an OWA and SharePoint deployment. You have Exchange and SharePoint Portal Servers on the corporate network. On the internal DNS server you create two Host (A) records in the mydomain.net DNS zone:

  • owa.mydomain.net This record maps to a private IP address of the server on the corporate network or a gateway address on the corporate network that enables access to this server, as in the case of an internal NAT device
  • sps.mydomain.net This record maps to private IP address of the server on the corporate network or a gateway address on the corporate network that enables access to this server, as in the case of an internal NAT device

On the public or external DNS server for the mydomain.net domain, you also create two Host (A) records:

  • owa.mydomain.net This record maps to a public IP address that enables access to the internal OWA site. This IP address can be a public address bound to the external interface of the ISA firewall, or to the public IP address bound to a front-end NAT device that is NATing between the Internet and the external interface of the ISA firewall
  • sps.mydomain.net This record maps to a public IP address that enables access to the internal SharePoint site. This IP address can be a public address bound to the external interface of the ISA firewall, or to the public IP address bound to a front-end NAT device that is NATing between the Internet and the external interface of the ISA firewall

Now let’s look at how clients resolve the names of these servers. The corporate network uses DHCP to assign IP addressing information to network hosts. The DHCP server assigns the IP address of the internal DNS server to hosts on the corporate network. The DNS servers assigned to the corporate network hosts are authoritative for mydomain.net. When users on the corporate network connect to owa.mydomain.net, a DNS query to the Internal DNS server provides the clients with the internal address of the OWA server. Users directly access the OWA site on the corporate network, bypassing the firewall or any other device used to provide public access to the OWA site.

When users move from the corporate network to an external network, they connect to the external network LAN or ISP and receive IP addressing information via DHCP. The external host is assigned via DHCP a DNS server that can resolve Internet host names. When the external network user connects to owa.mydomain.net, the DNS server provides the external network client the public address you configured for that resource in the external DNS server authoritative for the mydomain.net domain.

The figure below shows the DNS and connect actions for both internal and external hosts utilizing the split DNS infrastructure.


Figure 1

  1. An external laptop sends a DNS query to an external DNS server for the name owa.mydomain.net. The DNS servers resolves the name by querying other Internet DNS servers
  2. The DNS server returns the public IP address of owa.mydomain.net to the external client
  3. The external client sends a request to the public IP address provided by the DNS server. This is the address used to make the internal server available to external users. In this request is an HTTP host header for owa.mydomain.net
  4. The ISA firewall must be able to resolve the name of the internal DNS server based on the common/subject name configured on the OWA site’s Web site certificate. In this example, the OWA server has a certificate with the subject/common name owa.mydomain.net (note that this has nothing to do with the actual name of the server and bears no relationship to the machine’s NetBIOS name or Active Directory FQDN). The ISA firewall is configured to use the internal DNS server and resolves the name owa.mydomain.net to the internal IP address of the OWA site.
  5. An internal users wants to access the internal OWA site. The internal OWA client sends a DNS query to the internal DNS server for owa.mydomain.net to the internal DNS server. The OWA client on the internal network then sends a request to the internal IP address for the OWA server which was provided by the internal DNS server.

The above example shows how the user never needs to remember different names to reach the same resource, regardless of the user’s current location.

WARNING:
There is a lot of confusion regarding the role of Active Directory in a split DNS infrastructure. Your split DNS infrastructure can be integrated with your Active Directory domain, or you can create a separate and distinct DNS infrastructure for your split DNS. Keep in mind that while Active Directory has dependencies on DNS, DNS has no dependencies on Active Directory. For this reason, you can create a robust split DNS infrastructure without disturbing or involving your Active Directory DNS naming conventions.

The Split DNS Infrastructure in this Article Series

In this article series I deployed a pure split DNS infrastructure, where the internal Active Directory domain name is the same as the domain names used by external users to access the site. This is not a requirement and I could have deployed a parallel split DNS infrastructure, where the Active Directory domain name is different from that used to access the sites.

This is an important issue and I should explain what I mean here before moving on. There are two general types of split DNS infrastructures you can deploy:

  • What I’ll call the pure split DNS infrastructure, where the internal Active Directory domain name is the same as the domain name used by external users to access internal resources
  • Another that I’ll call the parallel split DNS infrastructure where the Active Directory domain name has nothing to do with the split DNS infrastructure used for your secure remote access solution

The parallel split DNS infrastructure will be attractive to those who are using illegal second level domain names (such as the dreaded .local domain) or who for invalid security reasons believe that a pure split DNS infrastructure is insure (it’s not, but there are a lot of security “experts” out there who don’t understand the security implications and provide this patently false advice). The parallel split DNS infrastructure is relatively easy to configure, but you do need to do a bit more footwork.

Parallel split DNS infrastructures work with the same basic principles of an internal DNS and external DNS supports the same domain names, with the internal DNS providing internal name resolution and the external DNS providing name resolution for external clients on the Internet. The only difference here is that you need to create a new DNS zone on your internal network to support this.

For example, consider the following:

  • The internal Active Directory DNS domain name is corp.net
  • Some security “expert” bamboozled management into not allowing you to use the corp.net domain name for secure remote access connections
  • You already have an external domain name that you want to use, called externalcorp.net for your secure remote access connections

In the example, you create a new zone on your internal DNS server for the externalcorp.net domain. You then enter resource records for all the servers on the corporate network that will be accepting incoming connections from external users. You do not need to replicate your entire internal DNS system, you only include records for published servers. While in larger environments this might be construed to have too much administrative overhead, I think you’ll find that this is not the case since server IP addresses are static and rarely change.

On the external side of the DNS, you don’t need to change anything. If you already have an external DNS zone setup for the externalcorp.net domain, then you’re all set. Adding the internal zone has no effect on external zone configuration. This is true for both pure split DNS configurations and parallel split DNS setups.

End to End Split DNS Naming Convention

In the lab configuration we’ll use in this article series, I’ll be using a subset of the pure split DNS infrastructure by using an end to end split DNS naming convention. In the end to end split DNS naming convention, the FQDN external users use to access the published Web servers is the same name that the ISA firewall uses. The only difference is that the external users are connecting to the published Web servers via a public IP address, and the ISA firewall connects to the servers via their private IP addresses.

We use the public name owa.msfirewall.org in our Web Publishing Rule for the OWA and RCP/HTTP Web Publishing Rule. The ISA firewall will also be configured to use the same name, owa.msfirewall.org when forwarding the connection to the back-end Exchange Servers. I do this out of convenience and not out of necessity. This is a misconception that you have to use an end to end naming scheme and that isn’t true. However, if you do not do so, it can have potential complications for your split DNS infrastructure and remove most of the utility it provides.

For example, I could have configured the external users to use owa.msfirewall.org to connect to the published OWA and RPC/HTTP site, but then configure the ISA firewall to forward the connection as mail.msfirewall.org. That would work fine, but it would break our split DNS infrastructure because users, when located on the Internet, would have to remember to use owa.msfirewall.org and when those users return to the corpnet they would have to remember to use mail.msfirewall.org. Since the entire point of using a split DNS infrastructure is to avoid this problem, it makes little sense to use an end to end naming scheme.

There is another problem with not using an end to end split DNS naming scheme and that has to do with certificates and the common/subject name on these certificates. We’ll discuss this issue in the next section.

The Importance of Certificate Naming Conventions

Let’s continue with our previous example to see why certificate name conventions are critical in a split DNS infrastructure. As seen in that example, our lab network users will be able to access the OWA and RPC/HTTP Web sites using the name owa.msfirewall.org when they are on the internal network behind the ISA firewall and also when they’re located somewhere on the Internet. This is because we’re using an end to end split DNS naming convention.

Now let’s suppose that we don’t use an end to end split DNS naming convention system. In this case the common/subject name on the Web site certificate bound to the Web listener publishing the OWA and RPC/HTTP sites is owa.msfirewall.org. Because we’re not using and end to end split DNS naming scheme, we’ll bind a certificate to the OWA and RPC/HTTP proxy server with the name mail.msfirewall.org. What do you think the implications of this configuration will be?

  • External users will be able to use the name owa.msfirewall.org to reach the OWA and RPC/HTTP Web sites because the Web listener is listening for connections to owa.msfirewall.org and the common/subject name on certificate is owa.msfirewall.org.
  • The ISA firewall is configured to forward connections to mail.msfirewall.org because this is the name on the Web site certificate bound to the OWA and RPC/HTTP Web site. The name mail.msfirewall.org resolves to the actual IP address of the Web site on the internal network (assuming there are no internal NAT devices in the path)
  • Internal users use the name mail.msfirewall.org to connect to the OWA and RPC/HTTP Web site because this is the common/subject name on the certificate bound to the site. Internal users are able to connect because the request is for a site with the same name as on the Web site certificate
  • Users must now remember to use https://owa.msfirewall.org/exchange when connecting from an external location and https://mail.msfirewall.org/exchange when connecting from an internal location.
  • In addition, users must now remember to reconfigure their Outlook RPC/HTTP configuration based on their location. When the users are located on the Internet, they must configure their Outlook client to connect to owa.msfirewall.org and when they are located on the internal network, they must configure the Outlook client to connect to mail.msfirewall.org or use MAPI connections, which is actually the default setting.

The situation isn’t so dire for the RPC/HTTP clients, as they should be configured to use MAPI RPC when connected to the corporate network, but we all know from experience that things often don’t work out that cleanly and sometimes the RPC/HTTP connection is used on the corpnet when it shouldn’t be (busy network with relatively high latencies). The situation is critical for the OWA users, who now have to remember to use different names based on their location.

Certificate naming conventions are critical because they determine your success or failure when configuring the ISA firewall and published Web servers for secure connections. Some things to consider regarding certificate naming conventions:

  • The common/subject name on the certificate must be the same as the name used by the client to connect to the site. If a client connects to http://owa.domain.com the common/subject name on the certificate must be owa.domain.com
  • The common/subject name on the certificate bears no relationship to the actual computer NetBIOS or DNS name. However, in order to connect to the server, there must be a DNS entry for the common/subject name on the certificate bound to the Web site or Web listener because this is the name users use to connect to the server. For example, a computer’s Active Directory DNS name might be serverA.domain.com but the Web site certificate bound to the Web site has the common/subject name mail.domain.com. A DNS entry is required for both these names but have the same IP address
  • Multiple Web Publishing Rules can forward to the same name, even though they are listening on Web listeners that have different certificates using different common/subject names. For example, Web listener 1 is listening for connections to rpc.msfirewall.org and Web listener 2 is listening for connections to mail.domain.com. The Web Publishing Rules using these Web listeners can both be configured to forward connections to the same secure site that uses a Web site certificate with the common name exchange.msfirewall.org

As you can see in these examples, certificate names and DNS configuration are dependent on one another. A broken DNS will break a correctly configured certificate infrastructure and a broken certificate infrastructure will break a well designed DNS infrastructure.

Summary

Before deploying an ISA firewall solution for secure publishing of OWA and RPC/HTTP Web sites you need to consider both DNS and certificate naming issues. The best DNS solutions for secure remote access to OWA and RPC/HTTP sites is the pure split DNS infrastructure, with the parallel split DNS infrastructure a close second. A very poor DNS design solution for secure remote access to OWA and RPC/HTTP sites is to use completely different names for internal and external access which requires users to remember to use different names base on their current location.

Certificate naming is closely allied with your DNS infrastructure. The common/subject name on the certificate must match the name the user uses to connect to the site. When publishing secure Web sites using ISA firewalls, the external user must use the name on the Web site certificate used in the Web Publishing Rule’s Web listener, and the ISA firewall must connect to the published Web server using the name bound to the published Web site.

In the next article in this series we’ll get to the fun stuff — configuring the ISA firewall to publish a Web farm of front-end Exchange Servers. See you then! –Tom.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top