Using [This] to replace ACL Template on User object

The default User Class Definition includes the following ACL definitions. The special thing about the ACL Template is that during the object creation, these rights are evaluated, and if the designated Right is already present, then an additional ACL to grant that right is not added to the object.

Screen capture from iMonitor of the Tree root object

In a default installation, the Tree root object will have the ACLs shown above. The first grants the Admin object Supervisor rights for the whole tree. The second grants [Public] (any non-authenticated connection, such as an LDAP anonymous bind) the right to browse entries, or in other words, see the names of the objects in the tree. This only allows the such a client to see the names of objects, and also the ability to read any attributes flagged in schema as “Public Read”. The other three ACLs are feature specific ACLs. The third and fourth ACLs here use a special trustee target of [This]. Like [Public], [This] is not a real object. What it refers to is the specific object where rights are being evaluated. So these next two ACLs grant Write rights (Self is not meaningful here) to the nsimHint and nsimPasswordReminder attributes for individual objects. This means that every user (or other object) can modify their own nsimHint attribute, but not see or modify any other user's nsimHint attribute, for example. The last ACL grants [Public] the right to read the sssActiveServerList attribute, which allows unauthenticated connections the ability to find a Server running SecretStore to finish the login process.

The original ACL Template on a User Object contains the following:

Screen capture from iMonitor of the ACL Template section of the User class definition

Some of these rights are generic, thus the rights for [Root Template], which will translate to the Tree root object, are the same on every object. But the rights for [Self] which is a special target meaning the object itself, end up creating an ACL with the object itself as the trustee for its own attribute.

Screen capture of ACLs section of the One.test.novell object

Note that there is a specific ACL created for each of the values from the ACL Template, except for the third value, which grants [Entry] Browse rights to [Root]. This ACL is suppressed, because of the already existing ACL on the tree root granting [Entry] Browse rights to [Public]. Thus an additional ACL is not needed for any object to receive that particular right.

With that knowledge, we can grant new inheritable ACLs at the Tree root, and suppress all the initial ACLs, or replace the rights granted individually on each object with inheritable rights for all objects, which cuts down dramatically on the number of ACLs present in the tree, and the number needed to be evaluated to determine appropriate rights for any given operation.

We can use the special ACL target [This] in place of the ACL template target [Self]. Thus if we add new ACLS to the Tree root object to make it look as follows (new ACLs from the Message Server down):

Screen capture from iMonitor of newly added inheritable ACLs

Note that this shows a line for Browse [Entry Rights] for [Public] and a line for Browse [Entry Rights] for the Tree Root object. Rights for the Tree Root object mean that any logged in connection will have those rights, whereas [Public] rights are given even to not logged in connections. In this case, the rights for the Tree Root object are extraneous, since the [Public] rights are greater. That particular ACL was added just to show how to match the original rights from the ACL template.  Also, unless you are still using the now ancient queue based NetWare printing, you likely don't need the ACL for "Print Job Configuration".

Now creating a new user Two.test.novell generates no ACLs on the user object, but yet Two still has the exact same rights as the One user created earlier. Note that if you change your mind, and decide to go back to using the ACL template and having specific ACLs on the user objects (which means removing the ACLs just added on the Tree Root object) that any object created while those ACLs were in effect will now not have the desired rights. You will have to go and manually add the necessary rights to restore the missing rights.