Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 – Part 5: Checking DNS and Certificate Settings and Installing the ISA Firewall

Tom Shinder’s Trek through Small Business Server 2003 Service Pack 1 –
Part 5: Checking DNS and Certificate Settings and Installing the ISA Firewall
by Thomas W Shinder MD, MVP



Have Questions about the article?
Ask at: http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=46;t=000096

If you missed earlier parts of this article, check them out at:

Let’s start out with a discussion of DNS settings created by the CEICW. For some reason, a DNS server address was assigned to the external interface. We need to fix this by removing the IP address from the external interface’s DNS setting and then enter the IP address of the internal interface of the ISA firewall to the internal interface’s DNS settings. We will have to add the address to the internal interface before removing the DNS setting from the external interface.

Now we need to fix the DNS server. It was at this point that I finally realized what the Router Configuration page was doing. It had nothing to do with configuring the router! The DNS server addresses you add to the Router Configuration are actually added as DNS forwarders to the DNS server on the SBS 2003 SP1 computer.

A DNS forwarder is a DNS server that can resolve DNS host names on behalf of the DNS server sending the request to the DNS forwarder. The terminology is a bit confusing, since you would think that the DNS server sending the DNS query to the DNS forwarder would be the forwarder, since it’s forwarding the request to the other DNS server. Even though that would make sense, it’s not the case. The DNS forwarder is the DNS server that resolves a name on behalf of another DNS server.

There are a number of uses for DNS forwarders. One of the most common uses for DNS forwarders is to offload Internet host name resolution from a DNS server. For example, our DNS server on the SBS 2003 SP1 computer is authoritative for i.e., responsible for resolving names in the SBS2003.local domain. Our SBS 2003 SP1 DNS server is authoritative for the SBS2003.local domain because it has a DNS zone file configured on it that includes the SBS2003.local DNS domain.

When a computer on the internal network sends a DNS query to our SBS 2003 DNS server for any host name in the SBS2003.local domain, such as server1.SBS2003.local or mail.SBS2003.local, our DNS server can answer authoritatively with the IP address of the name queried, or our DNS server can authoritatively answer that there is no record for that domain. Our DNS server doesn’t need to query other DNS servers to find the answer.

Our DNS server is not authoritative for any other domain, so it must have a mechanism in place allowing it to resolve host names in other domains. There are two ways our DNS server can do this:

  • Perform recursion and query Internet DNS servers until it finds the DNS server authoritative for the domain in question
  • Forward the DNS query to another DNS server and allow that DNS server to perform recursion

In the past I have recommended that you use your ISP’s DNS server as a DNS forwarder. The reason for this is that the DNS cache on your ISP’s DNS server is likely to be much larger than the cache on your own DNS, and thus could significantly improve DNS query performance.

However, given the increasingly popularity of DNS cache poisoning in the last year, and the fact that most ISP’s do not use Windows Server 2003-based DNS servers, I can no longer implicitly trust the security configuration of our ISP’s DNS servers. For this reason, I no longer recommend that you use your ISP’s DNS servers. Of course, if you know the people who manage your ISP, and they can confirm that they’ve adequately secured their DNS servers, you can then confidently use their DNS servers as DNS forwarders and gain the benefits therein.

On the SBS 2003 SP1 computer, open the DNS management console from the Administrative Tools menu. Right click the server name in the left pane of the console and click Properties. In the Properties dialog box for the DNS server, click the Forwarders tab.

Here you’ll see that CEICW used the DNS settings we put on the Router Configuration tab to populate the DNS forwarder IP address list. Since we don’t want to use DNS forwarders, we need to remove the IP addresses from this list. You can click on the IP addresses in this list and click the Remove button.


Figure 1

After all the IP addresses are removed from the list, your Forwarders tab will look like that in the figure below. Do not put a checkmark in the Do not use recursion for this domain checkbox. If you were to do that, the DNS server would not be able to use the entries in the Root Hints tab to resolve Internet host names. We do want the DNS server to perform recursion for all DNS domain for which this DNS server is not authoritative. Click Apply and then click OK to save the changes.


Figure 2

