Active Directory | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Active Directory (AD) is Microsoft's network operating system (NOS ) directory, built on top of Windows 2000 and Windows Server 2003. It enables administrators to manage enterprise-wide information efficiently from a central repository that can be globally distributed. Once information about users and groups, computers and printers, and applications and services has been added to Active Directory, it can be made available for use throughout the entire network to as many or as few people as you like. The structure of the information can match the structure of your organization, and your users can query Active Directory to find the location of a printer or the email address of a colleague. With Organizational Units, you can delegate control and management of the data however you see fit. If you are like most organizations, you may have a significant amount of data (e.g., thousands of employees or computers). This may seem daunting to enter in Active Directory, but fortunately Microsoft has some very robust yet easy-to-use Application Programming Interfaces (APIs ) to help facilitate data management programmatically.

This book is an introduction to Active Directory, but an introduction with a broad scope. In Part I, we cover many of the basic concepts within Active Directory to give you a good grounding in some of the fundamentals that every administrator should understand. In Part II, we focus on various design issues and methodologies, to enable you to map your organization's business requirements into your Active Directory infrastructure. Getting the design right the first time around is critical to a successful implementation, but it can be extremely difficult if you have no experience deploying Active Directory. In Part III, we cover in detail management of Active Directory programmatically through scripts based on Active Directory Service Interfaces (ADSI ), ActiveX Data Objects (ADO), and Windows Management Instrumentation (WMI ). No matter how good your design is, unless you can automate your environment, problems will creep in, causing decreased uniformity and reliability.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Network operating system, or "NOS," is the term used to describe a networked environment in which various types of resources, such as user, group, and computer accounts, are stored in a central repository that is controlled by administrators and accessible to end users. Typically, a NOS environment is comprised of one or more servers that provide NOS services, such as authentication, authorization, and account manipulation, and multiple end users that access those services.

Microsoft's first integrated NOS environment became available in 1990 with the release of Windows NT 3.0, which combined many features of the LAN Manager protocols and OS/2 operating system. The NT NOS slowly evolved over the next eight years until Active Directory was first released in beta in 1997.

Under Windows NT, the "domain" concept was introduced, providing a way to group resources based on administrative and security boundaries. NT domains are flat structures limited to about 40,000 objects (users, groups, and computers). For large organizations, this limitation imposed superficial boundaries on the design of the domain structure. Often, domains were geographically limited as well because the replication of data between domain controllers (i.e., servers providing the NOS services to end users) performed poorly over high-latency or low-bandwidth links. Another significant problem with the NT NOS was delegation of administration, which typically tended to be an all-or-nothing matter at the domain level.

Microsoft was well aware of these limitations and needed to re-architect their NOS model into something that would be much more scalable and flexible. For that reason, they looked to LDAP -based directory services as a possible solution.

In general terms, a directory service is a repository of network, application, or NOS information that is useful to multiple applications or users. Under this definition, the Windows NT NOS is a type of directory service. In fact, there are many different types of directories, including Internet white pages, email systems, and even the Domain Name System (DNS). Although each of these systems have characteristics of a directory service, X.500 and the Lightweight Directory Access Protocol (LDAP) define the standards for how a true directory service is implemented and accessed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As we mentioned earlier, Windows NT and Active Directory both provide directory services to clients. Although both share some common concepts, such as Security Identifiers (SIDs) to identify security principals, they are very different from a feature, scalability, and functionality point of view. Table 1-1 contains a comparison of features between Windows NT and Active Directory.

Table 1-1: A comparison between Windows NT and Active Directory
Windows NT	Active Directory
Single-master replication is used, from the PDC master to the BDC subordinates.	Multimaster replication is used between all domain controllers.
Domain is the smallest unit of partitioning.	Naming Contexts are the smallest units of partitioning.
System policies can be used locally on machines or set at the domain level.	Group policies can be managed centrally and used by clients throughout the forest based on domain, site, or OU criteria.
Data cannot be stored hierarchically within a domain.	Data can be stored in a hierarchical manner using OUs.
Domain is the smallest unit of security delegation and administration.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Although the first version of Active Directory available with Windows 2000 was very stable and feature-rich, it still had room for improvement, primarily around manageability and performance. With Windows Server 2003, Microsoft has addressed many of these issues. To utilize these features, you have to upgrade your domain controllers to Windows Server 2003 and raise the domain and forest functional levels as necessary.

