Novell eDirectory

This chapter is from the book

CNA Study Guide for NetWare 6

Learn More Buy

This chapter is from the book

This chapter is from the book 

CNA Study Guide for NetWare 6

Learn More Buy

Using eDirectory Objects

Test Objectives Covered:

7. Identify and describe eDirectory object classes.

8. Identify the flow and design of the eDirectory tree.

The Directory consists of the schema, objects, properties, and values.

The schema defines the types of objects that you can create, as well as what information is required when the object is created. Each type of object has associated with it a defined schema class. NetWare 6 ships with the base schema, which when modified becomes known as an extended schema. Modifications to the schema usually are done with the Schema Manager in the ConsoleOne utility.

An object is similar to a record or row of information in a database table. It contains information about a particular network entity. eDirectory represents each network resource as an object in the Directory. For example, a User object represents a particular user on the network. An object can be a physical resource (such as a workstation), an eDirectory resource (such as a group), or an organizational resource (such as a container).

An object property is similar to a field in a database record. It is a category of information you can store about an object. For example, properties of a User object include such things as Login Name, Password, and Telephone Number. Each type of object has a specific set of properties associated with it; this defines its class. Properties are predefined by eDirectory and determine how a given object can be used. For example, Server properties differ from Printer properties because they are different eDirectory objects with different functions.

Three important types of eDirectory properties are the following:

• Required properties—These properties contain vital object data and, therefore, must be supplied to create the object. Required properties can't be deleted. For example, when you create a User object, you must indicate values for the Login Name and Last Name properties. In fact, the name of an object is always a required property. Otherwise, you would have no way of referring to it.

• Optional properties—These properties contain nonvital information about an object. As such, you need to supply values for them only if desired. Examples include a User's Title, Telephone Number, and Fax Number.

