NET 121b: Essentials of Networking

Chapter 16: Directory Services


This chapter discusses network directory services. The topics of this chapter are:

  1. Directory Services Methods in Windows
  2. Active Directory
  3. Domains in an NT System
  4. NDS and eDirectory

A server on a network provides the users and administrators with access to two types of things: resources and services. A resource is a physical entity on the network, like a printer, a hard drive, or a file. A service is a method or mechanism for getting to the resource. Directory Services is a database system for keeping track of resources, users, and other objects on the network. Administrators use it to manage these resources. One aspect of such management is security: allowing or restricting access to various resources in the network.

Each object in a Directory Services database is a collection of information about a resource, like a database record. Within those records are the object's properties, which are like fields (attributes) in a database. Actual values for those properties may be required or optional, and this varies by the type of object.

Directory Services Methods in Windows

Windows networks accept the concept that we do not always need a complex network, nor do we always need Directory Services. A simpler method is to use workgroups. A Windows workgroup is like a collection of peers. In a workgroup, each computer participates in the management of its own resources. Each computer has its own security database, called the Security Accounts Manager (SAM) database. In a small network, this may be sufficient. However, it means that each user who needs to access resources must be given rights to those resources with an ID, a password, and an assignment of rights in the SAM on each machine that has such resources. This also means that each user must log in to each device holding a resource that user needs.

Microsoft advises that a workgroup should be no larger than ten network users. If the list of users is longer than ten, it is too cumbersome to maintain the overhead needed to manage the network.

Workstations and servers can both be made members of a workgroup. If a Windows 2000 or 2003 server is made part of a workgroup, it can be called a standalone server. This is not intuitive. The phrase means that the server has the same network behavior as a workstation in the workgroup.

Windows networks are more typically organized into domains. A Windows 2000 or 2003 server in a domain can hold a copy of a centralized database that offers directory services. The database is called Active Directory, and a server that holds a copy of it is a domain controller.

A domain controller manages user authentication with the Active Directory database. Windows 2000 servers and Windows Server 2003 servers that are part of a domain but that do not hold a copy of Active Directory, are not domain controllers. They are simply member servers. A workstation that is part of a domain is called a domain member.

A network that is otherwise using Active Directory may have some Windows NT servers in it. A Windows NT server cannot store a copy of Active Directory, but it can store a less active version of it. An NT domain may be considered a less relational directory than a Windows 2000 directory. Windows NT networks used domains, but not Active Directory. If you have an Active Directory network that still includes Windows NT servers, those NT servers can perform user authentication, but they cannot hold copies of Active Directory.

To make things more interesting, workstations and servers in a domain can allow users to share their resources through permissions given to the users' domain accounts, which are stored in Active Directory, but they are not limited to doing so. Users may also be given local accounts to workstations and servers, which allow an administrator to grant permissions directly to users who log on to those computers with those accounts. For instance, I have permissions that are based on my job function, and are assigned to my domain account. I am granted those permissions when I log on to the domain I use. I also have permission to perform specific functions on some servers, but I do not gain those permissions until I log in to the specific servers with my local account on each of those servers.

It is important to know that servers, workstations, and users may all join domains.

The text continues discussing common features of directory services, using Windows Active Directory as an example. Authentication is the process of proving identity to the network, usually by logging in with a user ID and a password. Authorization is the process of giving or refusing rights and permissions to users.

Group policies are rules that can be set in Active Directory to apply to groups of computers or groups of users. A group policy might be used to install software the next time someone logs in on a workstation that needs such software. Another policy may be used to inventory a computer based on the ID of the user logging in. A common use of a group policy is to perform a virus scan of the local hard drive on a regular basis.

Active Directory

The text lists several features of Active Directory that have already been discussed. New items include the term multi-master replication. As noted above, any server that holds a copy of the Active Directory is a domain controller. Assume that we have one domain. This means that each of our domain controllers holds an identical copy of the Active Directory. Storing data on more than one server is a classic method of providing fault tolerance, the capacity to survive the loss of a device.

Changes to the domain, like adding or removing a user, may be done from any copy because each is considered to be a master copy, and they are all replicas of each other. The text tells us that if a change is made to the copy of Active Directory on a server, that server will wait 15 seconds before announcing the change to the first other server holding a copy. If more than one other server holds a copy of the same Active Directory, then the other servers receive announcements at three second intervals. Actual replication takes place according to a schedule discussed below.

Objects in Active Directory are essentially records in a relational database. Like database records, they have properties/attributes that vary from one type of object to another. Some properties are required to be filled in when the object is created, while others are optional, and may be filled in later.

