chapter 1 managing the active directory (2)

8/11/2019 Chapter 1 Managing the Active Directory (2)

1/50

Chapter 1: Monitoring Active Directory Page 1

Chapter 1: Managing Active Directory

Directory services have been around for a while, and every company has at least one, and inmany cases several, directories of information. Traditional directory services were based on the

X.500 standard for a hierarchical, extensible data store. However, many other types of directories

can be found in companies today that dont fit the X.500 model. Typical examples of directorieswithin companies include Enterprise Resource Planning (ERP) applications (produced by

vendors such as PeopleSoft, SAP, and Baan), network operating system directories (such as

Novells NDS and NT 4.0s Security Account Manager, or SAM, database), white pagesapplications, and potentially dozens of other repositories where people or resource information is

stored.

Tip: For an excellent general overview of directory services and their various

implementations, I recommend reading Implementi ng Dir ectory Servicesby

Archie Reed (McGraw-Hill; ISBN: 007134408X).

The first revision of Active Directory (AD)represents another instance of these multipledirectories that a company can implement, albeit with a slant towards managing a networkoperating system. AD is an X.500-compliant implementation, which means it loosely follows

the constructs that the X.500 standard specifies but deviates as the needs of the vendor dictate.

Of course, Microsofts goal is for you, the customer, to use AD as more than just a network

operating system directory. Indeed, Microsoft Metadirectory Services (MMS), which is based on

the former ZoomIt! Metadirectory product, promises to tie AD, as well as all of your otherdisparate directory services, into a common, Microsoft-centric directory namespace. The engine

behind the namespace will, in the future, most likely be based on AD.

AD is the most significant, and arguably the most important, change that Windows 2000 bringsto the NT product line. It replaces the NT 4.0 SAM database as a repository for domain security

principals like users and computers, but it does much more than that. AD introduces the concept

of an extensible, hierarchical directory service. And, whats perhaps most interesting, ADprovides the basis for what I think will be the emergence of many directory-enabled

applicationsthat is, applications that use the directory as a store and a source of information to

facilitate many types of value-added computing. Using Microsofts Active Directory ServiceInterfaces (ADSI), a set of application programming interfaces (APIs) for accessing AD

information, independent software vendors (ISVs) will now have an easy and compelling path

towards directory-enabling their applications in many useful ways.


2/50

Page 2 Chapter 1: Monitoring Active Directory

For the system administrator, AD and ADSI provide many new capabilities for managing Win2K

users and devices. But they also open up a whole new level of complexity and a significantlygreater requirement for good planning before implementation. AD, in its first incarnation in

Win2K, also brings some interesting architectural and technical challenges that youll need to

take into consideration as you proceed in your planning. This chapter will give you theinformation you need to become an AD expert. Ill describe the behind-the-scenes structure of

the directory and point out how you can leverage it. Ill also touch on some practical advice for

the systems administrator facing the daunting task of not only implementing, but also managingand troubleshooting, an AD infrastructure.

AD Fundamentals

In order to implement and support an AD infrastructure, you need to have a lot of goodinformation about how the AD works at a high level. However, in order to troubleshoot and

optimize your AD implementation, you need to know how to do more than just navigate

Microsoft Management Console (MMC) snap-ins. You need to understand whats really goingon under the covers. You need to be part developer, part system administrator and part network

engineer. Based on that, I thought it would be valuable to give you some good technical detail

around how AD is structured and how it actually works. This next section is devoted to that task;it forms the basis for later parts of this chapter as well as other chapters in this book.

The Schema

The kinds of things that can be contained within a directory servicethat is, the objects and theproperties associated with those objectsare defined in the directoryschema. Just as with

databases, the schema defines the structure, if you will, of the directory service. . The AD

schema defines the types of objects and properties that you can create.

AD uses an object-oriented approach to defining directory objects. That is, there is a hierarchy of

classes, which define the kinds of objects that can be created within the directory. Each class hasa set of attributesthat define the properties associated with that class. For example, AD has a

userclass that has attributes such as firstName, Address,and so on. Interestingly, the AD

schema itself is stored in the directory as objects. That is, AD classes are stored as objects of theclass classSchema, and attributes are stored as objects of class attributeSchema. The schema,

then, is just a number of instances of the classes classSchemaand attributeSchema, with

properties that describe the relationship between all classes in the AD schema.

To better understand this relationship, lets go back to the object-oriented model, upon which the

AD schema is based. Just as with object-oriented development languages, a class is defined as akind of basic definition of an object. When I instantiate an object of a certain class, I create animplementation of that class. That implementation has a number of attributes, or properties,

associated with the class from which it was created. For example, suppose I create a class called

car, which has attributes like color, numberOfDoors, and so on. I can instantiate the class carand create a real object called Ford Pintowith attribute values like white(for the color

attribute) and two(for the number of doors).


3/50


Similarly, an AD implementation within your enterprise is just the instantiation of the AD

schema classes and attributes into hundreds or thousands of different object classes and theirassociated attributes. For example, I create an object of the class usercalled John Smith, who

has properties like password, address, homeDirectoryLocation,and so on. You can view the

AD schema using the MMC AD Schema snap-in.

The MMC AD Schema snap-in isnt a raw view of the AD schema. Rather, it provides a

sanitized view of the schema, shielding all of the individual attributes of every class andattribute type of object. It basically shows the important info you need when viewing the schema.

To get a more raw look at all of the individual attributes for all of the classSchema and

classAttribute type objects in the AD, you can use the MMC ADSIEdit snap-in that I describelater in this chapter in Naming Contexts. Figure 1.1 shows a view of the AD schema using the

MMC snap-in.

Figure 1.1: Viewing the AD sch ema using the MMC snap- in.

ClassesOn the left pane in Figure 1.1 are two foldersone for classes and one for attributes. If you drillinto each folder, you see all of the AD classes and attributes defined in the default AD schema on

the right-hand pane. The default AD schema, when you load Win2K out of the box, contains 142

different classes and 863 different attributes. There are actually three different categories ofclasses within the AD. These are described here:


4/50


StructuralA structural class is one that can be instantiated into a directoryobject. All structural classes in the AD inherit from abstract or auxiliary classes.

AuxiliaryAuxiliary classes are used to extend the properties of a class thatinherits from it. However, you cant instantiate a directory object directly from

an auxiliary class, only from a structural class that has inherited properties from

the auxiliary class. There are actually two types of auxiliary classes. Systemauxiliary classes are defined by the AD and therefore cant be removed. In the

second type, you as administrator of the AD can define auxiliary classes bymodifying the schema (described later in this section).

AbstractIn object-oriented (OO) parlance, the abstract class is similar to theabstract base class in OO programming. That is, abstract classes are meant to be

parent classes of structural classes, but you cant instantiate a directory object ofan abstract class.

Figure 1.2illustrates the basic relationship between these three types of classes and a typical AD

object.

Figure 1.2: The relat ionship between d if ferent AD schema c lass types.

If you look at Figure 1.1again, you can see that under the highlighted classes folder, each classtype is listed in the right-hand pane as structural, abstract or auxiliary. The default AD schema


5/50


actually specifies only four system auxiliary classes, namely mailRecipient, samDomain,samDomainBase,and securityPrincipal.

Note: The AD schema further categorizes classes into two types. Youll see

references to Category 1 and Category 2 classes. Category 1 classes are those

defined by Microsoft in the base product and are subject to certainrestrictions when you try to extend the AD schema (see Extending the

Schema below). Category 2 classes are those that you define and arent

subject to the same restrictions as Category 1 classes. You can identify the

category of a class by looking at its systemFlags attribute. If this attribute is

set to hex 10 (decimal 16), its a Category 1 class and is subject to

restrictions. Note that attributes are also categorized using this method.

In addition to containing these three types of classes, the AD schema is further described by the

relationship between specific classes. There is a hierarchy of inheritance within the schema thatdefines which classes inherit from which others. At the top of the hierarchy is a class called top,which is the mother of all classes, so to speak.

The convention of topas the root class comes from the X.500 specification and is used by the

AD as well. Each AD class defined in the schema has an attribute called subclassof, which tells

