The Evolving World of Network Directory Services

50-80-20

DATA COMMUNICATIONS MANAGEMENT THE EVOLVING WORLD OF NETWORK DIRECTORY SERVICES

Gilbert Held

INSIDE Single Point of Administration; Fault Tolerant Operations; Customization Capability; Enhanced Security; Novell’s NDS; Objects and Object Management; Distributed Database Operations; Novell Directory Access Protocol; Schema; Supporting Services; Support for Windows NT

Until recently, the use of network directory service was limited to facili- tating ﬁle and print service operations. As networks grew in complexity, it was realized that the role of a network directory service could be ex- panded to enhance user operations by providing access to other objects within a network, such as different applications, workgroups, and even other uses. Recognizing the need to expand and enhance their network directory services, Novell and Microsoft have introduced a series of products over the past few years that considerably facilitated access to network resources. Novell was ﬁrst to the market, introducing its Novell Directory Service (NDS) with NetWare 4.0 several years ago. Since then, Novell has upgraded the capabilities of its NDS through a series of new versions of their directory service, while Microsoft, until recently, was lit- erally left in the dust with an eventually obsolete directory structure based on the relationship between domains in an NT network. With the pending release of Windows NT 5.0, Microsoft is back in the network directory services competition. Its Ac- PAYOFF IDEA Network directory services are rapidly becoming tive Directory is quite similar to NDS a key and integral part of an overall network man- with respect to supporting a hierar- agement, administration, and security plan. Nov- chical inverted tree structure, and its ell has been providing NDS, its directory service, new product can be expected to sat- for a few years, and the much-anticipated release isfy a large number of Windows NT of Microsoft’s Active Directory will bring Mi- crosoft into the game. This article provides an accounts that were quite vocal in overview of services provided by a network direc- asking for an enhanced directory ser- tory service and then compares and contrasts vice capability. NDS and Active Directory.

This article examines the evolving world of network directory services, focusing attention on Novell’s NDS and Microsoft’s Active Directory. To provide maximum benefit, one should first review the rationale for using a directory service and some of the key functions this service can be expected to perform. Since NDS predates Microsoft’s Active Directory, attention is focused first on NDS. Once this is accomplished, one can compare and contrast some of the key features of each network directory service. Thus, in addition to making readers aware of the characteristics of a network directory service and its utilization, this article will also ac- quaint readers with the functionality of NDS and Active Directory as well as the similarities and differences associated with these network directory services.

DIRECTORY SERVICE OVERVIEW As briefly mentioned at beginning of this article, a network directory service provides access to various objects associated with a network. Those objects can represent file and print resources, applications, workgroups, database servers, and even other users. A network directory service is organized in a hierarchical design that appears to resemble an inverted tree. That tree has its root at the top of the structure and consists of branches that can represent objects that are located on other networks around the globe. To facilitate the management of objects, a directory service provides a mechanism to group related objects into a higher level structure in a manner similar to leaves falling under a tree branch. In an NDS environment, a group of objects can be placed into an organizational unit in a manner similar to the cre- ation of an organizational chart. Each object in a network directory is associated with specific information that defines its availability for utilization, access constraints, and various operational parameters. Because the network directory service can consist of tens of thousands to millions of objects, its ability to operate effectively and efficiently depends on its elements being organized in some manner that facilitates its use. This organization is accomplished by the directory service organizing each object and its associated elements into a database. To facilitate the use of a network directory service, it needs to be able to respond to the fact that different organizations have different organizational structures. Thus, both NDS and Active Directory include the ability to customize their directory service to the differing structures associated with commercial organizations, academia, and government agencies.

FEATURES Exhibit 1 lists the key features associated with the use of a network directory service. To obtain an appreciation of the value of each feature,

EXHIBIT 1 — Key Features of a Network Directory Service

• Single point of log-on • Single point of administration • Fault tolerant operations • Customization capability this article brieﬂy examines each in the order they are presented in the table.

Single Log-on A network directory service permits users to log into the network once using a single password. This action applies to every location on the network which results in each user, regardless of physical location, having a consistent network view of available resources. Once access to the network is gained, access requests to each object are checked against a database of permissions. To ensure that users requesting access to an object are who they claim to be, an authentication scheme is used to verify the identity of each network user. Through the ability to log into a network once to gain access to all au- thorized resources, employee productivity can be considerably enhanced. In addition, the hierarchical structure of a network directory service in which elements of objects can be located along an inverted tree structure reduces the effect of queries and operations on other network traffic. For example, a user might be able to drill down to locate a network resource by browsing elements in the hierarchical database structure used by a network directory service without affecting traffic flowing between another user and a network object.

