Comments on: Establishing a trust across a firewall http://retrohack.com/establishing-a-trust-across-a-firewall/ lest the tubes become overfull Tue, 15 May 2012 22:46:35 +0000 hourly 1 http://wordpress.org/?v= By: Ed Fisherhttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-1970 Ed Fisher Fri, 29 Jul 2011 06:00:11 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-1970 You're welcome to pay me today if you want. Starbucks or Amazon gift cards are always good :-) You’re welcome to pay me today if you want. Starbucks or Amazon gift cards are always good :-)

]]> By: Renahttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-1969 Rena Fri, 29 Jul 2011 05:15:42 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-1969 A few years ago I'd have to pay seonmoe for this information. A few years ago I’d have to pay seonmoe for this information.

]]> By: Ed Fisherhttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-13 Ed Fisher Wed, 11 Feb 2009 17:58:00 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-13 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? 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?

]]> By: Pete Charnockhttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-12 Pete Charnock Wed, 11 Feb 2009 15:38:00 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-12 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.<br/><br/>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.<br/><br/>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? 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?

]]> By: Ed Fisherhttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-11 Ed Fisher Wed, 23 Apr 2008 14:31:00 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-11 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.<br/>http://support.microsoft.com/kb/314108<br/>Good luck! 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!

]]> By: Anonymoushttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-10 Anonymous Wed, 23 Apr 2008 14:25:00 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-10 Good Morning Ed,<br/><br/>Thanks for the reply and sorry for not making myself clear...<br/><br/>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.<br/><br/>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).<br/><br/>Also in our case, all 5 domain controllers are connected to a Cisco 6509E and reside in two different VLANs.<br/><br/>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.<br/><br/>Thanks!!<br/><br/>-Norin 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

]]> By: Ed Fisherhttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-9 Ed Fisher Tue, 22 Apr 2008 21:59:00 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-9 Norin,<br/>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.<br/>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!<br/>Ed 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

]]> By: Anonymoushttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-8 Anonymous Tue, 22 Apr 2008 20:21:00 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-8 Hi Ed,<br/><br/>This is a very informative and helpful post! <br/><br/>Got a quick question here, <br/><br/>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?<br/><br/>Thanks!<br/><br/>- 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

]]> By: Anonymoushttp://retrohack.com/establishing-a-trust-across-a-firewall/comment-page-1/#comment-7 Anonymous Tue, 22 Apr 2008 20:19:00 +0000 http://retrohack.com/_retroh_wp_root/?p=20#comment-7 Hi Ed,<br/><br/>This is a very informative and helpful post! <br/><br/>Got a quick question here, <br/><br/>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?<br/><br/>Thanks!!!<br/><br/>-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 each root domain?

Thanks!!!

-Norin

]]>