MicrosoftR WindowsR 2000 Active DirectoryT Programming

Active Directory has several components that work together to provide a complete directory service. Before discussing the various systems, let's explore the concepts that Active Directory employs. Some of these concepts, such as domains, might be familiar to you, but they have different meaning with the release of Microsoft Windows 2000. Understanding these concepts is critical to successfully working with Active Directory.

Objects and Attributes

We know that network directories contain information about users, computers, and printers, but what else? The answer is "a lot." Each item in Active Directory is known as an object. Figure 2-1 shows some different objects in Active Directory. A class, sometimes called an object class, defines the type of object and what information is contained within it. Each class contains a list of attributes that comprise the information that is contained by objects of that class. Attributes are the properties of an object and hold information that describes the object. Some objects hold other objects. These objects are called containers.

Figure 2-1 Objects and attributes in Active Directory.

Schema

The set of definitions that specify what objects and attributes can be stored in Active Directory is called the schema. When an Active Directory domain is initially setup, it contains a default schema known as the base Directory Information Tree (DIT). There are over 140 predefined classes and over 850 attributes in the base DIT. What's particularly interesting is that the schema of Active Directory is stored within the directory itself. That's right, the definition of the objects and their attributes is included in a special directory partition that contains the schema objects. You can browse the schema using the Active Directory Schema console, as shown in Figure 2-2. To start this console, type schmmgmt.msc in the Run dialog box.

Figure 2-2 Active Directory Schema snap-in showing Active Directory classes and attributes.

While Microsoft has done a good job of implementing many different classes, they were also wise enough to know that whatever they defined, it wouldn't be enough. Developers can modify and extend the schema in several ways. New attributes can be added to existing classes and entirely new classes can be added. Best of all, since the definition of the classes is stored in the directory, other applications can discover and use new classes. Detailed information about extending the schema is covered in Chapter 9, "Active Directory Schema."

Domains

Unlike a telephone directory, Active Directory is a hierarchical directory, where objects can be grouped and separated as needed. Active Directory uses constructs such as organizational units, domains, trees, and forests to logically separate information and to help with the management of that information.

Versions of Windows NT before Windows 2000 were also based on domains, but while these domains are organizationally similar, the implementation in Windows 2000 is completely different. If you have a Windows NT background, a review of the differences between Windows NT and Windows 2000 domains is helpful.

Windows NT Domains

In Microsoft parlance, a domain is a collection of computers connected by a network that share user and security information. Domains are not specific to Active Directory or new to Windows 2000. From the first version, Windows NT included the concept of domains. A Windows NT domain is simply a definition of security and a grouping of computer and user accounts. For example, a Windows NT domain named Sales could be created. The Sales domain would contain all the computers and users related to the sales department.

In a Window NT domain, security information such as user accounts are stored in a directory database called the Security Accounts Manager (SAM). The SAM was the forerunner of Active Directory in that it contained directory information for the domain. The SAM resided on a computer called a primary domain controller (PDC), which processed requests for reading and writing to the domain database.

Although Windows NT domains are a useful way to define security boundaries, they do have some limitations. Windows NT domains aren't robust enough. The entire directory for a domain is hosted on a single PDC. The PDC contains the most current version of the directory. Backup domain controllers (BDCs) also contain a copy of the directory, but these copies are read-only in order to force updates to occur only on the PDC.

The SAM database isn't extensible. The various objects and attributes contained within it are fixed and cannot be modified. Also, new object classes or attributes can't be added.

Windows NT domains have limitations when used in large environments. In theory, a Windows NT domain can exist for an entire organization, but if the organization is large, the workload on the PDC is too great. Also, the SAM is not scalable, and once it reaches 40 megabytes, or approximately 40,000 objects, performance suffers greatly.

