Understanding NDS
Unless you're brand-new to NetWare, or networking in general, you know that
one of NetWare 5's most important features is Novell Directory Services (NDS).
But if you're new to NetWare, you may not be familiar with NDS. In this article,
we'll explore NDS and some of the basic objects associated with it. Even if
you've used NDS with NetWare 4.x, Novell has made several improvements with
NetWare 5 that are worth learning.
Why do I need a directory?
When computer networks became popular in the late 1980s and early 1990s, a
network administrator's life was much easier. Networks consisted of relatively
few clients and only one or two servers. Performing administration tasks (such
tracking network resources, adding users, and maintaining groups) didn't require
a lot of time, because you had only one or two machines. Reflecting the
simplicity of networks at the time, popular network operating systems such as
NetWare 3.x let you manage only a single server at a time.
Today's networks are more complex. Your network may have several servers,
hundreds of clients, and be spread out over several locations. If you must make
the same change on more than a few servers, you'll quickly run out of time for
other tasks. Tracking network resources can also be time consuming.
Directory services help you organize your network by storing all network
information in a central location. Directory services include Active Directory,
Netscape Directory, and, of course, NDS. Although the directory services do
approximately the same job—centralize network resources for administrative
purposes—they differ in how they perform their task.
How NDS works
In 1994, when Novell first included NDS in NetWare 4.0, NDS stood for NetWare
Directory Services. As NDS became more popular, Novell began porting NDS to
other platforms, such as Windows NT and various flavors of UNIX. Eventually, the
NetWare portion of NDS didn't make much sense, so Novell changed the name to
Novell Directory Services.
NDS uses a hierarchical tree structure to define network resources. The tree
contains objects that represent users, groups, printers, and other things in
your organization.
NDS objects are stored in a database based on the CCITT X.500 language standard.
The NDS database lets you access your entire network's resources with a single
login. It also lets you manage your entire network and its resources from one
central location.
Novell also provides several tools you can use to administer your NDS tree. You
make changes to the NDS database using either the traditional NetWare
Administrator (NWAdmin) program or NetWare 5's new ConsoleOne program. Although
both programs perform the same task, each takes a different route.
Novell released NWAdmin with NetWare 4.0 to let network administrators work with
the then-new NDS for NetWare 4.0. NWAdmin was specifically written to run under
Windows 3.x. Novell also created a version of NWAdmin for OS/2, but discontinued
it after NetWare 4.02
As newer versions of Windows came out, Novell created specialized versions of
NWAdmin to support them. Eventually, there was a version for Windows 3.x,
Windows 9x, and Windows NT. Snap-ins for NWAdmin used by programs to extend NDS
often ran only on certain versions of NWAdmin. For example, a snap-in with
NWAdmin designed for Windows NT would not function with NWAdmin for Windows 95.
The version of NWADmin that comes with NetWare 5 tries to address some of those
problems. It runs on all Win32 platforms and attempts to integrate snap-in DLLs.
ConsoleOne does most of the same things that NWAdmin does. Unlike NWAdmin,
Novell wrote ConsoleONE using Java. As we pointed out in "Novell Introduces
NetWare 5," Java lets ConsoleOne run on platforms other than Windows.
Unfortunately, ConsoleOne doesn't support as many snap-ins as NWADmin. Because
it runs under Java, it's also slower than the native Win32 version of NWAdmin.
Novell designed the NDS database to be very flexible. For instance, you can make
your NDS tree reflect your company's organizational chart or geographical
layout. As your company grows and changes, you can increase, prune, and graft
the branches of your tree accordingly.
However, NDS's flexibility goes beyond tree design. Novell also lets programmers
extend the NDS database. They can add new objects to the database or add new
properties to existing objects. But before you can design the tree, you must
understand the parts of the tree, the objects you can place in the tree, and how
they work in NDS.
Basic NDS objects
As we mentioned earlier, the NDS database contains NDS objects, which represent
users, groups, printers, locations, and other network resources. Each object
represents a distinct network resource that identifies and contains information
about the resource. Novell classifies NDS objects into three categories: [Root],
container, and leaf objects.
The [Root] object sits at the top of your NDS tree. This object contains the
name of the tree, which you can specify only during installation. NetWare
automatically creates the [Root] object when you install NetWare on your server.
The only things you can put in your [Root] object are Country, Locality,
Organization, and Alias objects.
As the name suggests, container objects contain other objects. Just as you use
folders and subdirectories to store data on your computer, you can use container
objects to group objects in your NDS tree.
Container objects are logical objects; they don't represent physical items on
your network. Container objects can represent things such as countries,
factories, companies, divisions, or work groups. They fall into one of four
classes: Country, Locality, Organization, and Organizational Unit.
You'll find the optional Country object only at the first level of the NDS tree
under the [Root] object. As the name suggests, it represents the country where
your network resides. You can place Locality, Organization, and Alias objects in
the Country object.
The optional Locality object represents the geographical location of a portion
of the network. You can put Locality objects in the [Root], Country,
Organization, and Organizational Unit objects. Locality objects can hold
Organization and Organizational Unit objects. However, you won't use Locality
objects much—Novell included them primarily to comply with CCITT X.500
standards. Normally, you'll just build your NDS tree around the Organization and
Organizational Unit objects.
Normally, Organization objects reside under the Root object, but you may find
them under Country and Locality objects. You can have only one level of
Organization objects. These objects let you create subdivisions in your tree.
Objects contained in an Organization object can share logon scripts and access
to network resources. Organization objects can contain Locality, Organizational
Unit, and leaf objects. Your tree should include at least one Organization unit,
although it isn't required.
Organizational Unit objects let you break down the branches of the tree created
by other container objects. They're the most flexible container objects because
you can have several layers of these. Organizational Unit objects can contain
other Organizational Unit, Locality, and leaf objects. You can put
Organizational Unit objects in Locality, Organization, and other Organizational
Unit objects.
The most common type of object in an NDS tree falls into the third category of
objects. Following the tree metaphor, Novell calls objects in this category leaf
objects. Leaf objects represents the actual resources on the network.
Leaf objects don't contain other objects. Instead, they hold the properties and
information you want to track for the object. After you've designed your NDS
tree, most of your administrative work will deal with changing properties in
leaf objects.
Novell includes many leaf objects with NetWare 5. Third-party vendors create new
leaf objects and change the properties of existing ones. The basic leaf objects
you can use in your NDS tree include:
AFP Server—The AFP Server leaf object represents an AppleTalk File
Protocol-based server on your network. This object stores only information about
the server, such as its description, location, and network address. It doesn't
have any effect on the server itself.
Alias—Alias objects refer to other objects that you've placed elsewhere
in the NDS tree. Alias objects can be confusing. Even if you create an alias for
an object, there's still only one object in your database. Deleting or renaming
an alias object has no effect on the original object.
Application—ZENWorks creates application objects that refer to programs
stored on your network. You can use these objects to configure and serve the
applications to your users with the Novell Application Launcher.
Auditing File—This object controls access to the audit trail on your
server. If you don't have auditing turned on, you won't see or need this object.
Bindery—If you upgraded your server from NetWare 3.x, you may see this
object. Bindery objects appear when the migration object can't convert something
to NDS.
Bindery Queue—This object represents a print queue that was migrated to
your tree from a NetWare 3.x server.
Computer—As the name suggests, this leaf represents a computer. Don't
confuse the computer object with a server on your network. It only represents a
workstation or some other item on your network—it doesn't control anything.
Directory Map—This object represents a directory on the server.
Distribution List—This object represents a list of mail recipients.
You'll use this leaf only if you're using an e-mail system that supports MHS.
External Entity—This object represents non-NDS objects for some
applications. You'll usually see this object only if you have a non-MHS mail
system.
Group—The Group objects stores properties for multiple user objects.
You'll use the Group object when you want to assign several users the same
rights on the network.
List—The List object is similar to a Group object. You'll use it to
store information on multiple objects. Unlike the Group object, the List object
doesn't change the rights of the members of the object.
Message Routing Group—This object represents a group of Messaging
Server objects. It allows messages to pass between the messaging servers. You'll
need this group only if you've installed MHS.
Messaging Server—The Messaging Server object contains information about
mail servers on your network. As with other message-related objects, you'll need
this object only if you use MHS.
NetWare Server—As the name suggests, this object represents a server on
your network that runs NetWare. When you install NetWare on your server, NetWare
automatically creates this object. Unlike most objects, this object must exist
in the tree. If this object isn't in your tree, your users can't access the
server's volumes and files.
Organizational Role—This object represents a position or task in your
organization. It works like the Group object. You can assign rights to the
Organizational Role object and then make a user a member of the Organizational
Role object rather than assigning rights directly to that user. You may want to
do so if a certain position experiences significant turnover but the position
itself doesn't change.
Print Queue—This object represents a print queue on the network.
Print Server—This object represents a print server.
Printer—This object represents a printer attached to the network.
Profile—This object contains the profile logon script for a user. You
use this object by assigning it as a property for a User object. It's useful if
users located in different branches of your NDS tree must share common logon
script commands.
Unknown—You'll see this object in your NDS tree when NWAdmin or
ConsoleOne encounters an object for which it doesn't have a snap-in. Because the
administration program doesn't understand the object, it displays this object as
a placeholder. You can't make changes to Unknown objects, but you can delete
them.
User—Naturally, this object represents an individual user on your
network. Each person who needs access to the network should have his or her own
User object.
Volume--The Volume object represents a physical volume on your server.
This object doesn't control access to the volume. Instead, you use this object
to store information about the volume. The object is optional, but it's created
automatically when you install NetWare.
Conclusion
NDS is an important part of NetWare 5. As a network administrator, you need
to be familiar with the basic components of NDS before you can properly design
and use your NDS tree.
