Object Classes and Properties

The definition of each type of eDirectory object is called an object class. For instance, User and Organization are object classes. Each class of object has certain properties. A User object, for example, has Login Name, Password, Last Name, and many other properties.

The schema defines the object classes and properties, along with the rules of containment (what containers can contain which objects). eDirectory ships with a base schema that you, or the applications you use, can extend. For more information about schemas, see Schema.

Container objects contain other objects and are used to divide the tree into branches, while leaf objects represent network resources.

List of Objects

The following tables list eDirectory object classes. Added services can create new object classes in eDirectory that are not listed below. Also, all classes might not be available on all server operating systems hosting eDirectory.

eDirectory Container Object Classes

eDirectory Leaf Object Classes

Container Object Classes

Tree

The Tree container, formerly [Root], is created when you first install eDirectory on a server in your network. As the top-most container, it usually holds Organization objects, Country objects, or Alias objects.

What Tree Represents

Tree represents the top of your tree.

Usage

Tree is used to make universal rights assignments. Because of inheritance, any rights assignments you make to Tree as the target apply to all objects in the tree. See eDirectory Rights. The [Public] trustee has the Browse right and Admin has the Supervisor right to Tree by default.

Important Properties

The Tree object has a Name property, which is the tree name you supply when installing the first server. The tree name is shown in the hierarchy of iManager.

Organization

An Organization container object is created when you first install eDirectory on a server in your network. As the top-most container under Tree, it usually holds Organizational Unit objects and leaf objects.

The User object named Admin is created by default in your first Organization container.

What an Organization Object Represents

Normally the Organization object represents your company, although you can create additional Organization objects under Tree. This is typically done for networks with distinct geographical districts or for companies with separate eDirectory trees that have merged.

Usage

The way you use Organization objects in your tree depends on the size and structure of your network. If the network is small, you should keep all leaf objects under one Organization object.

For larger networks, you can create Organizational Unit objects under the Organization to make resources easier to locate and manage. For example, you can create Organizational Units for each department or division in your company.

For networks with multiple sites, you should create an Organizational Unit for each site under the Organization object. That way, if you have (or plan to have) enough servers to partition the directory, you can do so logically along site boundaries.

For easy sharing of company-wide resources such as printers, volumes, or applications, create corresponding Printer, Volume, or Application objects under the Organization.

Important Properties

The most useful properties for Organization are listed below. Only the Name property is required. For a complete list of properties, select an Organization object in iManager. To display a description for each page of properties, click Help.

• Name

  Typically, the Name property is the same as your company's name. Of course, you can shorten it for simplicity. For instance, if the name of your company is Your Shoe Company, you might use YourCo.

  The Organization name becomes part of the context for all objects created under it.

• Login Script

  The Login Script property contains commands that are executed by any User objects directly under the Organization. These commands are run when a user logs in.

Organizational Unit

You can create Organizational Unit (OU) container objects to subdivide the tree. Organizational Units are created with iManager under an Organization, Country, or another Organizational Unit.

Organizational Units can contain other Organizational Units and leaf objects such as User and Application objects.

What an Organizational Unit Object Represents

Normally the Organizational Unit object represents a department, which holds a set of objects that commonly need access to each other. A typical example is a set of Users, along with the Printers, Volumes, and Applications that those Users need.

At the highest level of Organizational Unit objects, each Organizational Unit can represent each site (separated by WAN links) in the network.

Usage

The way you use Organizational Unit objects in your tree depends on the size and structure of your network. If the network is small, you might not need any Organizational Units.

For larger networks, you can create Organizational Unit objects under the Organization to make resources easier to locate and manage. For example, you can create Organizational Units for each department or division in your company. Remember that administration is easiest when you keep User objects together in the Organizational Unit with the resources they use most frequently.

For networks with multiple sites, you can create an Organizational Unit for each site under the Organization object. That way, if you have (or plan to have) enough servers to partition the directory, you can do so logically along site boundaries.

Important Properties

The most useful properties for the Organizational Unit are listed below. Only the Name property is required. For a complete list of properties, select an Organizational Unit object in iManager. To display a description for each page of properties, click Help.

• Name

  Typically, the Name property is the same as the department name. Of course, you can shorten it for simplicity. For instance, if the name of your department is Accounts Payable, you can shorten it to AP.

  The Organizational Unit name becomes part of the context for all objects created under it.