Creating multiple Windows NT domains increases complexity. To alleviate some of the limitations of a Windows NT domain, a multiple master domain model can be used. This allows several domains to be networked together, like Sales, Development, and Finance. In order to access information such as a shared file or printer on another domain, a trust relationship would need to be established. If Mike in the Sales department needs to access the quarterly reports from Finance, the network administrator is required to set up a trust relationship between the domains. So that everyone in the company has access, a total of six trust relationships would need to be established between the three domains. This is shown in Figure 2-3. For just six domains, thirty trust relationships are needed.

Figure 2-3 Three Windows NT domains with a total of six trust relationships.

Windows 2000 Domains

On the surface, a Windows 2000 domain is very similar to a Windows NT domain, but the implementation and functionality are very different. In fact, many organizations will simply upgrade from Windows NT domains to Windows 2000 domains, maintaining the same domain structure. Over time, however, that structure may change to take advantage of the Active Directory structure and improve network organization.

Windows 2000 and Active Directory improve greatly on the Windows NT domain model in a variety of ways. First and foremost, Windows 2000 domains are more scaleable. Active Directory has the ability to scale to millions of directory objects.

Unlike multiple Windows NT domains that are arranged in a flat structure, Windows 2000 domains use a hierarchical structure. Like Windows NT, Windows 2000 domains still contain all the necessary security and resource information. However, administrators have more control with the hierarchical structure of Active Directory to assign permissions and delegate management tasks.

A Windows 2000 domain is designed to align itself with the Internet's Domain Name System (DNS). Modeling Active Directory on a company's domain name allows for a more intuitive organization. My company, Copper Software, has registered coppersoftware.com for its Internet domain. When creating the primary domain for my network, I named it coppersoftware.com. Computers in the Copper Software network are named copper1, copper2, and so on. As shown in Figure 2-4, the full DNS name of the domain controller is copper1.coppersoftware.com. The alignment between Active Directory names and DNS names is very beneficial. It allows administrators to drop support for NetBIOS naming conventions, which required unique names for computers and devices within the entire organization. With DNS, the name of the computer or device only has to be unique within a particular domain. As an example, there can be a printer1.sales.coppersoftware.com device and a printer1.finance.coppersoftware.com device. Developers of networking applications are freed from the 15-character limitation on NetBIOS names.

Figure 2-4 Domain with two workstations and one server.

Similar to Windows NT, the computer that processes directory service requests and keeps a local copy (a replica) of the directory information is called a domain controller. A Windows 2000 domain can have more than one domain controller, but must have at least one domain controller. The first server created in a domain is charged with being a domain controller. Designing a domain with multiple domain controllers promotes redundancy and reliability and allows it to scale as an organization grows.

Putting the Entire U.S. Phone Book into Active Directory (and then some!)

Active Directory can store millions of objects and still provide quick access. While the Windows NT SAM database started suffering severe performance problems above 40 megabytes, the only meaningful limit on the size of an Active Directory database is hard disk storage. A demonstration was created that illustrated the scalability of Active Directory. Information taken from telephone books from around the country was compiled into a directory of more than 260 gigabytes, containing over 100 million contact objects! Most organizations won't need to store 100 million objects in their directory, but some—such as an Internet Service Provider (ISP)—might need to store millions of objects. For organizations wanting to store over 10 million objects, a multidomain structure may be necessary, but it's good to know that with Active Directory you won't run out of capacity anytime soon.

Namespaces

A namespace is the bounded area in which a name can be resolved. The process of resolving a name to an object or another item is called name resolution. Just like a phone book, where you have a name and can quickly find the phone number of the person with that name, Active Directory's namespace, given the object's name, allows the referencing of any directory object regardless of where it's placed within the hierarchy of the directory.

In Active Directory, the domain is the default unit of name resolution. I can request that the directory return to me information about the user Anthea and it will query the directory and return the associated object. However, this process only works for a single domain. If there is an Anthea in a separate domain, that directory object will not be found and retrieved.

Trees and Forests

