Windows 2000 Active Directory Review

In November 1996, Microsoft delivered the first preview of Active Directory for developers at the Professional Developers Conference held in Long Beach, California. At the time, it was merely the directory service that was shipped with Windows NT 5.0, and the preview included many other Windows NT 5.0 features. Many changes have taken place since then. For one, Windows NT 5.0 was renamed Windows 2000, and then it was officially released to the public in February 2000, over three years after its original preview to developers. The change of the name from Windows NT 5.0 to Windows 2000 was a surface change only. Windows 2000 inherits the NT technology legacy from previous versions.

Test Day Tip 

Although we spend several pages here presenting (and reviewing) Active Directory, don't get "wrapped around the axle" about the nitty-gritty of Active Directory. This exam is focused on working with security in Windows 2000, and for that you must know Active Directory. Don't worry about being asked very specific questions dealing with the ins and outs of Active Directory; that is the realm of the 70-217 exam.

Introduction to Directory Services

It would be tough to claim that Active Directory is the first directory service ever created. In fact, directory services have been available in a variety of network operating systems (NOSs). Novell's NetWare has used the Novell Directory Service (NDS) for quite some time now. Directory services are used primarily for organizing, locating, and managing network information.

People use directory services without even knowing they are doing so. Because it is used to translate server names to Internet Protocol (IP) addresses, the Domain Name System (DNS) is the most widely used directory service in the world. DNS is rather "usage specific," meaning that it organizes only a limited amount of information about network hosts. DNS stores data about servers, their IP addresses, and services that they offer to the network. Although this is pretty much the extent of DNS, other directory services do not have the same limitations. A directory service can organize all sorts of information about a network. Usually, this information falls into the following categories:

• Network resources  Servers, printers, and other devices on a network.

• Network services  Capabilities on the network such as file storage, printing, and e-mail.

• Network users and groups  Identifiers for users on a network and for groups of users.

As you can see, a directory service organizes the pieces of a network, enabling a way to create relationships between the pieces. The relationships between these pieces are what make the directory service so powerful. For example, in DNS, a DNS client computer can query a DNS server to find out the IP address of a server that it wants to contact. The DNS server receives a hostname query and returns the IP address in short order. More complex relationships can be created in more complex directory services, such as providing access to network resources and services for users who log on as well as providing a controlled security framework for the entire network.

History of the Windows Directory Service

In the not-too-distant past, networks were server centric. Each server had its own security system, which consisted of user accounts, group accounts, and network resources. The server would associate those user accounts to the files, directories, printers, and other services or resources that it had to offer. These associations had a value such that one person could have more access to one network resource than another person, simply due to the rights assigned to user and group accounts. In a way, this server-centric system was one of the first directory services, but one for which the scope existed only on a single server.

Networks first popped up in the military as a method to share data quickly across great distances. They offered a major advantage in times of war. Money was one of the main reasons that networking became prevalent in businesses. Hard drives were extremely expensive, as were printers. Many of the first corporate networks sprang up out of a need to share printers and precious hard-drive space among multiple computers. Soon, these servers' hard drives filled up. They ran out of printer ports. At some point, another server would be added to the network to allow further storage of shared files or to add new printers.

Once an administrator established a server to share files and printers, the administrator was faced with an issue-how to protect sensitive files and printers from unauthorized users while allowing use of the remaining files and printers. In some cases, the administrator wanted to allow some users limited access to a file or a printer. Access rights were added to the system, and users were given specific logon IDs. The server could then easily share files and printers with the correct users, depending on the administrator's configuration.

When a network contained more than one server, administration became difficult. If a user needed to access files or printers residing on two or more servers, that user needed to know how to access each specific server. In addition, the user needed a separate logon ID and password for each server. Some administrators used naming conventions to ensure that a user did not need to have more than one unique logon ID.

Sometimes a network had multiple administrators with different naming conventions, providing users with two or more unique logon IDs. For administrators, it was difficult to keep passwords synchronized, since each server might have a different timing mechanism to enforce password changes. For users, the end result in a multiserver environment was a convoluted and difficult process of remembering the location of resources, remembering the correct logon ID, and remembering the correct current password-all merely to be able to access resources on the network.