• Login Script

  The Login Script property contains commands that are executed by any User objects directly under the Organizational Unit. These commands are run when a user logs in.

Country

You can create Country objects directly under the Tree object using iManager. Country objects are optional and required only for connection to certain X.500 global directories.

What a Country Object Represents

The Country object represents the political identity of its branch of the tree.

Usage

Most administrators do not create a Country object, even if the network spans countries, since the Country object only adds an unnecessary level to the tree. You can create one or many Country objects under the Tree object, depending on the multinational nature of your network. Country objects can contain only Organization objects.

If you do not create a Country object and find that you need one later, you can always modify the tree to add one.

Important Properties

The Country object has a two-letter Name property. Country objects are named with a standard two-letter code such as US, UK, or DE.

Domain

You can create Domain objects directly under the Tree object using iManager. You can also create them under Organization, Organization Unit, Country, and Location objects.

What a Domain Object Represents

The Domain object represent DNS domain components. Domain objects let you use your Domain Name System location of services resource records (DNS SRV) to locate services in your tree.

Using Domain objects, a tree could look something like this:

DS=Novell.DC=Provo.DC=USA

In this example, all subcontainers are domains. You can also use Domain objects in a mixed tree, such as:

DC=Novell.O=Provo.C=USA

Or

OU=Novell.DC=Provo.C=USA

Usually, the topmost Domain is the overall Tree, with subdomains under Tree. For example, machine1.novell.com could be represented by DC=machine1.DC=novell.DC=com in a tree representation. Domains give you a more generic way to set up an eDirectory tree. If all containers and subcontainers are DC objects, users do not need to remember C, O, or OUs when searching for objects.

Usage

NetWare 4 and 5 trees cannot have Domain objects at the top of the tree. With NetWare 4 and 5, the NCP Server object can be placed in an Organization, Country, Organizational Unit, or Locality container, but not in a Domain container. With NetWare 6, however, you can place Domain objects at the top of the tree, and you can place the NCP Server object in a Domain container.

For older installations of NetWare (such as NetWare 4), when you prepare the tree to install or upgrade to NetWare 5 or later, the nds500.sch file will automatically run. After the first server is installed into the tree, this file extends the schema to allow the Domain container to be created anywhere and hold most directory objects.

Leaf Object Classes

Server

A Server object is automatically created in the tree whenever you install eDirectory on a server. The object class can be any server running eDirectory.

You can also create a Server object to represent a NetWare 2 or NetWare 3 bindery server.

What a Server Object Represents

The Server object represents a server running eDirectory or a bindery-based (NetWare 2 or NetWare 3) server.

Usage

The Server object serves as a reference point for replication operations. A Server object that represents a bindery-based server allows you to manage the server's volumes with iManager.

Important Properties

The Server object has a Network Address property, among others. The Network Address property displays the protocol and address number for the server. This is useful for troubleshooting at the packet level

For a complete list of properties, select a Server object in iManager. To display a description for each page of properties, click Help.

Volume

When you create a physical volume on a server, a Volume object is automatically created in the tree. By default, the name of the Volume object is the server's name with an underscore and the physical volume's name appended (for example, YOSERVER_SYS).

Volume objects are supported only on NetWare. UNIX file system partitions cannot be managed using Volume objects.

What a Volume Object Represents

A Volume object represents a physical volume on a server, whether it is a writable disk, a CD, or other storage medium. The Volume object in eDirectory does not contain information about the files and directories on that volume, although you can access that information through iManager. File and directory information is retained in the file system itself.

Usage

In iManager, click the Volume icon to manage files and directories on that volume. iManager provides information about the volume's free disk space, directory entry space, and compression statistics.

You can also create Volume objects in the tree for NetWare 2 and NetWare 3 volumes.

Important Properties

In addition to the required Name and Host Volume properties, there are other important Volume properties.

• Name

  This is the name of the Volume object in the tree. By default, this name is derived from the name of the physical volume, though you can change the object name.

• Host Server

  This is the server that the volume resides on.

• Version

  This is the NetWare or eDirectory version of the server hosting the volume.

• Host Volume

  This is the physical volume name. Because the actual Volume object name does not need to reflect the physical volume name, this property is necessary to associate the Volume object with the physical volume.

User

A User object is required for logging in. When you install the first server into a tree, a User object named Admin is created. Log in as Admin the first time.

You can use the following methods to create or import User objects:

• iManager

  For more information on iManager, see the Novell iManager 2.0.x Administration Guide.

