Active Directory, 4th Edition

Chapter 1. A Brief Introduction

Active Directory (AD) is Microsoft’s network operating system (NOS), built on top of Windows 2000, Windows Server 2003, and now Windows Server 2008. 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 enterprise 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). It may seem intimidating if you are faced with importing all of this data into Active Directory and managing it, but fortunately, Microsoft has some very robust yet easy-to-use Application Programming Interfaces (APIs) to help facilitate programmatic data management.

This book is a comprehensive introduction to Active Directory with a broad scope. In Part I, we cover many of the basic concepts of 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 detailed management of Active Directory programmatically through scripts based on Active Directory Service Interface (ADSI), ActiveX Data Objects (ADO), Windows Management Instrumentation (WMI), the .NET Framework, and Windows PowerShell. 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 take a moment to review how Microsoft came to the point of implementing a Lightweight Directory Access Protocol (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 of the OS/2 operating system. The NT NOS slowly evolved over the next eight years until Active Directory was first released in beta form 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 has 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 many 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 Request for Comments (RFC) 1487^[1] 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 them 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 overhead 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 http://www.microsoft.com/windowsserver2003/techinfo/overview/ldapcomp.mspx.

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 Primary Domain Controller (PDC) master to the Backup Domain Controller (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 Organizational Unit (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 and above, some attributes replicate on a per-value basis (such as the member attribute of group objects).
Maximum recommended database size for the Security Accounts Manager (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 1 billion users; for more information see http://technet.microsoft.com/en-us/library/cc756101.aspx.
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 was 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.

Note

UTOOLS provides a tool called UPromote through http://utools.com/UPromote.asp that allows you to demote NT4 DCs to member servers. Although this functionality is not supported by Microsoft, many 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 does not require NetBIOS name resolution. Instead, it relies on DNS. You may still encounter a need to install and run a WINS server, and for many organizations, retiring an existing WINS infrastructure is a daunting prospect. Running WINS in conjunction with Active Directory is only be required for compatibility for applications 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 functionality was further improved in Windows Server 2003 Active Directory, where value-level replication was enabled for linked attributes. This allowed common attributes such as group membership to be replicated at a more granular value level. For example, 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 10 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 the 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 recommended 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.

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 recommendation within an NT domain, forcing you to split the domain. You ended up managing multiple domains when you really didn’t want to, which could be 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 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.

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.

Note

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 many 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 applications can extend the schema and add in objects and attributes as required.

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.

Note

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 domain controllers in a domain were Windows 2000 and could therefore use a 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. While the decision to upgrade from Windows 2000 is a subjective one, based on your needs, Windows 2000 is in the extended support phase so you should definitely be considering migration to Windows Server 2008 if you are still running Windows 2000. On the whole, Microsoft added or updated more than 100 features within Active Directory during the Windows Server 2003 release, and we will now discuss some of the more significant ones.

Note

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

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 Windows Management Instrumentation (WMI) Filtering for Group Policy Objects (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

Feature	Description
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 log on. This feature allows DCs to cache universal group membership so that it may not be necessary to contact a GC for logins.
Microsoft Management Console (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

Feature	Description
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 domain controllers, 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 approximately every 10 days.
Quotas	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

Feature	Description
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. Domain Renames are supported only under Exchange 2003.

Windows Server 2003 Versus Windows Server 2003 R2

The release time frame for Windows Server 2008 was extended repeatedly, so Microsoft decided to release an interim update to Windows Server 2003—Windows Server 2003 R2. R2 includes Windows Server 2003 SP1 as well as a number of optional Active Directory add-on 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	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. Note that due to a regression bug, new Windows Server 2003 R2 forests have a tombstone lifetime of 60 days. This was subsequently corrected in Windows Server 2003 SP2 and Windows Server 2008.
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 Flexible Single Master Operator (FSMO) domain controller that cannot be performed will generate Directory Service event log messages.
Drag and drop changes in Active Directory Users and Computers (ADUC) 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

Feature	Description
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 Network Information Service (NIS). Automatically synchronize passwords between Windows and Unix.

Windows Server 2003 R2 Versus Windows Server 2008

Windows Server 2008 introduces substantial and, in some cases, complicated improvements to Active Directory. Perhaps the most important and well-known features are the introduction of Server Core and support for running Active Directory on Server Core along with the introduction of read-only domain controllers (RODCs). The differences between the fundamental Active Directory services in Windows Server 2003 R2 and Windows Server 2008 can again be considered evolutionary changes, as opposed to revolutionary. When evaluating your timeline to migrate to Windows Server 2008, consider the numerous new and improved features to aid your decision. Undoubtedly, one of the most compelling scenarios for upgrading to Windows Server 2008 Active Directory is for deployment into branch offices. A list of many of the key new features in Windows Server 2008 Active Directory are outlined in Table 1-7 and will be discussed in detail throughout the remainder of this book.

Table 1-7. Windows Server 2008 Active Directory enhancements

Feature	Description
Read-only domain controllers (RODCs)	RODCs do not allow local writes and do not store passwords and other secrets by default. This feature adds a great deal of security to domain controllers in locations with questionable physical security.
Server Core support	Domain controllers can now run on a version of the Windows Server 2008 operating system that is substantially lighter and thus more secure.
Fine-grained password policies	Password policies can now be defined on a per user or group basis.
Administrative role separation	Users who are not domain administrators can be securely delegated administrative control of RODCs without providing access to Active Directory.
Read-only DNS	RODCs can host dynamic DNS zones and refer the updates to writeable domain controllers.
GlobalNames DNS zone	A new type of DNS zone which can help pave the way to migrating away from WINS.
New auditing and logging infrastructure	Auditing of Active Directory access and changes as well as various other actions have been completely overhauled.
Last logon statistics	Windows Vista and Windows Server 2008 clients can store and display detailed last logon success and failure information directly on user objects in the directory.
Active Directory database snapshots	Point-in-time snapshots of the Active Directory database can be taken and mounted as a basis for disaster recovery and other object restore operations.
Restartable Directory service	Active Directory can be stopped to allow for certain offline operations to be performed without restarting the domain controller in Directory Service Repair Mode.
Improved user interface and tools	The core Active Directory graphical user interface (GUI) tools have been improved so that they can connect to mounted snapshots as well as Active Directory Lightweight Directory Services (AD LDS) instances.
ADMX repository	Upgraded Group Policy template files can now be stored once per domain in the Sysvol, thus greatly reducing the size of the Sysvol for many organizations.
Group Policy Preferences	A product Microsoft purchased from Desktop Standard, Group Policy Preferences allows you to control numerous settings and Windows features which were previously only accessible via scripts.
Starter Group policies	Group Policy templates can be defined which administrators can base new policies on.
Group Policy user interface enhancements	Numerous improvements to the Group Policy Management Console (GPMC) and GPO Editor tools such as searching for settings and filtering displays.
DFS-R Sysvol replication	Sysvol can now be replicated with the new Distribution File System Replication (DFS-R) replication engine which is much more reliable and scalable than the NT File Replication Service (NTFRS).
ESE single bit error correction	The JET database engine that Active Directory uses is now capable of detecting single bit errors and correcting them and thus reducing incidences of database corruption.
Owner access restrictions	An additional well-known security principal representing the owner of an object is now available.
Delegated DCPromo	Domain controllers can now be promoted by users other than domain administrators.
Phonetic name indexing	The displayName attribute is phonetically sortable on Japanese locale domain controllers.
Kerberos AES256 support	Kerberos support for Advanced Encryption Standard (AES) has been improved to support a maximum key length of 256 bits.

Summary

This chapter is a brief introduction to the origins of Active Directory and some of the new features available in Windows Server 2003, Window Server 2003 R2, and Windows Server 2008. 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.

---

^[1] You can look up the text of this RFC at http://www.ietf.org/rfc.html,