Objects are named following the rules of DNS (Domain Name Service), so higher level objects have shorter names. This naming standard is common for devices accessed across the Internet. For example, the Baker UNIX server that we use for many classes is called Crux. It exists in the domain, so its name is when written out completely. Domains can have child domains, so if Crux were moved to a UNIX subdomain, its name might become, assuming that the new subdomain is a child of In the same way, domain object names begin with the object, and continue with a series of container up to the domain. For example, if I were a user called Bill Smith in the state of Michigan domain, my object name might be, where the first label is my user name, the next stands for state of Michigan, the next for Active Directory, and the rest refer to an Internet domain assigned to the state of Michigan.

The text discusses the schema used in Active Directory. A schema is not unique to Active Directory, it is part of any Directory Services implementation. A schema is the set of rules for what kind of objects may exist and what properties those objects may have in your database. Since the schema is also part of Active Directory, it may be changed in Active Directory and the changes will be replicated to all domain controllers in your domain.

Logical Structures

Active Directory, like other Directory Services implementations, allows administrators to organize it with logical structures. Organizational Units, often called OUs, are used for this purpose. An administrator might make Organizational Units for each geographic location in a company, or for each functional division of a company, in order to store objects that fall into such categories in OUs created for that purpose. This makes an OU act as a natural group. The text explains that one reason to create OUs is to delegate responsibility for managing them. Often, users are widely separated by geography. It makes sense for people who are located close to users to manage some of the services those users need, such as printing and password resets.

The next concept discusses trees and forests. Although Microsoft recommends using a single domain for all designs, you may find instances in which it makes sense to have multiple domains. For example, when two companies merge, they would have separate domains that need to be associated. Two or more associated domains may be combined into a tree. A tree is a hierarchical model, showing domains arranged in a series of parent-child relationships. Creating this relationship from one domain to another creates a two-way transitive trust. That means that users and servers in one domain can find and be given rights to use resources in another domain.

To understand the difference between a tree and a forest, you need to understand another concept. Domains in a tree share a naming structure. According to Microsoft: "When multiple domains are connected by trust relationships and share a common schema, configuration, and global catalog, they constitute a domain tree. Multiple domain trees can be connected together to create a forest." This means that domains that are not all that similar can be joined in a forest. When they share the required similarities, they can be part of the same tree. Unfortunately, even if you have only one tree, it is still correct to describe it as a forest, so the distinction is less clear than it might be.

We have not discussed the global catalog. Think of a global catalog as the part of Active Directory that users use the most, without the parts they seldom use, and with indexes added for quicker searching. The text tells us that the first domain controller in a forest root (top of the forest hierarchy) is automatically a global catalog server. Other domain controllers may be made global catalog servers as needed. A global catalog server should be a server that is connected to other domain controllers by wide bandwidth, dependable connections. Windows Server 2003 allows for domain controllers at remote, poorly connected sites to query global catalog servers when needed. The service that allows this is called universal group caching.

Users access Active Directory with Lightweight Directory Access Protocol (LDAP). Objects in Active Directory, as noted above, are named by DNS standards. They are named with what are called distinguished and relative distinguished names, according to Microsoft standards.

More on Object Naming

A distinguished name starts with the object in question, then names its parent object, then that object's parent, and all other parents, up to and including the domain containing all those objects. In Active Directory, the parts of object names are qualified with a prefix and an equal sign, and are separated by commas. For example, a distinguished name for a user starts with that user's object, then its parent OU, then any other parents, then the subdomain and domain they are all in. It might look like this: CN=JoeSmith, OU=Students, DC=Baker, DC=Edu. CN stands for Common Name, OU stands for Organizational Unit, and DC stands for Domain Content, not Domain Controller. The Domain Content information is split into two parts, the subdomain followed by the top level domain.

In Microsoft terms, the relative distinguished name of an object is just the part of the distinguished name that represents the object itself. For the user described in the paragraph above, his relative distinguished name is his common name: CN=JoeSmith. (Note: Novell defines this term differently.)

A network using Active Directory should be designed with some physical characteristics as guidelines. Domain controllers must be able to communicate as needed to accommodate replication messages, but they must be located near the users who need them for authentication and access to resources. If your network includes relatively slow WAN links, you should put a domain controller on each side of each WAN link. Since replication must still take place, administrators can schedule such events with objects called site links. A site is operationally defined as one or more subnets sharing high speed connections. Sites that are connected by slow links need to be configured for scheduled replication updates. As noted above, a domain controller will notify other domain controllers sharing its replica that changes have been made. The first replica is notified after fifteen seconds, and other replicas are notified at three second intervals. The default schedule is to send replication data every three hours. This time can be changed in appropriate site link objects.

Windows Server 2003 Features

Windows Server 2003 updates Active Directory with tools and features that improve on earlier versions

  • Domains can be renamed in DNS and in NetBIOS.
  • The migration tool allows passwords to be retained for users migrated from earlier versions.
  • Schemas may be edited by deactivating class definitions and attributes. (A class is the definition of a type of object.)
  • Cross-forest trusts may be created to allow access to objects in different forests.
  • Credential Manager can be used to cache credentials of users after they authenticate to the system once for each resource requiring authentication. This can allow them to access those resources afterward without separate authentication.
  • Software Restriction Policies allow an administrator to forbid or allow specific software to run on a domain workstation.
  • Active Directory can have application directory partitions. They hold only the Active Directory information needed by users who run specific applications.
  • Replicas may be created from backup media when adding a new domain controller, minimizing the need to copy data from another server.
