Chapter 1. A Brief Introduction

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.

Before moving on to some of the basic components within Active Directory, we will now review how Microsoft came to the point of implementing an LDAP-based directory service to support their NOS environment.

Evolution of the Microsoft NOS

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.

Brief History of Directories

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.

In 1988, the International Telecommunication Union (ITU) and International Organization of Standardization (ISO) teamed up to develop a series of standards around directory services, which has come to be known as X.500. While X.500 proved to be a good model for structuring a directory and provided a lot of functionality around advanced operations and security, it was difficult to implement clients that could utilize it. One reason is that X.500 is based on the OSI (Open System Interconnection) protocol stack instead of TCP/IP, which had become the standard for the Internet. The X.500 Directory Access Protocol (DAP ) was very complex and implemented a lot of features most clients never needed. This prevented large-scale adoption. It is for this reason that a group headed by the University of Michigan started work on a “lightweight” X.500 access protocol that would make X.500 easier to utilize.

The first version of the Lightweight Directory Access Protocol (LDAP) was released in 1993 as RFC 1487,[*] but due to the absence of many features provided by X.500, it never really took off. It wasn’t until LDAPv2 was released in 1995 as RFC 1777 that LDAP started to gain popularity. Prior to LDAPv2, the primary use of LDAP was as a gateway between X.500 servers. Simplified clients would interface with the LDAP gateway, which would translate the requests and submit it to the X.500 server. The University of Michigan team thought that if LDAP could provide most of the functionality necessary to most clients, they could remove the middleman (the gateway) and develop an LDAP-enabled directory server. This directory server could use many of the concepts from X.500, including the data model, but would leave out all the overheard resulting from the numerous features it implemented. Thus, the first LDAP directory server was released in late 1995 by the University of Michigan team, and it turned into the basis for many future directory servers.

In 1997, the last major update to the LDAP specification, LDAPv3, was described in RFC 2251. It provided several new features and made LDAP robust enough and extensible enough to be suitable for most vendors to implement. Since then, companies such as Netscape, Sun, Novell, IBM, OpenLdap Foundation, and Microsoft have developed LDAP-based directory servers. Most recently, RFC 3377 was released, which lists all of the major LDAP RFCs. For a Microsoft whitepaper on their LDAPv3 implementation and conformance, see

Windows NT Versus Active Directory

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.

A property of an object is the smallest unit of security delegation/administration.

Domain is a policy, replication, and security boundary.

Domain is a policy and replication boundary. Forest is the security boundary.

NetBIOS and WINS are used for name resolution.

DNS is used for name resolution. WINS may be required for applications or legacy clients.

Object is the smallest unit of replication.

Attribute is the smallest unit of replication.

In Windows Server 2003 Active Directory, some attributes replicate on a per-value basis (such as the member attribute of group objects).

Maximum recommended database size for SAM is 40 MB.

Recommended maximum database size for Active Directory is 16 TB.

Maximum effective number of users is 40,000 (if you accept the recommended 40 MB maximum).

The maximum number of objects per forest is in the tens of millions. Microsoft has tested to 40 million objects.

Four domain models (single, single-master, multimaster, complete-trust) are required to solve per-domain admin-boundary and user-limit problems.

No domain models required as the complete-trust model is implemented. One-way trusts with external domains, forests, and Unix Kerberos realms can be implemented manually.

Schema is not extensible.

Schema is fully extensible.

Data can only be accessed through a Microsoft API.

Data can be accessed through a Microsoft API or through LDAP, which is the standard protocol used by directories, applications, and clients that want to access directory data. Allows for cross-platform data access and management.

First, Windows NT Primary Domain Controllers and Backup Domain Controllers have been replaced by Active Directory Domain Controllers. It is possible under Active Directory to promote member servers to Domain Controllers (DCs) and demote DCs to ordinary member servers, all without needing a reinstallation of the operating system; this is not the case under Windows NT. If you want to make a member server a DC, you can promote it using the dcpromo.exe wizard. dcpromo asks you a number of questions, such as whether you are creating the first domain in a domain tree or joining an existing tree, whether this new tree is part of an existing forest or a new forest to be created, and so on.


UTOOLS provides a tool called UPromote through that allows you to demote NT4 DCs to member servers. Although this functionality is not supported by Microsoft, companies and universities have successfully used the product to demote NT4 BDCs from Active Directory domains. This is useful if for some reason you cannot upgrade or reinstall the operating system on the NT4 BDC.

