Creating a 2003 AD external trust through a firewall

by Pber November 07, 2009 15:50

 

Recently I had to create an external trust through a firewall to a domain in a DMZ.  I found an article from Microsoft titled: "How to configure a firewall for domains and trusts”.  After looking at the insane number of ports required, I figured there must be a better way.  So here are the steps I took to create a working trust.

 

Requirements:

  •  Minimum amount of ports open in firewall.
  •  IPSEC can't be used for various reasons.
  • Pure DNS resolution and NetBIOS over TCP/IP is disabled.
  • All servers are Windows 2003.
  • Active Directory integrated DNS.

Step 1:  Configuring the firewall

 

If you gave that Microsoft article to your Network Administrators and asked them to open up all those ports on the firewall they would laugh and kick you out of their office.  So how can we get around opening up so many ports?  Well to be honest, most of the ports listed are what you call dynamic ports.  Initial communication for a service usually initiates over a few select ports and then subsequent communication occurs over one of these dynamic ports.  You may think this could be a bigger challenge to communicating over a firewall as now we have to deal with random ports.  This is where stateful firewalls come into play.  A stateful firewall keeps session information about each of its connections.  So once initial communication is established for a given service, the stateful firewall can trust that service connection over a different port since it already trusted that same connection over the previous port.  That's a very simplistic description, but what it means is that we really only need to open the few select ports required for initial communication and the dynamic ports will be handled by the stateful firewall functionality.

 

Here's a shortlist of the minimum amount of ports:

 

            Port          Protocol          Service

             53           TCP/UDP         DNS

             88           TCP/UDP         Kerberos

             389         TCP/UDP         LDAP

             445         TCP                 SMB

             636         TCP                 LDAP (SSL)

 

Unfortunately we still have to enable UDP communication for DNS, Kerberos and LDAP.  This is due to the RFC spec for those services.  We can force Kerberos to use TCP which would remove the UDP requirements for that port.  Subsequent RFC implementations in Vista and Server 2008 already force Kerberos to use TCP.

 

Now if you present this small list back to your Network Administrators, chances are they'll listen to you.  These days almost everyone is using stateful firewalls, so be sure to mention that dynamic port are still used.  You can further have them lock down the firewall rule by specifying the hosts or subnets that the rule allows.

 

Step 2: Getting the domains to find each other

 

One of the many challenges I see is administrators can't get the domains to talk in the first place even without a firewall.  Since we are using pure DNS resolution and no NetBIOS over TCP/IP how do we do this?   There are two ways to make the domains find each other using DNS: Conditional forwarders or stub zones. 

 

Conditional Forwarders

 

Just like with normal forwarding that is typically setup to forward internet requests to your ISP’s DNS servers, conditional forwarders do the same thing except you specify the domain that you are forwarding.  Both settings are configured in the same place in the Forwarders TAB on each DNS server.  Normal forwarders are configured to forward “All other DNS domains”.  To specify a conditional forwarder, you just specify the DNS zone of the domain you are trying to trust.

 

Stub Zones

 

A Stub zone is a read only zone that downloads just enough DNS information from the target DNS zone just to resolve authoritative DNS servers.  It shows up in your DNS servers forward or reverse zones just like other zones, but it's a read only and just contains HOST (A) records for the DNS servers.  So if you try and resolve a DNS zone that is a stub zone, your DNS server will pass the DNS request to the DNS servers in the stub zone and return the resolution back to the client.

 

I personally prefer to use stub zones because they only need to be configured once when you use AD replicated zones.  Each other DNS server will automatically obtain the stub zone.  Forwarders need to be configured on each DNS server separately.  Stub zones also automatically obtain updated HOST information from the master stub zone via zone transfers.  Conditional forwarders will have to be manually updated on every DNS server manually if things change.  Another added benefit of a stub zone is you get event log entries as well as visual indication if things aren’t working, once again with conditional forwarders you do not.

 

You will need to configure a conditional forwarder or stub zone on each domain pointing to the opposite domain in order for each domain to find each other when creating the trust.

 

Step 3: Creating the trust

 

Now that your firewall is working and your DNS zones are configured.  The external trust should be easy.  Just load Active Directory Domains and Trusts, Select your domain and right click and select properties.  Select the Trust tab, and then select New Trust.  You should be able to specify the FQDN of the domain you are trying to create the trust with and just follow the remaining steps to complete the trust.

 

Good luck and I hope this helps. 

 

Update:  Check out this blog entry regarding RPC filters and how they can help with firewall rules

 

Tags: , ,

Active Directory

Comments (1) -

12/1/2009 3:27:06 PM #

Thanks for your help!  I actually configured this today with a windows 2008R2 domain controller to have an external trust with a windows 2003 domain controller.

Michael Rodriguez United States

Pingbacks and trackbacks (1)+

Comments are closed

Powered by BlogEngine.NET 2.0.0.36
Theme by Mads Kristensen | Modified by Pber