Missing default public / root trustee assignments throughout the eDirectory Tree

  • 7010520
  • 25-Jul-2012
  • 05-Dec-2012


NetIQ eDirectory


Login scripts are failing to execute due to insufficient rights.

After adding root as a trustee of the organization, or Tree Root object with Read and Compare rights to all attributes, the login script works.

By default in default tree, when a user, group, volume or other objects are created, there are some explicit trustee assignments given to those individual objects for root and/or public.   If that trustee right, typically read, already exist for that object, (like when they are already granted at the top of the tree and are flowing down), then the default explicit trustee assignments are not placed on the object.   This is easily enough to duplicate, as you can create and object in the tree when you have root/public as a trustee of the root of the tree with read/compare rights, then remove the trustee and create the object.   The public/root trustee right to the object is there or not there, depending upon whether the rights existed prior to the creation of the object.

So if there was an explicit trustee assignment at the root of the tree for public and/or root which gave users read and compare rights to all attributes.   (This assignment is not there by default but was placed there at some point.)   Then when objects (users, groups, volumes, etc) were created while this trustee assignment was in place, in which they inherited rights from, then the newly created objects may be missing trustee assignments for public and/or root on them.

The end result is that you have users, volumes, groups  and potentially other objects are missing the default explicit public / root trustee assignment on them.


That makes it a difficult situation to resolve as each object has to be modified to add the public/root trustees back. 

The workaround is to add root as a trustee of the root of the tree (or organization object(s) with read and compare rights on all attributes to the top of the tree.  

The fix is to determine what the default public/root trustee assignment should be on the object and then add it back to each object.  

The best approach is to install a server into a new tree and see the default trustee assignments on the objects and determine if root/public is there and what rights it has.   Then create a script to export a ldif command to recreate the rights on the user/objects if they are missing the trustee assignment in the production tree.  Then execute the ldif import to recreate the rights.   This process will have to be done on each trustee assignment for each attribute, on each object class.

The solution of adding the trustees back would have to be implemented in a short time frame, because if you create another object after exporting the ldif command and importing it, but before removing the workaround, that new object would have the same issue on it.


Default Public and/or Root trustee assignments are missing on objects (users, groups, volumes, etc)

Additional Information

Below is a list of basic objects in eDirectory that have a default explicit trustee assignments for Public and/or Root on them.  This list may not be all inclusive.

Tree Root Object
        Entry Rights - Browse, Inherit
        sssActiveServerList - Read

        Message Server - Read
        Group Membership - Read
        Network Address - Read

        Member - Read

        Host Resource Name - Read
        Host Server - Read

NCP Server
        Messaging Server - Read

NDSPKI:KeyMaterial (sever certificate)
        Host Server - Read

SAS:Security (Security container object)
        NDSPKI:Tree CA DN - Read

NDSPKI:Certificate Authority (Tree CA)
        Cross Certificate Pair - Read
        Host Server - Read

Additional  objects that have, or may have Public / Root rights to them.

(Novell NW 6 License container object)
        All Attributes - Compare, Read, Inherit
        Entry Rights - Browse, Inherit

(NLS_LSP object)
        Network Address - Read

    Public  (An OES install adds these rights to the O, a newly created O does not have them)
        Entry Rights - Browse
        Description - Compare, Read, Inherit
        gecos - Compare, Read, Inherit
        gidNumber - Compare, Read, Inherit
        homeDirectory - Compare, Read, Inherit
        loginShell - Compare, Read, Inherit
        memberUid - Compare, Read, Inherit
        uamPosixSalt - Compare, Read, Inherit
        uamPosixWorkstationContexts - Compoare, Read, Inherit
        uamPosixWorkstationList - Compare, Read, Inherit
        uidNumber - Compare, Read, Inherit

If you users are missing these exact default rights, please contact NetIQ support.   They may be able to provide script files to assist you with this issue.