Organizational Units are an important change with Active Directory. Under Windows NT , administration was delegated on a per-domain basis. Active Directory allows the administrators to define administration boundaries that encompass anything from the entire forest, domain, or Organizational Unit, all the way down to individual objects and attributes. This can significantly reduce the number of domains you require and offers far greater flexibility in your management choices.

Windows NT uses NetBIOS as its primary network communication mechanism, whereas Active Directory requires DNS and uses TCP/IP as its exclusive transport protocol. Under previous versions, administrators were required to maintain two computer lookup databases —DNS for name resolution and WINS for NetBIOS name resolution—but Active Directory no longer requires traditional NetBIOS name resolution. Instead, it relies on DNS. You may still encounter a need to install and run a WINS server. However, this would only be required for compatibility for applications such as Exchange or older legacy clients that still require NetBIOS name resolution.

The significant difference in replication is that Active Directory will replicate at the attribute and, in some cases, even the value level rather than object level. With Windows NT, if you changed the full name of a user object, the whole object had to be replicated out. In the same scenario with Active Directory, only the modified attribute will be replicated. This was further improved in Windows Server 2003 Active Directory, where value-level replication was enabled for certain attribute types. This allowed common attributes like group membership to be replicated at the value level, so instead of replicating all members of a group, you only replicate the members that were added or removed. Coupled with some very clever changes to the way replication works, this means that you replicate less data for shorter periods, thereby reducing the two most important factors in replication. See Chapters 5 and 9 for more on replication.

The suggested maximum Windows NT Security Accounts Manager (SAM ) database size was 40 MB, which was roughly equivalent to about 40,000 objects, depending on what proportion of computer, user, and group accounts you had in your domain. Many companies have gone above 75 MB for the SAM for one domain due to the huge number of groups that they were using, so this rule was never hard and fast as long as you understood the problems you were likely to experience if you went past the limit. Active Directory is based on the Extensible Storage Engine (ESE) database used by Exchange and was developed to hold millions of objects with a maximum database size of 16 TB. This should be enough for most people’s needs, and the number of objects is only a recommended maximum limit. Remember, however, that this new database holds all classes of objects, not just the users, groups, and computers of the previous version’s SAM. As more and more Active Directory-enabled applications are developed, more classes of objects will be added to the schema, and more objects will be added to the directory. To bring this into perspective, imagine that one of the world’s largest aerospace companies has around half a million computers. Assuming an equivalent number of staff, this still uses only 10% of the maximum database capacity. However, when you begin to consider all the other objects that will be in Active Directory, including file shares, printers, groups, organizational units, domains, contacts, and so on, you can see how that percentage will increase.

For administrators of Windows NT , the significant increase in scalability may be the most important change of all. It was extremely easy to hit the 40 MB SAM limit within an NT domain, forcing you to split the domain. You ended up managing multiple domains when you really didn’t want to; it was quite frustrating. None of the domains were organized into a domain tree or anything of the sort, so they had no automatic trusts between them. This meant that NT administrators had to set up manual trusts between domains, and these had to be initiated at both domains to set up a single one-way trust. As you added more domains, you ended up managing even greater numbers of trusts. There are four domain models that you could use as templates for your Windows NT design: the single-domain model, the single-master domain model, the multimaster domain model, and the complete-trust domain model. All four are shown in Figure 1-1. The most common model after the single-domain model is probably the multimaster domain model.

The single-domain model had, as the name implied, only one domain with a SAM smaller than 40 MB and no trusts. Where multiple domains were needed for resource access but the SAM was still less than 40 MB, the single-master domain model was used. The single-master domain model was made up of one user (or account) domain and multiple resource domains. The important point was that the resource domains had one-way trusts with the user domain that held all the accounts. Due to the one-way trusts, the administrators of the resource domains could set permissions as they wished to their own resources for any accounts in the user domain. This meant that one central set of administrators could manage the accounts, while individual departments maintained autonomy over their own resources. The multimaster model came into play when the SAM limitations were approached, when you needed to separate out user management to different administrative groups, or when you wanted to better control replication traffic geographically. The administrators of the user domain split the user accounts into two or more domains, giving them two-way (i.e., complete) trust between each other, and then each resource domain had to have a one-way trust with each user domain. Scaling this up, for a multimaster domain with 10 user domains and 100 resource domains, that’s 90 trusts to make up the intrauser trusts and 1,000 separate resource-to-user trusts that must be manually set. Finally, in some cases, the complete-trust model was used where any domain could create accounts, and those accounts could be used to access shared resources to any other domain.

