This lesson surveys the basic properties of Windows 2000 Active Directory. You'll see how Active Directory affects migration from Windows NT, and you'll also see how it can potentially remove several limitations of the Windows NT architecture.
After this lesson, you will be able to
Estimated lesson time: 20 minutes
Active Directory makes possible the scalability of Windows 2000 across the enterprise. It describes how objects such as users and computers within Windows 2000 are located and accessed.
You can think of any operating system as a collection of administrative services, each of which is doing something for its customers. To work, each service will need to store and retrieve information. For instance, the security service will need to store and retrieve user information, the e-mail service will need to store and retrieve e-mail addresses, and the printing service will need to manage the details of the installed printers.
If any of the above services are Active Directory–aware, then Active Directory can enable these services to access the information they need from a central location to perform their functions. Active Directory is also extensible, in that the schema, which describes the objects that can be stored in Active Directory, can be updated to add new object types.
Active Directory wasn't designed solely to manage a network of Windows 2000 systems. It's intended to be the basis of an enterprise-wide directory that can index any kind of information and be used by applications such as Microsoft Exchange Server 2000 to provide more integrated services to users.
As you have read in Chapter 1, an organizational unit (OU) is a Windows 2000 container into which you can put such objects as users, groups, shared folders, printers, computers, and other OUs. An OU can be assigned DACLs and group policies that allow specified users and groups to manage it. These management properties are automatically passed down a subtree of OUs, making it possible to delegate control of lower OUs to others and build a management hierarchy tailored to the domain.
Also, within a given OU, you can set highly specific policies to define the users' authority with respect to object attributes. For example, you can allow a user to change the listed corporate telephone extension number but not to perform any other management tasks such as changing the listed descriptions of users or changing user passwords.
Just as with Windows NT domains, the arrangement of Active Directory domains and OUs doesn't need to follow the physical locations of the systems. This concept will be further explored in the next lesson, which deals with sites.
In the domain shown in Figure 5.3, a hierarchy of OU containers has been set up. At the top is the Europe OU. Suppose an employee named Rima has been put in charge of administering the users in Europe and has created two more OUs, Publicity and Market Research. She can then delegate the management of these OUs to managers in those departments. In turn, the manager of the Publicity OU has decided to delegate management further by creating the TV and Press OUs, which will be managed by administrators selected from those departments.
Figure 5.3 Organizational units in a domain
Note that although Rima has delegated authority so others can perform system management functions, Rima still has authority at all levels in the hierarchy below her. Similarly, the manager of the Publicity OU has authority over the TV and Press OUs but not the Europe OU which is shown above Rima's OU.
An Active Directory namespace is a region within which a particular set of object names become meaningful. The total Active Directory namespace is partitioned into domains. To make it possible to find objects across domain boundaries, a global catalog is held on designated servers. The global catalog server contains
The word domain can mean "a security environment within a Windows NT configuration" or it can mean "a partition in the Active Directory namespace." When expressing these concepts, be sure to make clear which of these definitions you're using. In the next paragraph domain is used in a third way, as in the Domain Name System.
Unlike Windows NT domains, which are flat (in other words, every name exists at the same level as any other), the Active Directory names are hierarchical. This means that instead of having three flat domains called MANAGEMENT, PAYROLL, and FINANCE, now you can have hierarchical domains, such as management, payroll.management, and finance.management. If these domain names look a bit like the names that are used to refer to objects on the Internet, it's because Active Directory uses the Internet's Domain Name System (DNS) standard to identify its objects.
Active Directory conforms to the X.500 directory model and uses the Lightweight Directory Access Protocol (LDAP) as its main communications protocol. The TCP/IP protocol standards is now a crucial component of Windows 2000. In addition, the way machines on the network are named is now aligned to the location of resources and the hierarchy of their management.
A set of items in Active Directory that share the same namespace is called a tree. For example, the user objects chester.payroll.management and rima.sales.management are in the same tree. This tree has the root management and everything else grows from that. However, chester.payroll.production can't be in the same tree because this root is production. In Active Directory, a collection of one or more trees are generically known as a forest. You can link forests by setting up explicit trust relationships between any two domains in the two forests. Forests and trees will be discussed in detail later in this lesson.
A domain in an Active Directory namespace contains a number of objects. An object is an identified collection of attributes with a name and a type. There are many types (or classes) in Windows; a good example is the user type. The user type has a number of attributes such as full name, description, e-mail address, and department. Container objects are those that hold references to other objects. An example of a container object is an OU or a local group. Figure 5.4 shows five of the default container objects in an Active Directory domain.
Figure 5.4 Active Directory domain and default container objects
These are the five container objects shown in Figure 5.4:
When a Windows NT domain is migrated to Windows 2000 Active Directory, the information in the Windows NT domain is moved to the appropriate objects in these containers.
Active Directory enhances the original concept of Windows NT trusts. Trusts are authenticated by the Kerberos protocol, a widely used standard for validation and authentication. Furthermore, in Active Directory, Kerberos trusts are automatic, transitive, and two-way. In other words, if A trusts B and B trusts C, B now trusts A and A trusts C. You can think of this as the "one big happy family" effect—everyone trusts everyone else. In Windows 2000 this happens automatically, in that the position of a domain in the tree determines the trust relationships in force; for example, in Figure 5.5, adding the payroll.admin.microsoft.com domain "beneath" the admin.microsoft.com domain determines the trust path that will be taken through servers to authenticate access to resources.
Figure 5.5 A simple domain tree
Remember that trust in this context means is aware of. Every domain in a forest is aware of every other, but the requests for access must follow the trust path to the authenticating domain. For example, in Figure 5.5, an attempt by a user in payroll.admin.microsoft.com to access a resource in sales.microsoft.com would result in a request being sent to admin.microsoft.com followed by a request to microsoft.com, and then finally by a request to sales.microsoft.com.
Traversing a long trust path can slow down the authentication of access to resources. Therefore, you should minimize the domain depth (the number of levels of hierarchy between domains) wherever possible in your design. When you cannot minimize the depth of the domain structure, Windows 2000 enables you to set up shortcut trust relationships (sometimes called cross-link trusts) directly between domains. In Figure 5.5, if users in the finance.admin.microsoft.com domain need to frequently access resources in the sales.microsoft domain, you could create a one-way shortcut trust between them to improve authentication performance.
You can link domains in separate forests by manually creating two one-way, nontransitive trusts. In Figure 5.6, the domains of microsoft.com and msn.com have been joined by two one-way trusts. This allows requests to move from one domain into the other, but not down either tree.
In these examples, the domain names microsoft.com and msn.com are being used to avoid using names that might be registered to other individuals or organizations.
Figure 5.6 Trust relationships between domain in two forests
You can create trust relationships between domains in a tree and external domains. The external domain can be a Windows NT domain or another Windows 2000 forest. This type of trust provides a way to limit the visibility of resources beyond those you're actually making available.
You can use such trust relationships during the migration to allow users in a new pristine forest to access resources in the domain from which they've been migrated. In this situation, you would set up an explicit one-way trust from the source domain into the destination.
In this lesson, you reviewed the basics of Active Directory and how the Windows 2000 model transforms the Windows NT one-way, non-transitive trust model to automatically create two-way transitive trusts between domains. You also learned about the three kinds of trusts: Windows NT one-way trusts, which can also be used to link a Windows NT network to Windows 2000; Windows 2000 automatic (two-way transitive) trusts; and Windows 2000 manually created trusts (shortcut trusts) that aid with faster authentication processes. A fourth type of trust to consider in heterogeneous environments is a non-Windows Kerberos realm trust between a Windows 2000 domain and a non-Windows environment such as UNIX.