Windows 2000 Active Directory introduced us to the concept of mixed mode and native mode. This was a domain concept that indicated whether or not all DCs in a domain were Windows 2000 and could therefore use new capability that wasn't available in Windows NT. Switching from mixed mode to native mode was a purposeful configuration change made by the domain administrators.

Windows Server 2003 Active Directory further refined this by adding functional levels. It introduced both domain functional levels and forest functional levels. Like mixed mode and native mode, domain functional mode depends on the types of domain controllers in the forest. If you have all Windows Server 2003 domain controllers, you can switch Windows Server 2003 domain functional mode and gain access to many new functions. Microsoft also added new functions that could be used only if all domain controllers in the forest were upgraded to Windows Server 2003, so they added forest functional mode. When all DCs in the forest are upgraded, the enterprise administrators can increase the forest functional mode.

The difference between Windows 2000 Active Directory and Windows Server 2003 Active Directory is more evolutionary than revolutionary. The decision to upgrade to Windows Server 2003 is a subjective one, based on your needs. For example, if you have a lot of domain controllers and Active Directory sites, you may want to take advantage of the improvements with replication as soon as possible. Or perhaps you've been dying to rename a domain, a capability available in Windows Server 2003 Active Directory. On the whole, Microsoft added or updated more than 100 features within Active Directory, and we will now discuss some of the more significant ones.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Microsoft has consistently extended release dates for future versions of Windows Server, so they decided to release an interim version of Windows Server 2003, which includes Service Pack 1 as well as several new optional components. Some of these new optional components, such as Active Directory Application Mode (ADAM), are available via Web downloads, but Microsoft chose to package them on the R2 CD to make them available to a wider audience. In addition, some users question Microsoft's commitment to software that is only available from its web site; making the components part of the Core OS dispels any doubts on Microsoft's support position.

Service Pack 1 offers a considerable number of improvements for Windows Server 2003. As with Windows XP Service Pack 2 , many of the changes are security related correcting issues in Internet Explorer and offering new firewall functionality, Table 1-5 gives an overview of the Active Directory specific updates.

Table 1-5: Windows Server 2003 SP1 Active Directory enhancements
Feature	Description
Directory service backup reminders	Special messages logged to the Directory Service event log if directory partitions are not backed up.
Additional replication security and fewer replication errors	Replication metadata for domain controllers removed from the domain is now removed. This enhances directory security and eliminates replication error messages related to the deleted domain controllers.
Install from media improvements for installing DNS Servers

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter is a brief introduction to the origins of Active Directory and some of the new features available in Windows Server 2003 and Window Server 2003 R2. The rest of the chapters in Part I cover the conceptual introduction to Active Directory and equip you with the skills necessary to gain the most from Parts II and III.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter aims to bring you up to speed on the basic concepts and terminology used with Active Directory. It is important to understand each component of Active Directory before embarking on a design, or your design may leave out a critical element.

Data stored within Active Directory is presented to the user in a hierarchical fashion similar to the way data is stored in a file system. Each entry is referred to as an object. At the structural level, there are two types of objects : containers and non-containers, which are also known as leaf nodes. One or more containers branch off in a hierarchical fashion from a root container. Each container may contain leaf nodes or other containers. As the name implies, however, a leaf node may not contain any other objects.

Although the data in Active Directory is presented hierarchically, it is actually stored in flat database rows and columns. The Directory Information Tree (DIT ) file is an Extensible Storage Engine (ESE ) database file. This answers the question "Does Active Directory use JET or ESE Database technology?" ESE is a JET technology.