you what that classs immediate parent class is. For example, the classSchemaobject called

Personhas a subclassof attribute of top. The classSchemaobject of class userhas a subclassof

attribute of organizationalPerson, which is typically part of any X.500 implementation. A

subclass inherits those attributes defined for the parent class. For example, if the class

organizationalPerson contains an attribute for the address to a users Web page, objects of class

userwill, by virtue of inheritance, also have that attribute.

In addition to having a parent-child relationship, AD classes also have a relationship to other

classes calledpossible superior. A possible superior is a class that can contain an instance of the

current class. For example, an object of type user class can be created within a domain or an

Organizational Unit (OU). However, it doesnt make sense to be able to create a user objectwithin a Group Policy Object (GPO). Therefore, GPOs arent a possible superior to the userclass.

There are actually two attributes on a class object that control its possible superiors. There is the

systemPossibleSuperiorand the possibleSuperiorattributes on every AD class. The

systemPossibleSuperiorattribute is defined by Microsoft in the default schema and controlswhat classes can contain instances of other classes. As the administrator of a forest (and by virtue

of membership in the Schema Admins user group), you can modify the possibleSuperior

attribute to specify additional possible superiors to a given class. Figure 1.3 shows thisrelationship for the userclass, viewed using the MMC AD Schema snap-in.


6/50


Figure 1.3: Viewing th e PossibleSuper ior Relat ionships for the user class object .

Also in Figure 1.3, you see any auxiliary classes that may be defined for this class. Think of

auxiliary classes as additional parent objects. They let you tack on additional attributes to aparticular class without changing the parent class. For example, suppose you wanted to add a few

attributes to user objects in your companys AD implementation that are specific to yourcompanyfor example, employeeIDand shoeSize. You could extend the default AD schema to

create a new auxiliary class called myCompanyUser with these two new attributes, and make itauxiliary to the user class, by adding it to the user classs auxiliaryClassattribute. Just as with

possible superiors, each AD class object contains two attributes related to auxiliary class

namely, systemAuxiliaryClassand auxiliaryClass. The former is defined by Microsoft for thatclass, and you can modify the latter to add additional auxiliary classes.

Note: The behavior of class inheritance in the AD means that a given class

may contain a number of inherited attributes that have no relevance to its

function in the directory. This is normal, but it may be confusing to the

administrator who is looking through the schema. Generally, these unusedattributes arent exposed through the normal MMC administrative snap-ins

and dont cause a problem. However, you need to be aware of them in any

case.


7/50


Attributes

Ive discussed AD classes, and now Ill move on to discuss AD attributes. Attributes are defined

in the schema as objects of type attributeSchema. Every available attribute is represented in thebase AD schema. Attribute objects have a few interesting attributes themselves, namelysyntax

and whether theyre indexed. Syntax indicates the type of data that the particular attribute can

store. For example, the surname(last name) attribute takes syntax of Unicode string,indicating that the data in this attribute must be a string. However, an attribute like

userPassword, as you can imagine, needs to store information in a different form and thus has a

syntax of Octet string, indicating that the attribute can store binary data (see Figure 1.4

below).

Figure 1.4: Viewing th e syntax of the userPassword at t r ibute.

The AD supports a total of 23 different types of syntax for different data types, including basic

strings, dates, directory-related types of data like the so-called distinguished name and even a

syntax for Security Identifiers (SIDs).

In addition to supporting syntax, AD supports indexing attributes. Just as with a typical database,

indexing a particular attribute speeds any searches that you need to perform based on thatattribute. So, for example, if you need to do a lot of searches of your AD for user objects with the

same manager, you can modify the schema to index the managerattribute. This improves the

speed of that particular search operation within the directory.


8/50


Another property on schema attributes that you can set controls whether the attribute is replicated

to the Global Catalog (GC). I havent talked yet about the GC, but its a partial replica of allobjects and some of their attributes within an AD forest. The GC is replicated to designated

domain controllers (DCs) within your forest. The set of attributes that is replicated to the GC is

controlled in the schema. Objects of type attributeSchemahave an attribute calledisMemberOfPartialAttributeSet . If this attribute is set to TRUE, that attribute is replicated to

the GC. You can enable this attribute using the AD Schema snap-in by right-clicking a particular

attribute, selecting Properties, then selecting the Replicate This Attribute to the Global Catalogoption (see Figure 1.5).

Figure 1.5: Choosing the opt ion fro m the A D Schema snap- in to repl icate an at t r ibute to the GC.

Of course, attributes and classes dont exist in isolation from each other. Attributes are related to

classes in meaningful ways. As I mentioned above, classes inherit from each other through ahierarchy of relationships. A parent class has a set of attributes associated with its object type.

For example, the organizationalPersonclass has the streetAddressattribute associated with it.And, by virtue of inheritance, the user class also has the streetAddressattribute.

Attributes come in two flavorsmandatory and optional. Mandatory and optional attributes for a

given class are defined in the schema for class objects using the following four attributes

systemMayContain, mayContain, systemMustContain, and mustContain. The two

mayContainattributes specify the optional attributes that the defined class may contain. The two

mustContainattributes specify the mandatory attributes for that class. Again, the two attributes


9/50


prefaced by the wordsystemindicate that these are defined by Microsoft in the base AD schema

and cant be modified. When an attribute is mandatory for a given class, any object created from

that class must contain a value in that mandatory attribute at creation time. For example, the userclass has eight mandatory attributes that must be filled in when a new user object is created.

Figure 1.6 shows these mandatory attributes for the userclass from the AD Schema snap-in.

Figure 1.6: Viewing th e mandatory at t r ibutes for the user class.

Note that the far right column of the right-hand pane in Figure 1.6 lists the source class for thatparticular attribute. That is, all of the mandatory attributes for objects of the userclass are

inherited from parent or auxiliary classes. For example, the samAccountNameattribute (which

stores a users downlevel NT 4.0-compatible user id) was inherited from an auxiliary class called

securityPrincipal. All eight of these mandatory attributes must have values when you add a new

user object to the AD; otherwise, the creation will fail.

Youll notice that, when you use the new user creation wizard available in the MMC AD Users

and Computers snap-in, youre asked to provide some basic information, including the users full

name, Win2K User Principal Name (UPN), and down-level logon name. Using this information,and other information the wizard derives automatically, the eight mandatory attributes (as well as

a number of optional attributes) are filled in for the new user created by the wizard.


10/50


What is the User Principal Name (UPN)?

Youll see references in AD documentation to something called the User

Principal Name. When you create a new user object in the AD, you assign it a

Win2Kcompatible logon id. The new user also gets a downlevel NT 4.0style

logon id (to go with the AD domains downlevel name). The Win2K-compatible logon takes the form of username@.

For example, if I create a user account called John Smith in the AD domain

called mycompany.com, the UPN for that user might take the form of

[email protected] or [email protected]. Either one is a

valid UPN. When that user logs onto the domain from a Win2K workstation,

they can provide either their UPN or their down-level(such as

mycompany\jsmith) logon name. Note, however, that both the UPN and the

downlevel logon name must be unique within the domain. That is, you cant

have two [email protected] accounts, nor can you have two

mycompany\jsmith accounts.

The AD also gives you the ability to create something called Alternative UPN

Suffixes. These are alternate domain names that you can use when creating

your User Principal Names. You create Alternative UPN Suffixes from the

AD Domains and Trusts snap-in, by right-clicking the words Active

Directory Domains and Trusts, choosing properties and adding additional

UPN suffixes. UPN suffixes are forest-wide, and let you choose a different

domain name for your UPNs from the actual name of your AD domains. For

example, suppose you have a forest with two domains called east.myco.com

and west.myco.com, but you wish to have users in both domains login using a

UPN of [email protected]. You can create a UPN suffix of myco.com, which

then can be assigned as the UPN domain name for users in both domains.Note that the Alternate UPN suffix is merely an AD object, and has relevance

only for UPNs. It does not have a corresponding DNS domain within your

DNS infastructure.

Optional attributes are just thatoptional. What youll find is that each object class in the AD,

by virtue of inheritance, can contain a large array of attributes. For example, the userclassinherits some 73 attributes from the root class, top. Many of these attributes arent exposed