Active Directory also supports the concept of trees. A tree is a grouping of one or more Windows 2000 domains. A tree in Active Directory follows the structure of DNS. For example, sales.coppersoftware.com indicates that "sales" is a sub-domain, or child domain, of coppersoftware.com. The top of the tree, coppersoftware.com, is known as the root domain. Each domain within a tree shares the same schema and configuration, forming a larger namespace in which to resolve objects. Domain trees and a DNS structure make it easy for a company to design their Active Directory organization. Figure 2-5 illustrates a Windows 2000 domain tree.

Figure 2-5 Domain tree with two child domains and one grandchild domain.

By now you might be thinking this is all very good for small companies, but what about large conglomerates with many different subsidiary companies? Actually, the single domain model scales upward very well. If geographical considerations or company policy dictates more domains, a single tree with a root and child domains can serve even a very large company well.

However, companies change constantly, divisions are spun off and new companies are formed or acquired. Managing change easily was a requirement for Active Directory. A company might have several Internet presences, for example, and desire to keep operations between them separate. In my own case, I have a separate company unrelated to software and dedicated to aviation and aircraft leasing. It's all contained within the Copper "empire," uh, enterprise, but has its own Internet domain name called copperaviation.com. Thus, coppersoftware and copperaviation would be considered trees. Since they are two facets of the same enterprise, there is much information contained in each tree that should be shared between them. So how can you combine two trees into one logical entity? Using a forest, of course, which you can see in Figure 2-6.

Figure 2-6 A forest of two trees.

As you would expect, a forest is a group of trees. In this case, the Copper enterprise consists of two independent trees, one for Copper Aviation and one for Copper Software, each containing one or more domains. All trees within the forest share a common schema, configuration, and global catalog (defined later in this chapter), but they do not allow for a contiguous namespace to resolve names. Security and replication is handled through trust relationships set up between the domain trees.

For more information about domain trusts, refer to the excellent book Active Directory Services for Microsoft Windows 2000 Technical Reference by David Iseminger (Microsoft Press, 1999).

When to use trees and forests is up to network planners. Generally, child domains making up a tree are formed along geographical or physical placement considerations or both. The key is that all domain controllers within a tree share the entire directory structure, whereas domain controllers in separate trees share only the schema and configuration portions of the directory.

Organizational Units

To subdivide domains, administrators can create organizational units (OUs), which are containers for related objects in a domain. How OUs are related is up to the network administer. One practice is to organize the domain into organizational units that follow business structure. For example, you can have the Research OU in the clearwater.coppersoftware.com domain, as shown in Figure 2-7.

Figure 2-7 Using organizational units to group business related objects.

Most important, delegation and security rights are assigned at the OU level. For example, with the organizational unit shown in Figure 2-7, the Research group assistant could be granted rights to create new users only within the Research OU. This delegation of authority can relieve network administrators from many minor chores while ensuring security.

Security

A key goal of Active Directory is to ensure secure access to data for authorized users and to prevent unauthorized users or their client applications from accessing restricted directory information. With that in mind, all the objects in Active Directory have security settings stored with the object. This information is known as the Access Control List (ACL); it contains data on what operations can be performed on the object and its attributes and what entities (users, groups, and so on) are allowed to perform those operations. These security settings can also include permissions for object creation, such as creating new user or computer accounts. Active Directory also allows child objects to inherit the security settings of their parent. By using Active Directory, administrators can both tighten security over the network and relieve their own administrative burden.

Directory Partitions and Naming Contexts

Each domain controller in a forest includes what are called directory partitions. A directory partition is a contiguous portion of the overall directory information. By partitioning the directory data into logical groups, indexing and searching operations can be improved. Additionally, each partition can have its own replication schedule. These partitions are also called naming contexts. By default, the Active Directory for a enterprise consists of at least three partitions: schema, configuration, and domain partitions.

Schema Partition

