Forum Search:
Forum.Brain-Cluster.com: Brain Cluster Technical Forum
Ultimate forum for Technical Discussions

Home » Microsoft » Windows Server » Active Directory » AD trust routing issue
AD trust routing issue [message #359990] Tue, 05 January 2010 11:15 Go to next message
Sawyer  is currently offline Sawyer
Messages: 315
Registered: July 2009
Senior Member
Hello all

I have a two way transitive trust configured between two separate 2003 AD
forests. ForestA has 3 AD sites, and each AD site has two DC's in it.
ForestB has one AD site. From site1 in forestA I can ping the forestB by its
FQDN and I can validate the trust. From site2 in forestA I cannot ping
forestB by FQDN I get a request time out. I can however from site2 and site1
in forestA ping the FQDN of the DC in forestB, but I cant validate the trust
from Adsite2, probably because I cant ping the FQDN of the forestB. The zone
I have created for forestB is a stub zone.

So it looks like any DC in ADsite 2 cannot validate the trust, and therefore
any workstation or servers in ADsite2 would have issues authenticating users
from forestB because these servers are using the DC/DNS in ADsite2. The stub
zone is AD integrated and has replicated to all DNS\DC in foretA.

Example
my workstation is in ADsite2 if I try and go to \\forestB.com\sysvol I
cannot access the folder nor can I see it. If I do the same thing from a DC
in ADsite1 I can open \\forestB\sysvol. This to me means that there is a
routing issue from ADsite2 to forestB and therefore the trust is not in
place from any server or workstation that is in this site

Does this sound correct?
Re: AD trust routing issue [message #360013 is a reply to message #359990] Tue, 05 January 2010 11:30 Go to previous messageGo to next message
florian  is currently offline florian  Germany
Messages: 484
Registered: July 2009
Senior Member
Howdie!

sawyer schrieb:
> I have a two way transitive trust configured between two separate 2003
> AD forests. ForestA has 3 AD sites, and each AD site has two DC's in it.
> ForestB has one AD site. From site1 in forestA I can ping the forestB by
> its FQDN and I can validate the trust. From site2 in forestA I cannot
> ping forestB by FQDN I get a request time out. I can however from site2
> and site1 in forestA ping the FQDN of the DC in forestB, but I cant
> validate the trust from Adsite2, probably because I cant ping the FQDN
> of the forestB. The zone I have created for forestB is a stub zone.

So this all boils down to a DNS issue, correct? Why'd you configure a
stub zone for forestB? Is that information on site2's DC? I'd recommend
you try to create DNS forwarder and have DNS requests for forestB's FQDN
be forwarded by all DNS servers (DCs) to DCs in the forest root domain
of forestB (put all forest root DCs in there for fault tolerance).

Cheers,
Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
ANY advice you get on the Newsgroups should be tested thoroughly in your
lab.
Re: AD trust routing issue [message #360034 is a reply to message #360013] Tue, 05 January 2010 12:05 Go to previous messageGo to next message
Sawyer  is currently offline Sawyer  United States
Messages: 315
Registered: July 2009
Senior Member
Yea I guess I could create a forwarder but really at the end of the day
whats the difference between a forwarder and a stub zone? both will aid me
in establishing the trust. The stub zone for forestB is AD integrated so its
available on all DNS\DC in forestA. This is not a DNS issue but a routing
issue, has I can resolve the name from a workstation in ADsite2 but it does
not reply.

"Florian Frommherz [MVP]" <florian@frickelsoft.DELETETHIS.net> wrote in
message news:OuaA$VjjKHA.2188@TK2MSFTNGP04.phx.gbl...
> Howdie!
>
> sawyer schrieb:
>> I have a two way transitive trust configured between two separate 2003 AD
>> forests. ForestA has 3 AD sites, and each AD site has two DC's in it.
>> ForestB has one AD site. From site1 in forestA I can ping the forestB by
>> its FQDN and I can validate the trust. From site2 in forestA I cannot
>> ping forestB by FQDN I get a request time out. I can however from site2
>> and site1 in forestA ping the FQDN of the DC in forestB, but I cant
>> validate the trust from Adsite2, probably because I cant ping the FQDN of
>> the forestB. The zone I have created for forestB is a stub zone.
>
> So this all boils down to a DNS issue, correct? Why'd you configure a stub
> zone for forestB? Is that information on site2's DC? I'd recommend you try
> to create DNS forwarder and have DNS requests for forestB's FQDN be
> forwarded by all DNS servers (DCs) to DCs in the forest root domain of
> forestB (put all forest root DCs in there for fault tolerance).
>
> Cheers,
> Florian
> --
> Microsoft MVP - Group Policy
> eMail: prename [at] frickelsoft [dot] net.
> blog: http://www.frickelsoft.net/blog.
> ANY advice you get on the Newsgroups should be tested thoroughly in your
> lab.
Re: AD trust routing issue [message #360299 is a reply to message #360034] Tue, 05 January 2010 16:20 Go to previous messageGo to next message
Jorge Silva  is currently offline Jorge Silva
Messages: 398
Registered: July 2009
Senior Member
Hi
>>> I have a two way transitive trust configured between two separate 2003
>>> AD forests. ForestA has 3 AD sites, and each AD site has two DC's in it.

Ok

>>> ForestB has one AD site. From site1 in forestA I can ping the forestB by
>>> its FQDN and I can validate the trust. From site2 in forestA I cannot
>>> ping forestB by FQDN I get a request time out. I can however from site2
>>> and site1 in forestA ping the FQDN of the DC in forestB, but I cant
>>> validate the trust from Adsite2, probably because I cant ping the FQDN
>>> of the forestB. The zone I have created for forestB is a stub zone.

- Ok, How many DCs do you have in Forest B?
- Do you have subnets in Forest B equal to any existing subnet in Forest A
(including Site 1 and 2)?
- Go to Advanced TCP/IP settings and select the option "Append these DNS
suffixes (in order):" and add both (FQDN of Forest A and B), then clear the
cache by running ipconfig /flushdns and restart the DNS service. Try again,
does that change anything?
- To narrow this issue you should also run a network sniffer to check which
server is being contacted and what paths are being taken. Tracert and
pathping should also help you with that task.

--

I hope that the information above helps you.
Have a Nice day.

Jorge Silva
MVP Directory Services

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.




"sawyer" <occompguy@cox.net> wrote in message
news:OJkE$njjKHA.2184@TK2MSFTNGP04.phx.gbl...
> Yea I guess I could create a forwarder but really at the end of the day
> whats the difference between a forwarder and a stub zone? both will aid me
> in establishing the trust. The stub zone for forestB is AD integrated so
> its available on all DNS\DC in forestA. This is not a DNS issue but a
> routing issue, has I can resolve the name from a workstation in ADsite2
> but it does not reply.
>
> "Florian Frommherz [MVP]" <florian@frickelsoft.DELETETHIS.net> wrote in
> message news:OuaA$VjjKHA.2188@TK2MSFTNGP04.phx.gbl...
>> Howdie!
>>
>> sawyer schrieb:
>>> I have a two way transitive trust configured between two separate 2003
>>> AD forests. ForestA has 3 AD sites, and each AD site has two DC's in it.
>>> ForestB has one AD site. From site1 in forestA I can ping the forestB by
>>> its FQDN and I can validate the trust. From site2 in forestA I cannot
>>> ping forestB by FQDN I get a request time out. I can however from site2
>>> and site1 in forestA ping the FQDN of the DC in forestB, but I cant
>>> validate the trust from Adsite2, probably because I cant ping the FQDN
>>> of the forestB. The zone I have created for forestB is a stub zone.
>>
>> So this all boils down to a DNS issue, correct? Why'd you configure a
>> stub zone for forestB? Is that information on site2's DC? I'd recommend
>> you try to create DNS forwarder and have DNS requests for forestB's FQDN
>> be forwarded by all DNS servers (DCs) to DCs in the forest root domain of
>> forestB (put all forest root DCs in there for fault tolerance).
>>
>> Cheers,
>> Florian
>> --
>> Microsoft MVP - Group Policy
>> eMail: prename [at] frickelsoft [dot] net.
>> blog: http://www.frickelsoft.net/blog.
>> ANY advice you get on the Newsgroups should be tested thoroughly in your
>> lab.
>
Re: AD trust routing issue [message #360370 is a reply to message #360034] Tue, 05 January 2010 17:56 Go to previous messageGo to next message
aceman  is currently offline aceman  United States
Messages: 5816
Registered: July 2009
Senior Member
"sawyer" <occompguy@cox.net> wrote in message
news:OJkE$njjKHA.2184@TK2MSFTNGP04.phx.gbl...
> Yea I guess I could create a forwarder but really at the end of the day
> whats the difference between a forwarder and a stub zone? both will aid me
> in establishing the trust. The stub zone for forestB is AD integrated so
> its available on all DNS\DC in forestA. This is not a DNS issue but a
> routing issue, has I can resolve the name from a workstation in ADsite2
> but it does not reply.
>

If you have two stub zones that exists in ForestA for ForestB's zones
(either a domain.com stub, or two zones one for_msdcs and one for the
domain.com zone), that is AD integrated and replicated to all DCs in ForestA
(assuming there is only one domain in ForestB), and can resolve ForestB's
resources, then from your description, it *appears* to be a routing issue or
possibly a firewall rules issue between Sites in ForestA.

If it can resolve, but it does not reply say with a ping, then a firewall
rule blocking ICMP could cause it, or static routes are not configured
properly. If you are trying to connect via a UNC, then there may be a block
or misonfig in the rules allowing the Dynamic service response ports (all
UDP 1024 and above).

Is there a VPN between the two organizations? If so, do the necessary rules
exist allowing all traffic from all subnets on both sides to the other?

As Jorge suggested, a sniffer may be your best bet in this case unless your
network team can review the rules in place to determine where the issue
lies.

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE &
MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services

If you feel this is an urgent issue and require immediate assistance, please
contact Microsoft PSS directly. Please check http://support.microsoft.com
for regional support phone numbers.
Re: AD trust routing issue [message #360949 is a reply to message #360299] Wed, 06 January 2010 10:01 Go to previous messageGo to next message
Sawyer  is currently offline Sawyer
Messages: 315
Registered: July 2009
Senior Member
There are 2 DC in forestB, forestB has one subnet (192.168.0.x) and this
subnet is not equal to any subnets in forestA (why would that matter?)

Go to Advanced TCP/IP settings and select the option "Append these DNS
> suffixes (in order):" and add both (FQDN of Forest A and B), then clear
> the cache by running ipconfig /flushdns and restart the DNS service.

What serves do I perform this on, the DC's in forestA ? I agree I would need
to run a tracert to see more information on the wire. But the question still
remains and hasn't fully been answered. Again what happens with
authentication of the trust specifically around when users from a separate
forest try to access resources in another forest, when all DC's in the
trusting forest do not have a network route to the trusted forests DC's ?

Example

In forestA there are 3 AD sites, each site has 2 DC\DNS servers. The DC's in
AD site1 have a network route to the DC's in forestB, and it was the DC's
in AD site1 that established the trust with forestB. The DC's in AD site2
(forestA) do not have a network route to the DC's in forestB. Now if all the
servers in AD site2 (forestA) are using the DC\DNS servers in AD site2, then
can these serves allow access to resources from user accounts from froestB ?

"Jorge Silva" <jorgesilva_pt@hotmail.com> wrote in message
news:67A27D28-054D-4544-AA8C-0A4266E914E8@microsoft.com...
> Hi
>>>> I have a two way transitive trust configured between two separate 2003
>>>> AD forests. ForestA has 3 AD sites, and each AD site has two DC's in
>>>> it.
>
> Ok
>
>>>> ForestB has one AD site. From site1 in forestA I can ping the forestB
>>>> by its FQDN and I can validate the trust. From site2 in forestA I
>>>> cannot ping forestB by FQDN I get a request time out. I can however
>>>> from site2 and site1 in forestA ping the FQDN of the DC in forestB, but
>>>> I cant validate the trust from Adsite2, probably because I cant ping
>>>> the FQDN of the forestB. The zone I have created for forestB is a stub
>>>> zone.
>
> - Ok, How many DCs do you have in Forest B?
> - Do you have subnets in Forest B equal to any existing subnet in Forest A
> (including Site 1 and 2)?
> - Go to Advanced TCP/IP settings and select the option "Append these DNS
> suffixes (in order):" and add both (FQDN of Forest A and B), then clear
> the cache by running ipconfig /flushdns and restart the DNS service. Try
> again, does that change anything?
> - To narrow this issue you should also run a network sniffer to check
> which server is being contacted and what paths are being taken. Tracert
> and pathping should also help you with that task.
>
> --
>
> I hope that the information above helps you.
> Have a Nice day.
>
> Jorge Silva
> MVP Directory Services
>
> Please no e-mails, any questions should be posted in the NewsGroup
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>
>
> "sawyer" <occompguy@cox.net> wrote in message
> news:OJkE$njjKHA.2184@TK2MSFTNGP04.phx.gbl...
>> Yea I guess I could create a forwarder but really at the end of the day
>> whats the difference between a forwarder and a stub zone? both will aid
>> me in establishing the trust. The stub zone for forestB is AD integrated
>> so its available on all DNS\DC in forestA. This is not a DNS issue but a
>> routing issue, has I can resolve the name from a workstation in ADsite2
>> but it does not reply.
>>
>> "Florian Frommherz [MVP]" <florian@frickelsoft.DELETETHIS.net> wrote in
>> message news:OuaA$VjjKHA.2188@TK2MSFTNGP04.phx.gbl...
>>> Howdie!
>>>
>>> sawyer schrieb:
>>>> I have a two way transitive trust configured between two separate 2003
>>>> AD forests. ForestA has 3 AD sites, and each AD site has two DC's in
>>>> it. ForestB has one AD site. From site1 in forestA I can ping the
>>>> forestB by its FQDN and I can validate the trust. From site2 in forestA
>>>> I cannot ping forestB by FQDN I get a request time out. I can however
>>>> from site2 and site1 in forestA ping the FQDN of the DC in forestB, but
>>>> I cant validate the trust from Adsite2, probably because I cant ping
>>>> the FQDN of the forestB. The zone I have created for forestB is a stub
>>>> zone.
>>>
>>> So this all boils down to a DNS issue, correct? Why'd you configure a
>>> stub zone for forestB? Is that information on site2's DC? I'd recommend
>>> you try to create DNS forwarder and have DNS requests for forestB's FQDN
>>> be forwarded by all DNS servers (DCs) to DCs in the forest root domain
>>> of forestB (put all forest root DCs in there for fault tolerance).
>>>
>>> Cheers,
>>> Florian
>>> --
>>> Microsoft MVP - Group Policy
>>> eMail: prename [at] frickelsoft [dot] net.
>>> blog: http://www.frickelsoft.net/blog.
>>> ANY advice you get on the Newsgroups should be tested thoroughly in your
>>> lab.
>>
Re: AD trust routing issue [message #360979 is a reply to message #360949] Wed, 06 January 2010 10:29 Go to previous messageGo to next message
aceman  is currently offline aceman  United States
Messages: 5816
Registered: July 2009
Senior Member
"sawyer" <occompguy@cox.net> wrote in message
news:815A5918-1C34-479A-93C9-D65C58EFECC3@microsoft.com...
> There are 2 DC in forestB, forestB has one subnet (192.168.0.x) and this
> subnet is not equal to any subnets in forestA (why would that matter?)

It matters because if the same subnet ID exists on both sides of a VPN or in
a routed network, how would the routers now which way to send the traffic?
This is a common issue with the retail box DSL/Cable routers. Their defaults
are either 192.168.0.0 or 192.168.1.0. Companies in some cases, have
configured their own internal networks with one of these subnets. Then they
decide to implement a VPN. One user using a Linksys at their home has a
matching subnet. Guess what? They can't access the company subnet or
resources while connected to the VPN because of the identical subnet ID.
Either the company has to change theirs, or the user. Same thing goes with
VPNs between company partnerships.

>
> Go to Advanced TCP/IP settings and select the option "Append these DNS
>> suffixes (in order):" and add both (FQDN of Forest A and B), then clear
>> the cache by running ipconfig /flushdns and restart the DNS service.
>
> What serves do I perform this on, the DC's in forestA ? I agree I would
> need to run a tracert to see more information on the wire. But the
> question still remains and hasn't fully been answered. Again what happens
> with authentication of the trust specifically around when users from a
> separate forest try to access resources in another forest, when all DC's
> in the trusting forest do not have a network route to the trusted forests
> DC's ?

It's called pass-through authentication. Your users try to communicate wtih
a machine on the other side of the trust. The user's machine send an
authentication request to the DC that logged him/her in, which then sends
that to the DC on the other side of the trust. All DCs need to be able to
communicate with each other, including the PDC Emulator. If there is a
network routing issue preventing this one direction or the other, you will
see failures.

>
> Example
>
> In forestA there are 3 AD sites, each site has 2 DC\DNS servers. The DC's
> in AD site1 have a network route to the DC's in forestB, and it was the
> DC's in AD site1 that established the trust with forestB. The DC's in AD
> site2 (forestA) do not have a network route to the DC's in forestB. Now if
> all the servers in AD site2 (forestA) are using the DC\DNS servers in AD
> site2, then can these serves allow access to resources from user accounts
> from froestB ?

Then if Site2's DCs cannot directly communicate, and a user logged on using
that DC, then they can't authenticate. If worse, such as no route from that
subnet to the other side, then that will cause the same issue.

Ace
Re: AD trust routing issue [message #361117 is a reply to message #360979] Wed, 06 January 2010 13:00 Go to previous messageGo to next message
Sawyer  is currently offline Sawyer
Messages: 315
Registered: July 2009
Senior Member
Thank you! that answered my question

"Ace Fekay [MVP-DS, MCT]" <aceman@mvps.RemoveThisPart.org> wrote in message
news:OzmN$WvjKHA.1652@TK2MSFTNGP05.phx.gbl...
> "sawyer" <occompguy@cox.net> wrote in message
> news:815A5918-1C34-479A-93C9-D65C58EFECC3@microsoft.com...
>> There are 2 DC in forestB, forestB has one subnet (192.168.0.x) and this
>> subnet is not equal to any subnets in forestA (why would that matter?)
>
> It matters because if the same subnet ID exists on both sides of a VPN or
> in a routed network, how would the routers now which way to send the
> traffic? This is a common issue with the retail box DSL/Cable routers.
> Their defaults are either 192.168.0.0 or 192.168.1.0. Companies in some
> cases, have configured their own internal networks with one of these
> subnets. Then they decide to implement a VPN. One user using a Linksys at
> their home has a matching subnet. Guess what? They can't access the
> company subnet or resources while connected to the VPN because of the
> identical subnet ID. Either the company has to change theirs, or the user.
> Same thing goes with VPNs between company partnerships.
>
>>
>> Go to Advanced TCP/IP settings and select the option "Append these DNS
>>> suffixes (in order):" and add both (FQDN of Forest A and B), then clear
>>> the cache by running ipconfig /flushdns and restart the DNS service.
>>
>> What serves do I perform this on, the DC's in forestA ? I agree I would
>> need to run a tracert to see more information on the wire. But the
>> question still remains and hasn't fully been answered. Again what happens
>> with authentication of the trust specifically around when users from a
>> separate forest try to access resources in another forest, when all DC's
>> in the trusting forest do not have a network route to the trusted forests
>> DC's ?
>
> It's called pass-through authentication. Your users try to communicate
> wtih a machine on the other side of the trust. The user's machine send an
> authentication request to the DC that logged him/her in, which then sends
> that to the DC on the other side of the trust. All DCs need to be able to
> communicate with each other, including the PDC Emulator. If there is a
> network routing issue preventing this one direction or the other, you will
> see failures.
>
>>
>> Example
>>
>> In forestA there are 3 AD sites, each site has 2 DC\DNS servers. The DC's
>> in AD site1 have a network route to the DC's in forestB, and it was the
>> DC's in AD site1 that established the trust with forestB. The DC's in AD
>> site2 (forestA) do not have a network route to the DC's in forestB. Now
>> if all the servers in AD site2 (forestA) are using the DC\DNS servers in
>> AD site2, then can these serves allow access to resources from user
>> accounts from froestB ?
>
> Then if Site2's DCs cannot directly communicate, and a user logged on
> using that DC, then they can't authenticate. If worse, such as no route
> from that subnet to the other side, then that will cause the same issue.
>
> Ace
>
Re: AD trust routing issue [message #361389 is a reply to message #361117] Wed, 06 January 2010 18:59 Go to previous messageGo to next message
aceman  is currently offline aceman  United States
Messages: 5816
Registered: July 2009
Senior Member
"sawyer" <occompguy@cox.net> wrote in message
news:EB1BEDD5-B265-4298-92A9-33AA1BFCDAFB@microsoft.com...

Cool! Glad to hear. But which answer? The pass-through or the subnet answer?

Ace



> Thank you! that answered my question
>
> "Ace Fekay [MVP-DS, MCT]" <aceman@mvps.RemoveThisPart.org> wrote in
> message news:OzmN$WvjKHA.1652@TK2MSFTNGP05.phx.gbl...
>> "sawyer" <occompguy@cox.net> wrote in message
>> news:815A5918-1C34-479A-93C9-D65C58EFECC3@microsoft.com...
>>> There are 2 DC in forestB, forestB has one subnet (192.168.0.x) and this
>>> subnet is not equal to any subnets in forestA (why would that matter?)
>>
>> It matters because if the same subnet ID exists on both sides of a VPN or
>> in a routed network, how would the routers now which way to send the
>> traffic? This is a common issue with the retail box DSL/Cable routers.
>> Their defaults are either 192.168.0.0 or 192.168.1.0. Companies in some
>> cases, have configured their own internal networks with one of these
>> subnets. Then they decide to implement a VPN. One user using a Linksys at
>> their home has a matching subnet. Guess what? They can't access the
>> company subnet or resources while connected to the VPN because of the
>> identical subnet ID. Either the company has to change theirs, or the
>> user. Same thing goes with VPNs between company partnerships.
>>
>>>
>>> Go to Advanced TCP/IP settings and select the option "Append these DNS
>>>> suffixes (in order):" and add both (FQDN of Forest A and B), then clear
>>>> the cache by running ipconfig /flushdns and restart the DNS service.
>>>
>>> What serves do I perform this on, the DC's in forestA ? I agree I would
>>> need to run a tracert to see more information on the wire. But the
>>> question still remains and hasn't fully been answered. Again what
>>> happens with authentication of the trust specifically around when users
>>> from a separate forest try to access resources in another forest, when
>>> all DC's in the trusting forest do not have a network route to the
>>> trusted forests DC's ?
>>
>> It's called pass-through authentication. Your users try to communicate
>> wtih a machine on the other side of the trust. The user's machine send an
>> authentication request to the DC that logged him/her in, which then sends
>> that to the DC on the other side of the trust. All DCs need to be able to
>> communicate with each other, including the PDC Emulator. If there is a
>> network routing issue preventing this one direction or the other, you
>> will see failures.
>>
>>>
>>> Example
>>>
>>> In forestA there are 3 AD sites, each site has 2 DC\DNS servers. The
>>> DC's in AD site1 have a network route to the DC's in forestB, and it
>>> was the DC's in AD site1 that established the trust with forestB. The
>>> DC's in AD site2 (forestA) do not have a network route to the DC's in
>>> forestB. Now if all the servers in AD site2 (forestA) are using the
>>> DC\DNS servers in AD site2, then can these serves allow access to
>>> resources from user accounts from froestB ?
>>
>> Then if Site2's DCs cannot directly communicate, and a user logged on
>> using that DC, then they can't authenticate. If worse, such as no route
>> from that subnet to the other side, then that will cause the same issue.
>>
>> Ace
>>
Re: AD trust routing issue [message #365360 is a reply to message #361117] Mon, 11 January 2010 14:12 Go to previous message
Jorge Silva  is currently offline Jorge Silva
Messages: 398
Registered: July 2009
Senior Member
Ok, I see that Ace already answered the questions. Did you performed the
tests that I provided to do? What conclusions did you come up with?

--

I hope that the information above helps you.
Have a Nice day.

Jorge Silva
MVP Directory Services

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.




"sawyer" <occompguy@cox.net> wrote in message
news:EB1BEDD5-B265-4298-92A9-33AA1BFCDAFB@microsoft.com...
> Thank you! that answered my question
>
> "Ace Fekay [MVP-DS, MCT]" <aceman@mvps.RemoveThisPart.org> wrote in
> message news:OzmN$WvjKHA.1652@TK2MSFTNGP05.phx.gbl...
>> "sawyer" <occompguy@cox.net> wrote in message
>> news:815A5918-1C34-479A-93C9-D65C58EFECC3@microsoft.com...
>>> There are 2 DC in forestB, forestB has one subnet (192.168.0.x) and this
>>> subnet is not equal to any subnets in forestA (why would that matter?)
>>
>> It matters because if the same subnet ID exists on both sides of a VPN or
>> in a routed network, how would the routers now which way to send the
>> traffic? This is a common issue with the retail box DSL/Cable routers.
>> Their defaults are either 192.168.0.0 or 192.168.1.0. Companies in some
>> cases, have configured their own internal networks with one of these
>> subnets. Then they decide to implement a VPN. One user using a Linksys at
>> their home has a matching subnet. Guess what? They can't access the
>> company subnet or resources while connected to the VPN because of the
>> identical subnet ID. Either the company has to change theirs, or the
>> user. Same thing goes with VPNs between company partnerships.
>>
>>>
>>> Go to Advanced TCP/IP settings and select the option "Append these DNS
>>>> suffixes (in order):" and add both (FQDN of Forest A and B), then clear
>>>> the cache by running ipconfig /flushdns and restart the DNS service.
>>>
>>> What serves do I perform this on, the DC's in forestA ? I agree I would
>>> need to run a tracert to see more information on the wire. But the
>>> question still remains and hasn't fully been answered. Again what
>>> happens with authentication of the trust specifically around when users
>>> from a separate forest try to access resources in another forest, when
>>> all DC's in the trusting forest do not have a network route to the
>>> trusted forests DC's ?
>>
>> It's called pass-through authentication. Your users try to communicate
>> wtih a machine on the other side of the trust. The user's machine send an
>> authentication request to the DC that logged him/her in, which then sends
>> that to the DC on the other side of the trust. All DCs need to be able to
>> communicate with each other, including the PDC Emulator. If there is a
>> network routing issue preventing this one direction or the other, you
>> will see failures.
>>
>>>
>>> Example
>>>
>>> In forestA there are 3 AD sites, each site has 2 DC\DNS servers. The
>>> DC's in AD site1 have a network route to the DC's in forestB, and it
>>> was the DC's in AD site1 that established the trust with forestB. The
>>> DC's in AD site2 (forestA) do not have a network route to the DC's in
>>> forestB. Now if all the servers in AD site2 (forestA) are using the
>>> DC\DNS servers in AD site2, then can these serves allow access to
>>> resources from user accounts from froestB ?
>>
>> Then if Site2's DCs cannot directly communicate, and a user logged on
>> using that DC, then they can't authenticate. If worse, such as no route
>> from that subnet to the other side, then that will cause the same issue.
>>
>> Ace
>>
Previous Topic:winxp not able to join domain
Next Topic:Bit Locker
Goto Forum:
  


Current Time: Tue Jan 23 16:30:55 MST 2018

Total time taken to generate the page: 0.36370 seconds
.:: Contact :: Home ::Sitemap::.

Powered by: FUDforum 3.0.0RC2.
Copyright ©2001-2009 FUDforum Bulletin Board Software