through the normal AD management snap-ins, and many of them are totally irrelevant to a user

object. However, they are there by virtue of inheritance and can be defined if needed.

Extending the Schema

One of the biggest advantages of the Win2K AD over the NT 4.0 SAM is that you can extend theAD schema as your organizations needs dictate. While extending the schema shouldnt be taken

lightly, you can in any case add new attributes and classes to the base AD schema if application

or infrastructure needs arise. In addition, youre likely to find third- party software vendors

taking advantage of this extensibility by requiring new AD classes or attributes when you install


11/50


their applications in the future. There are some limitations on exactly how you can extend the

AD and some best practices on doing so that Ill describe in this section.

Lets first talk about what you cant do when youre getting ready to extend the base AD schema.

The following list spells out the restrictions in the current version of the product:

You cant add or remove any mandatory attributes from an existing class. So,for example, the organizationalPersonclass contains a mandatory attributecalled ntSecurityDescriptor, and this cant be removed. Nor can you add a new

mandatory attribute to this class. Note that this also means you cant add a new

mandatory attribute to an existing class by virtue of adding an auxiliary class toan existing class. For example, if I tried to have the organizationalPersonclass

inherit a mandatory attribute from an auxiliary class that I created, this wouldnt

be allowed.

Once you add a new class or attribute, you cant delete it from the AD schema.You can only mark it defunct, which prevents any more instances of objects or

attributes of that class from being created, but doesnt remove existing objects.Note that only Category 2 classes and attributes (those that you create yourself)

can be declared defunctCategory 1 classes and attributes are consideredsystem critical and cant be marked defunct. Also note that if you mark an

attribute defunct, any classes that contain that attribute (that is, have

mayContainor mustContainvalues that include the defunct attribute) mustalso be declared defunct. This is because some of those classes might have the

defunct attribute declared mandatory, and that would prevent objects of that

class from being created.

There are limits on how Category 1 classes (those created by Microsoft and thattherefore may have system-critical roles) can be modified. Namely, you cant

rename a Category 1 class or attribute. You cant change the following attributesof a Category 1 attribute: rangeUpper, rangeLower, or

attributeSecurityGUID. You cant change the defaultObjectCategoryattribute for a Category 1 class, nor can you change the objectCategory

attribute for an AD object created from a Category 1 class. Finally, you cant

change the lDAPDisplayName of a Category 1 class or attribute.

Once youve determined that these restrictions arent going to impact your planned schema

changes, the next step is to determine what kind of change you need to make. For example, areyou just looking to add some additional attributes to an existing class? Do you need a completely

new class that shares none of the attributes with any existing ones? Or do you want to create a

new subclass of an existing class, so that it inherits the features of that parent class, but add morefeatures of its own? These are the three scenarios youre likely to face when you think aboutextending the schema.

To illustrate the process of extending the schema, Ill tackle the scenario where I want to addnew attributes to an existing class. To accomplish this, I have two options. I can either create a

new auxiliary class that contains the attributes Im interested in adding, or, I can add new


12/50


attributes to an existing class. The former approach is desirable if I need my new attributes to be

available to more than just one class. For example, I may want to use my auxiliary class to

extend userand groupclasses. Its more efficient to do this by creating a single auxiliary classrather than duplicating new attributes on each individual class that I need to extend.

Obtaining OIDsThe first step I need to take to extend the schema (after I decide which method Im going to use

to do so), is to obtain a root X.500 Object Identifier (OID) for my new classes or attributes.

Every class and attribute in the AD is uniquely identified by its OID. Figure 1.7shows the userclass with its OID highlighted.

Figu re 1.7: Viewing th e OID for the us er class.

The OID naming scheme is part of the X.500 specification. As you can see from Figure 1.7, the

OID naming scheme uses a dotted notation that corresponds to the issuing authority (the vendoror standards organization) for that schema element. If youre familiar with the SNMP protocol

and how MIB elements are identified, the directory OID scheme is a different part of the sametree.

In the case of any X.500-based schema elements included in the AD schema, these classes and

attributes are identified using an OID that starts with the indication that it was issued by the

International Standards Organization (ISO), then follows a hierarchical tree down to vendor-specific implementations. For example, if you look at the class topin the AD schema, its OID is

2.5.6.0. The first three numbers indicate the issuing authority, in this case the ISO. The last


13/50


number, 0, indicates that this class is at the root of this particular schema. If you look at some

other classes that are known to be part of the standard X.500 schema, like

organizationalPerson, youll see that they all start with 2.5.6, and the last number isincremented. Likewise, if you look at schema elements created by Microsoftfor example, the

user class, its OID is 1.2.840.113556.1.5.9. All Microsoft schema elements begin with

1.2.840.113556.

If you need to modify the default AD schema with your own custom classes or attributes, youre

going to need your own root OID. Ideally, if you plan to make frequent and significant changesto your AD schema, and especially if you plan to make your AD implementation available on the

Internet, register your organization to get an official ISO root OID with the governing body that

controls such things. In the United States, the governing body for OIDs is the American NationalStandards Institute (ANSI) at http://www.ansi.org.If youre not in the US, you can go to the

ISOs Web site at http://www.iso.chto find your own local governing body. Getting your own

registered OID ensures that any schema modifications you make dont conflict with those made

by another company.

If you dont plan to run your AD on a public network, and just intend it to be used within your

own organization for its entire life, you can use a Microsoft Resource Kit utility. CalledOIDGEN, it generates a unique OID underneath the Microsoft registered namespace (that is,

1.2.840.113556). OIDGEN is a command-prompt utility that takes no arguments and simply

returns a unique root ID for both class and attributes schema changes that you may want to make.Figure 1.8shows sample output for OIDGEN.

Figure 1.8: Viewing the output f rom the OIDGEN ut i l i ty .

Two OIDs are listed hereone for new classes and one for new attributes. When youre ready to

add new classes or attributes, you can use these OIDGEN -generated OIDs at the root, then
http://www.ansi.org/http://www.ansi.org/http://www.iso.ch/http://www.iso.ch/http://www.iso.ch/http://www.ansi.org/


14/50


simply tack on an incremented numeric value. For example, in Figure 1.8, the root OID

generated for new classes is:

1.2.840.113556.1.5.7000.111.28688.28684.8.471331.1747093.1818370.639263.

By adding the numeral 1 to the end of that:

1.2.840.113556.1.5.7000.111.28688.28684.8.471331.1747093.1818370.639263.1

you obtain the OID for the first class you plan to create.

To illustrate the process of extending the schema, create a new auxiliary class that adds somenew attributes to the userclass. First, you need to make schema changes at the server in your

forest that has the Schema Floating Single Master Operation (FSMO) role. Additionally, the user

account that you use to log on to the Schema FSMO role-holder server must be a member of the

Universal Group called Schema Admins. You can extend the schema either using the MMC AD

Schema snap-in or programmatically using ADSI. Next, you need to add a registry value to theSchema FSMO role-holder to enable schema modifications. In the following key:

HKLM\System\CurrentControlSet\Services\NTDS\Parameters

you need to add a value of type REG_DWORD called SchemaUpdateAllowedand set it to 1.

Note that after making this modification, you need to restart the server for the Schema FSO role-

holder to take effect.

For the purposes of this example, Ill describe extending the schema using the MMC snap-in.

Lets say youre going to create an auxiliary class called myCompany-User, which will containthe two attributes shoeSize andIQ. Youll then associate this new auxiliary class to the userclass. The first step is to create the two new attributes. From the AD Schema, right-click the

Attributes folder, then choose Create Attribute. Youre presented with a warning that creating

schema objects is a permanent, non-reversible process. Choose Continue to proceed withcreating the attribute. Youre presented with a dialog similar to the one in Figure 1.9.


15/50


Figure 1.9: Creat ing an at t r ibute using the AD Schema snap- in.

The first fieldCommon Name, or cnindicates the object name for the new attribute within

the AD. For example, when youre describing an object relative to its position in your AD forest,you use the cn, in conjunction with the location where that object resides, to name the object

the so-called distinguished name. For example:

cn=joe smith,OU=finance,DC=mycompany,DC=com

The cn can be called anything, but because youre creating a new schema object, you might want

to use a convention that makes it easy to identify the new schema object as your own. In Figure1.9, I call the new attribute myCompany-ShoeSizeto indicate that its a company-specific

attribute. The LDAP Display Name field is simply the name that LDAP (Lightweight Directory

Access Protocol) clients use to query your new class or attribute. In most cases, you can makethis the same as the common name.

Next, you need to provide the OIDeither the one that you registered with the registering bodyfor your country or the number you generated using the OIDGEN tool. In my case, I used

OIDGEN to generate a root OID, then added a .1 to the end to obtain my first attribute. (For my

second attribute, which Ill call myCompany-IQ, Ill add a .2 to the end of the same root OID.)

The next field required is the syntax. Remember from earlier in the chapter that the syntax

describes the type of data that the attribute can store. In the case of my shoeSizeattribute, you

can choose to store it as a case insensitive string. This works well for something like shoe size,but it may not work for other types of data. Finally, you can enter minimum and maximum

values for your attribute, which I entered here as 1-20. You can also check the box if this is to be


16/50


a multi-valued attribute. Multi-valued attributes (MVAs) are just what they implyattributes

that hold multiple values within a single instance. For example, Win2K stores members of a user

group as a single multi-valued attribute. Multi-valued attributes are discussed in more detail inThe Multi-Valued Attributes Conundrum later in this chapter.

Once youve created your first attribute, go ahead and create your second, IQattribute, then wecan move on to creating the new auxiliary class. After creating your two attributes, you can go

back into the AD Schema snap-in and add a description for each attribute, choose to index it or

add it to the GC by right-clicking it and choosing Properties.

Note: Adding an attribute to the GC has implications for the amount of data

that is replicated to your forest-wide DCs, so its important not to make this

decision indiscriminately. GC data should be small in size, and change

infrequently, to minimize negative network impact.

Now that youve created your attributes, the next step is to create your auxiliary class, which

well call myCompany-User. From the classes folder in the AD Schema snap-in, right-click and

choose Create Class. Again, the common name and LDAP display name are going to be thesameMycompany-User. And youll also enter a class OID similar to the attribute one (again

appending a 1 if this is the first new class using the assigned root OID).In the Parent Class field,

because this is an auxiliary class, Ill enter the topclass because there are no particular classesthat you need to inherit from for this new one. Finally, select this class to be of type Auxiliary

(see Figure 1.10).

Figure 1.10:Creat ing a new auxi l iary class in the AD sch ema.


17/50


When you click Next, youre presented with the screen that lets you associate your two new

attributes to this class as either mandatory or optional. Remember, however, that since we plan to

associate this new auxiliary class to the existing user class, youre restricted from making yourtwo new attributes mandatory. Figure 1.11 shows what the correct configuration will look like.

Figure 1.11: Adding opt ional at t r ibutes to a new auxi l iary class.

Once youve associated the two optional attributes, the only schema modification steps that you

have to complete are to add your new auxiliary class to the userclass and to reload the schema

cache so that your changes are immediately available. To associate your auxiliary class to the

userclass, from the AD Schema snap-in, I highlight the userclass from the left-hand pane,

right-click, then choose Properties from the context menu. Then, from the Properties window,

choose the Relationship tab. Here youll add your new auxiliary class to the auxiliary class list.Figure 1.12 shows this operation.


18/50


Figure 1.12: Assoc iat ing an auxi l iary class w ith the user c lass.

Finally, in order for your schema changes to become available, you need to update the schema

cache. That is, the AD schema is cached in memory on a DC at system startup. Therefore,changes to the schema wont reflect in new or existing AD objects until the schema is next

refreshed from disk. This normally happens five minutes after you apply the change, and ofcourse, it must replicate to all DCs throughout your forest (more on this later). If you wish toforce the change, you can do so from the AD Schema snap-in by highlighting Active Directory

Schema, right-clicking, then selecting Reload the Schema. After a short period of time, you

should see the new attributes available on new and existing user objects.

The final challenge is having the newly created attributes appear in one of the standard MMC

tools for administering AD objects. As youll notice, they dont appear automatically.

Unfortunately, unless you plan to manipulate AD objects using scripts or methods other than theMMC, there is no quick and easy way to have your new attributes appear in, for example, the

AD Users and Computers snap-in.

While the full description of how to extend the MMC user interface (UI) is outside the scope of

this book, you basically need to build a COM-based Property page using a language like Visual

Basic or Visual C++, and then register that into an area of the AD configuration called displayspecifiers. Ill talk a little bit about display specifiers later in this chapter, but if you want more

details about extending the MMC UI for AD administration, go to: http://msdn.microsoft.com

and search on Extending the User Interface for Directory Objects.


19/50


AD Naming Contexts

As you know, in Win2K as in NT 4.0, the domain is a boundary for AD objects like users and

computers. A single DC in the domain mycompany.com contains only objects that reside inmycompany.com. On the surface, this is true. However, if you dig a little deeper, youll find that

there is actually more data on a given DC than just the objects from the domain to which the DC

belongs. In fact, every DC in a forest has at least three differentpartitionsof data on it. Thesedirectory partitions are also known as naming contexts. Each naming context (or NC) is

responsible for storing and replicating certain kinds of data. The three NCs are:

Domain

Schema

Configuration

The domain NC is, as its name implies, responsible for replicating domain objects to all DCs

within a single domain. The schema NC is responsible for replicating all schema objects, as I

described it above, to all DCs within a single forest. Finally, the configuration NC is responsiblefor replicating data related to the site topology (including subnet objects), something called

display specifiers, which control how objects are displayed in the various user interfaces that candisplay AD objects (for example, the MMC snap-in and the AD Find facility on the Start menu)

as well as other forest-wide metadatasuch as extended security rights for AD objects and well-

known built-in security principals like the Everyone and Authenticated Users groups. You canview each of the three NCs using the MMC ADSI Edit snap-in that comes with the Win2K

Support Tools. Figure 1.13 shows the three NCs for my forest.


20/50


Figure 1.13:Viewing the three naming contexts u sing ADSI Edit .

In order to get this view, load the ADSI Edit snap-in, then connect to each NC separately. Right-

clickADSI Edit, select Connect To from the context menu, then choose the NC you wish toconnect to. Using this dialog box, you can also choose a specific server to bind with and (under

the Advanced tab) change the authentication id that youre using to connect to each NC. In

addition to the three NC, if a DC has been designated a GC server (see the discussion of the GClater in this chapter), it will also contain the partial replicas of all other domain NCs in the forest.

These will appear as separate NCs on the DC. Figure 1.14shows a graphical representation of

how NCs are replicated between DCs in a typical forest.

Figure 1.14:Graphical representat ion of th e repl icat ion of the three nam ing co ntexts in an AD forest .

In this figure, you can see that the domain NC replicates only amongst DCs within that domain.However, the schema and configuration NCs are replicated to every DC in the forest. Using the


21/50


Replication Monitor tool (Replmon.exe) from the Win2K Resource Kit, you can see each of the

NCs on a given DC, as well as view or trigger replication on each NC. When you start Replmon,

simply right-click Monitored Servers, select Add Monitored Server, then enter the server orservers you wish to monitor. Replmon organizes servers by site, so you may see DCs from

several different domains within a site. Figure 1.15 shows an example of a monitored server

using Replmon.

Figure 1.15: Viewing a m onitored s erver in the ReplMon u t i l i ty .

As you can see in the figure, under the server A are the three NCsdomain (for

mycompany.com), schema, and configuration. If this server were part of a multi-domain forestand it was designated as a GC server, you would see the GC partial replicas shown in ReplMon

as additional domain entries, like mycompany.com is shown. There is no additional designation

that ReplMon makes to indicate that a particular domain NC is really a GC partial replica.

The Physical AD

So far, Ive talked a lot about the logical portions of the ADthe schema and how attributesrelate to objects. Now Ill focus on the physical parts of it. Physically, the AD is backed by an

on-disk database. The actual database file is called ntds.dit, and, by default, its found in a