The schema partition contains the definition of the type of data stored in the directory. This partition is shared by all the domains within a forest. When Active Directory adds new objects to the directory, it checks the schema partition for the definition of the object and applies consistency rules. Additionally, applications can query the schema partition to discover allowable classes and attributes.

Configuration Partition

The configuration partition is used to store configuration data for the network, such as topology, replication settings, and other network-wide services. You can view a portion of the configuration partition of Active Directory using the Active Directory Sites and Services snap-in. By default, the configuration data in the Services node is hidden. To display the Services node, click the View menu and then select Show Services Node, as shown in Figure 2-8.

Figure 2-8 The Services node of Active Directory Sites and Services shows a portion of the data in the configuration partition.

Some network services, such as the remote access service (RAS), store their configuration data in the configuration partition. Network applications can add their own containers to this partition to store configuration information to be distributed to all the domains in the network.

Domain Partition

The domain partition is where most of the data in Active Directory for a specific domain is stored. It contains the information that is most often associated with a network directory, including information about users, computers, and various network resources such as shared printers and folders. The domain partition is also known as the default naming context. This partition is only shared among other domain controllers for the domain (for redundancy purposes) and not with child or parent domains.

Active Directory is really the combination of all the directory partitions for an enterprise. That includes all the individual domain partitions and one schema and configuration partition for each forest that makes up the enterprise. Since the data is partitioned and distributed throughout the enterprise, no one computer has to store all the data that makes up the Active Directory.

So how does an application find a particular piece of information? That's the purpose of the global catalog, discussed next.

Global Catalog

One way Active Directory improves searches is to maintain a global catalog. Similar to an index file of a database, the global catalog (GC) contains a copy of all the directory objects in an enterprise but only a subset of the attributes for each object. This is useful for the times when name resolution is required but the domain of the object is not known.

When a person logs on to a Windows 2000 domain and provides a username, the global catalog is searched to find a match between a user object and the provided username. Once found, the global catalog replica of the object is queried for the user's domain.

The global catalog replica contains only those attributes that are most commonly used when searching. Remember, in a forest configuration, each domain controller in a tree contains copies of the domain's directory partition. However, another tree has a completely different directory partition, which is shared among the domain controllers of that tree. By using the global catalog, a domain controller can quickly look up an object and provide certain attributes without deferring to other domain controllers. Compared with simply asking a domain controller to hunt down the object by making recursive calls to other domains within the forest, known as referral chasing, the global catalog provides real value and efficiency. I'll discuss referral chasing more in Chapter 5, "Searching Active Directory."

Multimaster Operations

In Active Directory, a copy of the domain partition is contained on each domain controller within the domain. Each domain controller is fully independent and can both read and write to its local copy of the directory. As mentioned earlier, this ability is different from Microsoft Windows NT domains, in which all updates to the SAM database are performed on the PDC and the BDCs have read-only copies of the database. The Windows NT style of updating—all changes made on one machine—is called a master-slave or single-master approach. In contrast, the approach to updating data that is used by Active Directory is known as multimaster: there is no single master domain controller and no single point of failure. If you have a complete copy of the directory on each domain controller, one domain controller does not need to send a request to another domain controller to process a request from a local user, and performance is greatly enhanced.

Flexible Single-Master Operation Roles

So, multimaster operation means that all domain controllers are created equal? Although that is the goal, in reality, there are certain dependencies on particular domain controllers. For example, in order to protect the integrity of the Active Directory schema, modifications can be performed only on one domain controller in the entire forest. This domain controller is called the schema operations master. In addition, Active Directory does away with the need for a specific PDC, but allows a particular domain controller to act as a PDC emulator for backward compatibility with network workstations running Windows NT 4.0 that expect to connect to a PDC. Table 2-1 lists the various flexible single-master operation (FSMO) roles.