Network operating systems soon developed a variety of ways to use a single logon ID and password to access multiple servers. For example, Microsoft Windows NT used a domain architecture. An NT domain is a group of Windows NT servers that participate in a single security system listing users, groups, and network resources. It consists of a primary domain controller (PDC), any number of backup domain controllers (BDCs), and any number of member servers and client computers.

The PDC is the security manager of the domain. BDCs maintain a read-only copy of the security database, and the PDC remains the single point of change control. Member servers and client computers contact the domain controller (DC) to access network resources. Because of their membership, a PDC or a BDC in the domain can use the security database to authenticate users to access resources. A member server can use the security database by querying a PDC or BDC. The basic Windows NT domain model is shown in Figure 1.1.

Figure 1.1: A Basic Windows NT Domain

The Windows NT domain was a security boundary, which means that if you needed to separate one security set from another, you needed to have more than one domain. Using trust relationships, you could have multiple domains. A trust relationship is established between two domains. In order to enable users of domain A to access the resources such as the files and printers of domain B, domain B must trust domain A. Drawn in a diagram, this trust relationship is shown as an arrow pointing from the trusting domain to the trusted domain. Microsoft defined various models for a multiple domain structure using Windows NT:

• Master Domain model  All resource domains trust a single Master Domain that contains all user accounts. This scenario is depicted in Figure 1.2.

Figure 1.2: A Multimaster Windows NT Domain

• Multiple Master Domain model  All resource domains trust all Master Domains. Master Domains contain user accounts. Each Master Domain trusts all other Master Domains.

• Single Domain model  There is only a single domain that contains all users and resources. There is no trust relationship with other domains.

• Complete Trust model  All domains trust each other, regardless of whether they contain users, resources, or both.

Windows NT domains contain the rudimentary elements of a directory service. They enable multiple servers to look up information and use it for authenticating users and granting those users access to network resources. Although a domain is effective as a security model for a small or medium-sized organization, it does not have some of the features that a directory service can offer.

An NT domain structure is flat rather than hierarchical like most directory services, which means security cannot be applied at different levels. Since each domain is its own administrative area, the only way to implement distributed administration is to have multiple domains. Legacy NT domains require a significant amount of traffic between clients and the PDC or a BDC. These domains also require the security database to be copied from a PDC to the BDCs on a periodic basis.

This traffic overhead is undesirable over wide area network (WAN) links that might have a limited amount of bandwidth available or that are costly to transmit traffic across. To reduce this overhead, multiple domains can be created such that no domain spans a WAN link. Trust relationships between multiple domains become cumbersome as more domains are added. As a result, trade-offs can be made between WAN performance or administrative needs and domain structures.

The directory services architecture of Windows 2000 was redesigned from the ground up to eliminate the limitations and difficulties found in the Windows NT directory services implementation. Use of the X.500 standard as the basis of Active Directory and implementation of the Lightweight Directory Access Protocol (LDAP) not only ensures that Windows 2000 Active Directory is more robust and user friendly but that it also uses existing and well-known standards that allow it to interact with other directory services and a variety of applications.

Comparing Active Directory to the Windows NT implementation of directory services, it is easy to see that Active Directory offers fully distributed administration via an efficient database that is distributed throughout the network to prevent WAN overhead issues. Let's examine Active Directory in more detail now so we can get a better idea of how it works to not only make using Windows 2000 easier but also to make Windows more secure.

Active Directory Architecture

Active Directory is not automatically part of the Windows 2000 Server installation process, although the capability is available should you need it. When a Windows 2000 Server (any version) is installed as a new install, by default it becomes a member server of a workgroup or domain. (Upgrades are handled differently if a Windows NT PDC or BDC is being upgraded to Windows 2000. In the case of upgrades of an NT PDC or BDC, the installer is prompted to upgrade the domain to Active Directory. If that did not occur, all information from the former domain would be lost.)