directory off the %systemroot% folder (for example, c:\winnt) called ntds. A pristine copy of

the base Win2K AD database is also stored in %systemroot%\system32\ntds.dit.This

copy is used when you DCPromo a member server to become a DC. The ntds.dit is a

transactional database file that uses Microsofts Extensible Storage Engine (ESE), also called Jet,


22/50


technology as the basis for the database. The ntds.dit file is actually composed of two main tables

that are used by the directory to store AD object data and four other system-related tables that

you dont normally encounter in Microsoft documentation.

The Data Table

The first table, called the datatable, is responsible for keeping all objects and their attributes fora given forest, as well as any indices that you define on a given attribute (remember that in the

discussion earlier on the schema, I mentioned that you could index an attribute for faster

searches). The format of the data table is pretty straightforward. All of the attributes available in

the AD schema are stored as columns in the data table (yep, all 863 of them). All objects that youcreate within the AD are stored as rows. So, if you create a million objects in your AD forest, the

data table will have a million rows.

When you index an attribute for faster searching, that index is stored as part of the data table as

well. A base AD ntds.dit file, on the first DC in your forest, will have a data table that consists

solely of columns for the default attributes and rows for each of the classSchemaand

classAttributeobjects that define the AD schema. (Remember that the schema itself isrepresented by regular AD objects of type classSchemaand classAttribute.) As you add more

real objects, like users and computers, the number of rows in the data table grows. Note that, asper our discussion in the previous section, all three NCs (domain, schema, and configuration) as

well as the GC partial replicas of all forest domains, are kept in the ntds.dit data table on each

DC in the forest (assuming that DC is a GC server as well).

The Link Table

The second table is called the link table, and it stores information that maintains logical links

between attributes on objects. That is, the link table tracks when you reference one AD object

from another. For example, an AD distribution list can contain user objects as members. Ofcourse, the list of members in a distribution list is stored in a multi-valued attribute in the

distribution list object. Additionally, the member objects themselves contain an attribute that listsall distribution lists (and groups) that that object is a member of. Each relationship between the

members and members_of attributes for distribution lists and users, for example, is stored in the

link table.

The link table guarantees that when one link changes, the other is updated. (For example, when a

user is removed from membership on a dlist, the associated user attribute no longer lists the user

as being a member of the dlist.) The relationship between these two linked attributes is describedas forward links (the members of the dlist) and back links (the user object with the memberOf

attribute). The link table stores these forward-link and back-link pairs for each object in the ADthat contains such a relationship.

Where to Put AD Files

When you DCPromo a member server into a DC, youre given the choice of where you want to

store the ntds.dit file (the AD database), the SYSVOL volume, and the AD log files (explained inthe next section). The folder location you choose for each of these isnt terribly important. I


23/50


always like to use default folder paths because it makes it easier for others to find the files in

question. For best performance, especially as your AD database grows, its best to have several

physical disks in your DCs. In fact, the ideal configuration for an AD DC would be to have threephysical disks serving the following purpose:

One disk for OS system files and page files

One disk for the ntds.dit database file

One disk for AD log files

At a minimum, try to ensure that the system page file and AD log files are on separate disk

spindles; both typically see the largest disk activity when a DC is in production.

How Changes are Written to the AD Database

Microsoft has implemented a number of mechanisms to ensure that changes to the ntds.dit fileare successfully written and not easily corrupted by system crashes or hard disk problems.

Changes to the AD are transactional. That is, each discrete change is committed to the databaseindividually. For example, if I make a change to the passwordattribute on user Joe Smith, that

is a single, discrete transaction.

Similar to other Jet database implementations that Microsoft has carried out, the AD uses a

circular log to ensure that database transactions occur without a hitch. When a change is made tothe AD database, its first written to the copy of the AD thats running in memory on the DC

where the change was made. Its also written to a change log file stored on disk.

If you look in the directory where the ntds.dit file is stored on a given DC, youll see a number of

files in addition to the database file. For example, youll see three log files: edb.log, res1.log,

and res2.log. All of these log files are roughly 10MB in size. The edb.log file is the main log filefor the AD database. Res1.log and res2.log are set aside as reserves. If the disk partition where

these log files are stored runs out of disk space, these reserve log files ensure that there is enough

space on the disk to write any uncommitted transactions to the database before shutting down theserver.

Youll also find a file called edb.chk. This is the AD database transaction checkpoint file. The

transaction checkpoint file keeps track of the last transaction in the transaction logs that wascommitted successfully to the ntds.dit file (this concept is illustrated in Figure 1.16).


24/50


Figure 1.16: The sequence that the AD uses to commit changes to the database.

The point of the edb.chk checkpoint file is to serve as a pointer to the location in the transactionlog fileedb.logwhere the last change was committed to ntds.dit. If an AD server were to

crash before all of the in-memory changes had been committed to ntds.dit, the checkpoint file

would allow a quick and easy replay of any transactions in the transaction log that hadnt beencommitted before the crash. The checkpoint file isnt absolutely required for the AD to recover

itself after a crash. But recovering takes much longer because the system has to scan the entire

transaction log to determine which changes were already committed to the database file.

I mentioned previously that the AD uses a circular logging mechanism to track transactions into

the AD. This means that the edb.log file is a fixed 10MB in size. If more than 10MB worth of

transactions is created (which is likely over time), the newest transactions simply overwrite theold ones. Unlike Microsoft Exchange, where you can disable the circular logging feature, Win2K

doesnt provide a way to do so. One log file is all you get!

Understanding and Managing AD Sites

Ive already alluded to AD sites in discussions above about the structure of the AD. Sites are an

important part of AD replication because you use sites, and site links, to manage which DCs

replicate with other DCs and how often. Sites also provide a boundary for defining Group Policy(see Chapter 3 for more info on Group Policy). Finally, sites allow you to provide some location-

specific affinity for services that you wish to provide in the AD (for example, locating DFSreplicas, clients locating DCs, and so on).

Closely related to sites aresubnet objects. Subnet objects are related to the topology of your

TCP/IP network. You define a subnet object for every TCP/IP segment on your network that willhave Win2K devices on it. Both site and subnet objects are stored in the configuration NC. This

makes sense because this kind of information needs to be available on every DC in your forest,

regardless of domain membership. When you first install a Win2K forest, a default site is created


25/50


for your first DCcalled Default-First-Site-Name. No subnet objects are created initially, but

you need to create them if you plan to gain any of the benefits provided by sites. When you

create a subnet object, you need to provide the IP address and mask of the subnet object yourebuilding, then associate it with a site that youve already built. All of this activity is done using

the MMC AD Sites and Services snap-in.

Note: By default, only Domain Admins on the forest root domain and

Enterprise Admins in the forest have rights to add and manage sites and

subnets. You can delegate these tasks to additional groups by modifying

security ACLs on the Sites folder within the MMC AD Sites and Services

snap-in.

To create a new site, start the MMC AD Sites and Services snap-in, right-click the Sites folder,

then choose New Site. Youll be prompted to provide a name for your new site and to associate it

with something called asite link. Youre not allowed to have spaces in your site name, so if youwant to create a site called New York, for all of your New Yorkbased Win2K resources, youll

need to call it something like New-York or NewYork.

If this is the first site youre creating in your AD forest, the only site link that will be available to

choose from is one called DefaultIPSiteLink. Site links are known as Inter-Site Transports. That

is, they help you group sites of similar network connectivity and let you control the inter-sitereplication schedule between sites within a singe site link. Defining sites and site links is a

required part of building your AD infrastructure, and it will require careful planning and close

coordination and understanding of your organizations network topology.

Once youve started to create sites for your AD infrastructure, you need to add all of the IP

subnets associated with your corporate network where you plan to have Win2K devices, and youneed to associate those subnet objects with your sites. To create subnets, you right-click the

Subnets folder in the MMC AD Sites and Services snap-in. Figure 1.17shows an example of

creating a subnet and associating that subnet object with a site called New-York.


26/50


Figure 1.17: Creating a Subnet object u sing th e MMC AD Sites and Services sn ap- in.

If you go to the MMC AD Sites and Services snap-in after creating the subnet, youll see it listedunder the Subnets folder using the convention of IP Subnet/Mask (for example, 172.16.20.0/24),