In a small domain, one domain controller might perform all the various operations. In a larger organization, the various FSMO roles might be distributed to other domain controllers to reduce workload on any one machine. The Ntdsutil tool (discussed later in this chapter) can be used to display and modify which domain controllers perform the various operation roles.

Table 2-1 Flexible single-master operations roles.

Generally, you do not need to worry about which domain controller is performing a specific role. The exception is when you write a program extending the schema. Doing this requires discovering and connecting to the schema operations master. In Chapter 9, "Active Directory Schema," I'll discuss retrieving the specific name and address of the domain controller performing the schema operations master role.

Replication

A major feature of Active Directory is its ability to synchronize directory information for multiple domain controllers. The process of synchronizing directory information is known as replication. Replication has three primary benefits: increased performance, scalability, and fault tolerance. Performance is improved because any domain controller can search the local domain for directory information. Scalability is made easier because as the directory grows, additional domain controllers can be added to distribute the load. Fault tolerance is increased because if one domain controller is disabled, other domain controllers in the domain can handle requests using the same directory data.

From the viewpoint of an Active Directory developer, replication normally happens automatically and transparently. However, application developers need to have an understanding of the process in order to take into account the inherent latency of distributing directory data.

Replication Model

The specific replication model that Active Directory uses is called multimaster loose consistency with convergence. (If we were playing Buzzword Bingo that would win the pot.) So what does it mean? Here is the breakdown:

• Multimaster  All domain controllers in the forest can accept changes.
• Loose consistency  The copy of the database on any particular domain controller is not guaranteed to be consistent with any other domain controller at the same time.
• Convergence  Changes to the directory will ripple through all the copies and eventually converge on the same values throughout.

What's important for developers to recognize here is that at any given time, a domain controller contains only a copy, or replica, of the directory data. Changes made at another domain controller will eventually reach the domain controller that you might be communicating with, but you should make no assumptions about how long that process might take. Since directory data is normally updated on an infrequent basis, this latency is generally not a concern.

Triggering Replication

Whenever a change is made to directory data, Active Directory triggers an update cycle that ensures that the information is propagated to the other domain controllers that hold replicated copies.

A change occurs when an object is modified in any way—created, deleted, or moved—or when any attribute of the object is changed. Something interesting to note is that when clients make changes to the directory, the changes are made at the object level as one transaction. If any change to a particular attribute fails, all the other changes are rolled back and the transaction is cancelled. This protects the consistency of the object. However, replication occurs at the attribute level. This makes sense, since it would be incredibly wasteful to copy the entire contents of an object to many different domain controllers if only one attribute has changed.

Within a domain, the changes are replicated immediately. When a change is made to a directory object, the domain controller on which the change is made uses remote procedure calls (RPCs) over TCP/IP to inform other domain controllers within the domain of the change. In turn, the other domain controllers then make an update request to the originating domain controller. This method is known as pull replication and relies on domain controllers to query each other for changes. This process provides for multiple replication paths that can reduce the time it takes for all directory replicas to converge on the same set of values (to be synchronized). For example, domain controller DC1 might update DC2, which then updates DC3. However, when DC3 requests updates from DC1, it should only receive changes that it hasn't already received from other domain controllers.

Update Sequence Number

Windows NT 4.0 would only allow changes to be made to the SAM database on the PDC and would then use timestamps to determine how to update BDCs. This approach required that all domain controllers be synchronized to the same clock, and even slight timing errors could cause problems in database consistency. Active Directory in Windows 2000 uses a new method, called an update sequence number, to determine how to update multiple versions of the database. An update sequence number (USN) is a 64-bit value kept at the local domain controller. When an object is changed, its uSNChanged attribute is updated with the current USN value at the DC making the change. The DC then increments the USN by 1 and waits for the next change.

