DNS Replication | Active Directory By the Numbers: Windows Server 2003

DNS Issues

We now have two domains. But there is a glaring weakness in our Active Directory layout: we only have one DNS server, and it is located on the sole domain controller located in the root domain guinea.pig. In a real world Active Directory setup, redundancy is the rule of the day. If our DNS service goes down on dc01.guinea.pig, then our whole domain tree collapses. We must find a way to replicate the DNS information from dc01.guinea.pig to dc02.denver.guinea.pig.

Tutorial: DNS Replication

In order for our denver.guinea.pig domain controller to function as a DNS server, we must install the DNS service first. Be sure to have your Windows Server 2003 CD handy, as you will need it. On the denver domain controller, bring up the Add/Remove Programs control panel located on Start ˆ’ > Control Panel .
Along the left side of the window, click the Add/Remove Windows Components option. After a brief pause, the Windows Components Wizard appears.
Scroll down the list and double-click the option labeled Networking Services and place a check in the box next to Domain Name System (DNS) . Click OK and Next . Windows installs the DNS server files. Click Finish when the wizard completes its task and close the Add/Remove Programs control panel.
Leaving the denver domain controller for moment, go back to the guinea.pig domain controller and bring up the DNS configuration editor located at Start ˆ’ > Administrative Tools ˆ’ > DNS .
In the left column, expand the folder listing next to Forward Lookup Zones , right-click the folder labeled guinea.pig , and choose Properties .
On the General tab, click the Change button next to Replication . On the screen that appears, click the item labeled To all DNS servers in the Active Directory forest guinea.pig . This causes the DNS information stored in dc01.guinea.pig to replicate to all other DNS servers in our forest. Click OK twice and close the DNS management console.
Back on the denver domain controller, change the DNS information in the Network Connections control panel to read 192.168.1.10 (we are telling the denver domain controller to use itself as a DNS server). This is done by clicking Start ˆ’ > Control Panel ˆ’ > Network Connections , right-clicking Local Area Connection , and choosing Properties . On the General tab, double-click TCP/IP and enter the new IP address in the Preferred DNS server field. Notice that the server's IP address and the Preferred DNS server's address are identical.
Restart the denver domain controller and open the DNS management console again. Notice that the guinea.pig DNS information has replicated from the other domain controller.

Inter-Domain Data Exchange

Now that we have our second domain (complete with DNS replication) configured correctly, what can we do with it? Since the root domain located in the home office has it own set of users, groups, OUs, GPOs, shared folders, and the like, why not do the same for the child domain? Because this domain is its own entity, it can operate autonomously in the exact same way that its parent can. But because the two are interconnected in a two-way trust relationship (parent trusts child and child trusts parent), users in denver.guinea.pig can access shared resources in guinea.pig, and vice versa.

That's the simple part of the story. Getting this data exchange to happen takes a bit more know-how than just assigning users and groups permissions to access objects across domains.

Think way back to our discussion of groups in Chapter 3. Recall that when we created our groups for the various departments in the guinea.pig domain (marketing, art, and accounting), we made these groups all global groups. Also recall that we mentioned that using the other two types of groups (universal and domain local) is best reserved for inter-domain and inter-forest functions. Right now, we have just such a situation, as we now have two domains that have the potential to share data. We do this by adding groups to other groups in a process called group nesting (i.e., one group is "nested" inside another group). When sharing data between domains, Microsoft recommends nesting global groups inside of domain local groups:

Figure 5-2: Sharing resources across domains
1 . Global groups are created in domain A (the root domain).
2 . Using the transitive, two-way trust relationship between domain A and domain B (the child domain), the global groups are added, or nested, into a domain local group located in domain B.
3 . The domain local group is granted the proper NTFS file permissions to access the shared folder located in domain B.

So in our guinea.pig and denver.guinea.pig example, let's say that we want users in the parent guinea.pig domain to access a shared folder published in the denver domain. We can create a new domain local group in denver.guinea.pig, add the global groups residing in guinea.pig to the new domain local group, and apply the appropriate permissions to the folder.