Member servers use a security architecture identical to that of the Windows 2000 Professional client workstations, in which they have a flat file local database with a set of local users and groups. This does not allow other servers or workstations to share in that security database. In fact, it hearkens back to the days of a server-centric network. The flat file database allows local users and groups, as well as shared local files and printers, in a server-centric model. Only when a member server or client workstation joins an Active Directory domain can it participate in Active Directory. When a client workstation or member server joins a domain, that server-centric local database remains. However, if a member server is upgraded to a DC, the local database is removed.

When a Windows 2000 server joins an Active Directory domain as a member server, it can communicate with any DC for Active Directory security information. Domains are configured as top-level containers in a tree structure that is created through trust relationships and that uses DNS naming.

Domains sharing a contiguous DNS namespace are organized into domain trees. In a contiguous namespace, the domains are linked via the DNS names. For example, a domain named open.com and its subdomain named way.open.com are part of the same contiguous namespace. However, a domain named closed.com is not part of that contiguous namespace and, in fact, forms the basis for another domain tree. There can be multiple domains in Active Directory, either with or without contiguous namespaces. Multiple domains with different namespaces that participate in a single Active Directory commonly are considered a forest of multiple domain trees, as depicted in Figure 1.3. However, it is important to note that a domain on its own can be its own forest.

Figure 1.3: The Windows 2000 Active Directory Domain Model with Forests, Trees, and Organizational Units

Exam Warning 

Bear in mind that although Windows 2000 Active Directory uses the standard DNS namespace, the top-level domain is ignored. In the case of our example domain open.com and its child domain way.open.com, both part of one contiguous namespace. The top-level domain, .com in this case, is ignored by Active Directory due to the way that Microsoft has implemented DNS in Active Directory. The top level of the domain (and the domain name) in this case would be open.

Internal to each domain, Active Directory provides Organizational Units (OUs) to create a tree structure. The OU tree is unique to each domain and completely configurable by an administrator. Within the OU containers, Active Directory enables the administrator to create objects that represent user accounts, network services, and resources such as users, groups, workstations, and printers. The result is a logical structure that can be scaled to any enterprise of any size and organizational formation.

Security is of great concern to companies that connect their private networks to the Internet or to external partners using an extranet solution. The hierarchical structure in Active Directory is a perfect basis for a flexible security service. Active Directory can secure objects using services such as Public Key Infrastructure (PKI) and can even extend to smartcard technologies. The security protocol named after the dog that guards the gates to Hades in Greek mythology, Kerberos, is used for trust relationships and is the default authentication protocol in Active Directory. LDAP can be used over Secure Sockets Layer (SSL), which extends Active Directory security into the Internet.

Some of these types of services integrate as objects, such as PKI certificates, in the authentication process using smartcard technologies and in extended properties of account objects so that they can support extra security requirements. In addition, you can find extensive security administration capabilities in Group Policies implemented within Active Directory.

The Active Directory architecture enables it to become the central authority for authentication and access control to the entire network and even the Internet. Before we move into the topic of using Active Directory to control security in our network, we first need to delve a little deeper into the basics of Active Directory, examining the logical and physical structures of Active Directory as well as the basic Active Directory objects.

The X.500 Directory Standard

Many directory services state that they are X.500 compliant. X.500 is a directory service standard ratified by the International Telecommunications Union (ITU-T) in 1988 and modified in 1993 and 1997. It was intended to provide a means to develop an easy-to-use electronic directory of people that would be available to all Internet users.

The X.500 directory standard specifies a common root of a hierarchical tree. Contrary to its name, the root of the tree is depicted at the top level, and all other containers (which are used to create "branches") are below it. There are several types of containers with a specific naming convention. In this naming convention, each portion of a name is specified by the abbreviation of the object type or container it represents. A user has a CN= before the username to represent its "Common Name," a C= precedes a country, and an organization is heralded by an O=. Compared to DNS domain names-for example, host.subdomain.domain-the X.500 version of CN=host/C=US/O=Org appears excessively complicated.

