Trusts Are Good for NT 4.0 and Active Directory Domains

team lib

In the good old days before the need for FSMO roles (that is, during Windows NT's prime), you had one main domain controller (a primary domain controller, or PDC) that could make changes to the Security Accounts Manager (SAM) database. Those changes were then replicated to other backup domain controllers (BDCs). In this model, the SAM database was simply a file stored on each PDC that contained information about the domain's security objects, such as users and groups. To support authentication across domains (and thus hinder unauthorized access to the network), you created one-way trust relationships between domains that would allow users and groups from the trusted domain to be assigned access to resources in the trusting domain.

KEY CONCEPT 

The concept of trusting and trusted is confusing, so we're going to try to shed some light on the subject. Imagine a trust between two domains: A and B. Domain A trusts domain B, so domain B is the trusted domain and domain A is the trusting domain. Because domain A trusts domain B to correctly authenticate its users, users from domain B can be assigned access to resources in domain A. (You could create a bidirectional trust relationship, where domain A trusts domain B with its resources and domain B trusts domain A with its resources. However, what you really have with a bidirectional trust is two unidirectional trusts that have been joined.) Before you get the idea that we're all one happy, trusting family, don't forget that Windows NT 4.0-based trusts are not transitive; therefore, if domain C trusts domain B, and domain B trusts domain A, domain C does not implicitly trust domain A. For domain A to trust domain C, you must establish an explicit trust relationship between domain A and domain C. Got all that? Remember it; we'll come back to it later.

Windows Server 2003 makes use of Active Directory to keep domains in line when it comes to trust relationships. Windows Server 2003 domain controllers store the directory service information in a file (NTDS.DIT), and trust relationships are still needed to authenticate across multiple domains. Windows Server 2003 automatically creates trust relationships between all domains in a forest just as it did under Windows 2000, but the real change from the older NT4 model to the Active Directory approach lies in how modifications are made and replicated to the domain database and how all automatically created trusts are two way and transitive by default. Now if A trusts B and B trusts C, A trusts C and the reverse is true as well.

Before you get too flabbergasted, don't forget that Windows 2000 and Windows Server 2003 use trusts in the same way. Both operating systems create two-way and transitive trusts.

How domain controllers work together

In the days of Windows NT, domains had it easy. You made changes at only one domain controller, and the changes were copied at regular intervals to any other controllers for the domain.

Now, with Windows Server 2003, you can make changes at any domain controller and remain confident that Windows Server 2003's left hand will always know what its right hand is doing. How does this work, you ask? The answer, dear friend, is multi-master replication. (And you thought we were going to say "blowing in the wind.") How multi-master replication works is discussed in Chapter 11, but here you look at the concept at a higher level.

With multi-master replication, any domain controller can make changes to the Active Directory database. Those changes are then replicated to all other domain controllers in that domain.

Replication between domain controllers in a Windows NT 4.0 domain is configured using a couple of Registry settings that's it fairly useless really. Windows Server 2003 is much cooler !

A site is a collection of machines and domain controllers connected by means of a fast network and grouped by IP subnets. What do sites have to do with replication, you ask? Well, everything. They allow us to define different replication schedules depending on the domain controllers' site membership.

There are essentially two types of replication: intra-site replication (between domain controllers in the same site) and inter-site replication (between domain controllers in different sites).

Intra-site replication

When a change is made to the Active Directory, such as adding or deleting a user or changing an attribute of an object (say, adding properties to a printer), this change must be replicated to other domain controllers in the domain. The change is called an originating update . The domain controller where the originating update was made sends a notification to its replication partners (other domain controllers in the site) that a change is available. After replication occurs, the replication partners will have a copy of the change that was made on the other domain controller. This updating of the Active Directory on the partner domain controller is called a replicated update because it originated elsewhere.

Replication is initiated between domain controllers at a defined regular interval (five minutes, by default) and urgent replication using notification can be initiated for any of the following:

  • Replication of a newly locked-out account: Prevents users from moving to another part of a domain to log on with a user account that has been locked out on a domain controller.

  • Modification of a trust account: Enables all members of a domain to take advantage of a new trust with another domain.

This replication methodology has some problems. In the good ol' days (in other words, with Windows NT 4.0), you changed your password at the PDC to avoid the problem of the new setting not being replicated for a long time. With Windows 2003, the password changes are initially changed at the PDC FSMO; in the event of password failure, the PDC FSMO is consulted in case the password has been recently changed but has not yet been replicated.

If replication partners do not receive any change notifications in an hour (the default setting), they initiate contact with their replication partners to see whether any updates were made remotely and whether the subsequent change notifications were missed.

Inter-site replication

Inter-site replication takes place between particular servers in one site to particular servers in another site. This is where Windows Server 2003 shines. You can configure a timetable of how often to replicate for every hour of every day. All you need to do is go through the Active Directory Sites and Services MMC snap-in (Start Administrative Tools Active Directory Sites and Services). Go to the Inter-Site Transport branch and select IP. In the righthand pane, select a site link (for example, a remote domain), right-click, and choose Properties. Make sure that the General tab is selected and then click Change Schedule. The dialog box used to change replication times appears, as shown in Figure 12-1.

click to expand
Figure 12-1: This is where you change replication times.

In Figure 12-1, replication is set to occur from 12 a.m. to 5 a.m. Sunday through Saturday. You can change this to any schedule you like. For example, you can set it to replicate only on Sundays from 6 p.m. to 7 p.m.

You can have different replication schedules for every pair of sites, so depending on the network connectivity and geographical location, different schedules may be appropriate. For example, if a slow WAN link exists between two sites, a replication with less frequent updates may be necessary to prevent bandwidth consumption.

One other area of replication crosses domains: Global Catalog information. The Global Catalog contains all the information about all the objects in its own domain and a subset of information for every object in the forest. However, Windows Server 2003 performs all the calculations needed to optimize this replication, so mere mortals like us don't need to worry about it.

Know your database limits

In Windows 2003, there's really no limit to the number of objects per domain you're organization will never get that big! Windows NT 4.0 domains are limited to around 40,000 objects per domain. This forces some companies to require multiple master domains joined by bidirectional trust relationships.

Windows 2003, on the other hand, extends this to around 10,000,000 objects per domain. Compaq has performed tests and created 16,000,000 user objects in a single domain with no significant performance problems. However, it had some very powerful hardware probably much more powerful than your home PC or even your company's primary server!

These objects have to be replicated at some point. Windows Server 2003 uses property rather than object replication, which means that only the property change is replicated, not the entire object. In other words, if you change just one property of an object (a user's phone number, for example), only the property change (the new phone number) is replicated not the entire user object.

Your database size is governed by your domain controller hardware and the physical network infrastructure. But if you have enough money to invest in the proper hardware, we doubt that you would need more than a single domain (unless your company is really big). There are, however, other reasons for needing multiple domains and forests, such as needing different schemas. (See Chapter 11 for more on schemas.)

Tip 

The backup and restoration needs of your enterprise may govern database size because a huge directory database is no good if it takes days to back it up.

team lib


Windows Server 2003 for Dummies
Windows Server 2003 for Dummies
ISBN: 0764516337
EAN: 2147483647
Year: 2003
Pages: 195

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net