Active Directory By the Numbers: Windows Server 2003

Get Info

You may have noticed that when we created the new shared folder in the denver domain, we didn't publish that folder to the Active Directory. This is because applying NTFS file permissions using domain local groups to Active Directory objects can have unpredictable results.

Inconsistencies in Global Catalog Replication and Domain Local Groups:

We keep telling you that using domain local groups on Active Directory objects is a bad idea. Why, you might ask? In a nutshell , here's the low-down:

A complete or partial replica of all objects in an Active Directory forest is stored in the Global Catalog. This includes a user 's group memberships in global, universal, and domain local groups. A universal group is stored in the Global Catalog in its entirety, including all users within that group. Global groups, on the other hand, only store the group data in the Global Catalog. The actual members of the group are not replicated to the Global Catalog, saving some network bandwidth. Domain local groups are a breed of their own. Like global groups, their members are not stored in the Global Catalog, again saving bandwidth. It's when we start adding domain local groups in a multi-domain or multi-forest environment that things get tricky.

When a user attempts to search for or access an Active Directory object (such as a shared folder or printer), he must go through the Global Catalog first. When a client accesses the Global Catalog, he is granted what is called an impersonation token . This token is used to grant or deny the user access to objects stored in the Global Catalog. Inside this token is information on what type of groups the user belongs to (global, universal, or domain local). However, domain local group membership included in the token can be incomplete in a multi-domain environment.

The following two items are included in the user's token:

BUT if the user is a member of other domain local groups in other domains, he is out of luck, as this information is not included in the token. Why is this important? In addition to a partial replica of all objects in a forest, the Global Catalog contains a listing of each object's permissions specifying who should and should not have access to them. This listing is called a Discretionary Access Control List (DACL) . When the user tries to access an Active Directory object, the Global Catalog compares the user's impersonation token with the object's DACL. If the object to be shared has read/write access granted to a domain local group in a different domain to which the user is a member, he may be denied access because this group membership is not present in the user's token.

Again, the best practice is to simply not use domain local groups for Active Directory objects.

Active Directory Inter-Site and Replication Settings

Recall that earlier in the chapter we mentioned that an Active Directory forest must contain three things: a common schema, Global Catalog, and common sites and replication settings (called a configuration ). Up to this point, we have created two Active Directory domains (parent-child) that exist in the same site (or subnet). Let's say, however, that the parent domain and the child domain are both located in different geographic locations. Because of this, the domains are probably not going to be located on the same network wire. For example, they might be connected via the internet over an ISDN connection which is significantly slower than a local area network with the domains connected with fast or gigabit ethernet. But the domains must still be able to replicate information to and from each other in order to keep their data up to date within the forest. This obviously isn't a problem over a fast, internal local area network connection, as Windows Server 2003 takes care of this automatically, replicating data between domain controllers in the same site ( intra -site replication ) every few minutes. But when we connect domains over a slower, wide area network, we no longer have the luxury of a super-fast replication route. Because of limited bandwidth, we must budget our resources in how domains replicate to each other. This is done by carving up domains and forests based on IP subnets. We can then instruct these subnets, or Active Directory Sites, to replicate to one another at set intervals ( inter -site replication ). We can also control the time periods when replication can and cannot occur.

Building upon the site replication concept, if we have more than two domains, and each is connected using differing network connections (such as a 128k ISDN connection, a 1.5mb T1 connection, and a 384mb cable modem connection), we can assign costs to each route. Active Directory automatically chooses the most efficient route to complete replication among the domains and/or domain controllers based upon the costs that we define:

Using the example in figure 5-3, we see that ISDN, the slowest connection of the three available, is assigned the highest cost. This is because it is the most "expensive" in terms of network bandwidth, as data takes more time to travel over it than it would over the faster and least expensive T1 connection.

Figure 5-3: Domains A, B, and C are located on different subnets and in different geographic locations. Each domain is connected via differing types of network connections, each with an assigned cost. Faster connections are assigned lower costs, while slower connections have higher costs.

Using this example, is the shortest distance between two points really a straight line? To test this, let's figure the most efficient way to replicate data from domain A to domain B. The most obvious way is to replicate over the ISDN connection, which has a cost of 80. The other way is to replicate data from A to C, and then from C to B; hardly a straight line. But looking at the costs:

A to C = 20

C to B = 40

” ” ” ” ” ”-

Total cost = 60

Since the ISDN connection carries a cost of 80, it is actually more efficient to replicate data using the less direct route. Windows Server 2003 domains perform replication in this manner. Of course, if the T1 connection were to go down for some reason, the domains would have to use the less efficient ISDN connection to transfer the replication data around the forest.

In the following tutorials, we are assigning our domain controllers to different subnets. This requires that each domain controller has a common route to each other so that they are able to communicate with one another. In a small, lab-based setting, this is relatively easy to set up as there are many lowend routing products available on the internet. In our tests when putting this book together, we used an inexpensive software based router/firewall for Unix called Brickhouse (http://personalpages.tds.net/~brian_hill). Obviously in a much larger setting, you must use something much more robust. Your Internet Service Provider (ISP) or network provider should be able to help you with this.

Figure 5-4 gives a very simplistic outline of how a basic router functions.

Figure 5-4: The domain controllers in domains A, B, and C are located on different IP subnets. In order for them to communicate with one another, each points its default gateway settings to an IP address located on router D. Router D contains IP addresses located on all three subnets. For example, for domain A located on subnet 192.168.100.0, router D contains an IP address located in the same subnet. It also contains IP addresses on the same subnets as domains B and C. When domain A needs to contact domain B or C, the router forwards the requests from A to B or A to C. The same holds true for the other two subnets.

Tutorial Prep:

In the following tutorials, we use the same IP subnets as shown in figure 5-3.

Related

Категории