Figure 4.7 NDS and other hierarchical directory services consist of objects arranged in a tree structure.
A directory service is a database of user accounts and other information that network administrators use to control access to shared network resources. When users connect to a network, they have to be authenticated before they can access network resources. Authentication is the process of checking the user's credentials (usually a user name and a password) against the directory. Users that supply the proper credentials are permitted access according to the permissions specified by the network administrator.
As explained in Lesson 1: Network Communications, in Chapter 1, "Networking Basics," on a peer-to-peer network, each computer maintains its own user accounts and security settings, while client/server networks rely on a centralized security database or directory service. Directory services range from simple flat file databases containing a list of accounts to complex hierarchical databases that store information about a network's many different resources: hardware, software, and human.
Flat file directory services are suitable for relatively small installations, but for large enterprise networks, they are difficult to maintain. For this reason, both Novell and Microsoft have developed hierarchical directory services that can support networks of virtually any size, and that have the fault tolerance and security capabilities needed for large installations.
The bindery—included in all versions of NetWare up to and including 3.2—is a simple database that contains a list of user and group accounts, information about those accounts, and little else. The bindery even stretches the definition of a directory service, since it is not a centralized storehouse of information for an entire network. Every NetWare bindery server maintains its own list of accounts, which it uses to authenticate users trying to access its resources. If network users need to access files or printers on more than one NetWare server, they must have an account on each server, and each server performs its own user authentication.
In the early days of NetWare, LANs were relatively small and users generally required access to only one or two servers, so the bindery was all they needed. In fact, there is still a substantial user base of NetWare shops that don't feel the need for an enterprise directory service like NDS, which is why there is a bindery-based version of NetWare (version 3.2) still on the market, years after the release of the newer NDS versions.
NetWare 4.0, released in 1993, was the first version to include NDS, which at that time stood for NetWare Directory Services, but is now Novell Directory Services. NDS was the first hierarchical directory service to be a commercial success, and in the years since its initial release, it has matured into a robust enterprise network solution.
A hierarchical directory service is composed of objects, which are arranged in tree-like structure, much like a directory tree (see Figure 4.7). There are two basic kinds of objects, called containers and leaves. Containers are the equivalent of directories in a file system; they hold other objects. Leaves represent network resources, such as users, groups, computers, and applications. All objects are composed of attributes (which NDS calls properties), the nature of which depend on the object's type. For example, the properties of a user object can specify the user's name, password, telephone number, e-mail address, and other pertinent information.
The types of objects that you can create in the NDS tree, and the properties of those object types are determined by the directory schema. Network applications can modify the schema to create their own specialized object types or to add new properties to existing object types. This makes the directory service a flexible tool for application developers. For example, a network backup program can create an object type used to represent a job queue, which contains backup jobs waiting to be executed.
Deploying the directory service is a matter of designing and building an NDS tree, which involves the creation of a hierarchy of containers into which administrators put the various leaf objects. The tree design can be based on the geographical layout of the network, with containers representing buildings, floors, and rooms, or it can be based on the structure of the organization using the network, with containers representing divisions, departments, and workgroups. An NDS tree can also use a combination of the two, or any other organizational paradigm the administrator chooses. The important part of the design process is grouping together users with similar network access requirements, to simplify the process of assigning them permissions. Like a file system, permissions flow down through the NDS tree and are inherited by the objects beneath. Granting a container object permission to access a particular resource means that all of the objects in that container receive the same permission.
Unlike the NetWare bindery, which is server-specific, there is usually only one NDS database for the entire network. When a user logs in, he or she logs into NDS, not into a specific server, and one authentication can grant the user access to resources located anywhere on the network. This means that administrators need only create and maintain one account for each user, instead of one for each server the user accesses, as in bindery-based NetWare.
Because the entire NetWare network relies on NDS, the directory is designed with features that ensure its availability at all times. You can split the NDS database into partitions, which are stored on different servers, to make it easy for a user to log in using a nearby server. In addition, you can create replicas of the partitions, and store those on different servers as well. This way, if a server containing all or part of the NDS tree should fail, users can still access the directory from another server.
Windows NT uses a directory service that is more capable and more complex than the NetWare bindery, but is still not suitable for a large enterprise network. Windows NT networks are organized into domains, which contain accounts that represent the users, groups, and computers on the network. A domain is a flat file database like a bindery, but it is not server-specific. The domain directory is stored on Windows NT servers that have been designated as domain controllers during the operating system installation.
A server can be a Primary Domain Controller (PDC) or a Backup Domain Controller (BDC). Most domains have at least two domain controllers, for fault tolerance purposes. Each domain has one PDC, which contains the main copy of the domain directory, and can have any number of BDCs, each of which contains a replica of the domain. Whenever network administrators modify the directory by adding, deleting, or modifying accounts, they are making changes to the files on the PDC, which holds the master copy of the data. At periodic intervals, the PDC replicates the directory database to the BDCs (as shown in Figure 4.8), which keeps them updated with the latest information. This process is called single master replication.
It's common for larger Windows NT networks to have multiple domains, and the domains can communicate with each other. To have this happen, administrators must create trust relationships between the domains, using a utility called the Server Manager. Trust relationships operate in one direction only. If Domain A trusts Domain B, users from Domain B can access resources in Domain A (assuming they have the appropriate permissions). In order for Domain A users to access Domain B resources, an administrator must create a trust running in that direction.
Because you have to create trust relationships manually, managing a large enterprise Windows NT network with many domains can be labor intensive. Users that have to access resources in multiple domains must have a separate account in each domain, just as users of bindery-based NetWare need a separate account on each server.
Run the c04dem01, c04dem02, c04dem03, c04dem04, and c04dem05 videos located in the Demos folder on the CD-ROM accompanying this book for a demonstration of Windows NT domains.
After many years of anticipation, Microsoft introduced an enterprise directory service in the Windows 2000 Server product line, called Active Directory. This directory service is similar in structure to NDS, in that it uses a hierarchical tree design comprised of container and leaf objects. The fundamental unit of organization in Active Directory directory service is still the domain, but now you can group domains together into a tree, and even group multiple trees together into a forest. Domains that are in the same tree automatically have bidirectional trust relationships established between them, which eliminates the need for administrators to create them manually. The trust relationships are also transitive, meaning that if Domain A trusts Domain B and Domain B trusts Domain C, then Domain A trusts Domain C.
In Windows NT, the domain structure is completely separate from the concept of DNS domains, but in Active Directory architecture, the two are more similar. Domains in the same tree are named using multiword domain names (as in DNS), which reflect the tree structure of the directory. If the root domain in a tree is called abccorp.com, the other domains beneath the root would have names like sales.abccorp.com and engineering.abccorp.com.
Active Directory architecture still uses domain controllers like Windows NT, but you have a great deal more flexibility in their configuration. In Windows 2000, you can promote any server to a domain controller at any time or demote it back to a standard server, using a Windows wizard. In addition, there are no more PDCs and BDCs; all domain controllers on an Active Directory network function as peers. Administrators can make changes to the Active Directory data on any domain controller, and the servers propagate those changes to the other domain controllers throughout the network, as shown in Figure 4.9. This is called multiple master replication.
With these features, Active Directory can support networks of virtually any size, including corporate networks with sites located anywhere in the world. You can configure the replication of data between domain controllers to occur only at specific times (in order to minimize the traffic on expensive WAN links), create a directory hierarchy that reflects the locations of the branch offices, and even create links between separate trees or forests built by different companies, in the event of a merger.