Each X.500 local directory is considered a Directory System Agent (DSA). The DSA can represent either single or multiple organizations. Each DSA connects to the others through a Directory Information Tree (DIT), which is a hierarchical naming scheme that provides the naming context for objects within the directory.

Although Active Directory is derived from the X.500 model, Active Directory does not implement all the X.500 protocols because of the excess overhead involved or the lack of their general usage. Some of the protocols that are not included are:

• Directory Access Protocol (DAP)

• Directory Information Shadowing Protocol (DISP)

• Directory Operational Binding Management Protocol (DOP)

• Directory System Protocol (DSP)

Active Directory does implement LDAP, which affords an effective combination of DAP and DSP features without involving any excess overhead.

The Logical Structure of Active Directory

As we've already briefly outlined, you know that the logical structure of Active Directory works similarly to that of the DNS model. A forest is established that forms the organizational boundary. Within that forest, you can then create and populate trees with domains and subdomains. These domains and subdomains then can be populated with OUs and objects. Additionally, Active Directory's content is controlled by the schema and advertised by the Global Catalog. Let's take a few minutes to examine each of these logical components in more detail.

Forests

A forest is a set of domain trees that share a common schema, configuration, and Global Catalog. The forest usually is referred to by the name of its root domain. It exists as a set of domain trees that trust each other via transitive and hierarchical trust relationships using the default Kerberos security trust model automatically implemented by Active Directory. Figure 1.3 depicts a forest consisting of the open.com and closed.com domain trees. The forest root is the name of the first domain created in it. So if in the example of Figure 1.3 the open.com domain was created first, it would lend its name to the forest as well.

Trees

A tree is a hierarchical organization of containers and objects. The tree is similar to the entire file system on a computer's hard drive. The tree has multiple branches created with nested containers. Nested containers are similar to folders in the file system. The ends of each branch are objects that represent users, services, and resources. These objects are analogous to the files inside containers. The domain tree is a group of contiguous domains that share a common schema and configuration and are united by trust relationships to create a single namespace. Active Directory can contain one or more trees, which can be depicted via their trust relationships or via their namespace. The open.com tree shown in Figure 1.3 consists of three domains, all of which share the common namespace open.com.

Domains

A domain is a group of Windows 2000 computers that participate in the same security subtree. Active Directory consists of one or more domains. Each domain can span both local area network (LAN) and WAN links, depending on the network design and subsequent domain implementation. Multiple domains can exist on the same LAN. When there are multiple domains using different namespaces in Active Directory, it is considered to be a forest of domain trees. This forest must enclose domains that share a common schema and configuration. They produce a GC of users, services, and resources.

Schema

The schema defines the types of objects that can be stored in a specific Active Directory. For example, an extremely simple schema might define three object classes as a server, an OU, and a user. Each of these object classes would have attributes such as the server IP address, the OU name, and the user e-mail address. When an actual server, OU, and user object are created, those attributes are given values. The value for the server IP address attribute might be 10.10.10.5, the value for the OU name attribute might be HQ, and the value for the user e-mail address attribute might be [e-mail]. This concept is summarized in Table 1.1.

Table 1.1: Schema Objects, Attributes, and Values

Object Class	Object	Attribute	Value
Server	Server.open.com	IP address	10.10.10.5
Organizational Unit	CN=HQ	Name	HQ
User	USER	E-mail address	[e-mail]

The Active Directory schema can be extended to include additional objects. For example, a backup program that is written to take advantage of Active Directory could add an object class for the backup service and add an attribute to the server object class to enable it as a backup service provider or a backup service requester. The schema must be updated across all the DCs that contain a replica of Active Directory in order for those objects and properties to be recognized and administered from any point in the network.

The Active Directory schema is stored within the directory itself. This reduces the overhead involved with users or applications that run queries on the Active Directory. It also allows the schema to extend dynamically, with immediate access to the new object classes and attributes. The ability to perform schema extensions is protected by access control lists (ACLs) so that only authorized users can extend the schema.

Global Catalog

The Global Catalog (GC) is a listing, or index, of the objects within Active Directory. As an index, the Global Catalog does not contain every value for every property of an object. It contains only enough information to find the object and perhaps a few oft-queried property values.

