The heart and soul of the Windows Server 2003 networking infrastructure resides in Active Directory, Microsoft’s directory services implementation. Active Directory was devised to fill the directory services void in the Windows world and to serve as a platform for future integration of Microsoft technologies. A full understanding of the structure of Active Directory is vital to the understanding of the Windows Server 2003 environment as a whole.
In addition to the overall operating system enhancements, Windows Server 2003 expands upon the capabilities of Active Directory, adding the ability to rename domains, improving administrative tools, optimizing compression, and other long-awaited enhancements to the capabilities of the Active Directory environment. In addition, incremental improvements made to Windows Server 2003 have increased the functionality and flexibility of Active Directory, with tools such as Active Directory in Application Mode (ADAM).
This chapter describes an overview of directory services in general and specifically focuses on the overall development of Active Directory as an enterprise directory service. In addition, the basic components and functionality of Active Directory in Windows Server 2003 are summarized.
Directory services have existed in one form or another since the early days of computing to provide basic lookup and authentication functionality for enterprise network implementations. A directory service provides detailed information about a user or object in a network, much in the same way that a phonebook is used to look up a telephone number for a provided name. For example, a user object in a directory service can store the phone number, email address, department name, and as many other attributes as an administrator desires.
Directory services are commonly referred to as the white pages of a network. They provide user and object definition and administration. Early electronic directories were developed soon after the invention of the digital computer and were used for user authentication and to control access to resources. With the growth of the Internet and the increase in the use of computers for collaboration, the use of directories expanded to include basic contact information about users. Examples of early directories included MVS PROFS (IBM), Grapevine’s Registration Database, and WHOIS.
Application-specific directory services soon arose to address the specific addressing and contact-lookup needs of each product. These directories were accessible only via proprietary access methods and were limited in scope. Applications utilizing these types of directories were programs such as Novell GroupWise Directory, Lotus Notes, and the Unix sendmail /etc/aliases file.
The further development of large-scale enterprise directory services was spearheaded by Novell with the release of Novell Directory Services (NDS) in the early 1990s. It was adopted by NetWare organizations and eventually was expanded to include support for mixed NetWare/NT environments. The flat, unwieldy structure of NT domains and the lack of synchronization and collaboration between the two environments led many organizations to adopt NDS as a directory service implementation. It was these specific deficiencies in NT that Microsoft addressed with the introduction of Active Directory.
The development of the Lightweight Directory Access Protocol (LDAP) corresponded with the growth of the Internet and a need for greater collaboration and standardization. This nonproprietary method of accessing and modifying directory information that fully utilized TCP/IP was determined to be robust and functional, and new directory services implementations were written to utilize this protocol. Active Directory itself was specifically designed to conform to the LDAP standard.
Exchange 5.5 ran its own directory service as part of its email environment. In fact, Active Directory took many of its key design components from the original Exchange directory service. For example, the Active Directory database uses the same Jet database format as Exchange 5.5, the same types of utilities are necessary to run maintenance on the Active Directory database, and the site replication topology is similar in many ways.
Several other Microsoft applications ran their own directory services, namely Internet Information Server and Site Server. However, each directory service was separate from the others, and integration was not very tight between the different implementations.
Five key components are central to Active Directory’s functionality. As compatibility with Internet standards has become required for new directory services, the existing implementations have adjusted and focused on these areas:
TCP/IP compatibility—. Unlike some of the original proprietary protocols such as IPX/SPX and NetBEUI, the Transport Control Protocol/Internet Prococol (TCP/IP) was designed to be cross-platform. The subsequent adoption of TCP/IP as an Internet standard for computer communications has propelled it to the forefront of the protocol world and essentially made it a requirement for enterprise operating systems. Active Directory and Windows Server 2003 utilize the TCP/IP protocol stack as their primary method of communications.
Lightweight Directory Access Protocol support—. The Lightweight Directory Access Protocol (LDAP) has emerged as the standard Internet directory protocol and is used to update and query data within the directory. Active Directory directly supports LDAP.
Domain Name System (DNS) support—. DNS was created out of a need to translate simplified names that can be understood by humans (such as www.cco.com) into an IP address that is understood by a computer (such as 12.155.166.151). The Active Directory structure supports and effectively requires DNS to function properly.
Security support—. Internet standards-based security support is vital to the smooth functioning of an environment that is essentially connected to millions of computers around the world. Lack of strong security is an invitation to be hacked, and Windows Server 2003 and Active Directory have taken security to greater levels. Support for IP Security (IPSec), Kerberos, Certificate Authorities, and support for Secure Sockets Layer (SSL) encryption is built into Windows Server 2003 and Active Directory. In addition, the last few years have seen a recent major push at Microsoft to further secure all aspects of its software to prevent embarrassing security melt-downs such as those caused by viruses and worms.
Ease of administration—. Although often overlooked in powerful directory services implementations, the ease in which the environment is administered and configured directly affects the overall costs associated with its use. Active Directory and Windows Server 2003 are specifically designed for ease of use to lessen the learning curve associated with the use of a new environment. In addition, Windows Server 2003 includes numerous administrative improvements over Windows 2000, in the form of additional command-line tools for scripting, “headless” management capabilities, software restriction policies, and an enhanced GUI based on Windows XP.
Introduced with Windows 2000, Active Directory (commonly referred to as AD) has achieved wide industry recognition and acceptance and has proven itself in reliability, scalability, and performance. The introduction of AD served to address some limitations in the NT 4.0 domain structure design and also allowed for future Microsoft products to tie into a common interface.
Windows NT 4.0 domains, while possessing enhanced security over previous Windows Workgroup models, have several functional shortcomings that have limited their use as enterprise directories. The Windows NT domain is basically a flat namespace that stores very little information about a user beyond the basic username, password, and so on. In addition, further organization of users beyond the domain level is essentially not possible.
In addition, a typical NT 4.0 domain has basically two types of users: full-blown administrators and standard users. In a nutshell, you were either a super administrator of the domain or just a simple network user. This kept delegation of administration simple but didn’t provide for the type of granular security required by many larger organizations. These organizations needed administrative tasks to be subdivided and strictly defined, and Windows NT domains did not provide these capabilities. To get around this problem, many organizations set up multiple resource and user domains, dividing them by geographical location and/or political subdivision. The resulting special administrative issues could confuse even a seasoned NT guru. Often, one individual had several user accounts in multiple domains with multiple passwords. Needless to say, this drawback has been addressed in the granular administrative design within Active Directory.
Connectivity between NT 4.0 domains was accomplished through the manual setup of one- or two-way trusts between the domains. The domain trusts allowed for the domain controllers in the “trusting” domain to accept credentials that were validated by domain controllers in the “trusted” domain. The trusts were not transitive, however, which meant that if Domain A trusts Domain B, and Domain B trusts Domain C, Domain A does not trust Domain C unless you specifically create a trust between Domain A and Domain C. The problem with this model was that multiple domain trusts between several domains started to look like a “spaghetti” domain structure similar to the trust configuration shown in Figure 4.1.
This type of domain structure, as any NT 4.0 administrator can attest, becomes frustratingly difficult to administer and troubleshoot, as new administrators must determine what is meant by “trusted” and “trusting” domains and even veterans have a hard time visualizing their trust relationships from memory.
In addition to the complicated trust schemes, the Windows NT primary domain controller (PDC) is a single point of failure within an NT domain. If the PDC went down for whatever reason, it would severely affect domain functionality. Large organizations were likewise limited by the object limitations of NT 4.0 domains, which could not scale higher than 44,000 objects in any one domain.
These limitations were aggressively addressed with the development of Windows 2000 and Active Directory. Windows Server 2003 expands upon the functionality of Windows 2000 and takes the administrative capabilities of Active Directory even further.
Since the early development of Windows 2000, and subsequently Windows Server 2003, Microsoft has strived to make all its products embrace the Internet. Standards that before had been options or previously incompatible were subsequently woven into the software as primary methods of communication and operability. All applications and operating systems became TCP/IP compliant, and proprietary protocols such as NetBEUI were phased out. With the introduction of Windows Server 2003, the Internet readiness of the Microsoft environment reaches new levels of functionality.
The logical structure of Active Directory enables it to scale from small offices to large multinational organizations. Administrative granularity is built in to allow delegation of control to groups or specific users. No longer is the assigning of administrative rights an all or nothing scenario.
Active Directory loosely follows an X.500 directory model but takes on several characteristics of its own. Many of us are already getting used to the forests and trees of Active Directory, and some limitations that existed before in Windows 2000 have been lifted. To understand Active Directory, we must first take a good look at its core structural components.
An Active Directory (AD) domain is the main logical boundary of Active Directory. In a standalone sense, an AD domain looks very much like a Windows NT domain. Users and computers are all stored and managed from within the boundaries of the domain. However, several major changes have been made to the structure of the domain and how it relates to other domains within the Active Directory structure.
Domains in Active Directory serve as administrative security boundaries for objects and contain their own security policies. For example, different domains can contain different password policies for users. It is important to keep in mind that domains are a logical organization of objects, and can easily span multiple physical locations. Consequently, it is no longer necessary to set up multiple domains for different remote offices or sites as replication concerns are more properly addressed with the use of Active Directory sites, which will be described in greater detail in the following sections.
Note
One of the key differences between AD domains in Windows 2000 and AD domains in Windows Server 2003 is that administrators now have the ability to rename domains. For this to occur, however, all domain controllers within the forest must be converted to Windows Server 2003 domain controllers and the Active Directory forest functionality levels must be raised to support Windows Server 2003. In addition, if Exchange is a part of the forest, the Exchange organization must be brought to Exchange Server 2003 Service Pack 1 levels before renaming a domain. A detailed discussion of the Active Directory domain rename tools is provided in Chapter 5, “Designing a Windows Server 2003 Active Directory.”
An Active Directory tree is composed of multiple domains connected by two-way transitive trusts. Each domain in an Active Directory tree shares a common schema and global catalog. In Figure 4.2, the root domain of the Active Directory tree is companyabc.com and the subdomains are asia.companyabc.com and europe.companyabc.com.
The transitive trust relationship is automatic, which is a change from the domain structure of NT 4.0, in which all trusts had to be set up manually. The transitive trust relationship means that because the Asia domain trusts the root companyabc domain, and the Europe domain trusts the companyabc domain, the Asia domain trusts the Europe domain as well. The trusts flow through the domain structure.
Note
Although trusts are transitive in a Windows Active Directory environment, that does not mean that permissions are fully accessible to all users or even to administrators between domains. The trust only provides a pathway from one domain to another. By default, no access rights are granted from one transitive domain to another. The administrator of a domain must issue rights for users or administrators in another domain to access resources within their domain.
All domains within a tree share the same namespace, in this example companyabc.com, but have security mechanisms in place to segregate access from other domains. In other words, an administrator in the Europe domain could have relative control over his entire domain, without users from the Asia or companyabc domains having privileges to resources. Conversely, the administrators in Europe can allow groups of users from other domains access if they so want. The administration is granular and configurable.
Forests are a group of interconnected domain trees. Implicit trusts connect the roots of each tree together into a common forest.
The overlying characteristics that tie together all domains and domain trees into a common forest are the existence of a common schema and a common global catalog. However, domains and domain trees in a forest do not need to share a common namespace. For example, the domains microsoft.com and msnbc.com could theoretically be part of the same forest but maintain their own separate namespaces (for obvious reasons).
Forests are the main organizational security boundary for Active Directory, and it is assumed that all administrators within a forest are trusted to some degree. If an administrator is not trusted, that administrator should be placed in a separate forest.
Note
Early on in the life of Active Directory, domains were considered to be its security boundary. Administrators within the forest did not necessarily have to trust each other and could be separated into domains. However, the January 2002 Microsoft Security Bulletin MS02-001 identified a vulnerabilty called the “Domain Trust Vulnerability.” This vulnerability allows an administrator to use SIDHistory to elevate his privilege to any other domain in the forest. Although not easy to acomplish, it is still possible. SID filtering can be used between forests to prevent this attack, but not within forests. Thus, the security boundary for Active Directory was pushed from the domain to the forest.
Windows NT 4.0 used a system of authentication known as NT LAN Manager (NTLM). This form of authentication sent the encrypted password across the network in the form of a hash. The problem with this method of authentication was that anyone could monitor the network for passing hashes, collect them, and then use third-party decryption tools, which effectively decrypt the password using dictionary and brute-force techniques.
Windows 2000 and Windows Server 2003 utilize a form of authentication known as Kerberos, which is described in greater detail in the following sections. In essence, Kerberos does not send password information over the network and is inherently more secure than NTLM. However, Kerberos authentication is not required by default in Active Directory because AD is set up by default to be backward compatible for legacy Windows clients.
Just as Windows 2000 is installed to be initially compatible with legacy Windows NT domains and clients, Windows Server 2003 initially does not upgrade the Active Directory forest to Windows Server 2003 functionality. This helps to maintain backward compatibility with Windows 2000 and Windows NT4 domain controllers. Four separate functional levels exist at the domain level in Windows Server 2003, and three separate functional levels exist at the forest level.
Windows 2000 Mixed Domain Functional Level—. When Windows Server 2003 is installed into a Windows 2000 Active Directory forest that is running in Mixed mode, it essentially means that Windows Server 2003 domain controllers will be able to communicate with Windows NT and Windows 2000 domain controllers throughout the forest. This is the most limiting of the functional levels, however, because functionality such as universal groups, group nesting, and enhanced security is absent from the domain. This is typically a temporary level to run in because it is seen more as a path toward eventual upgrade.
Windows 2000 Native Functional Level—. Installed into a Windows 2000 Active Directory that is running in Windows 2000 Native mode, Windows Server 2003 will run itself at a Windows 2000 functional level. Only Windows 2000 and Windows Server 2003 domain controllers can exist in this environment.
Windows Server 2003 Interim Functional Level—. Windows Server 2003 Interim mode enables Windows Server 2003 Active Directory to interoperate with a domain composed of Windows NT 4.0 domain controllers only. Although a confusing concept at first mention, the Windows Server 2003 Interim functional level does serve a purpose. In environments that seek to upgrade directly from NT 4.0 to Windows Server 2003 Active Directory, Interim mode allows Windows Server 2003 to manage large groups more efficiently than if an existing Windows 2000 Active Directory exists. After all NT domain controllers have been removed or upgraded, the functional levels can be raised.
Windows Server 2003 Functional Level—. The most functional of all the various levels, Windows Server 2003 functionality is the eventual goal of all Windows Server 2003 Active Directory implementations. Functionality on this level opens the environment up to features such as schema deactivation, domain rename, domain controller rename, and cross-forest trusts. To get to this level, first all domain controllers must be updated to Windows Server 2003. Only after this can the domains and then the forest be updated to Windows Server 2003 functionality.
To bring a Windows Server 2003 forest to Windows Server 2003 functional levels, perform the following steps:
Ensure that all domain controllers in the forest are upgraded to Windows Server 2003.
Open Active Directory Domains and Trusts from the Administrative Tools menu.
In the left scope pane, right-click on the domain name and then click Raise Domain Functional Level.
In the box labeled Raise Domain Functional Level, shown in Figure 4.3, select Windows Server 2003 and then click Raise.
Click OK and then click OK again to complete the task.
Repeat steps 1–5 for all domains in the forest.
Perform the same steps on the forest root, except this time choose Raise Forest Functional Level and follow the prompts.
When all domains and the forest level have been raised to Windows Server 2003 functionality, various Windows Server 2003 activities such as domain rename can be accomplished, and full realization of the Windows Server 2003 Active Directory capabilities can be achieved. Remember, before you accomplish this task, Windows Server 2003 will essentially be operating in a Mixed mode of compatibility, much as Windows 2000 initially ran in a Mixed mode with Windows NT Servers.
The main components of Active Directory were designed to be highly configurable and secure. Active Directory and all it contains are physically located in a database file but are composed of a wide assortment of objects and their attributes. Many of these characteristics are familiar to those acquainted with other directory services products, but there are some new additions as well.
Active Directory loosely follows, but does not exactly conform to, the X.500 directory services information model. In a nutshell, X.500 defines a directory service through a distributed approach defined by a Directory Information Tree (DIT). This logically divides a directory service structure into the now familiar servername.subdomainname.domainname.com layout. In X.500, directory information is stored across the hierarchical layout in what are called Directory System Agents (DSAs). Microsoft designed Active Directory around many of the basic principles of the X.500 definition, but AD itself is not compatible with X.500 implementations, as X.500 follows an OSI model that is inefficient under the TCP/IP implementation that Active Directory follows.
The Active Directory schema is a set of definitions for all object types in the directory and their related attributes. The schema determines the way that all user, computer, and other object data are stored in AD and configured to be standard across the entire Active Directory structure. Secured by the use of Discretionary Access Control Lists (DACLs), the schema controls the possible attributes to each object within Active Directory. In a nutshell, the schema is the basic definition of the directory itself and is central to the functionality of a domain environment. Care should be taken to delegate schema control to a highly selective group of administrators because schema modification affects the entire AD environment.
Objects within the Active Directory structure such as Users, Printers, Computers, and Sites are defined in the schema as objects. Each object has a list of attributes that define it and that can be used to search for that object. For example, a User object for the employee named Weyland Wong will have a FirstName attribute of Weyland and a LastName attribute of Wong. In addition, there may be other attributes assigned, such as departmental name, email address, and an entire range of possibilities. Users looking up information in Active Directory can make queries based on this information, for example, searching for all users in the Sales department.
One of the major advantages to the Active Directory structure is the ability to directly modify and extend the schema to provide for custom attributes. A common attribute extension occurs with the installation of Microsoft Exchange Server, which extends the schema, more than doubling it in size. An upgrade from Windows 2000 Active Directory to Windows Server 2003 Active Directory also extends the schema to include attributes specific to Windows Server 2003. Many third-party products have their own schema extensions as well, each providing for different types of directory information to be displayed.
An interesting method of actually viewing the nuts and bolts of the Active Directory schema is by using the Active Directory Service Interfaces (ADSIEdit) utility. This utility was developed to simplify access to the Active Directory and can also view any compatible foreign LDAP directory. The ADSI utility, shown in Figure 4.4, enables an administrator to view, delete, and modify schema attributes. Great care should be taken before schema modifications are undertaken because problems in the schema can be difficult to fix.
The Directory Service Protocol that is utilized by Active Directory is based on the Internet-standard Lightweight Directory Access Protocol (LDAP) defined by RFC-1777. LDAP allows queries and updates to take place in Active Directory. Objects in an LDAP-compliant directory must be uniquely identified by a naming path to the object. These naming paths take two forms: distinguished names and relative distinguished names.
The distinguished name of an object in Active Directory is represented by the entire naming path that the object occupies in Active Directory. For example, the user named Kathi Honnegger can be represented by the following distinguished name:
CN=Kathi Honnegger,OU=Marketing,DC=COMPANYABC,DC=COM
The CN component of the distinguished name is the common name, which defines an object within the directory. The OU portion is the organizational unit in which the object belongs. The DC components define the DNS name of the Active Directory domain.
The relative distinguished name of an object is basically a truncated distinguished name that defines the object’s place within a set container. For example, take a look at the following object:
OU=Marketing,DC=COMPANYABC,DC=COM
This object would have a relative distinguished name of OU=Marketing. The relative distinguished name in this case defines itself as an organizational unit within its current domain container.
As in NT 4.0, Active Directory uses domain controllers (DCs) to authenticate users. However, the primary domain controllers and backup domain controllers (BDCs) have been replaced with the concept of multiple domain controllers that each contain a master read/write copy of domain information. Changes that are made on any domain controller within the environment are replicated to all other domain controllers in what is known as multi-master replication.
The global catalog is an index of the Active Directory database that contains a partial copy of its contents. All objects within the AD tree are referenced within the global catalog, which allows users to search for objects located in other domains. Not every attribute of each object is replicated to the global catalogs, only those attributes that are commonly used in search operations, such as first name, last name, and so on.
Global catalog servers, commonly referred to as GCs or GC/DCs, are Active Directory domain controllers that contain a copy of the global catalog. It is wise to either locate a minimum of one global catalog server in each physical location or utilize Global Catalog Caching in remote sites as the global catalog must be referenced often by clients and the traffic across slower WAN links would limit this traffic. In addition, technologies such as Microsoft Exchange Server need fast access to global catalog servers for all user transactions, making it very important to have a global catalog server nearby.
Often, a larger organization will employ the use of multiple domain controllers and multiple global catalog servers in each large location, which distributes load, provides redundancy, and locates resources where they are needed. Choosing the right blend of global catalog servers and domain controllers is vital to the proper functionality of your Active Directory environment.
Most domain controller functionality in Windows 2000 and Windows Server 2003 was designed to be distributed, multi-master-based. This effectively eliminated the single point of failure that was present with Windows NT PDCs. However, five functions still require the use of a single server because their functionality makes it impossible to follow a distributed approach. These Operations Master (OM, also known as Flexible Single Master Operations, or FSMO) roles are outlined as follows:
Schema master—. There is only one writable master copy of the AD schema in a single AD forest. It was deliberately designed this way to limit access to the schema and to minimize potential replication conflicts. There can be only one schema master in the entire Active Directory forest.
Domain naming master—. The domain naming master is responsible for the addition of domains into the Active Directory forest. This OM role must be placed on a global catalog server because it must have a record of all domains and objects to perform its function. There can be only one domain naming master in a forest.
PDC Emulator—. The PDC Emulator does exactly what its name implies: It handles down-level clients by performing functionality previously handled by the NT primary domain controller. This functionality is not necessary when operating in Windows 2000–or Windows Server 2003–only modes (native modes). It is important to note that if the server running the PDC Emulator goes down, any down-level clients will have trouble with domain functions (just as though an NT PDC went down). There is one PDC Emulator FSMO role per Active Directory domain.
RID master—. All objects within Active Directory that can be assigned permissions are uniquely identified through the use of a Security ID (SID). Each SID is composed of a domain SID, which is the same for each object in a single domain, and a Relative ID (RID), which is unique for each object within that domain. When assigning SIDs, a domain controller must be able to assign a corresponding RID from a pool that it obtains from the RID master. When that pool is exhausted, it requests another pool from the RID master. If the RID master is down, you may not be able to create new objects in your domain if a specific domain controller runs out of its allocated pool of RIDs. There is one RID master per Active Directory domain.
Infrastructure master—. The infrastructure master manages references to domain objects not within its own domain. In other words, a DC in one domain contains a list of all objects within its own domain, plus a list of references to other objects in other domains in the forest. If a referenced object changes, the infrastructure master handles this change. Because it deals with only referenced objects and not copies of the object itself, the infrastructure master must not reside on a global catalog server in multiple domain environments. The only exceptions to this are if every domain controller in your domain is a global catalog server or if you are in a single-domain environment. In the first case, there is no need to reference objects in other domains because full copies are available. In the second case, the infrastructure master role is not utilized because all copies of objects are local to the domain.
Transfer of an OM role to another domain controller, whether in a disaster recovery situation or simply for design purposes, is accomplished through two methods. The first involves using the Change Schema Master function of the Active Directory schema snap-in. In disaster recovery situations in which the schema master, domain naming master, or RID master has gone down and no backup is available, however, the OM roles can be seized through the use of a command-line tool called ntdsutil, shown in Figure 4.5. Keep in mind that you should use this utility only in emergency situations and should never bring the old OM server back online into the domain at risk of some serious system conflicts. Domain maintenance and recovery are covered in Chapters 22, “Windows Server 2003 Management and Maintenance Practices,” and 33, “Recovering from a Disaster.”
The trust structure that was developed in Windows 2000 and is subsequently used in Windows Server 2003 has been streamlined in comparison to the Windows NT trust structure. Windows NT trusts utilized individual, explicitly defined trusts for each organizational domain. This created an exponential trust relationship, which was difficult, to say the least, to manage. Windows 2000 took the trust relationship to a new level of functionality, with transitive trusts supplying automatic paths “up and down the tree.” These trusts are implicitly easier to understand and troubleshoot, and have greatly improved the manageability of Windows networks. In addition, Windows Server 2003 provides for additional functionality, such as cross-forest transitive trusts, which expands the capabilities of the NOS even further.
Two-way transitive trusts are automatically established upon the creation of a subdomain or with the addition of a domain tree into an Active Directory forest. Transitive trusts are normally two way, with each domain trusting the other domain. In other words, users in each domain can access resources such as printers or servers in the other domain if they are explicitly given rights in those domains. Bear in mind that just because two domains have a trust relationship does not mean that users from one domain can automatically access all the resources in the other domain; it is simply the first step in accessing those resources. The proper permissions still need to be applied.
Explicit trusts are those that are set up manually, similar to the way that Windows NT trusts were constructed. A trust may be set up to join two unrelated domain trees into the same forest, for example. Explicit trusts are one way, but two explicit trusts can be established to create a two-way trust. In Figure 4.6, an explicit trust has been established between the companyabc domain and the companyxyz domain to allow them to share cross-forest resources.
When an explicit trust is set up to expedite the flow of trusts from one subdomain to another, it is known as a shortcut trust. Shortcut trusts simply allow authentication verifications to be processed faster, as opposed to having to move up and down a domain tree. In Figure 4.7, while a transitive trust exists between the asia.companyabc.com and the europe.companyabc.com domains, a shortcut trust has been created to minimize authentication time for access between the two subdomains of this organization.
Another possible use for explicit trusts is to allow connectivity between an Active Directory forest and an external domain. These types of explicitly defined trusts are known as external trusts, and they allow different forests to share information without actually merging schema information or global catalogs.
Note
The capability to establish cross-forest trusts in Windows 2000 was limited to explicit trusts that were defined between each domain that needed access to a forest. Windows Server 2003 adds the capability to establish cross-forest transitive trusts, where the trust relationships flow through separate forests. This concept is explained in more detail in Chapter 5, “Designing a Windows Server 2003 Active Directory.”
As defined in the RFC for the LDAP standard, organizational units (OUs) are containers that logically store directory information and provide a method of addressing Active Directory through LDAP. In Active Directory, OUs are the primary method for organizing user, computer, and other object information into a more easily understandable layout. As shown in Figure 4.8, the organization has a root organizational unit where three nested organizational units (marketing, IT, and research) have been placed. This nesting enables the organization to distribute users across multiple containers for easier viewing and administration of network resources.
As you can see, OUs can be further subdivided into resource OUs for easy organization and delegation of administration. Far-flung offices could have their own OUs for local administration as well. It is important to understand, however, that an OU should be created typically when the organization has a specific need to delegate administration to another set of administrators. If the same person or group of people administer the entire domain, there is no need to increase the complexity of the environment by adding OUs. In fact, too many OUs can affect group policies, logons, and other factors. Chapter 6, “Designing Organizational Unit and Group Structure,” gives a detailed rundown of the design considerations encountered with organizational units.
As previously mentioned, some administrators tend to start applying the Active Directory domain structure to political boundaries within the organization. The dry-erase markers come out and very soon well-meaning managers get involved, organizing the Active Directory structure based on political boundaries. Subdomains start to become multiple layers deep, with each department taking its own subdomain. The problem with this strategy is that the Active Directory structure allows for this type of administrative granularity without division into multiple domains. In fact, the rule of thumb when designing domains is to start with a single domain and add additional domains only when necessary. In a nutshell, the type of administrative control required by many organizations can be realized by division of groups into separate organizational units rather than into separate domains.
OUs can therefore be structured to allow for separate departments to have various levels of administrative control over their own users. For example, a secretary in the Engineering department can be delegated control of resetting passwords for users within his own OU. Another advantage of OU use in these situations is that users can be easily dragged and dropped from one OU to another. For example, if users are moved from one department to another, moving them into their new department’s OU is extremely simple.
It is important to keep in mind that OU structure can be modified on the fly any time an administrator feels fit to make structural changes. This gives Active Directory the added advantage of being forgiving for OU design flaws because changes can be made at any time.
The AD group structure, although not new in Active Directory, provides an efficient mechanism for managing security on large numbers of users. Without groups to logically organize users, permissions on each object in a network would have to be set up manually on a per-user basis. This means that if an entire department needed access to a printer, each user would need to be manually entered into the permissions list of that printer. These tasks would make the administration of security daunting.
The concept of groups was therefore devised to ease administration. If a large department needed access to that same printer, the department’s group need only be supplied the necessary permissions. This greatly eases security-based administration and has the added advantage of providing for ease of transition if specific users leave the company or are transferred to a different department. For example, imagine an administrator in charge of printing and her user account is a member of a group named Printer Admins, which has full administrative privilege to the printers. Now, if this user transfers to become an email administrator, for example, reassigning permissions to a new print administrator is as simple as adding that new user to the Printer Admins group. This capability greatly simplifies these types of situations.
Groups in Active Directory work in the way that previous group structures, particularly in Windows NT, have worked, but with a few modifications to their design. Groups are divided into two categories: group type and group scope. There are two group types in Active Directory: security and distribution. Essentially, a security group can be used to apply permissions to objects for the members of the group. A distribution group, on the other hand, cannot be used for permissions but is used instead to send mail to members of the group. Group scope in Active Directory is likewise divided into several components, defined as follows:
Machine local groups—. Machine local groups, also known as simply “local groups,” previously existed in Windows NT 4.0 and can theoretically contain members from any trusted location. Users and groups in the local domain, as well as in other trusted domains and forests, can be included in this type of group. However, it is important to note that local groups allow resources to be accessed only on the machine where they are located, which greatly reduces their usability.
Domain local groups—. Domain local groups are essentially the same thing as local groups in Windows NT, and are used to administer resources located only on their own domain. They can contain users and groups from any other trusted domain but are available only in native Windows 2000 domains. Most typically, these types of groups are used to grant access to resources for groups in different domains.
Global groups—. Global groups are on the opposite side from domain local groups. They can contain users only in the domain in which they exist but are used to grant access to resources in other trusted domains. These types of groups are best used to supply security membership to user accounts that share a similar function, such as the sales global group.
Universal groups—. Universal groups can contain users and groups from any domain in the forest and can grant access to any resource in the forest. Along with this added power come a few caveats. First, universal groups are available only in Native mode domains. Second, all members of each universal group are stored in the global catalog, increasing the replication load. It is important to note, however, that universal group membership replication has been noticeably streamlined and optimized in Windows Server 2003 because the membership is incrementally replicated.
Whereas OUs are primarily used to segregate administrative function, groups are useful for logical organization of security functions. Translated, OUs are created if there is a need for a department or physical location to have some certain type of administrative control over its own environment. For example, an organization with offices in Japan could organize its Japanese users into a separate OU and give a local administrator password-change and account-creation privileges for that OU. Groups, however, can be used to organize users to more easily apply security permissions. For example, you can create a group named Japanese Office Users that contains all the users from the office in Japan. Security permissions can then be established on objects in Active Directory using that group. They could, for example, be given privileges to folders in the main corporate location, something that could not be done at the OU level.
To summarize, the basic differences between OUs and groups is that groups can be used when applying security to objects, whereas OUs exist when certain administrative functionality needs to be delegated. Chapter 6 gives a more thorough explanation of groups and OU design.
Replication in Active Directory is a critical function that is necessary to fulfill the functionality of a multimaster environment. The ability to make changes on any domain controller in a forest and then have those changes replicate to the other domain controllers is key. Consequently, a robust method of distributing this information was a major consideration for the development team at Microsoft. Active Directory replication is independent of the forest, tree, or domain structure, and it is this flexibility that is central to AD’s success.
For purposes of replication, Active Directory logically organizes groups of servers into a concept known as sites. Typically speaking, a single site should be composed of servers that are connected to each other via high-speed connections. The links that are established to connect two or more locations connected potentially through slower-speed connections are known as site links. Sites are created with site links connecting the locations together to enable the administrator to specify the bandwidth used to replicate information between sites.
Rather than having information replicated immediately between servers within a high-speed connected site, the administrator can specify to replicate information between two sites only once per night or at a time when network demands are low, allowing more bandwidth availability to replicate Active Directory information.
Servers that funnel intersite replication through themselves are known as site link bridgeheads. Figure 4.9 shows a potential Windows Server 2003 Active Directory site structure. Site links exist between offices, and a domain controller in each site acts as the site link bridgehead. The site structure is completely modifiable, and should roughly follow the WAN structure of an organization. By default, only a single site is created in Active Directory, and administrators must manually create additional sites to be able to optimize replication. More on these concepts can be found in Chapter 7, “Active Directory Infrastructure.”
Replication of objects between domain controllers is accomplished through the use of a property known as Originating Write. As changes are made to an object, this property is incrementally increased in value. A domain controller compares its own version of this value to the one received during a replication request. If it is lower, the change is applied; if not, it is discarded. This simplistic approach to replication is also extremely reliable and efficient and allows for effective object synchronization. For more information on replication, including a detailed analysis of Originating Writes and its other key components, refer to Chapter 7.
When Microsoft began development on Active Directory, full compatibility with the domain name system (DNS) was a critical priority. Active Directory was built from the ground up not just to be fully compatible with DNS but to be so integrated with it that one cannot exist without the other. Microsoft’s direction in this case did not just happen by chance, but because of the central role that DNS plays in Internet name resolution and Microsoft’s desire to make its product lines embrace the Internet.
While fully conforming to the standards established for DNS, Active Directory can expand upon the standard feature set of DNS and offer some new capabilities such as AD-Integrated DNS, which greatly eases the administration required for DNS environments. In addition, Active Directory can easily adapt to exist in a foreign DNS environment, such as Unix BIND, as long as the BIND version is 8.2.x or higher.
Given the importance of DNS in Windows Server 2003’s Active Directory, a thorough understanding of DNS is a must. Chapter 9, “The Domain Name System,” goes into greater detail on DNS in Windows Server 2003.
A DNS namespace, simply defined, is the bounded logical area formed by a DNS name and its subdomains. For example, europe.companyabc.com, asia.companyabc.com, and companyabc.com are all part of the same contiguous DNS namespace. A DNS namespace in Active Directory can be published on the Internet, such as microsoft.com or msn.com, or it can be hidden from public exposure, depending on the strategy and security needs of its implementers.
External (Published) Namespaces—. A DNS name that can be resolved from anywhere on the Internet is known as a published or external namespace. This type of namespace is common for organizations that want the full convenience of having their commonly used Internet domain name represent their Active Directory structure. While security becomes a larger issue for published Active Directory namespaces, the convenience of being able to access servers directly from the Internet makes this option a popular one for organizations. For example, an Exchange server running Outlook Web Access could be set up as mail. companyname.com and easily accessible from anywhere in the world. Users would more readily understand how to connect, and in these cases their email addresses would likely be [email protected]. This will not be the first time that the balancing act between greater security and convenience will arise during the design of a Windows Server 2003 deployment.
Internal (Hidden) Namespaces—. For many organizations, publication of their internal domain structure is too high a security risk, despite the advantages. These organizations can easily define their Active Directory with an internal namespace that is not readable from the Internet. For example, a company may have an external DNS namespace of cco.com but decide that its Active Directory structure will correspond to
cco.internalor any namespace it wants. Bear in mind that any combination will work for internal namespaces because there is no limitation on using .com, .net, .gov, and so on when dealing with a namespace that is not published. For all intents and purposes, you could name your domain cucamonga.funkychicken if you want. For practical reasons, however, the.internalnamespace has been specifically reserved for private name addressing, and using it is a best-practice approach in many cases.
Note
If you decide to use a domain namespace that theoretically could be bought and used on the Internet either now or in the future, it is wise to purchase the rights to that domain name to prevent potential conflicts with name resolution in the future. For example, if you choose the internal namespace companyabc.com, you may want to first verify that it is not taken and buy it if possible. If you find the domain name is already owned by another company, you may choose a different domain name for your Active Directory namespace. Even though your domain might not be published on the Internet, home or laptop users who need dial-in or VPN access to your domain may experience conflicts because they would be incorrectly routed to the wrong DNS name on the Internet instead of your company’s namespace.
Dynamic DNS (DDNS) was developed as an answer to the problem of DNS tables having to be manually updated when changes were made. DDNS in Windows Server 2003 automatically updates the DNS table based on registrations, and can work in conjunction with DHCP to automatically process DNS changes as clients are added and removed from the network infrastructure. DDNS is not required for Active Directory to function properly, but it makes administration much easier than previous manual methods.
Note
Although DDNS is fully supported by Windows Server 2003 and is typically enabled for all Windows Active Directory domain-to-domain name replication, DDNS is still sometimes not implemented at the enterprise level. Organizations with Unix-based DNS servers tend to manually or statically update DNS tables rather than dynamically update DNS tables. This is solely the choice of the DNS administrator in an organization to enable DDNS from Active Directory DNS to the enterprise DNS.
Standard DNS essentially stores all name records in a text file and keeps it updated via dynamic updates. If you are accustomed to using Unix BIND DNS or other standard forms of DNS, this is essentially what Standard DNS is in Windows Server 2003.
Active Directory expands upon other implementations of DNS by allowing administrators to integrate DNS into Active Directory. By doing this, the DNS zones themselves exist as objects in the Active Directory, which allows for automatic zone transfers to be accomplished. DNS replication traffic piggybacks off Active Directory traffic, and the DNS records are stored as objects in the directory. In Windows Server 2003’s implementation of Active Directory, AD-integrated DNS zones are optimized by being stored in the application partition, thus reducing replication traffic and improving performance. For more information on DNS, see Chapter 9.
Often, some local administrators may be hesitant to deploy Active Directory because of their desire to maintain their own foreign DNS implementation, usually Unix BIND. If this is the case, it is possible for Windows Server 2003 DNS to co-exist in this type of environment, as long as the DNS supports dynamic updates and SRV records (BIND 8.2.x or higher). These situations occur more often than not, as political situations within IT departments are often divided into pro-Microsoft and pro-Unix groups, each of which has its own ideology and plans. The ability of Windows Server 2003 to co-exist peacefully in these types of environments is therefore key. For a more detailed analysis of DNS in Windows Server 2003, see Chapter 9.
The security built around Active Directory and Windows Server 2003 was designed to protect valuable network assets and address many of the common security problems inherent in Windows NT 4.0. Windows Server 2003 expands on these security capabilities and was specifically designed to address issues such as the problems in Internet Information Server (IIS) that were exploited by viruses such as Code Red and Nimbda.
Development of Windows Server 2003 security has also been affected by the Trustworthy Computing initiative by Microsoft, which changed the primary focus of Microsoft products to security. In a nutshell, Microsoft is more focused than ever before on the security of its products, and all new features must pass a security litmus test before they can be released. This initiative has affected the development of Windows Server 2003 and is evident in the security features.
Kerberos was originally designed at M.I.T. as a secure method of authenticating users without actually sending a user password across the network, encrypted or not. Being able to send a password this way greatly reduces the threat of password theft because malicious users are no longer able to seize a copy of the password as it crosses the network and run brute-force attacks on the information to decrypt it.
The actual functionality of Kerberos is complicated, but essentially what happens is the computer sends an information packet to the client that requires authentication. This packet contains a “riddle” of sorts that can be answered only by the user’s proper credentials. The user applies the “answer” to the riddle and sends it back to the server. If the proper password was applied to the answer, the user is authenticated. Although used in Windows Server 2003, this form of authentication is not proprietary to Microsoft, and is available as an Internet standard. For a greater understanding of Kerberos security, see Chapter 12, “Server-Level Security.”
One of the chief criticisms of Microsoft’s Internet Information Server and Microsoft products in general, for that matter, is a lack of security built into the products, both right out of the box and during standard operations. Components of IIS, especially Index Server, have proven to be vulnerable to virus and hack techniques such as those demonstrated by the infamous Code Red and Nimbda viruses. For these reasons, Microsoft disabled the Internet Information Server component in Windows Server 2003 by default. In addition, even when it is turned on, certain risky HTML verbs and other types of commonly used IIS exploit commands are disabled.
Active Directory implementations are, in essence, as secure as the Windows Server 2003 environment in which they run. The security of the Active Directory structure can be increased through the utilization of additional security precautions, such as secured server-to-server communications using IPSec or the use of smart cards or other encryption techniques. In addition, the user environment can be secured through the use of group policies that can set parameter changes such as user password restrictions, domain security, and logon access privileges.
Improvements in the functionality and reliability of Active Directory are of key importance to the development team at Microsoft. It is therefore no small surprise that Windows Server 2003 introduces improvements in Active Directory. From the ability to rename Active Directory domains to improvements in replication compression, the changes made to the structure of Active Directory warrant a closer look.
Windows Server 2003 Active Directory Domain Rename Tool—. A promised feature of Active Directory that has been eagerly awaited is the ability to prune, splice, and rename Active Directory domains. Given the nature of corporate America, with restructuring, acquisitions, and name changes occurring constantly, the ability of Active Directory to be flexible in naming and structure is of utmost importance. The Active Directory rename tool was devised to address this very need.
Before Active Directory domains can be renamed, several key prerequisites must be in place before the domain structure can be modified. First, and probably the most important, all domain controllers in the entire forest must be upgraded to Windows Server 2003 in advance. In addition, the domains and the forest must be upgraded to Windows Server 2003-functional level. Finally, comprehensive backups of the environment should be performed before undertaking the rename.
The domain rename process is complex and should never be considered as routine. After the process, each domain controller must be rebooted and each member computer across the entire forest must also be rebooted (twice). For a greater understanding of the domain rename tool and process, see Chapter 5.
Improvements in the Configure Your Server Wizard—. The Configure Your Server (CYS) Wizard, introduced with Windows 2000 Server, has been vastly improved. If you were used to disabling this wizard in Windows 2000, you may think again in Windows Server 2003 because the wizard can be very helpful in configuring your server for the role that it will play, shutting off services that are not necessary and configuring ones that are needed. There are now options to configure a server as a Terminal server, as well as Routing and Remote Access Server (RRAS) configurations.
Cross-Forest Transitive Trust Capabilities—. Windows Server 2003 Active Directory introduced the capability to establish cross-forest transitive trusts between two disparate Active Directory forests. This capability allows two companies to share resources more easily, without actually merging the forests. Note that both forests must be running at Windows Server 2003 functional levels for the transitive portion of this trust to function properly. Forests in mixed mode can use the older, nontransitive explicit trust capability.
Active Directory Replication Compression Disable Support—. By default, all replication traffic between domain controllers in Active Directory is compressed to reduce network traffic. However, this compression can have the undesired effect of slowing down processor performance on the domain controllers. In Windows Server 2003 Active Directory, you have the option of turning off this functionality, disabling compression and saving processor cycles. This would normally be an option only for organizations with very fast connections between all their domain controllers.
Schema Attribute Deactivation—. Developers who write applications for Active Directory can take heart in the fact that Windows Server 2003’s Active Directory implementation offers the ability to deactivate schema attributes, allowing custombuilt applications to utilize custom attributes without fear of conflict. In addition, attributes can be deactivated to reduce replication traffic.
Incremental Universal Group Membership Replication—. Windows 2000 previously had a major drawback in the use of universal groups. Membership in those groups was stored in a single, multivalued attribute in Active Directory. Essentially, what this meant was that any changes to membership in a universal group required a complete re-replication of all membership. In other words, if you had a universal group with 5,000 users, adding number 5,001 would require a major replication effort because all 5,001 users would be re-replicated across the forest. Windows Server 2003 simplifies this process and allows for incremental replication of universal group membership. In essence, only the 5,001st member is replicated in Windows Server 2003.
One additional function of Windows Server 2003 is the Active Directory in Application Mode (ADAM) product. AD was given the capability to run separate instances of itself as unique services. Active Directory in Application Mode allows specialized applications to utilize ADAM as their own directory service, negating the need for a new form of directory service for every critical application within an organization.
ADAM uses the same replication engine as Active Directory, follows the same X.500 structure, and is close enough to real AD functionality to allow it to be installed as a testbed for developers who design AD applications. Despite the similarities, however, ADAM runs as a separate service from the operating system, with its own schema and structure.
The real value to an ADAM implementation comes from its capability to utilize the security structure of the production domain(s), while maintaining its own directory structure. In fact, an instance of ADAM can run as a service on a Windows Server 2003 member server or even a Windows XP Professional workstation in a Windows NT domain. The ADAM would then utilize NT domain accounts for its own security.
ADAM functionality was developed in direct response to one of the main limitations in using Microsoft’s Active Directory: the fact that the directory was so intrinsically tied to the NOS that applications which did not require the extra NOS-related functionality of AD were restricted in their particular directory needs. ADAM allows each application to have its own separate AD directory forest and allows for personalized modification of the directory, such as schema extensions, tailored replication (or lack of replication) needs, and other key directory needs.
One of the major advantages to ADAM also lies in the fact that multiple instances of ADAM can run on a single machine, each with its own unique name, port number, and separate binaries. In addition, ADAM can run on any version of Windows Server 2003 or even on Windows XP Professional for development purposes. Each instance of ADAM can utilize a separate, tailored schema.
ADAM is virtually indistinguishable from a normal NOS instance of Active Directory and consequently can be administered using the standard tools used for AD, such as ADSIEdit, LDP.exe, and the Microsoft Management Console (MMC) tools. In addition, user accounts can be created, unique replication topologies created, and all normal AD functionality can be performed on a tailored copy of an AD forest.
In short, ADAM provides applications with the advantages of the Active Directory environment, but without the NOS limitations that previously forced the implementation of multiple, cost-ineffective directories. Developers now can exploit the full functionality of Windows Server 2003’s Active Directory without limitation, while at the same time assuming the numerous advantages of integration into a common security structure.
In addition to the changes listed in the preceding sections, Active Directory in Windows Server 2003 supports the following new features:
AD-Integrated DNS Zones in Application Partitions—. DNS zones that are Active Directory integrated are now stored in the application partition. This basically means that fewer objects need to be stored in AD, reducing replication concerns with DNS.
AD Lingering Objects Removal—. Objects listed in Active Directory that no longer exist can now be easily removed in Windows Server 2003.
AD Administration Enhancements—. Administrative tools have been enhanced in Windows Server 2003 to facilitate common tasks such as working with ACLs, finding objects, and selecting multiple OUs for tasks.
When Microsoft developed Windows Server 2003, the need arose for a common framework to tie in the various applications and frameworks. The success of Active Directory with Windows 2000 supplied Microsoft with the medium into that common framework. Along with the addition of new capabilities such as domain rename and other enhancements, Active Directory builds on its “road worthiness” and the real-world experience it gained with Windows 2000 to bring a robust, secure environment for networking services and functionality.
Design domains sparingly: Don’t necessarily set up multiple domains for different remote offices or sites.
Purchase any external domain namespaces that theoretically could be bought and used on the Internet.
Strongly consider using Dynamic DNS in an AD environment.
Consider using cross-forest transitive trusts between two disparate Active Directory forests when merging the forests is not an option.
Place the infrastructure master role on a domain controller that isn’t also a global catalog unless all domain controllers in the domain are global catalog servers or you are in a single domain environment.
Use the
ntdsutilcommand-line utility to transfer OM roles in disaster recovery situations.Use global groups to contain users in the domain in which they exist but also to grant access to resources in other trusted domains.
Use universal groups to contain users from any domain in the forest and to grant access to any resource in the forest.