1.2 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 First Name, 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.

1.2.1 List of Objects

The following tables list eDirectory object classes. Added services can create new object classes in eDirectory that are not listed below.

eDirectory Container Object Classes

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 NetIQ 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.

eDirectory Leaf Object Classes

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 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. The rights then 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.

1.2.2 Container Object Classes

Tree

Tree object icon 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.
Tree name cannot exceed 32 characters.

Organization

Organization object icon 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 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.
Organization name can be 64 characters long.

Organizational Unit

Organizational Unit object icon 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.
Organizational Unit name can be 64 characters long.

Country

Country object icon 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.
Country name cannot exceed 2 characters.

Domain

Domain icon 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

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

Domain name can be 64 characters long.

1.2.3 Leaf Object Classes

Server

Server object icon 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.

What a Server Object Represents

The Server object represents a server running eDirectory or a bindery-based 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

Volume object icon 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).

Linux file system partitions cannot be managed using Volume objects. Volume objects are supported only on OES Linux.

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.

Important Properties

In addition to the required Name and Host Server 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 eDirectory version of the server hosting the volume.

User

User object icon 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 NetIQ iManager 2.7 Administration Guide.
Batches from database files

For more information on using batch files, 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.
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™ 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 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

Group object icon 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 distinguished names (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 memberQueryURL, dynamic groups also allow for explicit inclusion and exclusion of users.

Dynamic groups can be created and managed through NetIQ iManager. You can access group management tasks by clicking the 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.

dgAllowDuplicates

Specifies whether or not duplicates are allowed while printing dynamic group members. The default is TRUE.
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
```
l"dap:///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:
```
l"dap:///o=nov??sub?cn=*
```
```
l"dap:///o=org??sub?cn=*
```
eDirectory 8.6.x servers use l"dap:///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 was overcome in eDirectory 8.7 and later. Now eDirectory 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 Dynamic Groups on Pre-eDirectory 8.6.1 Databases

Dynamic group 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

From eDirectory 8.7.3 onwards, 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.

IMPORTANT:The Novell Storage Services (NSS) volumes and NCP (Netware Control Protocol) volumes use the Novell Trustee Model to secure access to directories and files. eDirectory does not support assigning dynamic groups as NSS trustees. Although it is possible to add these groups as trustees in NSS volumes, NSS does not recognize the rights assigned to them as applying to group members.

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

Nested Groups

Nested groups allow grouping of groups and provide a more structured form of grouping. An attribute called groupMember is introduced to specify the nested groups whose members become nested members of the containing nested group object. Group objects are specified statically in the groupMember attribute. The group containing other groups is referred to as the containing group, and the groups that are part of this group are referred to as contained groups. Currently, nesting is allowed only for static groups (not dynamic groups). Nesting can have multiple levels up to 200.

IMPORTANT:Nesting is supported within the local server only. If a contained group is not found on the local server, its members are not listed as the nested members of the containing group.

Figure 1-4 Nested Groups

You can use iManager or LDAP tools to create the nested groups.

Creating Nested Groups by Using LDAP Tools

You can use LDAP tools to create the nested groups. A new auxiliary class, nestedGroupAux, along with the structural class Group represents a nested group. This auxiliary class can be added to the existing static group object to convert it into a nested group.

Both the contained and the containing group should be nested group objects. Only when the contained group is a nested group, it can populate the groupMembership attribute ( groupMembership attribute not a part of static group) on it to specify the containing group. If the contained groups are found to be static group objects or dynamic group objects, only the static members of the static or dynamic group objects are listed as nested members.

You can use LDIF files and LDAP tools to manage such groups. The most useful properties associated with nested groups are groupMember and nestedConfig.

Creating Nested Groups by Using iManager

You can use iManager 2.7 SP1 or later plug-ins to create a nested group or to change a static group to a nested group in order to associate it with another group.

Log in to iManager 2.7 SP1 or later with administrator credentials and select Groups > Create Group from the left panel to create a static group. For example, SG1.
Select Directory Administration > Modify Object from the left panel, then browse to and select the SG1.novell object.
Click the Other tab, then select Object Class from the Unvalued Arributes list.
Add the nestedGroupAux value to the Object Class, then click OK and Apply.
Select Groups > Create Group from the left panel, select the Nested Group checkbox to create a nested group with the name NG1, then click OK.
Select Groups > Modify Group from the left panel, select the Nested Group checkbox to modify the nested group with the name NG1, then click OK.
To modify the nested group, select Groups > Modify Group, then browse to and select NG1.novell.
To associate a static group to NG1, select the Nested tab > Group Member tab, then browse to and select the SG1 static group.
Click Apply, then click OK to convert the SG1 static group to the NG1 nested group.

The static group that you converted to a nested group is now a member of the static group.

To verify the membership details of SG1, select Groups > Modify Group from the left panel, then select SG1.novell. Select the Nested > Group Membership tab to verify the static group's membership information as NG1.novell.

Nested Group Properties

groupMember

By default, the members of a nested group include all the nested members. Therefore, the member attribute listing always returns all the nested members, and the assertion on the member attribute returns all the nested group objects. If the configuration is set to 1 (no nesting), it refers only to the direct members.
Group Membership

groupMembership specifies the group that this object (generally a user object) belongs to. This attribute is associated with the nestedGroupAux class, and it holds the DN of the nested group of which this group is a group member. When associated with a group object, it indicates the nested group of which this group is a member (specifically a groupMember). Similar to member and groupMember, groupMembership lists all the nested groups of which this group has a groupMembership via a nested relationship. The nestedConfig also applies to the groupMembership attribute. For non-group member objects, the nestedConfig of individual groups is used.
nestedConfig

nestedConfig sets the configuration of the nested group object. The configuration values currently supported are 0 (nesting local server) and 1 (no nesting). By default, it always nests the local server. If only direct values such as member, groupMember, or groupMembership are to be listed for the attribute, the configuration can be set to 1.
excludedMember

excludedMember is included as part of the nestedGroupAux class, but it is currently not used. In future, it will indicate members that are to be excluded from nested members, analogous to dynamic groups.

Nested Group Operations

One group can be a member of another group via the groupMember attribute. Both groups, contained as well containing, must have the nested group auxiliary class associated with the group object.

dn: cn=finance,o=nov

objectclass: group

objectclass: nestedGroupAux

groupMember: cn=accounts,o=nov

member: cn=jim,o=nov

dn: cn=accounts,o=nov

objectclass: group

objectclass: nestedGroupAux

member: cn=allen,o=nov

member: cn=ESui,o=nov

member: cn=YLi,o=nov

Reading the member attribute of a nested group also causes the members of the contained group to be returned if both the contained and the containing group are present locally on the server:
```
dn: cn=finance,o=nov
member: cn=jim,o=nov
member: cn=allen,o=nov
member: cn=ESui,o=nov
member: cn=YLi,o=nov
```
The same holds true for the groupMember attribute.
The reciprocal attribute to the member attribute is groupMembership. This implies that the cn=allen,o=nov user object needs to possess the groupMembership attribute populated with the cn=accounts,o=nov group DN. The groupMembership of the cn=accounts,o=nov group needs to be populated with cn=finance,o=nov. On reading the groupMembership attribute of the cn=allen,o=nov user object, both the groups are returned.
```
dn: cn=allen,o=nov
groupMembership: cn=accounts,o=nov
groupMembership: cn=finance,o=nov
```
The ACLs can be assigned to a nested group and all the objects that are members of the nested group will acquire the rights. In the assigned rights field, an additional nested ACL bit (0x80000000) needs to be set in addition to the rights being assigned.
```
dn: cn=finance,o=nov
groupMember: cn=accounts,o=nov
```
```
dn: cn=accounts,o=nov
member: cn=allen,o=nov
```
```
dn: ou=MyCo,o=nov
objectclass: Organizational Unit
ACL: 2147483650#entry#cn=finance,o=nov#[All Attributes Rights]
```
The rights value – 2147483650 (0x80000002) has nested ACL (0x80000000) and read rights bit (0x00000002) set. So, the user object cn=allen,o=nov has been granted read rights on all attributes of the MyCo object via the nested group cn=finance,o=nov.
Applications can use filter assertions on the member, groupMember, and groupMembership attributes. In the above example, an assertion of member=cn=allen,o=nov would return the following:
```
dn: cn=accounts,o=nov
dn: cn=finance,o=nov
```
An assertion of groupMembership=cn=finance,o=nov would return the following objects:
```
dn: cn=allen,o=nov
dn: cn=jim,o=nov
dn: cn=ESui,o=nov
dn: cn=YLi,o=nov
dn: cn=accounts,o=nov
```
NOTE:There is no limit on the levels of nesting in any of the above cases. Loop detection in nested groups is done while any of the above mentioned attributes are read.

Limitations

Nested relationships do not span beyond the local server. The objects, users, and groups involved need to be locally present on the server.
No duplicate elimination is done in membership listing.
Nesting of dynamic groups is not supported.
Nested ACLs as well as the nesting semantics are not supported on older eDirectory servers (version 8.8 SP1 and earlier).

IMPORTANT:The Novell Storage Services (NSS) volumes and NCP (Netware Control Protocol) volumes use the Novell Trustee Model to secure access to directories and files. eDirectory does not support assigning nested groups as NSS trustees. Although it is possible to add these groups as trustees in NSS volumes, NSS does not recognize the rights assigned to them as applying to group members.

Alias

Alias object icon 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 Figure 1-5, but need access to the Print Queue object named ColorQ in the North container.

Figure 1-5 Sample Containers

You can create an Alias object in the South container, as shown in Figure 1-6.

Figure 1-6 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

Directory Map object icon 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 volumes, you cannot create Directory Map objects.

What a Directory Map Object Represents

A Directory Map object represents a directory on a 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 1-7.

Figure 1-7 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 object icon 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.