When a destination domain controller requests updates from another domain controller, it uses a value called the high-watermark, which is the highest USN received from the other domain controller during previous replication cycles. The originating domain controller can then search through its list of updated objects and provide only those with a higher USN, cutting down on traffic and server overhead. However, the high-watermark value by itself is not sufficient to prevent redundant updates. Domain controllers maintain a table of the most recent USN value from all other replication partners. This is known as the up-to-dateness vector. When replicating, the destination domain controller sends the up-to-dateness vector to the originating domain controller. If the destination and originating domain controllers have the same USN value for a particular domain controller, it can be assumed that both have the changes originating from that particular domain controller and there is no need to send updates that originated from it. While reducing replication traffic, the up-to-dateness vector also prevents changes caused by endless looping from domain controller to domain controller.

Since updates to the directory usually occur in batches, Active Directory uses propagation damping to prevent excessive interserver replication traffic. Each domain controller uses a built-in holdback timer to bundle directory update changes into a group. By default, this timer is set for 5 minutes and can be changed through a registry setting, although changing it is rarely necessary. This means that a domain controller will wait 5 minutes after a directory change before notifying replication partners that updates are available. In addition, domain controllers wait 30 seconds before notifying replication partners of new changes that were not originated on that server.

Topology

In the previous examples, replication occurs immediately for the various domain controllers within a domain. This works well for domain controllers that are all connected using high-speed networking, such as 100-MB Ethernet, but given the frequency and asynchronous nature of changes, the pull method of replication would be inefficient over slower connections commonly found in wide-area networks (WANs). For that scenario, Active Directory uses a different strategy, called store-and-forward replication. In this strategy, one domain controller is designated to hold all updates and then forward them to another domain controller.

Network administers can set up a defined topology of domains interconnected using various means. The unit Active Directory uses for this topology is known as a site. A site represents one or more subnets of a well-connected IP network. Normally, when I think of "well connected," I think of receiving the latest beta of Flight Simulator from my friend at Microsoft, but in this case, a "well-connected" network is a network of computers, servers, and workstations that are physically connected at LAN speeds (10 Mbps) or greater. Computers that dial in to the network using a modem or DSL connection would not be considered well connected.

For example, I show a potential site topology in Figure 2-9. In this topology, I show two domains and four sites. The domains coppersoftware.com and europe.coppersoftware.com each contain two sites, representing imaginary branch offices of Copper Software. Since the servers and workstations within a branch office are well connected, a site is defined in Active Directory to ensure that replication traffic is handled nearly immediately. I can define a schedule for replication in Active Directory with an object called a site link. A site link is an object that represents a set of connected sites. However, the Clearwater site might not have good connectivity to the Dublin or Reading sites, so I want to route replication traffic between the coppersoftware.com and europe.coppersoftware.com domains only between a particular server in the Home Office site and the Dublin site. For this, a site link bridge can be established, which is an object that represents a set of site links. A site link bridge defines the servers, path, and schedule used to route replication traffic.

Figure 2-9 Site links and a site link bridge for a forest with two domains.

Another benefit to using sites is to help clients find directory services provided by servers that are electronically closest to them. When a user logs on to a computer using Windows 2000 Professional, the directory service client asks the nearest domain controllers to process the logon. By defining sites, network administrators reduce traffic over network routers and switches and spread directory service requests to various domain controllers. Figure 2-10 shows how sites are managed using the Active Directory Sites and Services snap-in.

Figure 2-10 Active Directory Sites and Services snap-in showing two sites, Home and Clearwater.

Patience Is a Virtue

What happens when distributed networks communicate information too quickly was painfully illustrated on Monday, January 15, 1990, when AT&T's toll-free telephone network experienced a massive failure because of a simple programming mistake. It started when one of the large network switches that routes telephone calls had a minor fault and went off line temporarily. In the process, the switch notified the other switches in the network of its status, and those switches automatically routed calls around the off-line switch. When the fault was corrected, the off-line switch notified the other switches that it was now available to start accepting calls again. However, because of a misplaced break statement in C language code recently loaded into the switches' computers, if a switch received two calls within 1/100^th of a second while it was updating its status map, it would corrupt some data. The switch would detect this corruption, send out a message indicating its status, and reboot. Once the switch had recovered, it would broadcast a message indicating that it was "OK." This caused other switches to update their status maps, putting them at higher risk of encountering the flaw. Eventually, this caused a cascading effect. During this time, business on the east coast of the U.S. was severely limited for several hours until AT&T reverted to a previous version of the switch software.