• Batches from database files

  For more information on using batch files, see Designing the eDirectory Tree.

• NetWare upgrade utilities

  For more information on upgrade utilities, including importing users from existing bindery servers, see Designing the eDirectory Tree.

What a User Object Represents

A User object represents a person who uses the network.

Usage

You should create User objects for all users who need to use the network. Although you can manage User objects individually, you can save time by

• Using Template objects to set default properties for most User objects. The Template applies automatically to new Users you create (not to already existing ones).
• Creating Group objects to manage sets of Users.
• Assigning rights using the container objects as trustees when you want that assignment to apply to all User objects in the container.
• Selecting multiple User objects by using Shift+click or Ctrl+click. When you do, you can change property values for all selected User objects.

Important Properties

User objects have over 80 properties. For a complete list of properties, select a User object in iManager. To display a description for each page of properties, click Help.

The Login Name and Last Name properties are required. These and some of the most useful properties are listed below.

• Account Expiration Date lets you limit the life of a user account. After the expiration date, the account is locked so the user cannot log in.
• Account Disabled has a system-generated value that indicates a lock on the account so the user cannot log in. The lock might occur if the account has expired or because the user has given too many incorrect passwords in succession.
• Force Periodic Password Changes lets you enhance security by requiring the user to change passwords after a specified interval.
• Group Memberships lists all the Group objects that include the User as a member.
• Home Directory refers to a NetWare volume and file system path for the user's own files. Most administrators like to create such a directory so that a user's working files can be kept on the network.

  The directory referred to in this property can be automatically created when you create the User object.

• Last Login is a system-generated property that lists the date and time that the user last logged in.
• Last Name, although required, is not used directly by eDirectory. Applications that take advantage of the eDirectory name base can use this property, along with other identification properties such as Given Name, Title, Location, and Fax Number.
• Limit Concurrent Connections lets you set the maximum number of sessions a user can have on the network at any given time.
• Login Name is the name shown in iManager by the User icon. It is also the name supplied by the user when logging in.

  eDirectory does not require that login names be unique throughout the network, only in each container. However, you might want to keep login names unique across the company to simplify administration.

  Typically, login names are a combination of first and last names, such as STEVEJ or SJONES for Steve Jones.

• Login Script lets you create specific login commands for a User object. When a user logs in, the container login script runs first. Then a profile login script runs if the User object has been added to the membership list of a Profile object. Finally, the user login script runs (if one exists).

  You should put most of the login commands in container login scripts to save administrative time. The user login script can be edited to manage unique exceptions to common needs.

• Login Time Restrictions lets you set times and days when the user can log in.
• Network Addresses contains system-generated values that list all the IPX^TM and/or IP addresses that the user is logged in from. These values are useful for troubleshooting network problems at the packet level.
• Require a Password lets you control whether the user must use a password. Other related properties let you set common password constraints such as password length.
• Rights to Files and Directories lists all rights assignments made for this user to the NetWare file system. Using iManager, you can also check a user's effective rights to files and directories, which include those inherited from other objects.

Group

You can create Group objects to help you manage sets of User objects.

What a Group Object Represents

A Group object represents a set of User objects.

Usage

Container objects let you manage all User objects in that container, and Group objects are for subsets within a container or in multiple containers.

Group objects have two main purposes:

• They allow you to grant rights to a number of User objects at once.
• They allow you to specify login script commands using the IF MEMBER OF syntax.

Static Groups

Static groups identify the member objects explicitly. Each member is assigned to the group explicitly.

These groups provide a static list of members, as well as referential integrity between the members list of the group and the members of attributes on an object. Group membership is managed explicitly through the member attribute.

Dynamic Groups

Dynamic groups use an LDAP URL to define a set of rules which, when matched by eDirectory User objects, define the members of the group. Dynamic group members share a common set of attributes as defined by the search filter specified in the URL. For more information on the LDAP URL format, see RFC 2255.

Dynamic groups let you specify the criteria to be used for evaluating membership in a group. The actual members of the group are dynamically evaluated by eDirectory, which lets you define the group members in terms of a logical grouping and lets eDirectory automatically add and remove group members. This solution is more scalable, reduces administrative costs, and can supplement normal groups in LDAP to provide increased flexibility.

