subnet - Ad site and services

  • 225 Views
  • Last Post 02 May 2016
vluu posted this 30 April 2016

Hi,

 

We have two separate Domains from different forest that are trusted.

DomainA is in Chicago and has 10.4.0.0\16 assigned to its site. I would like to add a new DC in joined to DomainB where it would have an IP of 10.4.46.## which falls in the whole 10.4.0.0/16 subnet of DomainA. I would create a new site in DomainB and assign subet 10.4.46.## / ## to it. Is this recommended and would it cause any problems to both domainA and domainB? 

Thx

Order By: Standard | Newest | Votes
kurtbuff posted this 30 April 2016

WRT domains and their sites, I believe that this shouldn't present any
problem, because members of each domain seek DCs in their own domain
for auth.

But, where would the new DC reside? In the physical location where the
10.4.0.0/16 subnet currently exists, or would you create a new subnet
in the physical location where the other domain exists?

If the former, no problem. If the latter - you've got a routing
problem to work around.

Kurt

show

ZJORZ posted this 30 April 2016

No, it would not cause any problems in either domain A or B when it is about authentication within either domain A or BIn general, when talking about cross domain authentication, the only possible issue is a member of domain B trying to contact a less optimal DC in domain A. As long as everything at network level is unique, there is no problem Met vriendelijke groeten / Kind regards, Jorge de Almeida Pinto*: JorgeDeAlmeidaPinto@xxxxxxxxxxxxxxxx(: +31 (0)6 26.26.62.80 Description: Description: Description: Description: Think Green 

show

vluu posted this 30 April 2016

Thx mark and jorge. For more clarification:
The new DC would be in the physically location of network 10.4.0.0/16 but joined to domainB. 
10.4.0.0/16 looks like a catch-all subnet defined as a site in domainA,
An IP 10.4.46,## which would be assigned to  the new DC in domainB and the subnet would be defined in domainB. This subnet isn't exclusive to domainB as there already have servers in domainA using addresses.
Present any problems?
Thx

show

vluu posted this 30 April 2016

Apologies , Kurt (not mark) for getting your name wrong.

show

bdesmond posted this 30 April 2016

That will be fine. If you name the sites the same in both forests, that will be helpful with clients going across the trust.



 

Thanks,

Brian Desmond

 

w – 312.625.1438 | c – 312.731.3132

 

show

gkirkpatrick posted this 01 May 2016

Several of the orgs I’ve worked with that had multiple forests maintained the site structure in one forest and replicated the site

information to the other forests, mostly to simplify administration around sites and subnets. That might be a useful approach depending on how much overlap there is between the networks used by the different domains.

 

-gil

 

show

Parzival posted this 01 May 2016

Hi,




If you have 2 forests that share domain/forest trusts, it is beneficial to share the same site names.. when clients look in the other trusted forest for domain controllers, their initial call is actually to the ldap.tcp.OWNSITENAME.sites.dc.msdcs.OTHERDOMAIN.local

DNS zone, to ensure they are connecting locally first..,




if the site names between the two trusted forests do not match at all, they will fail back to the global

ldap.tcp.dc._MSDCS.otherdomain.local zone.






While the blogpost is about creating trusts, the same principle applies to clients trying to get info on the trusted domain



http://studioblog.azurewebsites.net/cross-forest-authentication-part-2-creating-trusts/














show

ZJORZ posted this 02 May 2016

>>>> if the site names between the two trusted forests do not match at all, they will fail back to the global ldap.tcp.dc.MSDCS.otherdomain.local zone. Nope, not accurate The DC in the OTHERDOMAIN will first try to match the IP of the client to a subnet In the otherdomain forest, which in turn is linked to a site in the otherdomain forest. Of course, this does assume that iteration will succeed. If it fails, then it will revert to _ldap.tcp.dc.MSDCS.otherdomain.local Met vriendelijke groeten / Kind regards, Jorge de Almeida Pinto*: JorgeDeAlmeidaPinto@xxxxxxxxxxxxxxxx(: +31 (0)6 26.26.62.80 Description: Description: Description: Description: Think Green 

show

Close