Objects and Attributes

For the most part, an object is nothing more than a collection of specific pieces of information about the object. For example, an object that represents a user account contains attributes that hold information about the particular user. When you create user accounts in the Active Directory, you supply the same information that you did when you created user accounts using the User Manager for Domains in previous Windows versions, as well as a great deal of other information. Chapter 37 details the information you can store about a user, for instance. The Active Directory contains objects that can be used to store information about everything from user accounts to printers to the actual schema of the Active Directory itself.

However, the Active Directory can be used to store almost any kind of information you want. It's just a matter of finding the correct object (or creating a new object class) and then entering the data for instances of the object.

From the discussion of X.500 names earlier in this chapter, remember the term "organizational unit (OU)," as it is represented in the X.500 naming scheme. An organizational unit is an object in the directory that holds or contains other objects. For example, in the Active Directory, a domain is a container object. It holds other objects, some of which are container objects also, such as the Users object. The Users object holds the actual individual user accounts. It is in these instances of the User object that the attributes will be found that contain the data for each user in the domain.

Attributes are simply the fine-grained details of the data stored in an object. Each attribute for an object holds a specific kind of data, and thus has a specific syntax associated with it. An attribute that is used to hold a person's name would have a syntax that requires a text string. The syntax would define a minimum and maximum length for the string. An attribute that represents a numeric value would have a syntax that specifies the minimum and maximum value of the number that can be stored in the object.

When a new class of objects is defined, you have the capability to create two particular types of attributes: required or optional. If an attribute is of the required type, each object you create of the particular object class must have some value defined for the required attribute. However, there can be other attributes you might want to define for the User object class that do not apply to all users. For example, you might want to keep a list of the names of the user's spouse and children. However, not all users will necessarily have a spouse or offspring, so this kind of attribute could be created as an optional attribute.

Standard Objects in the Active Directory

The Active Directory comes with two sets of standard objects: container and leaf. Container objects hold other objects in the directory. Leaf objects are the endpoints in a directory tree that contain specific attributes about a directory object entry. In other words, the leaf objects contain the actual data (attributes) that the Active Directory stores, whereas container objects group these leaf objects, such as individual users or printers, into meaningful groups.

Note that a container object also can contain other container objects, as well as leaf objects. This makes it possible to create subdivisions in the directory that model your business or administrative needs. Using the uniform Microsoft Management Console (MMC) interface, container objects appear as folders in a tree.

What Objects Are Included in the Active Directory?

These are the standard container objects you are most likely to encounter during day-to-day system management chores:

• Namespaces

• Country

• Locality

• Organization

• Organizational Unit

• Domain

• Computer

And these are the standard leaf objects that are provided:

• User

• Group

• Alias

• Service

• Print Queue

• Print Device

• Print Job

• File Service

• File Share

• Session

• Resource

These built-in object classes provide most of the functionality a network will need when using the Active Directory to manage users, computers, and resources. This is not a complete listing, however, of all the objects you'll find in the Active Directory. There are many, many more. And if you need the capability to store still other types of objects, you can modify the schema by using the Active Directory Schema Manager Snap-In.

The Directory Namespace

Two types of names can be used to identify an object in the directory. The first is called the distinguished name (DN) and the second is the relative distinguished name (RDN). The relative distinguished name is just a value of a particular attribute of the object. For example, for user objects, the RDN is the common name (CN) of the object. So for the user object that holds account information for user Luke Kurtis, the RDN for the object would be Luke Kurtis. In the Active Directory there can be more than one Luke Kurtis, so there needs to be a method for telling them apart. The distinguished name is that method.

A distinguished name consists of the RDN of the object, plus all the RDNs of every object that precedes it in the directory. Referring to the X.500 address format, it quickly becomes apparent that the DN of an object not only uniquely identifies the object in the directory, but also reveals its location in the hierarchy.

The example given earlier showing how X.500 defines an object name shows the structure of a distinguished name:

CN=Ono,OU=Studio One,OU=New York,O=mydomain,C=US 

Here the RDN of the user object is the common name Ono. But the object Ono is located in the container object named Studio One, which is located in the container object called New York, which is located in the container object called mydomain, and so on. Although there can be more than one Ono object in the directory, there can be only one object with the RDN of Ono that is located in the Studio One department in New York for this domain in the United States. If another Ono comes to work in that department, she will have to use a different name! There is an easier way around this, of course. When assigning usernames to employees, many companies already use a combination of letters rather than an employee's full name. For example, John Doe might be assigned a username of doej, using the last name plus the first letter of the first name. If another John Doe is hired, a variation on this can be performed by assigning the new employee the username doej2.

However, another distinct Ono might work in the manufacturing department in the same organization. For example,

CN=Ono,OU=Manufacturing,OU=New York,O=mydomain,C=US 

is a perfectly legal distinguished name and can reside in the same directory database as the first Ono.