The four Windows NT domain models
Figure 1-1. The four Windows NT domain models

By contrast, all Active Directory domains within a forest trust each other via transitive trusts . This results in an automatic complete-trust model within the forest. In Windows Server 2003 Active Directory, transitive forest trusts are also available so that all of the domains in two different forests can completely trust each other via a single explicit trust between the forest root domains.


Windows NT had simple trusts. This means that if DomA trusted DomB, and DomB trusted DomC, there was no automatic connection between DomA and DomC.

Active Directory gave us transitive trusts; with transitive trusts, if DomA trusted DomB, and DomB trusted DomC, DomA could trust DomC through the trust transitivity.

Finally, the Windows NT schema was not extensible. No new object types could be added to it, which was a significant limitation for most enterprises. When Microsoft products that extended Windows NT—such as Terminal Server and File and Print for NetWare—were released, each had to store any attribute data that it wanted all together within one existing attribute. Under Active Directory, the schema is fully extensible, so any new products can extend the schema and add in objects and attributes as required.


For more information on upgrading from Windows NT to Active Directory, take a look at Chapter 16.

Windows 2000 Versus Windows Server 2003

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.


For information on upgrading to Windows Server 2003 from Windows 2000 , check out Chapter 14.

Some of the new features are available as soon as you promote the first Windows Server 2003 domain controller into an existing Windows 2000 Active Directory domain. In Table 1-2, the features available when you do so are listed, along with a description. Note that, with the exception of WMI Filtering for GPOs, these features will apply only to the Windows Server 2003 domain controllers in the domain.

Table 1-2. Windows 2000 domain functional level feature list



Application partitions

You can create your own partitions to store data separately from the default partitions, and you can configure which domain controllers (DC) in the forest replicate it.

Global Catalog (GC); not required for logon (i.e., universal group caching)

Under Windows 2000, a DC had to contact a GC to determine universal group membership and subsequently to allow users to logon. This feature allows DCs to cache universal group membership so that it may not be necessary to contact a GC for logins.

MMC enhancements and new command-line tools

The new Active Directory Users and Computers console allows you to save queries, drag and drop, and edit multiple users at once, and it is much more efficient about scrolling through a large number of objects. In addition, several new command-line tools (dsadd, dsmod, dsrm, dsquery, dsget, and dsmove) come installed with the server, allowing for greater flexibility in managing Active Directory.

Install from media

Administrators can create new DCs for an existing domain by installing from a backup of an existing DC that resides on media such as a CD or DVD.

WMI filtering for GPOs

You can apply a WMI filter, which is a query that can utilize any WMI information on a client, to a GPO, and that query will be run against each targeted client. If the query succeeds, the GPO will continue to process; otherwise, it will stop processing. The feature requires clients to be Windows XP or better.

GC replication tuning

After an attribute has been added to the GC, a sync of the contents of the GC for every GC server will no longer be performed as it was with Windows 2000. This occurs only with Windows Server 2003 to Windows Server 2003 replication.

In Table 1-3, the features available in domains running the Windows Server 2003 functional level are listed. A domain can be changed to the Windows Server 2003 functional level when all domain controllers in the domain are running Windows Server 2003.

Table 1-3. Windows Server 2003 domain functional level feature list



Domain controller rename

With Windows 2000, you had to demote, rename, and repromote a DC if you wanted to rename it. With Windows Server 2003 domains , you can rename DCs, and it requires only a single reboot.

Logon timestamp replicated

Under Windows 2000, the lastLogon attribute contained a user’s last logon timestamp, but that attribute was not replicated among the DCs. With Windows Server 2003, the lastLogonTimeStamp attribute is occasionally updated, by default every seven days, and will be replicated.


Users and computers that have write access to AD can cause a Denial of Service (DOS) attack by creating objects until a DC’s disk fills up. You can prevent this type of attack by using quotas. With a quota, you can restrict the number of objects a security principal can create in a partition, container, or OU. Windows Server 2003 DCs can enforce quotas even when not at the Windows Server 2003 domain functional level, but for it to be enforced everywhere, all DCs must be running Windows Server 2003.