Windows NT Domains

The text discusses differences between NT domains and 2000/2003 domains.

  • Windows NT uses one server as the Primary Domain Controller (PDC), and one or more as Backup Domain Controllers (BDCs). In the 2000/2003 domains discussed above, all domain controllers have equal status.
  • Windows NT domains store user accounts and security information in a Security Accounts Manager (SAM) database, like the one on individual servers in workgroups. A master copy of this SAM is kept on the PDC and replicas are kept on the BDCs. In Windows 2000/2003 domains, the user accounts and security information is kept in Active Directory.
  • Windows NT domains can have different kinds of trust relationships.
    • In a one-way trust, one domain is called the trusting domain, and the other called the trusted domain. Users and groups in the trusted domain can be assigned rights to resources in the trusting domain. No rights are assigned automatically.
    • In a two-way trust, there are two one-way trusts. This classes each of the domains as the trusting domain in one trust, and the trusted domain in the other trust.
  • Windows NT domains can follow several models:
    • Single domain - one PDC and any number of BDCs
    • Master domain - One domain is set up to provide authentication services, and other domains are set up to provide specific users and groups access to resources. One-way trusts exist from the master domain to the resource domains.
    • Multiple master domain - like the master domain model above, but using more master domains for larger numbers of users
    • Complete trust model - Multiple domains can serve as masters and as resource domains. Trust relationships may be two-way trusts.
Novell Directory Services

Novell Directory Services (NDS) was added to Novell networks with NetWare 4. In NetWare 5, it was renamed eDirectory. It is a relational database that provides directory services, much the same way that Active Directory provides directory services to Microsoft networks.

NDS keeps track of resources on the net as objects. Each object in NDS is a collection of information about that resource, like a database record. Within those records are the object's properties, which are like fields (attributes) in a database. Actual values for those properties may be required or optional, and this varies by the type of object. For instance, a User object must be given a value for its User Name property and its Last Name property when it is created. Values for other properties, while useful, are optional.

Two types of objects exist in the Directory: containers and leaves. Think about it the way you think about file directories in DOS or Windows. Containers are like DOS directories, in that they contain other objects to organize them. Leaves are objects that are usually resources, and they do not contain other objects. Remember the root of a DOS directory? NDS has one too, but we call it the [Root]. The [Root] is unique in an NDS tree. It cannot be moved or renamed. Your book calls the [Root] a third class of object, but it is really just a special container.

Common containers come in three types: Country, Organization, and Organizational Unit. To simplify things, Novell recommends that we do not use Country containers. It is best to start a Directory tree with an Organization that is a child of [Root]. An Organization may be placed in a Country container, or directly in the [Root], but a Country may only be placed in the [Root] object. Organizational Units may be placed in an Organization or in other Organizational Units.

Naming objects in an NDS tree is a bit different from a Windows domain. A distinguished name specifies the name of an object, and the name of the container that object exists in, and the name of the container the container exists in, all the way up to, but not including the [Root]. Each name in a distinguished name is preceded by a dot (period). For example:
could represent a User named VScott, in the container Computer, which is in the container Baker. This is a typeless distinguished name. To be more clear and more precise, we might use a typeful distinguished name: .CN=VScott.OU=Computer.O=Baker
It is the same, except that we have explicitly stated the type of each object, where CN stands for Common Name, which is simply the name a leaf object is given when it is created, OU stands for Organizational Unit, and O stands for Organization. (If we had used a Country in the tree, we would have included .C=US, or something like it.)

A relative distinguished name in NDS (or eDirectory) specifies the path from an object back to a specified point in the tree, not necessarily up to the [Root]. To understand why we would want such a thing, you need to understand a context. A current context is a specific container, the one we are concerned with at any given time. It is analogous to the concept of a current directory in DOS and Windows. Relative distinguished names do not start with periods, but do use them as separators, as above. This way it is easy for the software that uses them to tell the difference. A relative distinguished name tells us everything we need to know to locate an object, based on our current frame of reference. In NDS, the object's common name is its relative distinguished name, if and only if our frame of reference is the container that the object is in. If our current context is some other container, a relative distinguished name is longer.

A Novell bindery is discussed at the end of the chapter. Novell used bindery services for each server in their networks before NDS was created. A bindery was a flat file database, limited to listing the resources on a given server, and used to manage the rights of users to those resources. A bindery was made of three files: NET$OBJ.SYS, NET$PROP.SYS, and NET$VAL.SYS. Users who needed access to resources managed by a bindery needed to have IDs created in that bindery, and had to log on to that server to access them.