eDirectory lets you create a dynamic group when you want to automatically group users based on any attribute, or when you want to apply ACLs to specific groups that contain matching DNs. For example, you can create a group that automatically includes any DN that contains the attribute Department=Marketing. If you apply a search filter for Department=Marketing, the search returns a group including all DNs containing the attribute Department=Marketing. You can then define a dynamic group from the search results based on this filter. Any User added to the directory who matches the Department=Marketing criteria is automatically added to the group. Any User whose Department is changed to another value (or who is removed from the directory) is automatically removed from the group.

Dynamic groups are created in eDirectory by creating an object of type objectclass=dynamicGroup. A static Group object can be converted into a dynamic group by associating an auxiliary class, dynamicGroupAux, to the Group object. The dynamic group has the memberQueryURL attribute associated with it.

A dgIdentity attribute can be set on the Dynamic Group object to the distinguished name of an entry, whose credentials and rights should be used to expand the dynamic members of the group.

The groups are managed using the memberQueryURL. A typical memberQueryURL has a base DN, a scope, a filter, and an optional extension. The base DN specifies the search base. Scope specifies the levels below the base to search, and filter is the search filter based on which entries are selected from within the specified scope.

NOTE:  To address exceptions to the listing created by the memberQueryURL, dynamic groups also allow for explicit inclusion and exclusion of users.

Dynamic groups can be created and managed through Novell iManager. You can access the Dynamic Group management tasks by clicking the Dynamic Groups role on the Roles and Tasks page.

You can also use LDAP commands to manage such groups. The most useful properties associated with dynamic groups are dgIdentity and memberQueryURL.

Important Properties

The most useful properties of the Group object are Members and Rights to Files and Directories. For a complete list of properties, select a Group object in iManager. To display a description for each page of properties, click Help.

• dgIdentity

  This property holds the DN whose identity the dynamic group will use for authentication while searching. The identity must be on the same partition as the dynamic group. The object specified by dgldentity should have the necessary rights to do the search specified in the memberQueryURL attribute.

  For example, if memberQueryURL value is

  "ldap:///o=nov??sub?(title=*)"

  then dgldentity should have read/compare rights on the attribute title below the container o=nov.

• dgTimeout

  This property specifies the maximum duration a server can take to read or compare a member attribute before it times out. When the server exceeds this dgTimeout value, the -6016 error is displayed.

• memberQueryURL

  This property defines the set of rules that match with the attributes of the group members.

  memberQueryURL is a multivalued attribute according to its schema definition. Although memberQueryURL is multivalued, eDirectory 8.6.1 servers used only the first value of memberQueryURL.

  For example:

  An administrator creates a dynamic group, which has two memberQueryURL values:

  "ldap:///o=nov??sub?cn=*"

  "ldap:///o=org??sub?cn=*"

  eDirectory 8.6.x servers use "ldap:///o=nov??sub?cn=*" to compute the members of the group. They accept more than one query, but only read the first query.

  This limitation is overcome in eDirectory 8.7.1. eDirectory 8.7.1 servers compute the members based on all the memberQueryURL values, and the set of members is the union of the members computed using each of the memberQueryURL values.

  In the above example, resultant members of the dynamic group are all entries under o=org and o=nov, which have cn values.

• member

  This property lists all objects in the group. Rights assignments made to the Group object apply to all members of that group. Adding values to the member property of a dynamic group will add the static members to the dynamic group. This can be used for specific inclusion of members.

• excludedMember

  The property holds the DNs that are specifically excluded from the membership list of the dynamic group. This can be used to construct exclusion lists for dynamic groups.

  excludedMember is used to exclude DNs from being dynamic members of a dynamic group.

  Thus, a DN is a dynamic member of a dynamic group only if it is selected by the member criteria specified by memberQueryURL and is not listed in excludedMember or explicitly added to uniqueMember or member.

• staticMember

  This property reads the static members of a dynamic group and also determines whether a DN is a static member of a dynamic group. staticMember can find the dynamic groups in which a DN is a static member alone and can also find which groups have dynamic members and no static members.

  To add this property to the existing dynamic groups, extend the schema using dgstatic.sch.

Upgrading a Dynamic Groups on Pre-eDirectory 8.6.1 Databases

Dynamic groups functionality requires some internal values stored on the Dynamic Group objects, which are created either when a dynamic group is locally created or received as a part of synchronization.

Although older servers can hold dynamic groups, they are unable to generate these values, because dynamic groups were introduced in eDirectory 8.6.1.