In Table 1-4, the features available to forests running the Windows Server 2003 functional level are listed. A forest can be raised to the Windows Server 2003 functional level when all domains contained within the forest are at the Windows Server 2003 domain functional level.

Table 1-4. Windows Server 2003 forest functional level feature list



Reuse of critical schema identification properties

This feature allows certain critical identification properties to become available for reuse in the event a schema extension was originally misdefined and has since been defuncted.

Forest trust

A forest trust is a transitive trust between two forest root domains that allows all domains within the two forests to trust each other. To accomplish something similar with Windows 2000, you would have to implement trusts between each domain in the two forests.

Per-value replication

This feature allows certain linked-value attributes to replicate on a per-value basis instead of a per-attribute basis (i.e., all values). This is vital for group objects because under Windows 2000, a change in the member attribute caused the entire set of values for that attribute to unnecessarily be replicated.

Improved replication topology generation

The Intersite Topology Generator (ISTG) and Knowledge Consistency Checker (KCC) have been greatly improved and will create more efficient replication topologies.

Dynamic auxiliary classes

This feature allows for dynamically assigned per-object auxiliary classes. Under Windows 2000, an object could only utilize auxiliary classes that were statically defined in the schema for its object class.

Dynamic objects

Dynamic objects have a defined time to live (TTL) after which they will be removed from Active Directory unless the TTL is updated. This can help facilitate data management for short-lived objects.

InetOrgPerson class for users

The inetOrgPerson object class is a standard (RFC 2798) commonly used by directory vendors to represent users. With Windows Server 2003, you can use either the Microsoft-defined user object class or the inetOrgPerson object class for user accounts.

Domain rename

A domain can be renamed, which was not previously possible under Windows 2000. The impact to the environment is pretty significant (i.e., all member computers must be rebooted), and there are special considerations if Exchange is involved, so it should be done conservatively.

Windows Server 2003 Versus Windows Server 2003 R2

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



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

New option to include application directory partitions in the backup media eliminates the requirement for network replication of DomainDNSZone and ForestDNSZones application directory partitions before the DNS Server is operational.

Updated tools

Newer versions of DcDiag, NTDSUtil, IADSTools.DLL, AdPrep, and other tools to aid in management, updates, and troubleshooting.

Virtual server support

Official support for running domain controllers within Microsoft Virtual Server 2005. Additional logic was added to guard against directory corruption due to improper backup and restoration procedures.

Extended storage of deleted objects

Tombstone lifetime on new forests increased from 60 to 180 days. Existing forests are not modified.

Improved domain controller name resolution

To avoid replication failures due to DNS name-resolution issues, Windows Server 2003 with SP1 will request other variations of the server name that could be registered.

Confidential attributes

Ability to mark attributes as confidential so they cannot be read without additional permissions granted. By default, any attribute marked confidential can only be read by trustees with full control access to the object; however, this can be delegated in a granular manner.

SID History attribute retained on object deletion

The SID History attribute has been added to the default list of attributes retained on an object tombstone. When the object is undeleted, the attribute will be restored with the object.

Operations master health and status reporting

Operations that require a FSMO domain controller that cannot be performed will generate Directory Service event log messages.

Drag and drop changes in Active Directory Users and Computers Console

Ability to disable drag and drop functionality in ADUC and display confirmation dialogs when initiating a move operation.

Although Service Pack 1 is certainly full of great updates that any domain administrator would want loaded on their domain controllers, the real meat in Windows Server 2003 R2 is in the optional components. If the optional components do not interest you, then R2 will probably not be an upgrade you will spend a lot of time on. Table 1-6 lists the various new components available in R2 specific to Active Directory.

Table 1-6. Windows Server 2003 R2 optional Active Directory-specific components



Active Directory Application Mode (ADAM)

Standalone LDAP service that is Active Directory with the NOS-specific components and requirements stripped out.

Active Directory Federated Services (ADFS)

Standards-based technology that enables distributed identification, authentication, and authorization across organizational and platform boundaries.

Identity Management for UNIX (IMU)

Manage user accounts and passwords on Windows and Unix via NIS. Automatically synchronize passwords between Windows and Unix.


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.

[*] You can look up the text of this RFC at

Get Active Directory, 3rd Edition now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.