Force authentication to a specific site?

[Shawn Flynn]

Our company has recently consolidated with another company and I am
attempting to setup a trust between our two Windows 2000 AD networks, but
have hit a stumbling block. Our original AD (AD1) consists of a forest with
1 domain spread across 7 sites in different geographic locations. The new
company's AD (AD2) consists of a forest with 1 domain contained within a
single site. For security and bandwidth cost reasons, the new company has
been setup with a physical link into only one of the sites in AD1 (our HQ
site). DNS is working between the new company and HQ, and each side can
"see" the other side's network. The trouble comes when I attempt to create a
trust between the two domains. It always fails with a RPC failure. It
appears that AD2 is attempting to create the trust via an AD1 server in a
site to which it has no physical connectivity (thus the RPC failure). Is
there any way to "force" AD2 to prefer talking to AD1 servers that exist in
a particular AD1 site (i.e. the site it actually can talk to)?

 

[David Brandt [MSFT]]

It sounds like your hq site will probably already have the 2kdc that holds
the pdc role, but to create the cross forest trusts, the respective pdc of
each domain will need to resolve the pdc emulator of the other so verify
that dns works properly. You should be able to ping pdcname.ad2.com and
ad2.com from a server in ad1, and vice versa. Don't know if you have
secondary dns zones created, or how it is set up between those two forests,
but rpc errors "often" are the result of name resolution problems and not
anything to do with rpc itself.
Some people will also use an lmhosts file to resolve the 1B domain name of
each pdc but in your situation, dns should be the easiest route especially
since this will be an ongoing enterprise. However if wanted, look at the
following for lmhosts 1b resolution
180094 How to Write an LMHOSTS File for Domain Validation and Other Name
http://support.microsoft.com/?id=180094;


--
David Brandt
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

 

[Shawn Flynn]

Hi David,

All fsmo roles are indeed held by servers that exist at the hq site. I
verified that with "netdom query fsmo". The PDC Emulators in each domain are
indeed the machines I thought they were. We'll call them pdce.AD1.com and
pdce.AD2.com

When I ping pdce.ad2.com from AD1 I get a response back from the expected IP
address.

When I ping ad2.com from AD1 I get a response back from the same IP address.
Which is what I would expect as there is only one server currently at that
site.

When I ping pdce.ad1.com from AD2 I get a response back from the expected IP
address.

When I ping ad1.com from AD2 I get a ping timeout and the name resolves to
an IP address of a server in one of our other sites. This appears to be
where the problem lies. Doing an "ipconfig /displaydns " on the AD2 server
shows that ad1.com resolves to every dns server in the AD1 domain (there is
a dc acting as gc and dns server in each site).

Our dns is setup such that dns.ad2.com is authoritative for the ad2.com zone
and forwards all other requests to dns.ad1.com. All dns servers in ad1.com
(one in each site) are using AD integrated dns for ad1.com zone and hold a
secondary copy of the ad2.com zone.

I wonder if the problem lies in the fact that every dns server in our sites
are authoritative and can take updates. Would this problem go away if I were
to change the dns servers in the remote sites to only hold secondary copies
of the dns zone and leave just the dns server(s) at the hq site as
authoritative?

Thanks,
Shawn Flynn

 

[Brian Mahaffey [MSFT]]

Hello Shawn,

In your situation with two AD forests that are 2000 the trusts are going to
be established using NetBIOS, you can follow the KB article that David
provided to create an LMHOSTS file on each PDC emulator. You will also need
to verify that the correct ports are opened if there is a firewall between
the two forests or any access lists on the routers. The following KB
articles should point you in the right direction.

179442 How to Configure a Firewall for Domains and Trusts
http://support.microsoft.com/?id=179442
306733 HOW TO: Create a Trust Between a Windows 2000 Domain and a Windows NT
http://support.microsoft.com/?id=306733
306733 HOW TO: Create a Trust Between a Windows 2000 Domain and a Windows NT
http://support.microsoft.com/?id=306733

--
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

 

[David Brandt [MSFT]]

That might work, but just because they can accept records, it shouldn't
affect what records they return.
Lets try to forward pdce.ad2.com to pdce.ad1.com instead of dns.ad1.com.
Also try delete the existing secondary ad1 zone on pdce.ad2.com, run
"ipconfig /flushdns", create a new secondary zone for ad1 and pull from the
pdce.ad1.com if you haven't already.

--
David Brandt
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

 

[Shawn Flynn]

David,

I was just in the process of writing a long-winded reponse to your last
message and following the steps as I wrote down what I was doing. All of a
sudden it started working. Not sure what caused it to start working, the
only things I can think of that I did differently was to specify the netbios
name for the domain when I set the trust rather than the dns name as I was
doing previously. <shrug> Maybe I should file that under "Phase-of-moon"
problem.

Thanks for helping me work through this.

-----

I've tried your suggestions below and they returned identical results to
what I was experiencing all along. I also followed the instructions in
KB180094 and set the lmhosts files on both pdce's to point at the correct
machines. Still the same results. So I went ahead and changed the dns
structure of AD1 so that only only the dns server(s) in the hq site are
authoritative. Looking at the dns zone, I no longer see the ip addresses of
the dns servers in the other sites listed as "same as parent folder". Once I
did a "ipconfig /flushdns" on pdce.ad2.com I now get the expected server's
ip address returning from a "ping ad1.com". I thought I was home free at
that point, but upon trying to create the trust, I recieved the exact same
errors.

Perhaps some further clarification on what I am seeing will help...

From pdce.ad2.com if I attempt to open a share on pdce.ad1.com, I am
presented with a username/password prompt and upon entering a valid
AD1\username I can gain access to the share. That seems to tell me that RPC
is working, and I can authenticate between the domains.

From pdce.ad1.com, I can access a share on pdce.ad2.com in the same manner
as above.

To create the trust I do the following...
* Open "AD Domains and Trusts" on pdce.ad1.com and pdce.ad2.com
* Add an entry for ad1.com under "domains that trust this domain" on
pdce.ad2.com
* Add an entry for ad2.com under "domains that trust this domain" on
pdce.ad1.com
* Add an entry for ad2.com under "domains trusted by this domain" on pdce.ad
1.com.
* I get a "The trusted domain has been added and the trust has been
verified" message on pdce.ad1.com
* Add an entry for ad1.com under "domains trusted by this domain" on
pdce.ad2.com
* Hmmm.... that's odd.... it seemed to work this time :-S


Thanks for helping. Much appreciated.
Shawn Flynn