where the mask is given in number of bits. In this case, 24 bits correspond to a mask of

255.255.255.0. By associating a subnet with this site, youre allowing any workstations orservers that are on this IP subnet to be associated with the New-York site. This is called

establishing affinitybetween a workstation or server and an AD site.

Tip: You can determine the site that a workstation or server has associated

itself with by checking in the registry on that device for the value:\HKLM\System\CurrentControlSet\Services\Netlogon\Parameters

\DynamicSiteName

Alternatively, you can use the nltest.exe utility (part of the Win2K Support

Tools) and issue the following command:

nltest /server: /dsgetsite

In addition to establishing site affinity, you can create location codes for each subnet that you

define. After defining the subnet, highlight it under the Subnets folder, right-click, selectProperties, then choose the Location tab. Here, you can use a new feature in Win2K-- the ADs

ability to keep track of a subnets physical location to help your users find printers more easily.

However, to use this feature, you must use a structured naming convention for the location


27/50


attribute within the subnet object, and you must enable a particular printer policy in Group

Policy. The Group Policy setting that must be enabled is under Computer

Configuration\Administrative Templates\Printers. The Pre-Populate Printer Search Location Textitem must be enabled.

For more information on Group Policy, see Chapter 3.

Additionally, the information you use in your location fields must be structured in a particular

way. For example, if subnet 172.16.20.0 is located in a building in New York, on 5th Avenue, onthe 20th floor, you would enter a location code for that subnet ofNY/5thAve/20. Similarly, if you

have another subnet that spans two floors in the same building, you might enter it as

NY/5thAve/18-19.

Its important to delineate each geographic or spatial distinction with a slash character (/). The

AD uses this convention to determine the search hierarchy for locations. Using locationscorrectly allows users to search for printers that are physically close to them and to consistently

choose the closest printer as they move around your network. Figure 1.18 shows what the FindPrinter dialog looks like when subnet location has been properly filled in for two locations(Memphis and New York).

Figure 1.18: Searching for a pr inter b y locat ion.

Populating Subnet Objects

Unfortunately, Microsoft hasnt provided an easy, automated way for you to

create subnet objects within the AD. In a large enterprise, where you might


28/50


have hundreds or thousands of locations, you could have hundreds or

thousands of subnets within your IP address space. The ideal solution, if

youre a DHCP user, would be to use DHCP scope information to

automatically populate subnet objects. However, that capability doesnt yet

exist.

Your best bet at this point is to use a combination of tools and scripts to take

information out of DHCP and populate subnets. Win2K comes with a tool

called netsh.exe,which has the ability to dump all scopes from a DHCP

server. The sequence of commands is as follows:

netsh

netsh>dhcp

dhcp>server

dhcp server> show scope

The show scopecommand will dump all scope information for that server

to your screen. You can redirect the output to a file, then use that as the basis

for an input file to a script that creates new subnet objects based on each

scope.

Remember that site and subnet objects are kept in the configuration NC for

a given forest. Using that info, and some basic ADSI coding, you can create a

script that will import DHCP scopes, create new subnet objects, and

associate them with sites. However, this approach is best followed when

youre first populating your AD infrastructure with subnets. As you add new

DHCP scopes, youll still most likely need to manually create subnet objects.

DCs and Sites

As I mentioned, the first DC that you create in your forest will be automatically placed under the

Default-First-Site-Name site. Any subsequent DCs that you promote will also be placed in thissite unless you first build subnet objects and sites that encompass your new servers. If you need

to move a DC from one site to another, you can do this using the AD Sites and Services snap-in.

Under each site is a Servers folder. Within this folder are all of the DCs that are associated to thissite. You can move a DC to a different site simply by right-clicking on the server name, then

selecting Move from the context menu.

And while Im talking about DCs, I should explain what you see underneath each DC within its

site. Underneath each DC, youll see a container called NTDS Settings. This folder is where AD

replication connection objects are created. Connection objects are the mechanism by which

Win2K builds a replication topology between all DCs in your forest. Ill talk more about ADreplication in a later section of this chapter, but if youre interested in looking at what replication

connection objects have been created between DCs in your forest, this is the place to look.


29/50


Note: Normally, when you start up the MMC AD Sites and Services snap-in,

you see DCs (as opposed to member servers) listed only under the sites

youve created. This is expected because sites relate to replication topology;

only DCs replicate AD data. However, an interesting feature in Win2K

results in a situation where this may not be the case.

Some AD-enabled applications can also write information to the Servers

folder other than the replication-specific NTDS Settings folder. So, if you

DCPromo a DC back to a member server, youd expect the server to be

removed from the site to which it belonged. However, because its possible

that other application stuff may be written to this server object, Win2K

doesnt remove the server when its demoted. Rather, it just removes the

NTDS Settings folder and thus all of that servers replication connection

objects.

The main question that everyone asks when they start building their AD infrastructure is, What

constitutes a site? The answer is that there is no hard-and-fast answer. The typical scenario is thatyou have two DCs within the same site, separated by a relatively slow-speed network link, and

you need to decide whether they should each be in their own site, rather than a single one. Thenext question is, What is the threshold speed for that slow link before I create the second site?

My answer is always, When the amount of AD replication traffic traversing that link starts to

become the primary user of that links bandwidth, its probably time to split the two locationsinto two sites to control the replication traffic moving between the two locations.

Microsofts AD Sizer Tool

Microsoft has a tool called AD Sizer (located on the companys website at

http://www.microsoft.com/WINDOWS2000/library/planning/activedirectory/

adsizer.asp) that can help you predict expected replication traffic on your

network for the size of AD forest youre using. Ill talk more about the issues

surrounding AD replication later in this chapter.

Understanding and Managing the Global Catalog

Ive already alluded to the global catalog (GC) in my discussion on naming contexts, but here Ill

drill into the GC and what it really is. To put it simply, in a multi-domain forest, Microsoft

needed a way for end users as well as Win2K services to quickly and easily find objects in the

AD without necessarily going to every domain in the forest to find them. Hence, Microsoftcreated the GC.

The GC is a read-only partial replica of all objects, and some of their attributes, for all domains

in a forest. Its a partial replica because it doesnt include every attribute for every object in the

forest, and its read only because you can only search on it; you cant use it to modify objects in

the AD. The boundary of the GC is the forest; you cant have a GC that spans forests. As I
http://www.microsoft.com/WINDOWS2000/library/planning/activedirectory/adsizer.asphttp://www.microsoft.com/WINDOWS2000/library/planning/activedirectory/adsizer.asphttp://www.microsoft.com/WINDOWS2000/library/planning/activedirectory/adsizer.asphttp://www.microsoft.com/WINDOWS2000/library/planning/activedirectory/adsizer.asp


30/50


mentioned earlier, the copy of the GC on a so-designated DC is physically stored in the same

ntds.dit AD database file as the other NCs. I also mentioned that by modifying the schema, you

can add additional attributes to the GC that dont exist by default. However, you should note thatin Win2K today, if you modify the schema to add additional attributes to the GC, you force a full

re-synchronization of the GC across all GC servers in your forest.

Caution: Modifying the AD schema to change the attributes that are stored

in the GC will cause all GCs to perform a full synchronization, potentially

causing a large increase in network traffic.

The GC is particularly important when it comes to Universal Groups. As you know, UniversalGroups are groups whose membership can include (and is accessible to) users or groups in any

domain within a forest. Because of this cross-domain ability, all members of a given Universal

Group are included in the GC. This isnt the case for Global Groups or local groups (whose

membership isnt stored in the GC).

Because the GC is the only place where a client or server can go to get the complete membership

of a Universal Group from any domain, Microsoft made GC availability a requirement for a userto be able to authenticate to an AD domain. This is because, at logon, a users access token is

built from a collection of their user SID and the SIDs of all groups the user belongs to. If the GC

werent available to provide the membership information for Universal Groups, the users tokenwould be incomplete, and any resources to which permissions had been assigned using that

Universal Group would be unavailable to that user.

So, if a GC isnt found by a client workstation when a user tries to log on, they are denied access.

