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.
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.
iManager Icon | Container Object (Abbreviation) | Description |
---|---|---|
Tree |
Represents the beginning of your tree. For more information, see Tree. |
|
Country (C) |
Designates the countries where your network resides and organizes other directory objects within the country. For more information, see Country. |
|
License Container (LC) |
Created automatically when you install a license certificate or create a metering certificate using Novell Licensing Services (NLS) technology. When an NLS-enabled application is installed, it adds a License Container container object to the tree and a License Certificate leaf object to that container. |
|
Organization (O) |
Helps you organize other objects in the directory. The Organization object is a level below the Country object (if you use the Country object). For more information, see Organization. |
|
Organizational Unit (OU) |
Helps you to further organize other objects in the directory. The Organizational Unit object is a level below the Organization object. For more information, see Organizational Unit. |
|
Domain (DC) |
Helps you to further organize other objects in the directory. The Domain object can be created under the Tree object or under Organization, Organizational Unit, Country, and Locality objects. For more information, see Domain. |
iManager Icon | Leaf Object | Description |
---|---|---|
AFP Server |
Represents an AppleTalk* Filing Protocol server that operates as a node on your eDirectory network. It usually also acts as a NetWare router to, and the AppleTalk server for, several Macintosh* computers. |
|
Alias |
Points to the actual location of an object in the directory. Any directory object located in one place in the directory can also appear to be in another place in the directory by using an Alias. For more information, see Alias. |
|
Application |
Represents a network application. Application objects simplify administrative tasks such as assigning rights, customizing login scripts, and launching applications. |
|
Computer |
Represents a computer on the network. |
|
Directory Map |
Refers to a directory in the file system. For more information, see Directory Map. |
|
Group |
Assigns a name to a list of User objects in the directory. You can assign rights to the group instead of to each user; then the rights transfer to each user in the group. For more information, see Group. |
|
License Certificate |
Use with NLS technology to install product license certificates as objects in the database. License Certificate objects are added to the Licensed Product container when an NLS-aware application is installed. |
|
Organizational Role |
Defines a position or role within an organization. |
|
Print Queue |
Represents a network print queue. |
|
Print Server |
Represents a network print server. |
|
Printer |
Represents a network printing device. |
|
Profile |
Represents a login script used by a group of users who need to share common login script commands. The users don't need to be in the same container. For more information, see Profile. |
|
Server |
Represents a server running any operating system. For more information, see Server. |
|
Template |
Represents standard User object properties that can be applied to new User objects. |
|
Unknown |
Represents an object for which iManager has no custom icon. |
|
User |
Represents the people who use your network. For more information, see User. |
|
Volume |
Represents a physical volume on the network. For more information, see Volume. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The Country object represents the political identity of its branch of the tree.
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.
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.
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:
DC=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.
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.
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.
The Server object represents a server running eDirectory or a bindery-based (NetWare 2 or NetWare 3) server.
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.
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.
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.
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.
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.
In addition to the required Name and Host Volume properties, there are other important Volume properties.
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.
This is the server that the volume resides on.
This is the NetWare or eDirectory version of the server hosting the 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.
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:
For more information on iManager, see the Novell iManager 2.0.x Administration Guide.
For more information on using batch files, see Designing the eDirectory Tree.
For more information on upgrade utilities, including importing users from existing bindery servers, see Designing the eDirectory Tree.
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
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.
The directory referred to in this property can be automatically created when you create the User object.
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.
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.
You can create Group objects to help you manage sets of User objects.
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:
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 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.
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.
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.
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.
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.3. eDirectory 8.7.3 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.
The memberQuery URL supports two URL extensions:
The request is chained if the URL value contains x-chain extension.
Example:
ldap:///O=org??sub?(objectClass=inetOrgPerson)?x-chain
The sparse replicas are considered for dynamic group member search queries if the URL value contains x-sparse extension.
ldap:///O=org??sub?(objectClass=inetOrgPerson)?x-sparse
IMPORTANT: These extensions are mutually exclusive. When x-chain is present, x-sparse is automatically ignored.
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.
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.
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.
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.
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:
In eDirectory 8.7.3, the following additional attribute syntaxes are supported in a memberQueryURL value:
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.
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.
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.
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 Figure 6, but need access to the Print Queue object named ColorQ in the North container.
Figure 6You can create an Alias object in the South container, as shown in Figure 7.
Figure 7The Alias object points to the original ColorQ object, so setting up printing for the users involves a local object.
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.
A Directory Map object represents a directory on a NetWare volume. (An Alias object, on the other hand, represents an object.)
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 8.
Figure 8A 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
The Directory Map object has the following properties:
Identifies the object in the directory (for example, Shared) and is used in MAP commands.
Contains the name of the Volume object that the Directory Map object references, such as Sys.North.YourCo.
Specifies the directory as a path from the root of the volume, such as public\winnt\nls\english.
Profile objects help you manage login scripts.
A Profile object represents a login script that runs after the container login script and before the user login script.
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.
The Profile object has two important properties:
Contains the commands you want to run for users of the Profile.
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.