A quick look at the DNS console shows in the right pane the host names for which the DNS server is currently configured with. This wizard added two DNS resource records: one Host (A) record for sbs2003sp1.SBS2003.local and one CNAME (alias) record for companyweb.SBS2003.local. In addition to these two critical records, the wizard has automatically populated the DNS zone with the DNS resource records required for intradomain communications.

Close the DNS console and we’ll move our attention next to the Certificates added by the CEICW.


Figure 3

In a new mmc console, open the Certificates standalone snap-in with the focus on the local computer account. Expand the Certificates node and then expand the Personal node in the left pane of the console. Click on the Certificates node. In the right pane of the console you see the name we informed the CEICW to use for remote access to SBS hosted Web resources. This is a self-signed certificate. The wizard created the certificate and also created a CA certificate with the same name which it placed in the SBS computer’s Trusted Root Certificate Authorities node.


Figure 4

Have Questions about the article?
A URL will be added here shortly

The figure below shows a certificate with the same name in the Trusted Root Certification Authorities\Certificates node. This is interesting because I’m not used to deploying certificates in this way, as I typically use a PKI based on Microsoft Certificate Services, where machines are assigned machine certificates and users are assigned user certificates from a Certificate Server and there is a hierarchy of trust.

I’m not saying the approach SBS uses will not work, because it clearly does, but it significantly limits your security options for granular control over your certificate infrastructure. There’s no reason in the world why you should be limited to this configuration, but at this point I highly recommend that you leave this certificate infrastructure in place. In the future I’ll give you detailed information on how to bolster your PKI security by deploying a Microsoft Certificate Server.

Remember, the name on the certificate stored on the SBS 2003 SP1 is the name you must use when connecting to Web services running on the server. This name must also resolve to an IP address that can accept incoming connections to the Web services running on the SBS 2003 SP1 computer.

If your SBS 2003 SP1 computer is directly connected to the Internet and has a public IP address on its external interface, then this name must resolve to the IP address bound to the external interface. If you’re using a NAT device or a simple stateful packet inspection firewall in front of the SBS 2003 SP1 computer, then this name must resolve to the IP address on the external interface of the NAT device or simple stateful packet inspection firewall

Close the Certificates MMC.


Figure 5

Now we’re finally ready to install the ISA firewall software! Remember, we’re still working with the first scenario where I chose to not enable a firewall since I thought that if I enabled the Windows Firewall on the SBS machine, it would adversely affect the ISA firewall software configuration. Recall that this was a mistaken assumption on my part, since the CEICW should have asked if I would like to enable either the Windows Firewall or the ISA Firewall (if I planned on installing ISA later). As is typically the case when I play option button guessing games, I guessed the wrong option. However, often I learn interesting things from my mistakes, and I’m sharing those insights with you in this series of articles.

Insert the Premium Technologies CD into the SBS SP1 computer and you’ll see the autorun page appear. Click the Install Microsoft Internet Security and Acceleration Server 2004 link.


Figure 6

Click Next on the Welcome to the ISA Server 2004 Setup for Windows Small Business Server 2003 Wizard page.


Figure 7

Select the I accept the terms in the license agreement option on the License Agreement page and click Next.


Figure 8

Accept the default path on the Installation Path page and click Next.


Figure 9

Now, a surprising thing happened. The Completing the ISA Server 2004 Setup for Windows Small Business Server 2003 Wizard page appears. I thought this was pretty interesting, since I really hadn’t done any ISA firewall setup configuration yet. However, what I didn’t know at the time was that the CEICW is able to pull the settings already configured on the SBS 2003 SP1 computer and incorporate those settings to create a meaningful and effective ISA firewall configuration and firewall policy.

Click Finish on the Completing the ISA Server 2004 Setup for Windows Small Business Server 2003 Wizard.


Figure 10

Have Questions about the article?
Ask at: http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=46;t=000096

Conclusion

Have we really finished? Not a chance! But we’ll continue next week with part 6 of this article series and I’ll let you know what happens. It’s not what you think, but it will most definitely be an interesting trip. See you then! –Tom.

Editor’s note:
Due to personal circumstances, Tom will be unable to complete this series. We appreciate your understanding in this matter

If you missed earlier parts of this article, check them out at:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top