Re: Windows Server 2003 domain trust issue

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).

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.

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.

Thanks again

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: AD Trusts and Firewall
    ... you can pretty much ignore the client ports in MS's example IF the domain in which a client is a member of does not have a traverse over a firewall. ... trusted domains/forests only require communication between the domain/forest in which it explicitly trusts. ... you will need to setup communication through the firewall for all ports listed under "Server Ports" in MS's documentation for all of the domain controllers on each side of any trust you create. ...
    (microsoft.public.windows.server.active_directory)
  • 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: 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: 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: Blocking Microsoft Messenger
    ... I assume you are blocking them at the firewall. ... or you didn't block all ports to the IP addresses you ... If you have a DNS server [or have one or two Windows 2000 servers where DNS ...
    (microsoft.public.security)