In eDirectory 8.6.2, automatic upgrade of the Dynamic Group objects in a pre-8.6.1 database to match a eDirectory 8.6.1 database was implemented.

Support for Additional Syntaxes in memberQueryURL

The memberQueryURL attribute can hold a search filter that the eDirectory server uses to compute the members of a dynamic group.

In eDirectory 8.6.1, the syntaxes of attributes used in the filter were restricted only to the following basic string types:

• SYN_CE_STRING
• SYN_CI_STRING
• SYN_PR_STRING
• SYN_NU_STRING
• SYN_CLASS_NAME
• SYN_TEL_NUMBER
• SYN_INTEGER
• SYN_COUNTER
• SYN_TIME
• SYN_INTERVAL
• SYN_BOOLEAN
• SYN_DIST_NAME
• SYN_PO_ADDRESS
• SYN_CI_LIST
• SYN_FAX_NUMBER
• SYN_EMAIL_ADDRESS

In eDirectory 8.7.1, the following additional attribute syntaxes are supported in a memberQueryURL value:

• SYN_PATH
• SYN_TIMESTAMP
• SYN_TYPED_NAME

In both eDirectory 8.6.1 and eDirectory 8.7.x, binary syntaxes like SYN_OCTET_STRING and SYN_NET_ADDRESS are not supported in the memberQueryURL search filters.

For more information, see How to Manage and Use Dynamic Groups in Novell eDirectory.

Alias

You can create an Alias object that points to another object in the tree. An Alias object gives a user a local name for an object that lies outside their container.

When you rename a container, you have the option of creating an Alias in the former container's place that points to the new name. Workstations and login script commands that reference objects in the container can still access the objects without having the container name updated.

What an Alias Object Represents

An Alias object represents another object, which can be a container, User object, or any other object in the tree. An Alias object does not carry trustee rights of its own. Any trustee authority you grant to the Alias object applies to the object it represents. The Alias can be a target of a trustee assignment, however.

Usage

Create an Alias object to make name resolution easier. Because object naming is simplest for objects in the current context, you should create Alias objects there that point to any resources outside the current context.

For example, suppose users log in and establish a current context in the South container as shown in Sample Containers, but need access to the Print Queue object named ColorQ in the North container.

Figure 10
Sample Containers

You can create an Alias object in the South container, as shown in Alias Object in eDirectory Container.

Figure 11
Alias Object in eDirectory Container

The Alias object points to the original ColorQ object, so setting up printing for the users involves a local object.

Important Properties

Alias objects have an Aliased Object property, which associates the Alias object with the original object.

Directory Map

The Directory Map object is a pointer to a path in the server file system. It allows you to make simpler references to directories.

If your network has no NetWare volumes, you cannot create Directory Map objects.

What a Directory Map Object Represents

A Directory Map object represents a directory on a NetWare volume. (An Alias object, on the other hand, represents an object.)

Usage

Create a Directory Map object to make drive mapping simpler, particularly in login scripts. Using a Directory Map object allows you to reduce complex file system paths to a single name.

Also, when you change the location of a file, you don't need to change login scripts and batch files to reference the new location. You only need to edit the Directory Map object. For example, suppose you were editing the login script for the container South, shown in Figure 12.

Figure 12
Sample eDirectory Container

A command mapping drives to the Shared directory on volume sys: would look like the following:

MAP N:=sys.North.:Shared

If you created the Shared Directory Map object, the map command would be much simpler:

MAP N:=Shared

Important Properties

The Directory Map object has the following properties:

• Name

  Identifies the object in the directory (for example, Shared) and is used in MAP commands.

• Volume

  Contains the name of the Volume object that the Directory Map object references, such as Sys.North.YourCo.

• Path

  Specifies the directory as a path from the root of the volume, such as public\winnt\nls\english.

Profile

Profile objects help you manage login scripts.

What a Profile Object Represents

A Profile object represents a login script that runs after the container login script and before the user login script.

Usage

Create a Profile object if you want login script commands to run for only selected users. The User objects can exist in the same container or be in different containers. After you have created the Profile object, you add the commands to its Login Script property. Then make the User objects trustees of the Profile object and add the Profile object to their Profile Membership property.

Important Properties

The Profile object has two important properties:

• Login Script

  Contains the commands you want to run for users of the Profile.

• Rights to Files and Directories

  If you have INCLUDE statements in the login script, you need to give the Profile object rights to the files included with the Rights to Files and Directories property.