Novell Home

My Favorites

Close

Please to see your favorites.

Is it possible to block attribute rights for container administrators?

(Last modified: 24May2006)

This document (10080778) is provided subject to the disclaimer at the end of this document.

goal

Is it possible to block rights for an attribute from container administrators?

fact

Novell eDirectory 8.6 for All Platforms

Novell eDirectory 8.7 for All Platforms

With eDirectory 8.6 and 8.7 this is only partially possible.

symptom

Administrative scheme is to use main tree administrators and container administrators.

All user objects will have the workforceID attribute populated with their social security number.

The main tree admins will have complete access to this attribute.

For security reasons it is desired that the container admins should have NO rights to this attribute including browse.

fix

This can be done by performing the following. At the container level make the container admin a trustee of the container with Entry rights of browse, create, rename, and delete. Give the container admin the attribute rights for workforceID, but then assign no actual rights (all boxes unchecked). This allows the admin to be able to create users in the container but not see the workforceID attribute on existing user objects.

This works fine for existing users in the container. The container admin is not able to view the workforceID attribute. However, when the container admin creates a new user they are made a trustee of that new user with supervisor entry rights by default and therefore can then see the workforceID attribute on the users they create. This is the case no matter what you try in terms of IRF's and rights assignments. This is how the default rights are designed to function.

This functionality is only possible with user objects created before the container administrator is assigned.  By default a container admin is assigned supervisor entry rights for any user object they create and therefore have access to all the attributes of that object. This is because the base schema definitions specify this behavior. The only way to change this behavior is to modify the base schema for the entire tree. Modifying the base schema is a very serious procedure and should not be attempted unless the full ramifications of the change are understood. It is highly recommended that any change of this nature be tested in a lab environment prior to being used in production. TID 10092621 "How to Modify the default ACL Templates in Schema" covers the procedure to make these schema changes.

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

  • Document ID:
  • 10080778
  • Solution ID: NOVL87534
  • Creation Date: 04Mar2003
  • Modified Date: 24May2006
    • NetIQeDirectory

Did this document solve your problem? Provide Feedback