Re: Windows Server 2003 domain trust issue




"ScottK" <ScottK@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:138EBDA2-93B7-43A1-B2B0-B5E47371B1D7@xxxxxxxxxxxxxxxx
Thanks Herb,

at the start of play yesterday we were lacking DNS resolution in one
direction. That was tracked down to the Watchguard firewall at the remote
end
from me and after an explicit allow was added for UDP & TCP port 53 we had
DNS functioning (I should say that the odd thing is that there was already
an
allow all rule on the firewall for both directions - clearly something was
overriding it).

I don't know that firewall but some firewall rules are "last one wins"
others use "most specific wins".

Then there is the reverse (answer rule) and the reverse direction
for the request and response through the firewalls at BOTH ends.

Easy for someone to leave one of those out or get the order/specificity
wrong.

In doing some further digging, yesterday afternoon I determined that the
same firewall was also blocking a whole bunch of other ports - for anyone
else reading this with a similar problem, take a look at this link:

http://technet2.microsoft.com/windowsserver/en/library/108124dd-31b1-4c2c-9421-6adbc1ebceca1033.mspx?mfr=true

and this one:

http://support.microsoft.com/kb/179442

MS Portqry V2 (downloadable from the MS download center) is very handy in
checking the status of the listed ports.

Depending on how much you REALLY trust the other people, you might
be better off with a VPN or IPSec (mandatory) tunnel from router to
router (i.e., net to net) and just let the machines communicate freely over
that virtual link.

I have asked the admin at the other end to explicitly allow the relevant
ports.

Once that is done I will get WINS up and running and see where we stand.
I'm
pretty confident that the ports blocking issue is the cause of our
problems
as everything else appears to be running correctly.

Of interesting note, we have an IPSEC VPN between the Watchguard and my
local Cisco PIX. The pix has an allow all rule that does just that,
whereas
the Watchguard seems to like to overlap policies.

I'll let you know the outcome of today's work.

Good.

And good luck.

Scott

"Herb Martin" wrote:


"ScottK" <ScottK@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3D9DCD4D-76AE-455B-876C-D5ADEF55504D@xxxxxxxxxxxxxxxx
Hi all,

We are in mid corporate merger and need to get the domains of each corp
linked up - hence the need for a trust. To cut a long story short, we
appear
to have full DNS resolution from both ends via conditional forwarding
(after
pinning down a firewall issue blocking port 53 traffic). We can ping
any
server/client machine by name without a problem.

However, while one end can step through the trust creation wizard
without
a
problem, the other end bombs out as soon as you enter the remote domain
name
with a "The name you specified is not a valid Windows domain name"
dialog.
We
are then prompted to say if this is a Kerberos V5 trust or a WIndows
domain -
choosing the latter then drops out with a "specified domain name cannot
be
contacted message".

How does THAT (failing) domain's DNS resolve the DCs of
the other (working) domain?

Walk that manually and explicitly with NSLookup using specific
servers. Prove it works.

nslookup dcX.otherdomain.com EachIP.ofLocal.DNSServers


Having Googled half to death, we have checked SRV records for both ends
and
all seems as it should, the _msdcs DNS zone folder is present at both
ends,
both domains are at Win2k3 native functional level.

Were the trusts created in BOTH directions?

Is it an External or Forest trust? (Both are possible in Win2003+ FFL but
only Domain trusts are possible in lower forest functional levels.)

You might also want/need to setup WINS-NetBIOS resolution;
this is semi-required for EXTERNAL trusts and is helpful anyway.

I've thought about setting up some sort of WINS replication between the
two
sites, but surely that shouldn't be needed in a ntaive 2k3 setup.

Yes, it is if you want BROWSING to work anyway. Browsing is
a legacy NetBIOS service.

WINS is (practically) needed for NetBIOS when you have more
than one subnet.

Remember that EXTERNAL trusts were designed MOSTLY with
NT domains in mind although they work just fine between domains
of different forests.

How many domains in each forest? External trusts are NON-transitive
and must be explicitly created with each domain you wish to use in
the other forest.

Suggestions are very welcome as we need this up and running by the end
of
the week.

Double check the DNS across the firewalls. UDP(and perhaps TCP)
53 requests plus responses in each direction.

Someone might have done TCP without UDP or forgot the return
direction and is looking at a one way filter.

Or a filter that only allows requests in one directions.

Prove they work with explicit NSLookup commands (this won't prove
TCP but UDP is your primary concern anyway.)







.



Relevant Pages

  • Re: Windows Server 2003 domain trust issue
    ... at the start of play yesterday we were lacking DNS resolution in one ... That was tracked down to the Watchguard firewall at the remote end ... checking the status of the listed ports. ... Were the trusts created in BOTH directions? ...
    (microsoft.public.windows.server.dns)
  • Re: DNS and Domain problem
    ... > problems and they added themselves into DNS. ... > and seperated by a firewall. ... I'm able to ping from this server to ... ports that need to be allowed pass thru. ...
    (microsoft.public.win2000.dns)
  • Re: dns server behind a firewall?
    ... I only have one public address, and there was no firewall before. ... No additional changes on my w2k dns console? ... > (DNS server) address on ports 53. ...
    (microsoft.public.windows.server.dns)
  • Re: DNS and DHCP
    ... I checked my McAfee Firewall and made sure that it trusts my DNS addresses, ... > problems where the personal firewalls, for some reason, have to trust the DNS ...
    (microsoft.public.windowsxp.network_web)
  • Re: One Way TRUST Through Firewall problem
    ... I've allowed all ports on the firewall and added static routes to both ... You mean ideas other than establishing that it is or is not RPC? ... I have a one way trust domain setup between two windows 2003 forests ...
    (microsoft.public.security)