Re: Trusts between W2k domains in different forests

From: Matthew Melbourne (matt@melbourne.org.uk)
Date: 09/28/02


From: Matthew Melbourne <matt@melbourne.org.uk>
Date: Sat, 28 Sep 2002 21:31:26 GMT


In article <uqXBrKyZCHA.1496@tkmsftngp09>, Dave Shaw [Microsoft MVP]
<dhshaw@gNeOnSePsAiMs-ii.com> wrote:
>
> > We wish to grant access to resources in the Corporate Domain (Domain
> > A), particularly web-based resources which are heavily integrated into
> > the NTLM authentication model, to users in the third party domain
> > (Domain B).
>
> Certificates. Have you decided upon a PKI model?

No, not yet. Could you expand on this? I did wonder whether there was a
different way of solving this problem, without using NT/2000 trusts.
However, a requirement is to provide seamless access to resources in other
domains, without the need for an additional authentication.

> Actually, only the PDC FSMO role holders need to *find* each other.
> They are the machines that will make the trusts for the domain. To do
> this, they need to each be able to locate and determine the ip address
> of the computers in each domain holding the <1Bh> service (Domain Master
> Browser). These are the PDC emulators. To do this, you will need to
> ensure NetBIOS Name resolution of each machine to each machine.

So, only the FSMO role holders need to be defined in any firewall rulebase
which specifies "trust-related" traffic. Does that therefore mean that if
the PDC FSMO role holders become unavailable, then the trust is
effectively broken?

> > To complicated this further, a firewall exists between the two
> > networks, so network traffic associated with W2k trusts will need to
> > be permitted through the firewall. Domain A is a Windows 2000 native
> > domain consisting of a number of domain controllers and Domain B will
> > likely have a number of domain controllers too. When a one-way trust
> > is created so that Domain A trusts Domain B, which domain controllers
> > actually exchange traffic? Could it be any of the DCs, or just the DC
> > on which the trust was created, as this will dictate the firewall
> > rules.

> Create a tunnel between the two firewalls.

Setting up an IPSec tunnel between the firewalls may be an option, but we
would want to constrain traffic between the DCs to only that required to
maintain the trust, and from what I have read in various KB/TechNet
articles, setting up a trust through a firewall is non-trivial :)

Cheers,

Matt

-- 
Matthew Melbourne


Relevant Pages

  • Re: Windows Server 2003 domain trust issue
    ... That was tracked down to the Watchguard firewall at the remote ... DNS functioning (I should say that the odd thing is that there was already ... checking the status of the listed ports. ... Depending on how much you REALLY trust the other people, ...
    (microsoft.public.windows.server.dns)
  • Re: Is additional firewall necessary?
    ... deactivate any desktop firewall, but by not using such a firewall ... NOT use a feature or to NOT trust some random stranger. ... When it comes to deciding the level of security to be taken, ...
    (comp.security.misc)
  • Re: Security and the User experience
    ... Why should we trust any one/group? ... cannot get their "blessing" up or down until my submission has, ... Trimming the firewall down or pumping it up ... having to deal with security. ...
    (microsoft.public.security)
  • Re: Seperate Domain Trusts
    ... Using the trust, you can grant access to resources in DOMAIN2 by adding DOMAIN1/USER1 to the ACL. ... If in DOMAIN2 Global Groups are used to grant access to resources, you cannot add the user from DOMAIN1, as a global group can only contain members of the domain it is located in. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Trust Issues
    ... I understand both of two DCs in the same subnet and there is no firewall ... similiar function to block the port. ... other words, if you share a folder in win2k domain, are you able to select ... I ask these questions intend to know if the trust has been sucessfully ...
    (microsoft.public.windows.server.general)