Single Point of Administration An enterprise network manager or administrator will greatly appreciate the fact that a directory-enabled network provides a single point of administration for the entire enterprise. In doing so, the use of a network directory service eliminates the need for redundant administration-related operations. This in turn reduces the total cost of managing and maintaining a comprehensive network that, for some enterprises, can span the globe.

Fault Tolerant Operations Recognizing the fact that the support of a single-point log-on and a single point of administration can be risky if such functions are performed by devices devoted to each function, a network directory service includes a degree of redundancy. To provide redundancy, the database that con- tains information on each object is distributed and replicated across the network. This provides a fault tolerant operational capability.

Customization Capability The heart of a network directory service is the directory tree. The structure of that tree, as well as its ability to define its use to include specify- ing objects that can be defined and attributes that can be associated with different objects, is governed by the directory schema. That schema defines a set of rules that govern the set-up and modification of the structure of the tree and its elements. Depending on the capability of the schema, one more than likely can move objects to different locations on the tree to optimize network performance, define different object attributes as user requirements change, and even add functionality to the network by adding such objects as access servers and fax servers to the directory tree. Because of the ability to customize a network directory, this feature also facilitates network administration as well as provides a more responsive capability to satisfy end-user networking requirements.

Enhanced Security A network directory service includes a series of rules that deﬁnes how the administration process occurs. These rules can deﬁne how users are requested to use the network, how they gain access to different objects, whether or not they can inherit certain permissions to use different objects, and how users authenticate themselves. Through the previously de- scribed rules, different security policies can be effected to govern access to the directory service and, once access is obtained, the ability of a user to use network resources. Because a network directory service supports a single point of access, this means that all network access is funneled through the rules that govern security. This in turn makes it easier to protect both access to the network and, once access occurs, the ability of network users to perform a variety of network-related operations. Armed with a general appreciation for the operation, utilization, and key features of a network directory service, one can now focus on Novell’s NDS and Microsoft’s Active Directory.

NOVELL’S NDS Novell’s NDS was ﬁrst introduced with the release of NetWare 4.0. Since that time, NDS has been revised and improved upon, both with the release of NetWare 5.0 and as individual upgrades to NDS. Either by late 1999 or early 2000, the newest revision to NDS, which represents its eighth version, should be available. This revision, which is now referred to as NDS Version 8.0, was in beta testing during mid-1999. This new version of NDS is backward compatible with prior versions of NDS, yet is far more scalable than previous versions. Under NDS Version 8.0, support is provided for one billion objects per tree as well as the most recent ver-

EXHIBIT 2 — NDS Core Components

• Objects and object management modules • Distributed database operations • Novell Directory Access Protocol • Schema • Supporting services sion of the Lightweight Directory Access Protocol, LDAP Version 3.0. Al- though the number of NDS releases appears considerable, the major structure and core components associated with this directory service have not changed, with each release building on those core components. NDS consists of a core series of ﬁve components that are listed in Ex- hibit 2. By examining each of the core components, one can obtain an appreciation for the operation of this network directory service.

Objects and Object Management NDS was designed to provide users with a single, logical view of all network resources and services. Resources, which are referred to as objects, are organized in a hierarchical tree structure, with the resulting structure referred to as the directory tree. Because the schema allows the tree structure to be modified, an organization can tailor the arrangement of objects in the tree according to its organizational structure. Under the NDS architecture, an object is contained in an organizational unit (OU). An OU in turn can be contained within another OU, similar to an organizational chart. This feature allows access to different network resources to be performed either on an individual basis or on an organizational basis. For example, consider network users Jane and John in the advertising department at the well-known firm Whoami. Their login names could be set to Jane.advt.whoami and John.advt.whoami. Sup- pose the advertising team requires access to a color laser assigned to the marketing group. The administrator could either grant Jane and John access to the printer on an individual basis, which would require two steps, or grant the entire advertising OU (advt.whoami) access to colorla- ser.mkt.whoami, with the latter only requiring a single step. Thus, the preceding example indicates both the flexibility of the use of a directory tree-based directory service as well as how its use facilitates the administrative process.

Distributed Database Operations As previously mentioned, NDS directory tree information is replicated on multiple servers, which provide both fault-tolerant login operations as well as facilitate network administration. If the primary copy of the tree should become unavailable, either due to a server or communications