The exception to this is where the domain youre authenticating to is in mixed mode, since

mixed-mode domains dont support Universal Groups, or if the authenticating user has cachedtheir credentials on the workstation due to a prior login. Additionally, if you are an administrator

on the domain, you dont need to have a GC present.

If youre in native mode and dont wish to deny logons if the user or computer cant find a GC,you can change a registry value on the workstation or server in question. Specifically, in:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

you need to add a key called IgnoreGCFailures of type REG_DWORD with a value of 0x1.Adding this registry value lets a normal user log on if a GC cant be contacted. However any

Universal Groups that the user (or machine) is a member of will also be unavailable because

when building the users (or machines) access token, their membership cant be resolved.

Deploying Global Catalog Servers

Because the GC is an important part of your Win2K infrastructure, how do you know how many

you need and where to deploy them? There are several answers to these questions. However,lets take care of the basics first. How do you designate a DC as a GC? The easiest way to do this

is to start up the MMC AD Sites and Services snap-in and find the server that you wish to make a

GC server. Drill down to that servers NTDS Settings folder, right-click this folder, and youll


31/50


see a check box that says Global Catalog. Checking this box makes this DC a GC server. Its as

simple as that.

We already know that a GC needs to be highly available. This means that you generally want to

have a GC available on your network, near your users, at all times. Microsoft generically

recommends designating at least one DC as a GC in every AD site that you create on yournetwork. This means that, because of site affinity, client computers will always be able to find a

GC near them. However, youll need to balance this requirement with the additional overhead on

your network that is incurred by designating a DC as a GC server. And, in some large sites, youmay need more than one GC to handle the load.

Remember that a GC server contains, in addition to the three NCs (domain, schema, andconfiguration), partial replicas of all other domains in your forest. If you have only one domain

in your forest, there really is no difference in the amount of data replicating to a GC server as

opposed to a normal DC. However, the more domains you have, the more data will be replicated

to a GC server. Because the GC data is a partial replica (includes all domain objects but only

some attributes) of all other domains, the amount of data replicated to a GC for each domain inyour forest is going to be smaller than the amount of data replicated by those DCs within each of

their own domains.

How much smaller? Well, tests have shown that about 20% less data is replicated to a GC for

each domains partial replica. Of course, this number will be impacted if you modify the schemato include more than the base attributes that are replicated to the GC, but its a good guideline to

start with. So, for example, if you have four domains in your forest and each one typically

generates 1KB/second of replication traffic between DCs, a GC server could experience anadditional 3.2 KB/second of traffic (1KB/second per domain * 4 domains * 80%). Now, this

assumes that your domains are uniformly sending 1KB/second across the network. Most

domains wont experience this kind of constant network usage, nor will all intra-domainreplication traffic be replicated to a GC server (because the GC doesnt replicate all object

attributes).

The best approach to take for deploying GC servers is to first determine how many domainsyoull have in your forest. Next, use a tool like the AD Sizer to determine how much traffic each

domain can be expected to generate. After that, you can estimate the impact that designating a

GC server will have on each sites network connectivity and on the rest of your corporatenetwork. Keep in mind the normal events that typically require access to the GC, which are listed

below:

If you log on using a User Principal Name. The GC is queried to determine

which domain your UPN resides in (especially if you use Alternate UPNsuffixes).

If you log on in a native mode domain. As I mentioned earlier, the GC is used todetermine Universal Group membership.

If you perform a search using one of the UI tools (for example, Start Menu,Search, For People) whose scope is the entire AD.


32/50


Another distinction that needs to be made concerns the TCP ports that are used for searching the

AD. As you know, LDAP is the primary protocol used in many operations to communicate withthe AD. LDAP is used by ADSI and most MMC-based admin tools when manipulating the AD.

LDAP uses TCP port 389. However, if youre querying the AD programmatically or within an

application, and want to communicate with the GC instead, you need to use TCP port 3268. Port3268 connects you directly to the GC, which of course has a forest-wide view of all AD objects.

Understanding and Managing AD Replication

Weve discussed the concept of sites and subnets as a means of controlling AD replication; nowlets take it one step further. In this section, Ill dive into the actual process that Win2K uses to

replicate AD data throughout your network. AD uses a replication approach that seeks to achieve

loose consistency with convergence between all DCs. This means that AD replication balancesthe need for real-time updates across all servers with bandwidth constraints on your network. It

also means that, within a finite period of time, all DCs will be identical.

Explaining what you have to do to achieve this loose consistency with convergence is the goal

of this chapter. In an ideal world, all you have to do to build a good AD replication infrastructure

is to create sites and site links that fit your network topology, and Win2K does the rest. The basicmodel for replication starts with the idea of Update Sequence Numbers (USNs). USNs are 64-bit

sequence numbers. Every object in the AD has a USN when its created. In addition, every DC

controls its own pool of USNs. The USN is key to how the AD stays consistent and resolvesconflicts. Additionally, replication happens at the attribute, rather than whole-object level. This

means that each individual attribute for a every object has its own USN as well.

USNs and Repl icat ion b etween DCs

The first thing to keep in mind is that each DC in a domain contains its own pool of USNs. The

USN, and some other information, is used to determine which updates need to take place as data

is replicated between DCs and, in the case of conflicts, which change wins.

Every time a change happens on a DC, the USN for the object or attribute is incremented.

Incrementing the USN on a particular DC occurs server-wide. That is, you cant have twoobjects changing on a single DC with the same USN. If I change User As password on a DC,

and another administrator changes User Bs password, the USN on the passwordattribute for

User A would be 1711, and the USN for User B would be 1712. You can visually look at USNinformation at the object level by right-clicking an object in the AD Users and Computers snap-

in, choosing Properties from the context menu, then selecting the Object tab (see Figure 1.19).


33/50


Figure 1.19: Viewing USN informat ion on a User object .

In Figure 1.19, you see the USN assigned to the object when it was created (the Original USN)

and the most recent USN for the object (Current USN). The Current USN value indicates theUSN assigned to the attribute that was last changed on this object. When a new object is created,

the object and all of its attributes get the same starting USN number. Then, as each attribute on

that object is modified, its USN is incremented independently of other attributes for that object.The AD Users and Computers snap-in doesnt expose the per-attribute USNs. instead, you have

to use a tool like repadmin.exe from the Win2K Support Tools. To view the per-attribute USNs

for an object, use the /showmeta option for repadmin and provide the DN to the object, as shownhere:

repadmin /showmeta "CN=Fred Smith,OU=Finance,DC=mycompany,DC=com"

The data that is returned is shown in Figure 1.20.


34/50


Figure 1.20: Viewing p er-at t r ibute USNs using the Repadmin ut i l i ty .

To interpret the data in this figure correctly requires that I dig into how the AD uses USNs and

other information to replicate the correct data between DCs. First, lets look at the columns in

Figure 1.20. Note that there are two columns that contain the word USNthe Loc. (or local)USN and the Orig. (or originating) USN. The local USN is the USN for that attribute that is

specific to the DC where that object is stored.

Remember that I mentioned that all DCs keep track of their own pool of USNs. This means that,depending upon the number of changes made on a given DC, two DCs will likely be handing out

very different USNs. Win2K keeps track of this fact by differentiating between the local USN

(the USN for that object on a particular DC) and the originating USN. The originating USN isthe USN on an attribute that is replicated to its partners. When an object is first created on a DC,

the local USN and the originating USN are identical. However, as objects are replicated to other

DCs and are changed on those other DCs, the local USN will no long match the originatingUSN. Ill dive into why this is in a minute.

But first, note that in Figure 1.20, the local and originating USNs are the same, even thoughsome changes have obviously been made to the attributes on this object. The reason for that is

that, in this particular AD environment, there is only one DC, and therefore, all changes are

happening on this DC. Also note that there are cases where more than one attribute has the sameUSN. We know this is true when the object is created, but why is it that way after changes have

been made to individual attributes?


35/50


Its because the USN is incremented on a per-update transaction basis. For example, the figure

shows that five attributes have 2969 as their local and originating USN. This means that user

object Fred Smithwas sitting with its current USN at 2968, and along came an administratorand changed something (in this case, the password). This triggered the USN to be incremented