Conflict Resolution

What happens when an attribute of an object is updated on one server, but before it can be replicated, it is also updated on another server? For example, a user at the Clearwater site of Copper Software forgets his password and asks the help desk to reset it. Someone at the help desk resets the user's password, updating the password attribute of the user's object. These changes are made locally on the domain controller COPPER1 located at the home site in Seattle. Just then, the user remembers the old password, logs in, and changes it to something else. This change would be made on the CLEARWATER1 domain controller at the Clearwater site. Now the system has two changes to the same attribute of the same object, but the new values are stored on different domain controllers. When replication occurs between COPPER1 and CLEARWATER1, a conflict will occur and must be resolved.

Resolution is accomplished by sending a unique stamp along with each attribute of an object that has been changed. This stamp contains the version number of the attribute, the time when the value was changed, and the globally unique identifier (GUID) of the server that was processing the change. This stamp travels with the changed attribute throughout the replication process to all domain controllers.

When COPPER1 and CLEARWATER1 connect to replicate changes, they compare the stamps applied to their versions of the same attribute. To resolve the conflict, they compare the version number of the password attribute. Since both domain controllers made changes to the same version and increased its value accordingly, the version numbers will be the same. The next tiebreaker is the time of the modification. In this example, the help desk made its change first at the COPPER1 server. Its modification time will be earlier than the change at CLEARWATER1. Active Directory's policy is to accept the change recorded last, so the value at CLEARWATER1 will be accepted, and the COPPER1 value will be discarded.

The modification time is recorded in 1-second resolution, so it's theoretically possible that two changes could occur at the same time. In that case, which change is accepted and which is discarded is arbitrary. I suspect that whichever originating domain controller has the greater GUID value wins in these cases, and GUIDs are as arbitrary as you can get. To paraphrase an old saying, "You can pick your friends, you can pick your domain names, but you can't pick your GUIDs."

Password Changes and Urgent Replication

The previous password example is actually somewhat misleading. In reality, Active Directory treats changes to password attributes differently from other changes. When a password attribute is updated on a domain controller, it immediately notifies the domain controller that is serving as the PDC operations master for the forest.

When the user attempts to log on with a newly assigned or blank password, the local domain controller checks its local copy of the user object. If the password matches, the user is verified. However, if the password does not match, the local domain controller refers to the PDC operations master to verify the user. Since the PDC operations master was updated immediately, the new password will be accepted. Readers experienced with Windows NT or Windows 2000 network administration will notice that until normal replication occurs, both the old and new passwords will authorize the user.

Another type of replication is known as urgent replication; it is trigged by security-sensitive changes. Like password changes, urgent replication does not respect predefined schedules or site links when communicating with replication partners. The following types of operations trigger urgent replication:

• Locking out a user account
• Changing the Local Security Authority (LSA) secret
• Changes to the relative identifier (RID) manager, which assigns roles to particular domain controllers

Forcing Replication

It's rarely necessary for a directory-enabled application to force a replication between domain controllers and sites. One exception is when changes have been made to the schema. It's desirable to ensure that all domain controllers get these changes as soon as possible. There are multiple ways you can initiate a replication. One way you can force a particular domain controller to replicate with a specific domain controller or all of its replication partners is by using the DsReplicaSync or DsReplicaSyncAll API functions. Network administrators and developers using scripting languages can use the Repadmin tool from the Windows 2000 Support Tools set to force a replication.