link failure, the network automatically switches over to use a backup copy of the tree. Because WAN links normally operate at a fraction of the speed of that of a LAN, it is important to obtain the ability to partition a tree in order to place its data closer to users who need its services. NDS permits this, allowing for example the partition of a tree associated with one server to be placed on another server when the sets of users reside on different sides of the WAN. This action enables directory information required by each set of users to be placed on servers local to the users, minimizing directory searching across the lower speed WAN.

Novell Directory Access Protocol The NDS protocol is referred to as the Novell Directory Access Protocol (NDAP). This protocol is a request/response protocol built on top of the NetWare Core Protocol (NCP). Because NCP is not a transportable protocol, it relies on other protocols to provide for the transmission of packets across a network. Since NCP supports IPX and IP, this means that NDAP and NDS can be used in both legacy Novell environments built on IPX, as well as the evolving industry standard Internet Protocol (IP).

Schema The NDS schema consists of a set of rules that governs the structure of the directory tree, defining such parameters as how objects are defined, which attribute values can be associated with an object, and similar characteristics that define how the directory can be used. To facilitate directory operations, the schema requires every object in the directory to belong to an object class. Because attributes are associated with an object class, this allows attributes for a group of objects to be set with one operation, which can considerably facilitate the administrative process. Under NDS, a schema maintenance utility, referred to as Schema Man- ager, permits administrations to easily modify the operational schema. Through the use of Schema Manager, one can review, modify, print, compare, extend, and diagnose the NDS schema.

Supporting Services NDS includes a variety of supporting services interfaces. Such services al- low NDS to be integrated with other network or operating system services. One example of an NDS supporting service is for the Simple Network Management Protocol (SNMP). NDS can be conﬁgured to support SNMP, which enables this directory service to interact with an SNMP agent supported by the host operating system. Through this interaction, it becomes possible to view NDS SNMP-managed objects through an SNMP management console. A second example of NDS supporting services is the NDS Event Servic- es. NDS Event Services enable the monitoring of NDS activity on an indi-

vidual server. Through NDS Event Services, one can track local events as well as certain types of global events. In addition, event services can be configured to notify a NetWare Loadable Module (NLM) during or after the event, permitting Novell or third-party products to be used to generate e-mail messages, page an administrator, or perform other functions. Other examples of NDS supporting services include support for Uni- code, auditing, tracing, and logging certain NDS events. In addition to the previously mentioned supporting services, it should be mentioned that NDS includes several configuration and maintenance tools. Configu- ration tools assist users in installing and configuring NDS when a server is first installed into an NDS tree, while maintenance tools facilitate merg- ing two NDS trees, repairing the local NDS database, and logging and tracing NDS operations.

Support for Windows NT No discussion of NDS would be complete without discussing Novell products that enable NT application servers to be integrated with NDS. Novell currently provides two products to integrate NT application servers with NDS: Novell Administrator for Windows NT and NDS for NT. Novell Administrator for Windows NT permits user information to be cre- ated and maintained in NDS, which is then automatically synchronized with the NT domain-based network directory system. This results in network users having a single login view of the network because Novell Ad- ministrator for Windows NT synchronizes user passwords. The second Novell product that provides for the integration of NT application servers is NDS for NT. This product stores NT domain information as NDS data, eliminating the necessity to synchronize Windows NT domain information with NDS. To illustrate the beneﬁt of NT support, assume an employee requires access to both a NetWare server and an NT domain. Without NDS for NT, the network administrator would need to create and maintain two accounts for the employee — one on the NT domain computer and another on the NetWare server. However, if NDS for NT is installed on the NT server, all requests to the NT domain user object for log-in will be redi- rected to a single user object in NDS which controls access to NT resources. Thus, this action halves the administration effort, which can greatly facilitate the work of the network administrator when the organization has hundreds or thousands of employees. Having an appreciation for NDS, one can now focus on Microsoft’s Active Directory.

ACTIVE DIRECTORY Microsoft’s Active Directory represents a new network directory service that is currently in beta ﬁeld trials. Active Directory is incorporated in the newest version of Windows NT, which at one time was referred to