Consider the parent-child relationships of the containers and leaves in Figure 2-1. The root of this tree has two children, Finance and Sales. Both of these are containers of other objects. Sales has two children of its own, Pre-Sales and Post-Sales. Only the Pre-Sales container is shown as containing additional child objects. The Pre-Sales container holds user, group, and computer objects as an example. Each of these child nodes is said to have the Pre-Sales container as its parent. Figure 2-1 represents what is known in Active Directory as a domain.

Figure 2-1: A hierarchy of objects

The most common type of container you will create in Active Directory is an Organizational Unit (OU), but there are others as well, such as the one called Container. Each of these has its place, as we'll show later, but the one that we will be using most frequently is the Organizational Unit.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Data stored within Active Directory is presented to the user in a hierarchical fashion similar to the way data is stored in a file system. Each entry is referred to as an object. At the structural level, there are two types of objects : containers and non-containers, which are also known as leaf nodes. One or more containers branch off in a hierarchical fashion from a root container. Each container may contain leaf nodes or other containers. As the name implies, however, a leaf node may not contain any other objects.

Although the data in Active Directory is presented hierarchically, it is actually stored in flat database rows and columns. The Directory Information Tree (DIT ) file is an Extensible Storage Engine (ESE ) database file. This answers the question "Does Active Directory use JET or ESE Database technology?" ESE is a JET technology.

Consider the parent-child relationships of the containers and leaves in Figure 2-1. The root of this tree has two children, Finance and Sales. Both of these are containers of other objects. Sales has two children of its own, Pre-Sales and Post-Sales. Only the Pre-Sales container is shown as containing additional child objects. The Pre-Sales container holds user, group, and computer objects as an example. Each of these child nodes is said to have the Pre-Sales container as its parent. Figure 2-1 represents what is known in Active Directory as a domain.

Figure 2-1: A hierarchy of objects

The most common type of container you will create in Active Directory is an Organizational Unit (OU), but there are others as well, such as the one called Container. Each of these has its place, as we'll show later, but the one that we will be using most frequently is the Organizational Unit.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we've shown how objects are structured and referenced, let's look at the core concepts behind Active Directory.

Active Directory's logical structure is built around the concept of domains introduced in Windows NT 3.x and 4.0. However, in Active Directory, domains have been updated significantly from the flat and inflexible structure imposed by Windows NT. An Active Directory domain is made up of the following components:

An X.500-based hierarchical structure of containers and objects
A DNS domain name as a unique identifier
A security service, which authenticates and authorizes any access to resources via accounts in the domain or trusts with other domains
Policies that dictate how functionality is restricted for users or machines within that domain

A domain controller (DC) can be authoritative for one and only one domain. Currently, it is not possible to host multiple domains on a single DC. For example, Mycorp Company has already been allocated a DNS domain name for their company called mycorp.com, so they decide that the first Active Directory domain that they are going to build is to be named mycorp.com. However, this is only the first domain in a series that needs to be created, and mycorp.com is in fact the root of a domain tree.

The mycorp.com domain itself, ignoring its contents, is automatically created as the root node of a hierarchical structure called a domain tree. This is literally a series of domains connected together in a hierarchical fashion, all using a contiguous naming scheme. So, when Finance, Marketing, and Sales each want their own domain, the names become finance.mycorp.com, mktg.mycorp.com, and sales.mycorp.com

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, we've gone over the groundwork for some of the main internals of Active Directory. We covered such concepts as domains, trees, forests, Organizational Units, the Global Catalog, FSMOs, Windows 2000 domain modes, and Windows Server 2003 functional levels. We then delved into how groups work in Active Directory and what features are available under the various domain modes and functional levels.

With this information under our belts, let's now take a look at how data is organized in Active Directory with Naming Contexts and Application Partitions.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Due to the distributed nature of Active Directory, it is necessary to segregate data into partitions. If data partitioning were not used, every domain controller would have to replicate all the data within a forest. Often it is advantageous to group data based on geographical or political requirements. Think of a domain as a big data partition, which is also referred to as a naming context (NC). Only domain controllers that are authoritative for a domain need to replicate all of the information within it. On the other hand, there is some Active Directory data that must be replicated to all domain controllers. There are three predefined naming contexts within Active Directory:

A Domain Naming Context for each domain
The Configuration Naming Context for the forest
The Schema Naming Context for the forest

Each of these naming contexts represents a different aspect of Active Directory data. The Configuration NC holds data pertaining to the configuration of the forest or forest-wide applications such as the objects representing naming contexts, LDAP policies, sites, subnets, MS Exchange, and so on. The Schema NC contains the set of object class and attribute definitions for the types of data that can be stored in Active Directory. Each domain in a forest also has a Domain NC, which contains data specific to the domain—for example, users, groups, computers, etc.

In Windows Server 2003 Active Directory, Microsoft extended the naming context concept by allowing user-defined partitions called application partitions. Application partitions can contain any type of object except for security principals. The major benefit of application partitions is that administrators can define which domain controllers replicate the data contained within these partitions. Application partitions are not restricted by domain boundaries, as is the case with Domain NCs; they can exist on any domain controller running Windows Server 2003 or later in a forest, regardless of the domain the DC hosts.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Each Active Directory domain is represented by a Domain NC, which holds the domain-specific data. The root of this NC is represented by a domain's distinguished name (DN) and is typically referred to as the NC head. For example, the mycorp.com domain's DN would be dc=mycorp,dc=com. Each domain controller in the domain replicates a copy of the Domain NC.

Table 3-1 contains a list of the default top-level containers found in a Domain NC. Note that to see all of these containers with the Active Directory Users and Computers (ADUC) snap-in, you must select View → Advanced Features from the menu. Alternatively, you can browse all of these containers with the ADSI Edit tool available in the Windows Support Tools on any Windows Server 2003 or Windows 2000 CD.

Table 3-1: Default top-level containers of a Domain NC
Relative distinguished name	Description
`cn=Builtin`	Container for predefined built-in local security groups. Examples include Administrators, Users, and Account Operators.
`cn=Computers`	Default container for computer objects representing member servers and workstations. You can change the default container used in Windows Server 2003 with the `redircmp.exe` utility.
`ou=Domain Controllers`	Default organizational unit for computer objects representing domain controllers.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Configuration NC is the primary repository for configuration information for a forest and is replicated to every domain controller in the forest. The root of the Configuration NC is found in the Configuration container, which is a sub-container of the forest root domain. For example, the mycorp.com forest would have a Configuration NC located at cn=configuration,dc=mycorp,dc=com.

Table 3-2 contains a list of the default top-level containers found in the Configuration NC.

Table 3-2: Default top-level containers of the Configuration NC
Relative distinguished name	Description
`cn=DisplaySpecifiers`	Container that holds display specifier objects, which define various properties and functions of the Active Directory MMC Snap-ins.
`cn=Extended-Rights`	Container for extended rights (`controlAccessRight`) objects.
`cn=ForestUpdates`	Contains objects that are used to represent the state of forest and domain functional level changes. This container is new in Windows Server 2003.
`cn=LostandFoundConfig`	Container for orphaned objects.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Schema NC contains objects representing the classes and attributes that Active Directory supports. The schema is defined on a forest-wide basis, so the Schema NC is replicated to every domain controller in the forest. The root of the Schema NC can be found in the Schema container, which is a sub-container of the Configuration container. For example, in the mycorp.com forest, the Schema NC would be located at cn=schema,cn=configuration,dc=mycorp,dc=com.

Although the Schema container appears to be a child of the Configuration container, it is actually a separate naming context in its own right. Figure 3-1 shows how the Schema and Configuration NCs are segregated in the ADSI Edit tool.

Figure 3-1: ADSI Edit view of the Configuration and Schema naming contexts

You may be wondering why the schema isn't just contained within the Configuration NC. As we covered in Chapter 2, there is a Schema FSMO role that is the single master for updates to schema objects. The Schema FSMO role is necessary due to the highly sensitive nature of the schema. Schema modifications need to be processed prior to any updates that utilize the schema. The mechanism to most easily guarantee this with the replication model AD uses is to put the schema into its own partition so it can replicate separately prior to other changes.

