Hi there. Today, lets discuss setting up a trust between two domains when they are separated by a firewall. There are several KB articles about this, but none of them (in my opinion) give quite enough detail about how to set this up. I will try to do a better job. For purposes of this discussion, lets take two AD environments as pictured below.
Domain FOO and Domain BAR are separated by a Cisco ASA firewall. You need to establish a trust between the two domains. Note that newly creating one domain as a child of the other will require the same basic connectivity, though you will want to expand your permits so that the new domain can contact all dc’s in the parent domain within the same site, and any FSMO role holders. Since I cannot address EVERYTHING in this post, let’s make certain assumptions…
- You are a domain admin in both domains
- You have level full enable mode access to the ASA
- Though there is a firewall here, there is NO NETWORK ADDRESS TRANSLATION. Remember, NAT is evil. Say it. SAY IT BIATCH! NAT IS EVIL!!!
Okay, there is a valid time and place for NAT, but this is NOT it. Microsoft does NOT support trusts across NAT, and neither do I. - All the rules will be based on the addressing shown in the diagram above.
- Statics necessary for traffic between the interfaces are already setup, as is any necessary routing. We will only be discussing ACL entries in this post.
- The necessary name resolution, which includes both host name and NetBIOS name resolution, is already set up. You have an appropriately designed DNS, and either a healthy WINS environment, or you are using LMHOSTS files.
At a minimum, we need to permit the following types of traffic between the two PDCe’s; Kerberos, RPC, NetBIOS, LDAP, SMB, and PING. See How to configure a firewall for domains and trusts for the KB article that this post is based upon. Note that ICMP will be used by the dc’s, as will both LDAP over both udp and tcp. While Kerberos will favour udp, it may need to use tcp based on either the total size of the PAC, or on fragmentation issues on the network. In other words, YES, you need to permit both tcp and udp for 88 and 389. And also remember, tcp 135 is only the RPC end point mapper. RPC services using tcp will bind by default to any port above 1024, so you need to permit them all unless you restrict RPC to a specific range. See below for more on that.
On our ASA, we will have at least two access-lists. The one controlling traffic from the FOO side will be called aclFOO, and the one controlling traffic from the BAR side will be called aclBAR. To permit the necessary traffic, configure your ACLs as follows…
access-list aclFOO permit udp host 172.16.20.15 host 10.80.7.81 eq 53
access-list aclFOO permit udp host 172.16.20.15 host 10.80.7.81 eq 88
access-list aclFOO permit udp host 172.16.20.15 host 10.80.7.81 range 137 139
access-list aclFOO permit udp host 172.16.20.15 host 10.80.7.81 eq 389
access-list aclFOO permit tcp host 172.16.20.15 host 10.80.7.81 eq 53
access-list aclFOO permit tcp host 172.16.20.15 host 10.80.7.81 eq 88
access-list aclFOO permit tcp host 172.16.20.15 host 10.80.7.81 eq 135
access-list aclFOO permit tcp host 172.16.20.15 host 10.80.7.81 eq 389
access-list aclFOO permit tcp host 172.16.20.15 host 10.80.7.81 eq 445
access-list
aclFOO permit tcp host 172.16.20.15 host 10.80.7.81 eq 636
access-list aclFOO permit tcp host 172.16.20.15 host 10.80.7.81 range 1024 65535
access-list aclFOO permit icmp host 172.16.20.15 host 10.80.7.81
access-list aclBAR permit udp host 10.80.7.81 host 172.16.20.15 eq 53
access-list aclBAR permit udp host 10.80.7.81 host 172.16.20.15 eq 88
access-list aclBAR permit udp host 10.80.7.81 host 172.16.20.15 range 137 139
access-list aclBAR permit udp host 10.80.7.81 host 172.16.20.15 eq 389
access-list aclBAR permit tcp host 10.80.7.81 host 172.16.20.15 eq 53
access-list aclBAR permit tcp host 10.80.7.81 host 172.16.20.15 eq 88
access-list aclBAR permit tcp host 10.80.7.81 host 172.16.20.15 eq 135
access-list aclBAR permit tcp host 10.80.7.81 host 172.16.20.15 eq 389
access-list aclBAR permit tcp host 10.80.7.81 host 172.16.20.15 eq 445
access-list aclBAR permit tcp host 10.80.7.81 host 172.16.20.15 eq 636
access-list aclBAR permit tcp host 10.80.7.81 host 172.16.20.15 range 1024 65535
access-list aclBAR permit icmp host 10.80.7.81 host 172.16.20.15
Now, if you want to test this out before you try to actually setup the trust, there is a very cool tool from MS called PortQueryUI. It is a simple port mapper, but with the added benefit of a pull down menu that can do all the AD related tests at once. You can download it from here.
http://www.microsoft.com/downloads/details.aspx?familyid=8355e537-1ea6-4569-aabb-f248f4bd91d0&displaylang=en
It is self contained, and makes no modifications to your system. Run the exe on the PDCe of each domain. This will extract fi
ve files to c:\portqryui. From that directory, run the portqueryui.exe file to get the GUI. Enter the fqdn or ip.addr of the ‘other’ PDCe in the destination field. The default tests are for domains and trusts, so the only thing to do next is click the Query button.
Once it runs, review the output. You should see that all the required tcp ports are LISTENING, all udp ports are LISTENING OR FILTERED, RPC services are successfully enumerated, and that ldap anonymous BINDs are successful and dump the ROOTDSN data. You may see tcp 42 (WINS) is not listening if the PDCe is not a WINS server. As long as you have NetBIOS name resolution setup through other WINS servers or using an LMHOSTS file, you’ll be okay. Carefully parse the RPC services listed to make sure that there are no errors. Some older firewalls do not understand the enhance RPC syntax Windows 2003 uses post SP1, and will ‘kill’ that traffic. If you see some RPCs enumerated, and others with errors, you have a firewall killing RPC traffic. Either upgrade the code on the firewall, or see this article to disable the enhanced RPC.
Finally, you may encounter firewall admins who stroke out when you ask them to open up all the ports for RPC. In that case, you can restrict RPC to a range of ports in a number of ways. See the following articles for more information on that and adjust the range statements in your acl’s as necessary.
How to configure RPC dynamic port allocation to work with firewalls
Information on the registry values that can modified to allow more controlled use of RPC through a firewall. the article also gives some recommendations on the minimum number of ports to keep open to prevent possible RPC endpoint exhaustion. Be careful here…I have seen many times when the range configured is inadequate for the needs of the system. I would suggest a range of 1000 ports as a good starting point.
Active Directory Replication over Firewalls
An extensive guide to configuration of a firewall for AD replication. Includes examples and step by step sections, as well as background information on the process. This also includes details on using IPSEC to ensure that the communication is more secure. Of course, if you choose to go the IPSEC route, you will need to configure the acl’s to permit that traffic. That means udp port 500, and ip types 50 and 51.
I hope you find this useful!
here endeth the lesson
No related posts.
{ 9 comments… read them below or add one }
Hi Ed,
This is a very informative and helpful post!
Got a quick question here,
if we have multiple domain controllers in each root domain, do we still only include the PDCes of each domain on the ACLs or do we have to include every domain controller in each root domain?
Thanks!!!
-Norin
Hi Ed,
This is a very informative and helpful post!
Got a quick question here,
if we have multiple domain controllers in each root domain, do we still only include the PDCes of each domain on the ACLs, or do we have to include every domain controller in the root domain?
Thanks!
- Norin
Norin,
I almost think that you are referring to trusts between separate forests since you mention root domains. This post is only discussing external trusts between domains, which are NOT transitive. Two root domains of separate forests can trust one another, but this will not pass through to child domains unless you establish forest transitive trusts, which I believe requires both to be at FFL 2003 or 2008.
As long as we are only talking about two domains, you only need the PDCe’s permitted in the ACLs, but you may find that connection attempts are made to/from other domain controllers as they try to do authentication of trusted accounts. Make sure that all DCs that may have to process an authentication request can resolve the NetBIOS names of the other domain’s PDCe. Thanks for checking in!
Ed
Good Morning Ed,
Thanks for the reply and sorry for not making myself clear…
Basically, we have two forests. Forest A has only one domain – a.local which has only one domain controller. Forest B has only one domain – b.local which has 4 domain controllers.
We need to establish a one-way external trust between a.local and b.local (a.local is the trusting, and b.local is the trusted).
Also in our case, all 5 domain controllers are connected to a Cisco 6509E and reside in two different VLANs.
So that’s why I wanted to know if we need to permit the traffic between a.local’s PDCe and all domain controllers of b.local or just between the two PDCes.
Thanks!!
-Norin
Then it sounds like you are all set…again, just make sure that the PDCs can resolve one another’s NetBIOS names. The LMHOSTS file creation tool is pretty useful, since it ensures that you have the proper number of null characters in any name <15 characters in length, and maps the correct GROUP names for the domain.
http://support.microsoft.com/kb/314108
Good luck!
Using a cisco ASA you can also use the inspect feature to dynamically map the RPC endpoints so you don’t have to open 100s of ports.
Your comment about NAT is valid and it’s a pain but often descisions from networks created years ago are the problems of today and a NATd network may be one of them. The ASA can allow a trust through a NAT using the inspect fetaure, static nat entries for DC’s and a manually bodged DNS zone with the NAT addresses.
When I did some similar tests I was also suprised to find it wasn’t just the DCs that were talking to each other across the trust. The terminal server I configured was also directly contacting the DCs in the trusted domain. I thought it would and should work in the way your ACLs are configured and just the DCs would communicate. Did you test beyond running diagnostic tools on each DC?
Static DNS entries and ASA’s inspect are both good workarounds to an otherwise impossible situation, however, MS will not support that, and you may find that extended RPC functions (post W2K3 sp2 and later) will still fail. For domain migrations, I have found it easier to establish an intermediate domain natively accessible by both and do a two-step migration. For resource access, ILM, ADFS et al work out well (application dependencies aside.) As to your TS server…I haven’t seen that. Was it trying to reach a licensing server registered in the environment or coded in its registry?
A few years ago I’d have to pay seonmoe for this information.
You’re welcome to pay me today if you want. Starbucks or Amazon gift cards are always good