by 1 on five attributes (e.g. attributes dBCSpwd, unicodePwd, ntPwdHistory, pwdLastSet,

supplementalCredentials) that were changed in association with the password change operation.

Now, lets look at some of the other columns in Figure 1.20. The Originating DSA (Directory

Server Agent) is the site and name of the server that originated the last change on this attribute.The Orig. Date/Time is the date and time stamp for the most recent change. The version number

corresponds to the number of times this attribute has been changed since it was created. All new

objects and their associated attributes start with a version of 1. Finally, the last column lists thename of the attribute within the object.

Confl ic t Resolut ion

Using this basic information and some other metadata, a DC is able to replicate changes to its

partners in an organized way that maximizes convergence. Before I examine the actualreplication process, its important to understand how the AD deals with conflicts or collisions

where the same object or attribute is changed on multiple DCs.

Other directory services implementations use a mechanism whereby the time stamp on an

attribute is compared to other versions, then takes a last writer wins approach to resolvingconflicts. This approach requires pretty low tolerances on clock differences across all directory

servers in an environment. The AD doesnt use this mechanism. Rather, it uses a combination of

the metadata shown in Figure 1.20 to guarantee that the correct change happens in the correctsequence across many DCs.

First, the USN is used to determine if a particular source DC has any new data for a destination.If its determined that there is new data, a precession of the attribute version, then time stamp,

then originating DSA is used to act as a tiebreaker. For example, if DC A has a set of changed

attributes for Object X and DC B has a set of changed attributes, also for Object X, this

tiebreaker mechanism is used. For example, a DC C is replicating with DC A. DC C first looks atDC As update version for a particular attribute or attributes. If its greater than the version

number that DC C has for that attribute on its local copy, the update is applied.

Now suppose DC B replicates its changes to DC C, and they request a change to the same

attribute using the same updated version number that DC B provided. In that case, the date/time

stamp is used to resolve the conflict. If DC Bs update to the attributed was made at a later time

than DC As, DC Bs update overwrites DC As. If not, the change that DC A provided stands.In the unlikely event that both updates from both DCs have the same version anddate/time

stamp (the resolution on the timestamp is 1 second), the Globally Unique ID (GUID) for theoriginating DSA is arbitrarily used as the tiebreaker.


36/50


The Repl icat ion Process

Now that Ive presented some background on the replication process, the best way to describe

how the AD replicates directory changes between DCs is to walk through a typical scenariomodifying a user object on a DC and replicating the change to another DC. The easiest way to

illustrate this is to build a table that shows each of the key pieces of data that I described above

(for example, USN, version, and so on).

Lets assume that we have three DCs called ServerA, ServerB, and ServerC. ServerA contains a

user object that I just created called Bob Smith. Table 1.1shows the basic replication metadatafor object Bob Smith. For simplicitys sake, Im going to show only a few attributes. Note thatall attributes on the object have the same USN and a version number of 1.

Object: Bob SmithLocal USN Orig. DSA Orig. USN Date/Timestamp Version Attribute

1000 ServerA 1000 01-01-

00,12:00PM

1 sn (surname)

1000 ServerA 1000 01-01-00,12:00PM

1 givenName

1000 ServerA 1000 01-01-

00,12:00PM

1 profilePath

Table 1.1

The next step is to replicate this object to ServerB. The way this works varies depending upon

whether ServerA and ServerB are in the same site, but the bottom line is that ServerB is the

destination of ServerAs object Bob Smith. The first thing that ServerB does is communicate toServerA what its high-watermarkUSN is.

Each DC stores a high-watermark USN value for each of its direct replication partners. (Directrefers to all DCs that have a direct connection object established with the DC.) In my example,

the high-watermark USN is the last USN that was replicated from ServerA to ServerB. ServerB

sends this information to ServerA to tell ServerA what it already has. This reduces any kind of

network usage and processor cycles that might otherwise have to happen between the two DCs ifthey had to do a series of requests and replies to determine what was needed. You can view a

DCs current high-watermark USN for each of its replication partners by using the Support Tools

repadmin utility.

To get high-watermark information, type:

Repadmin /showreps /verbose

Under each DC listed in the output, you should see a line that says:

USNs: /OU,...

The number that precedes the /OUtag is the high-watermark USN for that particular partner.


37/50


The second mechanism that the AD uses to prevent excessive replication traffic is called the Up-

to-dateness vector. The goal of this vector is to provide for propagation dampening. To explainthat, lets take the three servers in the example. Because a given DC can get replicated updates

from any number of replication partners, its possible that a change made on ServerA might be

replicated to ServerC first, then from ServerC to ServerB. This is more likely as the number ofDCs in a particular forest grows large because not every DC in every site will have a direct

connection to every other DC.

Therefore, the destination DC for a replicated event needs a way of knowing, for all possible

DCs on a given NC, what the last USN was for each DC. This is what the up-to-dateness vector

provides. If ServerA is replicating some attribute changes to ServerB, ServerB can look at theentry for ServerA in its up-to-dateness vector table and see if its already received the last update

from any replica partner. If the vector is equal to or greater than the highest USN on ServerA, its

assumed that all changes are present. So, between the high-watermark and the up-to-dateness

vector, ServerB can tell ServerA exactly what it already has and exactly what it needs.

Note: You can check the up-to-dateness vector on a given DC by issuing the repadmin

/showvector command, where NC is the DN of the NC you wish to display.

(Remember that the up-to-dateness vector is specific to an NC.) For example, repadmin

/showvector dc=mycompany,dc=comprovides the up-to-dateness vector for the domain NC

for mycompany.com.Lets continue with the example from Table 1.1. We replicate the object

Bob Smithfrom ServerA to ServerB, and Table 1.2shows the resulting metadata, which is nowstored on ServerB.


2100 ServerA 1000 01-01-00,12:00PM

1 sn (surname)

2100 ServerA 1000 01-01-00,12:00PM

1 givenName

2100 ServerA 1000 01-01-

00,12:00PM

1 profilePath

Table 1.2

Note that in Table 1.2, all of the metadata related to the object Bob Smithremains the same

except for the local USN. The local USN is assigned based on the next USN that is available on

ServerB as a wholein this case, 2100. Now, lets suppose that an administrator changes the

profilePathattribute for Bob Smithon ServerB. Table 1-3 shows what happens to the replicatedmetadata on Bob Smithafter the change is made.


2100 ServerA 1000 01-01- 1 sn (surname)


38/50


00,12:00PM

2100 ServerA 1000 01-01-

00,12:00PM

1 givenName

2203 ServerB 2203 01-01-

00,17:35PM

2 profilePath

Table 1.3

In Table 1.3, you can see that a change was made to the profilePathattribute, resulting in it

getting all new metadata. It received both a new originating USN as well as a local USN. Theoriginating USN was changed because the attribute was changed on this server. The originating

DSA, version, and time stamp were updated as well. Now lets look at what happens during the

next replication cycle between ServerA and ServerB. ServerA sends its high-watermark USNand up-to-dateness vector to ServerB, and ServerB sends the required records, namely the

changed profilePathattribute. Table 1.4 shows the resulting object on ServerA.

Object: Bob Smith

Local USN Orig. DSA Orig. USN Date/Timestamp Version Attribute1000 ServerA 1000 01-01-

00,12:00PM

1 sn (surname)

1000 ServerA 1000 01-01-

00,12:00PM

1 givenName

1050 ServerB 2203 01-01-

00,17:35PM

2 profilePath

Table 1.4

Note that in Table 1.4, ServerA has placed its next available USN (1050) in the local USN field

for the profilePathattribute, but otherwise, the metadata stored in profilePathis as it was set onServerB.

Of course, this process becomes more complicated as you add more DCs, and more changed

objects per replication cycle, but the preceding tables help illustrate the process that Win2K goesthrough to determine the correct change to apply to a DC during replication.

Understanding Repl icat ion Mechanics and the Role of the Knowledge

Cons istenc y Checker (KCC)

Now that weve gone through the process by which the AD reconciles replicated data between

DCs, were ready to dive

chapter 1 managing the active directory (2)

Documents