For example, if all the users in a network query the Active Directory to find their colleagues' telephone extensions, the value of the phone extension property can be placed in the GC to enable quick access to that information. When a property value is not in the GC, there is enough information about the object to locate a replica of the Active Directory partition, which contains the object, without the querying user or application needing to know the location of that object within the Active Directory hierarchy. Of course, the user or application needs to know one or more attributes of the desired object to perform the query.

Organizational Units

OUs are used to organize objects, such as users or computers, into a location for the easier assignment of permissions and privileges. In the Windows NT domain model, this was typically domain with resource domains, which meant the complex establishment of trusts and security between domains. Using OUs does away with all the complex management issues found when using resource domains. Simply place all objects that need the same permission set into an OU and then apply the permissions directly to the OU itself.

OUs make it easy to apply hierarchical security as well, because configurations are inherited by child objects from their parent object. An important fact to consider is that OUs are the smallest items that can receive Group Policy configuration settings. You can further divide objects using groups, but you cannot apply Group Policy to groups, hence you cannot apply enterprise security settings to groups. Figure 1.4 shows how you could divide the closed.com domain into OUs, each for a specific group of objects.

Figure 1.4: Using Organizational Units to Simplify Management

Groups

Groups exist by default on all Windows 2000 installations and are the smallest objects that you can use to apply permission settings to more than one object at a time. You can place user objects, computer objects, and even other group objects inside a group and apply permissions to that group. Groups are typically placed inside OUs so that they can inherit the Group Policy settings.

Figure 1.5 shows the use of groups in one of the OUs in the closed.com domain. Each group contains specific objects that require different security permissions from the other groups.

Figure 1.5: Using Groups to Assign Specific Permissions

Head of the Class…
Active Directory: It's Just a Big Database

So far in your reading of this chapter, the concept of Active Directory and how it works to keep all parts of a Windows 2000 domain running smoothly might seem a bit overwhelming. Despite all its power, Active Directory is still just a database, much like any other database that you have used in the past.

The differences between the Active Directory database and that database you have at home for your disco record collection is that the Active Directory database is very scalable, is easily configurable via a graphical user interface (GUI) front end, and supports simultaneous access and updating over multiple logical and physical locations. Can your disco record database do all that?

One of the other very important differences between Active Directory and a typical database is that different levels of control can be assigned to various users, such as allowing the help desk the ability to reset user passwords. This feature is called delegation, and Active Directory makes it easy for you to delegate almost any common administrative function to a nonadministrative user. For an example of how this works, check out the article Create a Password Administrator with the Delegation of Control Wizard at https://www.techrepublic.com/article.jhtml?id=t01320020319WCS01.htm.

The Physical Structure of Active Directory

Armed with your knowledge of the logical structure of Active Directory, you can now start to put some of this information to work looking at Active Directory's physical structure. Things such as sites, DCs, servers, and workstations come into play here; they define the part of Active Directory (and Windows 2000) that you can easily observe without any trouble.

Sites

Think of a site as a geographically based location for servers. The official definition of a site is one or more IP subnets that share a fast and reliable connection. It is recommended that a site consist of links with greater than 512 Kbps of available bandwidth. Available bandwidth is the amount of bandwidth that is not being used by other network traffic. If a link exists for a T-1 line of 1.54 Mbps, it would appear that it has more than enough bandwidth to meet this recommendation. However, if that T-1 line is saturated with network traffic, it will not be sufficient.

You can configure sites any way you want. If you add IP subnets to one site, you can still move them to their own site later. The nice thing about sites is that they grow and change to match your physical network. Site definition is vague enough to allow a site to encompass WAN links; however, a site is best configured as one that contains only LAN connections that are less likely to become saturated with network traffic. The servers that are placed in a single site are configured automatically for replication to each other. If those servers are connected only with high-speed reliable links, the replication traffic can take advantage of the physical network.