Unlike the Domain and Configuration NCs, the Schema NC does not maintain a hierarchy of containers or organizational units. Instead, it is a single container that has classSchema, attributeSchema, and subSchema objects. The classSchema objects define the different types of classes and their associated attributes. The attributeSchema objects define all the attributes that are used as part of classSchema definitions. There is also a single subSchema instance that represents the abstract schema as defined in the LDAPv3 RFC (

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Application partitions are a new feature in Windows Server 2003. They enable administrators to create areas in Active Directory to store data on specific DCs they choose rather than on every DC in a domain or forest. You can define which domain controllers hold a copy of each application partition, known as a replica. There is no limitation based on domain or site membership, which means that you can configure any domain controller running Windows Server 2003 or later within a forest to hold any application partition replica. The existing site topology will be used to automatically create the necessary connection objects to replicate among the servers that hold replicas of an application partition. Domain controllers will also register the necessary SRV records (explained in more detail in Chapter 6), so that clients can use the DC locator process to find the optimal domain controller for an application partition, just as they would for a domain.

There are a few limitations to be aware of with application partitions :

Application partitions cannot contain security principals, which most notably includes user, inetOrgPerson, group, and computer objects. Any other type of object can be created in an application partition.
None of the objects contained in an application partition are replicated to the global catalog. Even if a domain controller that holds a replica of an application partition is also a global catalog server, the domain controller will not return any objects from the application partition during a global catalog search.
Objects in an application partition cannot be moved outside the partition. This is different than objects contained in domains, which can be moved between domains.
The Domain Naming FSMO must be on a Windows Server 2003 domain controller to create an application partition. After the application partition has been created, you can move the Domain Naming FSMO back to a Windows 2000 domain controller if necessary.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, we covered how objects are grouped at a high level into naming contexts and application partitions, which are used as replication boundaries. The Domain NC contains domain-specific data such as users, groups, and computers. The Configuration NC contains forest-wide configuration data such as the site topology objects and objects that represent naming contexts and application partitions. The Schema NC contains all the schema objects that define how data is structured and represented in Active Directory. Application partitions were introduced in Windows Server 2003 Active Directory as a way for administrators to define their own grouping of objects and, subsequently, replication boundaries. Storage of DNS data for AD-integrated DNS zones is the classic example of when it makes sense to use application partitions, due to the increased control they give you over which domain controllers replicate the data. Dynamic objects are also new to Windows Server 2003 Active Directory. This allows you to create objects that have a time-to-live (TTL) value; after the TTL expires, Active Directory automatically deletes the object.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The schema is the blueprint for data storage in Active Directory. Each object in Active Directory is an instance of a class in the schema. A user object, for example, exists as an instance of the user class. Attributes define the pieces of information that a class, and thus an instance of that class, can hold. Syntaxes define the type of data that can be placed into an attribute. As an example, if an attribute is defined with a syntax of Boolean, it can store True or False as its value.

Active Directory contains many attributes and classes in the default schema, some of which are based on standards and some of which Microsoft needed for its own use. However, the Active Directory schema was designed to be extensible, so that administrators could add any classes or attributes they deemed necessary. In fact, extending the schema is not a difficult task; it is often more difficult to design the changes that you would like to incorporate. Schema design issues are covered in Chapter 12, and in Chapter 27, we cover how to extend the schema programmatically. In this chapter, we're concerned only with the fundamentals of the schema.

The Schema Container is located in Active Directory under the Configuration Container. For example, the distinguished name of the Schema Container in the mycorp.com forest would be cn=schema,cn=Configuration,dc=mycorp,dc=com. You can view the contents of the container directly by pointing an Active Directory viewer such as ADSIEdit or LDP at it. You can also use the Active Directory Schema MMC snap-in, which splits the classes and attributes in separate containers for easy viewing, even though in reality all the schema objects are stored directly in the Schema Container.

The schema itself is made up of two types of Active Directory objects: classes and attributes. In Active Directory, these are known respectively as classSchema (Class-Schema) and attributeSchema (Attribute-Schema) objects. The two distinct forms of the same names result from the fact that the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Schema Container is located in Active Directory under the Configuration Container. For example, the distinguished name of the Schema Container in the mycorp.com forest would be cn=schema,cn=Configuration,dc=mycorp,dc=com. You can view the contents of the container directly by pointing an Active Directory viewer such as ADSIEdit or LDP at it. You can also use the Active Directory Schema MMC snap-in, which splits the classes and attributes in separate containers for easy viewing, even though in reality all the schema objects are stored directly in the Schema Container.

The schema itself is made up of two types of Active Directory objects: classes and attributes. In Active Directory, these are known respectively as classSchema (Class-Schema) and attributeSchema (Attribute-Schema) objects. The two distinct forms of the same names result from the fact that the cn (Common-Name) attribute of a class contains the hyphenated easy-to-read name of the class, and the lDAPDisplayName (LDAP-Display-Name) attribute of a class contains the concatenated string format that is used when querying Active Directory with LDAP or ADSI. In the schema, the lDAPDisplayName attribute of each object is normally made by capitalizing the first letter of each word of the Common-Name, and then removing the hyphens and concatenating all the words together. Finally, the first letter is made lowercase. This creates simple names like user, as well as the more unusual sAMAccountName and lDAPDisplayName. We'll specify the more commonly used LDAP display name format from now on.

Whenever you need to create new types of objects in Active Directory, you must first create a classSchema object, defining the class of the object and the attributes it contains. Once the class is properly designed and added to the schema, you can then create objects in Active Directory that use the class. Alternatively, if you want to add a new attribute to an object, you must first create the attributeSchema object and associate the attribute with whatever classes you want to use it with.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Just as class information is stored in Active Directory as instances of the class called classSchema, attributes are represented by instances of the class called attributeSchema. As with all objects, the attributeSchema class has a number of attributes that can be set when specifying a new instance. The attributeSchema class inherits attributes from the class called top. However, most of the top attributes are not really relevant here. Table 4-1 shows the defining attributes of an instance of the attributeSchema class (i.e., an attribute) that can be set.

Table 4-1: The defining attributes of an attributeSchema object instance
Attribute	Syntax	Mandatory	Multivalued	Description
`accessCategory`	Integer	No	No	Used by the system.
`attributeId`	OID

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are several properties on attributes that have significant and varied impact on attribute use and functionality. Here we give a little more detailed information on a few of these attributes that you need to understand when modifying the schema.

Figure 4-3: The UPN attribute as viewed by the Active Directory Schema snap-in

The syntax of an attribute represents the kind of data it can hold; people with a programming background are probably more familiar with the term "data type." Unlike attributes and classes, the supported syntaxes are not represented as objects in Active Directory. Instead, Microsoft has coded these syntaxes internally into Active Directory itself. Consequently, any new attributes you create in the schema must use one of the predefined syntaxes.

Whenever you create a new attribute, you must specify its syntax. To uniquely identify the syntax among the total set of 21 syntaxes, you must specify 2 pieces of information: the OID of the syntax and a so-called OM syntax. This pair of values must be set together and correctly correlate with Table 4-3. More than one syntax has the same OID, which may seem strange; and to distinguish between different syntaxes uniquely, you thus need a second identifier. This is the result of Microsoft requiring some syntaxes that X.500 did not provide. Table 4-3 shows the 21 expanded syntaxes, including the name of the syntax with alternate names followed in parentheses.

Table 4-3: Syntax definitions
Syntax

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Schema classes are defined as instances of the classSchema class. Table 4-6 shows the most important attributes that you may wish to set.

Table 4-6: The defining attributes of a classSchema object instance
Attribute	Syntax	Mandatory	Multivalued	Description
`auxiliaryClass`	OID	No	Yes	The list of Auxiliary (or 88-Class) classes that this object inherits attributes from.
`Cn`	Unicode	Yes	No	The Relative Distinguished Name (RDN).
`defaultHidingValue`

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this chapter, we've shown you how the internal blueprint for all objects in Active Directory, known as the schema, was derived from the X.500 directory service. We explained the purpose of the OID numbering system and how it can be used. We then detailed how an attribute and its syntax are structured in the schema as attributeSchema objects, using the userPrincipalName attribute as an example. We showed how attributes are added to classes by detailing how classes are stored in the schema as instances of classSchema objects. To make this more clear, we dug into the details of the user class to see how it was constructed. Finally, we covered how auxiliary classes can be dynamically linked in Windows Server 2003 and why it is significant.

Chapter 12 builds on what you've learned here to demonstrate how you can design and implement schema extensions.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter introduces a major feature of Active Directory: multi-master replication. Active Directory was one of the first LDAP-based directories to offer multi-master replication. Most directories replicate data from a single master server to subordinate servers. This is how replication worked in Windows NT 4.0 as an example. Obviously, there are several potential problems with a single-master replication scheme, including single point of failure for updates, geographic distance from master to clients performing the updates, and less efficient replication due to single originating location of updates. Active Directory replication addresses these issues, but with a price. To get the benefit of a multi-master replication, you must first create a site topology that describes the network and helps define how domain controllers should replicate with each other. In large environments, building and maintaining a site topology can be a significant amount of overhead.

This chapter looks at the basics of how sites and replication work in Active Directory. InChapter 9, we'll describe the physical infrastructure of a network layout using sites. We'll also discuss in that chapter how the Knowledge Consistency Checker (KCC) sets up and manages the replication connections and details on how to effectively design and tailor sites, site links, and replication in Active Directory.

The Active Directory site topology is the map that describes the network connectivity, Active Directory Replication guidelines, and locations for resources as it relates to the Active Directory forest. The major components of this topology are sites, subnets, site links, and connection objects. These are all Active Directory objects that are maintained in the forest's configuration container to allow the information to be locally available on all domain controllers so the DCs can properly communicate.

A subnet is a portion of the IP space of a network. Subnets are described by their IP network address combined with a subnet mask measured in bits. For instance, the subnet mask 255.255.255.0 is a 24-bit subnet mask. If you have a 24-bit mask for the 10.5.21.0 network, your subnet object would be described as 10.5.21.0/24. The subnet objects in Active Directory are a logical representation of the subnets in your environment; they may, but do not necessarily have to, reflect your actual physical subnet definitions. For example, you may have a building that has two 24-bit subnets of 10.5.21.0 and 10.5.22.0, which for the purposes of Active Directory could be included in a single AD subnet of 10.5.21.0/23, which specifies a 23-bit subnet mask.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Active Directory site topology is the map that describes the network connectivity, Active Directory Replication guidelines, and locations for resources as it relates to the Active Directory forest. The major components of this topology are sites, subnets, site links, and connection objects. These are all Active Directory objects that are maintained in the forest's configuration container to allow the information to be locally available on all domain controllers so the DCs can properly communicate.

A subnet is a portion of the IP space of a network. Subnets are described by their IP network address combined with a subnet mask measured in bits. For instance, the subnet mask 255.255.255.0 is a 24-bit subnet mask. If you have a 24-bit mask for the 10.5.21.0 network, your subnet object would be described as 10.5.21.0/24. The subnet objects in Active Directory are a logical representation of the subnets in your environment; they may, but do not necessarily have to, reflect your actual physical subnet definitions. For example, you may have a building that has two 24-bit subnets of 10.5.21.0 and 10.5.22.0, which for the purposes of Active Directory could be included in a single AD subnet of 10.5.21.0/23, which specifies a 23-bit subnet mask.

You define this subnet information in the directory because the only key available for determining relative location on a network is the IP addresses of the machines. The subnets are in turn associated with sites. Without these definitions, there is no way for a machine to make an efficient determination of what distributed resources it should try to use. By default, no subnets are defined in Active Directory.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at

Table of Contents