• Multivalued properties—These properties support more than one entry. For example, the Telephone Number property associated with a User object can hold multiple phone numbers for that user. Other User-related multivalued properties include Title, Location, and Fax Number. (This type of multivalued property is represented in ConsoleOne with an ellipsis (...) button to the right of the property field. If you click this button, you'll be allowed to enter additional entries for the property.)

Finally, a property value is similar to a data string in a field of a database record. In other words, it's a data item associated with a property. For example, the value associated with the Password property of a User object would be the actual password for that User object.

Refer to Table 3.2 for an illustration of the relationship between eDirectory objects, properties, and values.

Table 3.2 Understanding eDirectory Objects, Properties, and Values

Hierarchy of eDirectory

As you learned earlier, the Directory is an object-oriented database that is organized in a hierarchical structure called the eDirectory tree. It provides a way to view the logical organization of network resources stored in the Directory database. As you can see in Figure 3.5, the tree is similar to the DOS file system.

Figure 3.5 Understanding eDirectory objects.

The schema contains object classes, which represent the actual definition of each type of eDirectory object. eDirectory contains the following three main classes of objects:

• Tree Root

• Container objects

• Leaf objects

The top of the tree is called the Tree Root. Container objects, which are analogous to folders, define the organizational boundaries of the Directory and are used to store other container objects and/or leaf objects, depending on which type of container they are. (A container object is called a parent object if it contains other objects.) Leaf objects, which are analogous to files, are typically stored in container objects. They are the physical or logical network resources that provide technical services and WAN functionality. Leaf objects define the lowest level of the eDirectory structure and therefore cannot contain other objects.

The main difference between eDirectory and DOS architecture is that eDirectory containers have restrictions on where they can be placed and what can be placed in them. Typically, each NetWare 6 network will have only one eDirectory tree. If a network has more than one tree, each will function as a separate, independent database. In other words, resources cannot be shared between them.

In the Directory, each network resource is defined as a logical object. There are a number of types of objects. For example, an object can represent a person (such as a user), a physical resource (such as a printer), an eDirectory resource (such as a group), or an organizational resource (such as an Organizational Unit container).

The bottom line is this—users don't access physical resources anymore. Instead, they access logical objects in the eDirectory tree. This means they don't need to know which NetWare 6 server provides a particular resource. All they need to know is where the resource exists in the logical eDirectory world.

Now that you've mastered the subtle differences between eDirectory schema, objects, properties, and values, let's explore some of the most interesting objects in detail, starting at the top with the Tree Root.

Tree Root

The Tree object (also known as the Tree Root) is a required object that defines the top of the eDirectory organizational structure. Because it represents the opening porthole to the eDirectory world, its icon is appropriately a picture of a tree. Each Directory tree can have only one Tree Root, which is created during installation of the first server in that tree. The only objects that can be created directly under the Tree are Country, Organization, and Alias. (In this case, the Alias object can point only to a Country or Organization.)

Although some people think of the Tree as a container object (because it contains all the objects in the Directory), it differs from other container objects in the following ways:

• It cannot be created except during installation of the first NetWare 6 server on a network.

• It is essentially a placeholder; it has only one property: Name. The Tree name is shown in the hierarchy of ConsoleOne.

• It cannot be moved, deleted, or renamed.

• It uses the eDirectory tree name, which can be changed at a later date.

Like other objects, the Tree can be assigned as a trustee of other objects, and other objects can be granted trustee access rights to it. For example, an object can be granted trustee rights to the entire eDirectory tree by making the object a trustee of the Tree object. (See Chapter 6, "NetWare 6 Security," for further information on trustee rights.)

Container Objects

Container objects are logical objects that organize (store) other container or leaf objects. A container can represent a country, a location within a country, a company, a department, a responsibility center, a workgroup, or a collection of shared resources. Each class of container object has different rules that define what it can contain and where it can be located in the tree. Each class also has different properties.

The following are the three most common types of NetWare 6 container objects:

• Country—Designates the country where certain parts of the organization reside.

• Organization—Represents a company, university, or department. eDirectory supports only one layer of Organization objects; hence, the term one-dimensional. Organizations can hold Organizational Unit containers or Leaf objects.

• Organizational Unit—Represents a division, a business unit, or a project team within the Organization. Organizational Units hold other Organizational Units or leaf objects. They are multidimensional.

Refer to Figure 3.5 earlier in this chapter for an illustration of the relationship between the Tree Root and container objects. The ACME Organization houses other Organizational Units (including LABS), that in turn house leaf objects (like AEinstein). In the next sections, you'll take a closer look at these three container objects.

Country

The Country object is an optional container that organizes a Directory tree by country. This type of object can be defined only directly under the Tree Root and must be named using a two-character abbreviation. Novell states that you must use a valid two-character country abbreviation. Presumably, this is to ensure that your network is in compliance with the two-character abbreviations defined in the ISO X.500 standard.

Interestingly, if you create a Country object using the ConsoleOne utility, it allows you to use any two-character name. To determine which two-character names are compliant with the ISO X.500 standard, click Help when creating the Country object, and NetWare 6 will tell you. You can also visit the ISO Web site at http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html to see a list of country codes. The only objects that can exist in a Country container are an Organization or Alias object pointing to an Organization.

Organization

If you don't use a Country object, the next layer in the tree is typically an Organization. You can use an Organization object to designate a company, a division of a company, a university or college with various departments, and so on. Every Directory tree must contain at least one Organization object. Therefore, at least one Organization is required. Many small implementations use only the Organization object and place all their resources directly underneath it. Organization objects must be placed directly below the Tree Root, unless a Country object is used. Finally, Organization objects can contain all objects except Tree Root, Country, and Organization.

Earlier, we defined the Organization as a one-dimensional object. This means the tree can support only one layer of Organization objects. If you look closer at the icon, you'll see a box with multiple horizontal boxes underneath. Additional vertical hierarchy is defined by Organizational Units, which are multidimensional. You'll learn about them in just a moment.

Figure 3.6 illustrates the object dialog box for the ACME Organization using ConsoleOne. On the right side of the screen are the many page buttons that identify categories of eDirectory properties for this object. Associated with each page button is an input screen for a specific set of information (on the left side). The Identification page button (shown here) allows you to define a variety of Organization properties, including Name, Other Name, Description, Location, Telephone, and Fax Number.

Similar page buttons enable you to configure important Organization parameters, including postal information, print job configurations, trustee assignments, and so on. As far as ACME is concerned, the Organization container defines the top of the functional tree.

Figure 3.6 Properties of an eDirectory Organization object.

Organizational Unit

The Organizational Unit object is a natural group. It enables you to organize users with the leaf objects they use. You can create group login scripts, a user template for security, trustee assignments, security equivalences, and distributed administrators. Although the Organizational Unit container is optional, you should definitely use as many as you need to build a scalable hierarchy for two main goals: resource access and partitioning.

Organizational Units can represent a division, a business unit, a project team, or a department. Organizational Units are multidimensional, in that you can have many hierarchical levels of containers within containers. Remember, Organization objects can exist only at one level in the eDirectory tree.

Organizational Units are the most flexible containers because they can contain other Organizational Unit objects or leaf objects. Organizational Units can contain most of the eDirectory object types, except the Tree Root, Country, or Organization containers (or Aliases of any of these).

Now take a look at the real stars of the eDirectory world—leaf objects.

Leaf Objects

Leaf objects represent logical or physical network resources. Because leaf objects reside at the end of the structural eDirectory tree, they cannot be used to store other objects. In other words, they represent the proverbial "end of the road." As you learned earlier, each class of leaf object has certain properties associated with it. This collection of properties differentiates the various leaf object classes from each other. For example, User objects contain different properties than Printer objects do.

The following are some of the key leaf objects covered in this course:

• Alias—An Alias object points to another object that exists in a different location in the eDirectory tree. It enables a user to access an object outside of the user's normal working context (that is, container). An Alias object does not carry trustee rights.

• Application—An Application object enables network administrators to manage applications as objects in the eDirectory tree. The advantage of this object is that users don't have to worry about drive mappings, paths, or rights when they want to execute an application. This information is defined by Application object properties.

• Directory Map—A Directory Map object represents a logical pointer to a physical directory or folder in the NetWare 6 file system. This object is useful in mapping statements because it enables you to map a drive to a resource without knowing its physical location. If the path to the resource changes, you need to change only the path designated in the Directory Map object, rather than any of the login script mappings statements that refer to it.

• Group—A Group object defines a list of users for the purpose of assigning access rights or other configuration parameters. The members of a group can be a subset of users in the same container or spread across multiple containers. The difference between containers and groups is that container objects store User objects, whereas Group objects store a list of User objects. Groups enable one of the great CNA tricks: they allow you to specify login script commands to a subset of users with the IF MEMBER OF syntax.

• LDAP Group—An LDAP Group object stores configuration data (class mappings, attribute mappings, and security policies) for groups of LDAP Servers. During installation, an LDAP Group object named LDAP Group- <servername> is created by default in the host Server's home container.

• LDAP Server—An LDAP Server object stores configuration data for a NetWare 6 server running LDAP Servers for eDirectory. During installation, an LDAP Server object named LDAP Server- <servername> is created by default in the host Server's home container. Make sure not to assign the same LDAP Server object to more than one server running LDAP Services for eDirectory.

• License Certificate—A License Certificate object is used by NetWare Licensing Services (NLS) to monitor and control the use of licensed applications on the network. When the NLS-aware application is installed, a License Certificate object is added to the Licensed Product container.

• NDPS Broker—An NDPS Broker provides three network support services for network printing: Service Registry Services (SRS), Event Notification Services (ENS), and Resource Management Services (RMS). When NDPS is installed, the installation utility ensures that a Broker object is loaded on your network.

• NDPS Manager—The NDPS Manager is a logical entity used to create and manage NDPS Printers and Printer Agents. The NDPS Manager object stores information used by NDPSM.NLM on a single server. This single server can control multiple Printer Agents.

• NDPS Printer—NDPS Printers magically transform electronic bits into written words. These objects are created by iManager as Controlled Access Printers. As eDirectory objects, NDPS Printers are no longer available as Public Access Printers.

• Organizational Role—An Organizational Role object defines a position or role within the organization that can be filled by any designated user. The Organizational Role is particularly useful for rotating positions that support multiple employees, where the responsibilities of the job, and the network access required, are static. If a User object is assigned as an occupant of an organizational role, the user "absorbs" all trustee rights assigned to it. Some organizational role examples include PostMaster, Network Administrator, Silicon Valley CEO, or Receptionist.

• Print Server (Non NDPS)—A Print Server (Non NDPS) object represents a network print server used for monitoring queue-based print queues and printers.

• Printer (Non NDPS)—A Printer (Non NDPS) object represents a queue-based physical printing device on the network, such as a printer or plotter. Refer to Figure 3.7 for an illustration of the Printer (Non NDPS) properties that can be managed using ConsoleOne.

Figure 3.7 Properties of an eDirectory Printer (Non NDPS) object.

• Profile—A Profile object defines a login script for a subset of users in the same container or spread across multiple containers. (If all the users in a container need the same login script, you should use a Container login script, instead.)

• Server—A Server object represents a server running eDirectory on your network. eDirectory supports the following operating system platforms: NetWare, Solaris, Linux, and/or Windows 2000. You can even create a Server object for Bindery servers running NetWare 2 or NetWare 3. This object is used by various leaf objects (such as Volume objects) to identify a physical server that provides particular network services. Refer to Figure 3.8 for an illustration of the Server properties that can be managed using ConsoleOne.

Figure 3.8 Properties of an eDirectory Server object.

• Unknown—An Unknown object represents an eDirectory object that has been corrupted, invalidated, or that cannot be identified as belonging to any of the other leaf classes. For example, an Alias object becomes Unknown when its host is deleted. Ouch!

• User—A User object represents a person who uses the network (for example, you, me, or Fred). For security reasons, you should create a separate User object for each user on the network. A User object contains a plethora of interesting properties, including Login Name, Password, Full Name, Login Restrictions, and so on. Refer to Figure 3.9 for an illustration of the User properties that can be managed using ConsoleOne.

Figure 3.9 Properties of an eDirectory User object.

• Volume—A Volume object represents a physical volume on the network. Typically, volumes are created during the server installation process. Remember that a Volume object is a leaf object rather than a container object—even though the ConsoleOne utility may give you the opposite impression. It stores information about a volume, including server name, physical volume mapping, and volume use statistics. No information about files and folders on a volume is contained in a Volume object. However, you can access that information through ConsoleOne. Volume objects are supported only on NetWare. If you are using UNIX file system partitions, these cannot be managed using Volume objects.

• Workstation—A Workstation object enables you to manage network workstations through eDirectory. This leaf object is automatically created when a workstation is registered and imported into the eDirectory tree.

Table 3.3 summarizes some important eDirectory object characteristics.

Table 3.3 eDirectory Object Characteristics

This completes the discussion of the most interesting eDirectory objects offered by NetWare 6. You'll want to get to know all these leaf objects because future discussions center around how to organize, design, and manage them. After you understand the relationships between eDirectory objects, you can start building your tree.

How do you feel? So far, you've explored all the physical and logical objects that make up NetWare 6's revolutionary eDirectory tree. However, this is only the beginning. Your success as a CNA is defined by your ability to manage eDirectory objects and their properties.