Cross-Forest Logon Process
When a user from Forest A logs on to a computer in Forest B, the logon process requires location of a domain controller from the user’s domain in Forest A. If the site of the computer from Forest B is not specified in Active Directory in Forest A, the computer might locate any (rather than the closest) domain controller from the user’s domain in Forest A. If the connection to the domain controller is made over a WAN, then this logon process adds traffic to the WAN (the amount of traffic depends on the number of Group Policies and logon scripts, as well as the size of the roaming profile). This connection generates traffic during logon as well as logoff and usually ranges from 100 kilobytes (KB) to a few hundred KB. Depending on the WAN bandwidth that is available for logon traffic, logon duration over the WAN might be increased. If these drawbacks are acceptable, especially if you anticipate that most users will be logging on to computers in their own forest, then site and subnet information might not be important enough to warrant synchronizing the data between forests.
Cross-Forest File Download
When a user who is logged on to a computer that is joined to Forest B requests a file that is hosted by multiple DFS servers, the nearest one being a server that is joined to Forest A, the DFS server that is contacted for the download depends on whether site and subnet information for Forest A is available in Forest B. If the site of this DFS server is not specified in Forest B, then the file might be downloaded from an arbitrary (potentially remote) DFS server. If the site of the DFS server is available in Forest B, the server in Forest A can be located.
Note
DFS enhancements in Windows Server 2003
ensure that files are downloaded from the next closest DFS server that hosts the
desired file and is joined to Forest B.
Downloading a file from a remote DFS server increases network traffic over a WAN (the amount of traffic is determined by the size of the file to be downloaded) and potentially increases the download time (the delay depends on bandwidth available to download the file). If these drawbacks are acceptable, especially if you anticipate that users download files only from the DFS servers in their own forest, then synchronizing site and subnet information might not be important.
Cross-Forest Authentication
When a user needs to authenticate to a resource in a different forest, the user’s computer or domain controller (depending on the authentication mechanism that is used) must contact a domain controller in the domain of the resource. Domain controller location is optimized by the closest site across forests only when identical site and subnet information is configured in Active Directory in both forests. However, if the traffic that is generated by authentication of the user does not cause significant delay, then it is not critical that a local domain controller be contacted.
Solution
The initial solution for mirroring site and subnet information is to create the same site and subnet objects in all forests. After these objects have been created, two methods can be used to ensure that site and subnet information is maintained identically in both forests:
| • |
Use a directory data synchronization product (for example, Microsoft Identity Integration Server 2003) to synchronize the data when site and subnet information changes in one forest. This approach is characterized by a high level of automation and requires practically no administrator involvement after Microsoft Identity Integration Server 2003 configuration is in place. However, this approach is not acceptable in scenarios where service isolation is required (the service administrators in the destination forest do not trust the service administrators from the source forest). |
| • |
Establish a business process by which network administrators inform service administrators in each forest when site and subnet information changes, and the service administrators then update the information in their respective forests. This approach is most appropriate for the customers who have service isolation requirements for separate forests. However, this approach requires a high level of administrator overhead to create mirrored information in multiple forests. |
Microsoft intends to issue a deployment guide that will describe the site and subnet objects and attributes that need to be synchronized to mirror network topology information.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ruston, Neil
Sent: Monday, May 09, 2005 10:45 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Cross forest trusts and site & subnet syncing
I am researching x forest trusts and the need / advantage in syncing sites and subnets between forests. I have found a MS paper which describes multi forest scenarios in some detail but would ideally like to see a paper which describes the process used by a root domain DC to locate a root domain DC in the 'other' forest in more detail.
i.e. does the DC simply look for a DC in the same site as itself? If so, then this implies that both forests need to have a similar site naming convention, which may be an issue :) Does the DC cache the DC used (and form a secure channel) or is some other mechanism used?
Does anyone know of any detailed papers which cover the above? [I thought I once read a paper available in the w2k3 JDP timescales, but have not seen anything similar post RTM.]
Thanks in advance,
neil
==============================================================================
This
message is for the sole use of the intended recipient. If you received this
message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains
and monitors electronic communications sent through its network. Instructions
transmitted over this system are not binding on CSFB until they are confirmed by
us. Message transmission is not guaranteed to be
secure.
==============================================================================
