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 who 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, whereas 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 have the fault tolerance and security capabilities needed for large installations.
The bindery—included in all versions of NetWare up to and including version 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, as it is not a centralized storehouse of information for anentire 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 the final bindery-based version of NetWare (version 3.2) was only removed from the market in late 2000, seven years after the first release of the NDS version of NetWare.
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 DirectoryServices. NDS was the first hierarchical directory service to be a commercial success. 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 a treelike structure, much like a directory tree (see Figure 4.7). There are two basic kinds of objects: 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 depends 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.
Figure 4.7 NDS and other hierarchical directory services consist of objects arranged in a tree structure
The basic components of the hierarchical directory services in NetWare and Windows 2000, such as the use of objects and attributes, containers and leaves, and the tree structure, are derived from the X.500 directory service standard, which was developed by the International Telecommunications Union (ITU) and the International Organization for Standardization (ISO). X.500 is not a commercial directory services product. Rather, it is a model for a global directory that is designed to enable users to search for people and objects by providing an object naming standard and a hierarchical tree structure.
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 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 a list of backup jobs waiting to be executed as one of its properties.
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 on, he or she logs on to NDS, not 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 on using a nearby server. In addition, you can create replicas of the partitions and store those on different servers as well. In this way, if a server containing all or part of the NDS tree fails, 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 it 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 Windows NT domain is not the same as an Internet domain (such as those used by the DNS). Windows NT domains are named using a single word, whereas DNS domains have names that are at least two words long and are separated by periods (such as microsoft.com). Be sure not to confuse the two.
A server can be a Primary Domain Controller (PDC) or a Backup DomainController (BDC). Most domains have at least two domain controllers for fault-tolerance purposes. Each domain has one (and only one) PDC, which contains the main copy of the domain directory. Domains 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.
Figure 4.8 Single master replication: Windows NT domain controllers keep their information updated by replicating in one direction, from the PDC to the BDCs
You can only designate a Windows NT server as a domain controller during the installation of the operating system. Once Windows NT is installed, you can promote a BDC to a PDC or demote a PDC to a BDC, but you can't convert a regular server into a domain controller, nor can you convert a domain controller into a regular server.
It's common for larger Windows NT networks to have multiple domains that can communicate with each other. For this to occur, administrators must create trust relationships between the domains, using a utility called the User Manager for Domains. 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). 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 who 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.
After years of anticipation, Microsoft introduced an enterprise directory service in the Windows 2000 Server product line called the Active Directory service. 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 oforganization in Active Directory is still the domain, but now you can groupdomains 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, eliminating the need for administrators to create them manually. The trust relationships are also transitive, meaning that ifDomain 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 the Active Directory architecture, the two are more similar. Domains in the same tree are named using multiword domain names (just as in DNS) that 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.
The 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 the Dcpromo 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 calledmultiple master replication.
With these features, Active Directory can support networks of virtually any size, including corporate networks with sites located across in the world. You canconfigure the replication of data between domain controllers to occur only at specific times (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.
Figure 4.9 The Active Directory architecture uses multiple master replication to keep all its domain controllers updated
Match the directory service concepts in the left column with the correct descriptions in the right column.
| || |