About NDS Objects
Articles and Tips: article
Senior Editor
DeveloperNet University
nmclain@novell.com
18 Oct 2000
As we've discussed Novell Directory Services (NDS) partitions, replicas, and naming, I've often mentioned objects and containers. In this article, I'll explain more about objects and containers. One of the reasons I discussed partitioning and replication first is because your first task in installing NDS is to create the partitions. After you partition the NDS tree, you create the objects that represent the network resources.
What Is an NDS Object?
One of a network administrator's primary responsibilities is to maintain network resources, such as printers, users, groups, network volumes and directories, and so on. A primary function of directory services is to help administrators organize those resources in such a way that their jobs become easier. NDS lets you view and administer all the network resources as objects within a distributed directory tree.
Each resource in the NDS tree is represented as an object. Each of these objects can store data that describe it. This data is called either a property or an attribute. In this article, I'll use the word "attribute" to refer to this data.
NDS objects represent both physical and logical network resources. Physical network resources include printers, servers, workstations, and hard disk volumes. These resources are actual physical entities on your network. Logical network resources are entities that have no physical substance, such as groups and print queues. These resources are logical structures only. These objects are organized in a hierarchical structure called the NDS tree.
Container and Leaf Objects
All NDS objects are classified as either container or leaf objects. In the sample NDS tree shown in Figure 1, all the objects that are labeled as either O (Organization) or OU (Organizational Unit) are container objects, such as Very Small Company, HR, Engineering, and so on. They can have other objects subordinate to them; in other words, they can contain other objects. Container objects typically represent locations, such as the divisions, departments and workgroups in a company. They help you group other NDS objects together into a subtree. A subtree is made up of a container object and all the other objects it holds, including both lower container and leaf objects.
Leaf objects are those objects at the end of the tree branches. Leaf objects can't contain other objects, and they represent the actual network resources. In Figure 1, the objects labeled Brenda and Printer are leaf objects.
Figure 1: A sample NDS tree with container and leaf objects
Container Objects Supported by the NDS Schema
Currently, the NDS schema supports the following container objects:
Top. The top-most object in an NDS tree, it contains basic properties that it gives to all the objects below it.
Tree Root. This defines the NDS tree's root object.
Organization (O). This is an object that represents an organization.
Organizational Unit (OU). These are objects that represent an organization's subdivisions, such as marketing, human resources, education, and so on.
Country (C). This is an object that represents a country.
Locality (L). This is an object that defines geographic locations in the NDS tree.
Domain (dc). This defines a container object that can hold nternet or domain objects that aren't represented by other classes in the schema.
Only NDS can create the Top and Tree Root container objects. An Organizational Unit can contain other Organizational Units. Although the NDS schema defines Country and Locality objects, the Organizational Unit is commonly used instead of these containers.
Container objects help you organize your network so that users can find the resources they need easily. For example, if Brenda needs to locate a printer, she doesn't need to know its network address. She only needs to browse the HR container to find it. Container objects also help you administer your network more easily. You don't have to give users explicit rights to every resource they need. You only need to give them rights to the container that holds the resources the users require.
Using NDS Objects
You will use some of the NDS objects much more than others. The NDS schema incorporates a large range of objects in order to accommodate the diverse needs of our customers. Some NDS objects are required by all trees, some are used by nearly all trees, and some are used only in trees that have specific needs. The next sections describe the required and most common NDS objects. If you have special needs, or need more information about the NDS objects, refer to the NDS schema document, which you can download from http://www.developer.novell.com.
Required NDS Objects
When you create an NDS tree, NDS defines the tree [Root] object, an Organization object, a User object, an NCP Server object, and a Volume object. During the installation process, the NetWare Configuration (NWConfig) utility prompts you to enter names for each of these required objects.
The [Root] Object. The [Root] object is the most superior object in the NDS tree; it holds all other objects in the tree. When you look at the tree view in the NDS management utilities, you see that [Root] is the starting point of the tree, which branches downward from there. Although the management utilities always display the [Root] object with the name [Root], the object's actual name is the name of your tree. When you install the first NetWare 5 server in your tree, the installation utility prompts you for a tree name. That's when you assign a name to the [Root] object. Every tree has only one [Root] object.
The tree name is broadcast on the network with the Service Advertising Protocol (SAP). So, if you have multiple trees on your network, each tree name must be unique. It is best to name your tree with a name that clearly identifies the organization or company for the tree. Once you name your tree, and thus the [Root] object, you can only change it with the DSMerge utility.
Note: Novell Consulting Services recommends that you name your tree with your company name and add "_tree" to it.
The Organization Object. NDS defines an Organization object just below the [Root] object (unless you created a Country object during installation; since NDS doesn't require country objects, it doesn't define one by default). You must have at least one Organization object in your tree. Most companies name the Organization object with the same name as the company.
Your tree can have more than one Organization object directly below the [Root] (or Country) objects. However, Novell Consulting Services recommends that you have only one Organization object in your tree if all of your business units are connected on the same network. They recommend multiple Organization objects only if it makes sense according to your network infrastructure.
For example, if your company is a conglomerate with varied businesses that share information often, and each company within the conglomeration has a separate network infrastructure, you might want to create multiple Organization objects directly below the [Root] object. In most cases, however, you would use Organizational Unit objects to represent different business units.
The User Object. The most common object in most NDS trees is the User object. You should have one User object for each of your network users. When you install your first NetWare 4 or 5 server, NDS creates the first user, named Admin, and prompts you to give that user a password.
The Admin User object has all Supervisor rights to the [Root] object of your tree. Unless you change this rights assignment, Admin has all NDS and file system rights to the entire tree. It's the only object that has these extensive rights granted to it by default.
A word of caution is in order here. If you delete the Admin User object without making certain that at least one other object has such extensive rights to [Root], you lose access to your NDS tree. You would then have to either reinstall NDS or call Novell Technical Support.
One of Novell Consulting Service's recommendations is to consider creating an object, such as an Organizational Role object, and granting it Supervisor rights to the NDS tree. In this case, any objects contained by the Organizational Role object also have complete access to the tree. Don't just make the Organizational Role object security equivalent to the original Admin user. If you do that and the Admin object is deleted, the Organizational Role object would also lose access to the [Root] object because its security equivalence has been deleted.
The NCP Server Object. NDS automatically creates an NCP Server object for every NetWare 4 or 5 server that is installed, or for every server that is upgraded to NetWare 4 or 5. This object holds information such as the server's NetWare version and its network address. An NCP Server object can represent any entity that provides NCP (NetWare Core Protocol) transport and session services, including bindery-based (NetWare 3) servers. The Services attribute of the NCP Server object can be used to list the NCP-based services available on the server.
Note: NDS manages NCP Server objects. Typically, the administrator need pay little attention to these objects.
The Volume Object. NDS automatically creates a Volume object when you install a NetWare 4 or 5 server into the tree. Every file server must have at least one volume, named SYS. You can define additional volumes during the installation process.
Novell Consulting Services recommends that you create at least one other volume in addition to the SYS volume and place your print queue on it. This prevents the situation where you could have a lot of print jobs in the queue, filling up the SYS volume and thereby disabling NDS. They also suggest that you use volume restrictions to limit the volume size before it fills up completely.
Commonly Used Objects
The NDS schema defines dozens of object classes. (We'll discuss an object class in a later primer article.) Most of these objects are not created during installation because they are not required. The network administrator decides which objects would be useful on the network. Of all the supported object classes, about a dozen are commonly used. This section describes those objects. If you have a small site with only one or two servers, you might not even need all of these objects. Only use those objects that make sense in your network environment.
The Application Object. The Application object defines applications for ZENworks' Novell Application Launcher. In NetWare 4, there was a different Application object for each workstation operating system. In other words, if you had workstations running DOS, Windows 3.1, and Windows NT, you had to have an Application object for each of these operating systems. NetWare 5 uses only one Application object to represent the desktop operating systems on your network.
The Bindery Object. The Bindery object represents any object that isn't an NDS object and is created through and supported by bindery services. User, Group, Queue, Profile and Print Server are NDS objects, and therefore aren't represented with a Bindery object.
The Bindery object provides backward compatibility for bindery-oriented applications and utilities. This allows the application or utility to create the bindery objects it needs and have those objects represented in NDS. These bindery objects will appear in NDS management utilities such as NWAdmin. However, they are for information only; you won't be able to manage them with the utility.
Note: Do not delete any Bindery object until you verify its purpose. Often, installation utilities create a Bindery object that an application must have in order to operate correctly.
The Organizational Unit Object. If your network environment includes more than one NetWare server, you'll probably use an Organizational Unit object. These objects divide the tree into either locations or organizations. Organizational Unit objects can contain other Organizational Unit objects. This allows you to further subdivide the location and organization branches of your tree into departments, divisions, or workgroups. This helps you manage your network resources by fine-tuning the placement of network resources, such as printers and users, as well as fine-tuning network rights.
The Organizational Role Object. The Organizational Role object is usually used to define a role or position. Any object or file rights granted to this object are passed on to the objects it has listed in its attributes. But the Organizational Role object is the object that actually has the rights, not the objects it has listed. This means that you can assign rights to the Organizational Role object and then move other objects, such as users, into and out of the Organizational Role object's list. When an object is listed in the Organizational Role object, it has the appropriate rights to perform specific tasks. When it is moved out of the Organizational Role object's list, it loses those rights.
For example, you could create an Organizational Role object for the network administrator role and grant the object supervisory rights. You could then add the appropriate User objects to the Organizational Role object's list. Those User objects would then have the rights to administer the network. When the users' roles within the organization no longer requires them to administer the network, you simply remove the User objects from the list. Doing so automatically removes their supervisory rights.
The Group Object. The Group object represents a set of users from any part of the NDS tree. This is a way of grouping together objects that require the same set of rights to the network or to a network resource. You can then administer these objects by managing the Group object they are members of. You don't have to manage each object individually.
In addition, when you must create or modify an object to have the same set of rights that an already-defined Group object has, you only have to move the object into that appropriate Group object. This means you can manage an object's rights by dragging and dropping it. You don't have to explicitly grant and remove specific rights on individual objects.
Novell Consulting Services recommends using the Organizational Role and Group objects to grant rights whenever possible. This prevents network objects from having rights granted to them individually that are later forgotten about.
The Directory Map Object. The Directory Map object is a pointer that refers to a file system directory on a NetWare volume. Login scripts and the MAP command can use this object to point to the directories they need to reference. The advantage is that if you must change a file system directory name, you only have to change it in the Directory Map object instead of every place the directory is referred to.
The Alias Object. An Alias object points to another object that you specify in the NDS tree. This means that you can create an Alias object to point to another object, such as a printer, residing in a different Organizational Unit than the one in which your users reside. The Alias object would then make the printer look to the users as if it were in their OU. The advantage is that users don't have to know which OUs have printers--they can simply select the printer by selecting its Alias object.
You can also create an Alias object within an OU for another OU. This would allow the objects in the first OU to access the other OU's resources more easily.
The Print Server Object. The Print Server object represents a server that takes print jobs out of a print queue and sends them to a network printer. You use this object with the Printer and Queue objects. Every print server on a NetWare 4 or 5 network must have a Print Server object.
The Printer Object. The Printer object helps you manage the actual physical printer. Every printer on a NetWare 4 or 5 network must have a Printer object. You use this object to assign the print queue to the printer.
The Queue Object. The Queue object represents a print queue that has been defined on a NetWare 4 or 5 server. The print queue is the directory that holds the print jobs that are waiting to be serviced by a printer.
The Profile Object. The Profile object is a special-purpose scripting object that is executed by the LOGIN.EXE program. The profile script can contain special drive mappings or environment settings that you want a specific group of users to receive. User objects have a Profile property. You can use this property to specify that the user is part of a profile. In other words, you can use the User object's Profile property to assign the Profile object to it.
The Unknown Object. The Unknown object represents any object created by the server to restore any object whose class is currently undefined in the schema. The server, not the client, creates these objects. Usually, an object becomes unknown because one of its mandatory properties has somehow been lost.
If an Unknown object appears in your tree, check to see if another object has been deleted. The deleted object might simply have become the Unknown object. Be aware that Unknown objects also appear temporarily as the NDS background processes synchronize the tree.
Conclusion
NDS objects are either container or leaf objects, and they help you manage your NDS tree. Organization and Organizational Unit objects help you organize your network view in a logical, hierarchical structure that is easy to navigate. With proper planning, you can use Alias objects, Group objects, and Organizational Role objects to help you efficiently manage network rights to its many resources.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.