as NT 5.0 and was renamed during 1999 as Windows 2000. Because an understanding of Active Directory is best understood by examining the current method of network directory services supported by Microsoft, this will be done prior to turning our attention to the newer network directory service. Through Windows NT 4.0, the Microsoft network operating system is based on Windows NT Directory Service. Similar to Novell’s NDS, Win- dows NT Directory Service provides a single point of network log-in and administration. However, instead of a hierarchical relationship, Windows NT Directory Service uses a domain model in which trust relationships must be developed to provide a centralized management capability. Under the current Windows NT Directory Service, a domain is a group of Windows NT servers and modes that share a common user account database and security policy. Within a domain, one Windows NT server functions as a primary domain controller (PDC), while other servers can function as backup domain controllers (BDCs). The PDC is responsible for maintaining security and synchronizing security information among other servers on the network. The PDC also replicates its database to the BDCs, enabling a BDC to be promoted to the role of a PDC if the PDC should fail. Unlike NDS, which can support millions and under the soon-to-be released NDS Version 8 billion objects, an NT PDC is limited to 40,000 or fewer objects. While this limit might be efficient for small organizations, if the organization has multiple locations connected by relatively low- speed WANs, they would probably divide their network into multiple domains. However, because the security model of Windows NT Directory Service is based on the domain concept, a user from domain advt will not be able to log on to domain mktg unless he or she is either made a member of mktg, configured to be a member of a global group, or domain advt is configured in a trust relationship with domain mktg. Each of these options can represent a time-consuming task that requires coordi- nation between persons administering each domain, which is the reason why many people refer to the inability of the current NT Directory Ser- vice to scale well. This also explains why NDS is currently the preferred network directory service used by many competitive local exchange car- riers (CLECs) and Internet service providers (ISPs). With an appreciation for the general operation and limitations of Windows NT Directory Ser- vice, one can now focus on Microsoft’s Active Directory. Active Directory represents a hierarchical directory structure that can be divided, similar to NDS, into organizational units for functional or organizational groupings. To facilitate the integration of an existing Win- dows NT Directory Service, Active Directory permits domains to be interconnected into a hierarchical structure. Although Microsoft has not released final specifications for Active Directory, it should be capable of storing ten million objects, which is a considerable improvement over Windows NT 4.0 40,000 user limit per domain.

The architecture of the Active Directory is as ﬂexible and perhaps more so than NDS, supporting integrated application programming interfaces (APIs) that enable the look-up of e-mail addresses through Mi- crosoft’s Exchange Mail and the support of the Internet domain name services (DNS), which is used as its locator service. That is, in the Active Directory, Windows NT domain names represent DNS names and permit a host to have a common address for both Internet and Active Directory usage.

PRODUCT COMPARISON Any attempt to compare the actual usage of NDS and Active Directory at this time is on relatively shaky ground as NDS is a viable product that is in use by organizations requiring millions of objects while Active Direc- tory is in beta testing. Although it will probably be a year or more until Active Directory is in use by large organizations that can truly test its capability, there are certain features of Active Directory that may make this network directory service extremely appealing. Those features are in the area of Internet standards support and security. In the area of Internet standards support, Active Directory fully inte- grates its name space with DNS, which simpliﬁes both object location and access to objects. In comparison, although NDS can be set up to support a “DNS-like” structure, it does not truly integrate its name space with DNS. Thus, NDS can make object naming and access more complex if the administrator used a proprietary naming convention when NDS was installed. Concerning security, NDS used the commercially available RAS public and private key encryption scheme for authentication and RADIUS for remote access. In comparison, Active Directory supports Kerberos and smart cards. Although the difference between RAS and Kerberos might be similar to the difference between a half dozen and six, the difference between RADIUS and smart cards is more pronounced. The Remote Au- thentication Dial-in User Service (RADIUS) represents an emerging Inter- net Engineering Task Force (IETF) standard that is used by some vendors besides Novell for obtaining a centralized point for verifying a user name and password. In comparison, smart cards, while not a standard, are in common use by hundreds of commercial organizations, government agencies, and academic institutions as a mechanism for user authentication. Thus, it might appear that the support of smart card technology is a more popular choice than RADIUS for remote access.

SUMMARY If one is attempting to compare NDS and Active Directory, probably the best decision is to experiment and wait. When Windows 2000 is ofﬁcially released, it will be like other newly released products, requiring a service

pack to correct mistakes observed through use. Because of the impor- tance of a network directory to the operation of an organization, perhaps the best advice this author can make is to test Active Directory and read trade press reports of experiences of other organizations. After all, if NDS is working ﬁne, why risk a stable platform? As one local TV announcer would say, “That’s my opinion — what’s yours?”

Gilbert Held is an award-winning author and lecturer. Gil is the author of over 40 books and 250 technical articles covering the ﬁeld of data communications and personal computing. Some of his recent titles include High Speed Digital Networking, Working with Network Based Images, LAN Performance, 3rd edition, Ethernet Networks, 3rd edition, and Data and Image Compression, 4th edition. Gil can be reached via e-mail at 235-8068@mci- mail.com.