The basics of Novell Directory Services and Active Directory: installation and design principles.
As an instructor for both Microsoft and Novell courses, I'm often asked which I think is better: Active Directory (AD) or Novell Directory Services (NDS). In general, it's a loaded question. If I'm teaching a Microsoft course, students want to hear that AD is king; the same goes for NDS in a Novell course. In both instances, my answer is simple: There is no simple answer. Both have advantages over the other, and both have disadvantages. The "right" one depends on many factors, including your personal perspective.
In this two-part article, I will look at AD and NDS as they fit into a working environment. I'll start by looking at basics such as installation and design principles, before moving on to the some of the standard day-to-day activities involved with managing network objects like users, groups, and printing. I am not seeking to conclude whether one is better than the other; instead, I hope to illustrate how each deals with certain technical issues and aspects. Rather than trying to quantify performance by measuring the millions of directory lookups per second, or the ability to search through a couple of million objects to find a phone number, I will look at more practical and relevant issues such as how easy it is to create users, grant permissions to a printer in another location, and so on.
NDS and AD are both examples of directory services systems. Both provide the capability to manage network objects and can also act as a data repository for external applications. In both cases, scalability is not an issue; each supports a massive number of objects. Unlike AD, which will run only on Windows 2000, a version of NDS is available for NetWare, Linux, Windows NT/2000, and Solaris. For the purposes of this discussion, I'll assume that NDS is being used on a NetWare platform. The fact that AD is available on only one platform may be an influencing factor for some, but you must remember that AD is a newcomer to the directory services scene--NDS has been around since 1994.
Logical and Physical Structure
The distributed nature of directory services systems changes the way that a network must be configured. In essence, the big picture must be considered, with individual servers simply performing a role within this picture.
In AD, the directory is defined by one or more trees, which in turn are comprised of one or more domains. Within the domains, servers are nominated as domain controllers. The first domain that is created is referred to as the root domain, and each subsequent domain is called a child. Information is propagated between the domains by two-way, transitive trusts, enabling resources to be assigned transparently to other objects between domains. Within each domain, it is possible to create subcontainers called Organizational Units (OUs) that can be used to group network objects together. If, for some reason, an organization has more than one tree, trees can be grouped together into a forest.
NDS is also based around a tree structure, but it does not use the concept of domains. Instead, NDS allows the creation of Organization objects and Organizational Unit objects to logically organize network resources. Unlike AD, in which domains are the central points of information storage and replication, NDS allows you to create partitions in the database at any container. The point at which the partition is created then becomes the replication point.
From a physical perspective, Windows 2000 stores files that relate to AD in subdirectories under the WINNT directory. NDS stores its information in a similar way, in a set of files, by using a directory called _NETWARE located at the root of the SYS: volume that exists on each Novell server.
NDS is typically installed during the NetWare server installation. After the text-based portion of the setup has been completed, the NetWare install switches into an X-Window graphical system for the remainder of the system setup. The screens are easy to follow, but realistically you already need to have some understanding of directory services and NDS to complete the setup. A useful and informative help system is available during the NDS configuration, but it does assume a certain level of knowledge.
In contrast, the AD creation wizard does a very good job of explaining what is happening and which decisions need to be made and why. AD relies heavily on the Domain Name Service (DNS), and so it will create and configure a DNS server as part of the installation process if it isn't already installed. You could argue that anyone setting up a server that will be used in a directory services environment should know what they are doing before starting out--but how often have you had to approach a new product and technology with little background information? If you find yourself in such a situation, the added information that the AD wizard provides is reassuring. The wizard is run as part of the Windows 2000 server configuration, which runs automatically after the Advanced Server installation is complete.
AD differs from NDS in that in a small environment, you can elect to not use AD at all--you can stay with local users and groups. This is a great feature for those who do not want to concern themselves with directory services. NDS doesn't give you this option, although a simple tree is easy enough to administer with just a basic level of knowledge.
The tools supplied by Microsoft for managing AD and related objects are excellent and straightforward to use. Separate utilities are available for such things as User/Group Management, Active Directory Sites and Services, and Active Directory Domains and Trusts. Administration of printing is performed through Control Panel on a server-by-server basis, and file management tasks are completed through the familiar Windows Explorer. The only issue I have with the AD-related utilities is that at times it's easy to get lost in them; but once you are reasonably familiar with the utilities and what is performed where, they're fine. Windows 2000's use of the Microsoft Management Console (MMC) provides a uniform look to the different utilities and an easy way for new utilities to be added. It would appear that Microsoft favors the approach of using separate utilities for a task or group of tasks.
NDS, on the other hand, has only three main administration utilities, two of which overlap each other to a great extent. NetWare Administrator, which has been around since the beginning of NDS, is a 32-bit Windows-based application that provides the ability to manage users, groups, network file systems, printing, and almost every other conceivable network administration task from within one interface. It's a great tool, and as with the MMC, it has the ability to accept snap-in modules.
The second tool is the Java-based Console One utility. It has the same basic functionality as NetWare Administrator, with the exception of some features such as certain security settings. Being Java-based, it can be run either on a NetWare Server or on a Windows workstation. Both versions are slower than NetWare Administrator; the server-based implementation is slow enough to make me not want to use it unless absolutely necessary. Even so, it is useful to be able to work on the file system from the server--a feature that many NT/2000 administrators take for granted, but which has only been available to NetWare administrators since the introduction of ConsoleOne with NetWare 5.0.
NDS also comes with a third utility: NDS Manager. This 32-bit Windows-based utility is used to perform high-level management and administration tasks on the NDS structure. It is so easy to use that the importance of the task being performed can sometimes be underestimated.
Both systems come with a set of predefined network objects that should prove adequate in most environments. Even so, the ability to customize existing objects and create new ones is an attractive feature, particularly to those who will be using the compatibility features of the respective directories. Adding new objects or amending existing ones is known as extending the schema. In NDS, schema extension can be performed through ConsoleOne, but not through NetWare Administrator. In AD it is done through the Active Directory Schema MMC snap-in. In both cases, little help is provided during the schema extension process; and in contrast with my comments on the installation phase, this is fine. Schema extensions really are only for those who understand the process and the implications of their actions.
In Part 2, I'll continue my comparison by looking at performing user and group management, replication and fault tolerance issues, troubleshooting, and the steps involved in expanding your system. //
Drew Bird (MCT, MCNI) is a freelance instructor and technical writer. He has been working in the IT industry for 12 years and currently lives in Kelowna, B.C., Canada. You can e-mail Drew at firstname.lastname@example.org.