Authentication traffic also takes advantage of site configuration. When a user logs on to Active Directory, the workstation tries to locate servers in the same site as the user first, then tries other servers in other sites. The local site is determined by the IP subnet in which the workstation exists. It looks up a server that is in a site that contains that IP subnet in order to log on. Taking advantage of a physically close server and a fast connection makes the user perceive higher performance from the network.

Domain Controllers

A domain controller is the computer (or computers) in a Windows 2000 Active Directory network responsible for managing user access to that network, including logging on, authenticating, and controlling access to network resources. The domain model in Windows NT had one PDC and one or more BDCs, where the PDC was the only DC with a writable copy of the domain database. In Windows 2000 this model is broken because all DCs have a writable copy of the database, and thus all DCs can make changes to this database. In this way, it would seem that all Windows 2000 DCs are created equal, but this is not entirely the case.

The first DC in an organization is automatically assigned the role of the Global Catalog server and the following five other Operations Master roles:

• PDC emulator

• Schema master

• Domain-naming master

• Relative identifier (RID) master

• Infrastructure master

These five roles can be reassigned later as more DCs are added, creating a powerful and robust DC arrangement.

Servers and Workstations

Computer objects are perhaps the most physical items in the entire domain. Users interact with servers and workstations all day, every day. Servers and workstations form the end point in your domain structure.

Objects: The Heart of It All

An object is a representation of a user, resource, or service within the Active Directory database. Each object is described by a set of properties, or attributes. Each property has a corresponding value. An object typically appears as an icon in a management console, and when you right-click it, you can look at the values of its properties. Some objects do not appear in the various management consoles, because they are not intended to be managed. The basic objects consist of the following:

• Computers

• Users

• Groups

• Shares

• Printers

Of these objects, we have already examined computers and groups; they rightfully appear in more than one part of the Active Directory implementation. Computers are objects in Active Directory and are part of the physical organization of Active Directory. Groups, on the other hand, while objects, are part of the logical organization of Active Directory-the "how it gets organized and implemented" end of business. Users, shares, and printers, on the other hand, are strictly objects and do not really fall into either of the two previously mentioned categories.

Users are the crux of the network. The network exists to serve users' needs, and this service is achieved in a variety of ways, depending on exactly what is needed by whom and where it is needed. Shares and printers, as well as computers, are objects provided to users to enable them to produce a valuable output. Each of these objects can have permissions applied to it, specifying who has what rights to that object. This is a basic part of the Windows 2000 security model.

Containers: Odd Men Out

A container is an object in the directory that simply contains other objects. Containers are similar to folders in a file system. Container objects can contain other containers in the same way that a file system folder can contain other folders. A container does not represent any user, service, or resource, but it does have its own attributes and values. Instead, a container is what shapes Active Directory into a tree structure. Both domains and OUs are examples of containers.

Note 

For more information Active Directory, consider the following resources:

• Managing Active Directory for Windows 2000 Server, Syngress Publishing (ISBN: 1-928994-07-5)

• Active Directory Overview, www.microsoft.com/windows2000/ server/evaluation/features/ dirlist.asp

• Active Directory Service Overview, www.microsoft.com/windows2000/ server/evaluation/ business/addatasheet.asp

• Active Directory Design, www.microsoft.com/TechNet/prodtechnol/ windows2000serv/training/ w2khost/w2ktad.asp

In Active Directory, containers are not security principals. You cannot apply rights to the containers and have those rights flow through to the objects contained within them. Users of Novell Directory Services consider this a limitation to Active Directory, since Novell Directory Services can be configured this way. If you want to have the same functionality with Active Directory, you can mirror the OUs with groups, placing all OU objects within those groups and nesting the groups. It takes some considered planning, especially to ensure that your rights inheritance mirrors your OUs, but the same result can be obtained.

Exam Warning 

This exam expects you to have a very solid understanding of Active Directory and Group Policy. This might come as a surprise to many readers, since this understanding is not listed in the exam objectives, but in reality, it is perquisite knowledge for the topics that are covered on this exam. Just the same way IP subnetting never shows up on a Microsoft exam outline but always manages to show up on a test, Active Directory and Group Policy are pivotal to your success on this exam.