Removing Unwanted and Unknown ACL's

Novell Cool Solutions: Feature
By Leonard Holling

Digg This - Slashdot This

Posted: 12 Oct 2006

Do you use Organizational Roles in NetWare and block the ACL for the Roles so that the security on your user context cannot be altered?

If so then you may have a security hole that you are not aware of. When you have a "local admin" that creates a new user account, eDirectory (due to ACL blocking) adds the creating "local admin" userid to be a trustee of the newly created user. Normally this would not be a problem but let's say that the "local admin" person changes jobs or moves to another part of your business then the security issue arise.

Due to the old "local admin" userID still having a trustee of the userID they created, they can modify any of the attributes of the user - even when they are removed from the Organizational role that allowed them to create the user in the first place.

You can easily check this by using ConsoleOne and looking at the trustees of a userID that was created by one of these types of local admins. At the company I work for most of the userids are created by the Response Centre.

Here is an example of how blocking the ACL causes this problem.

Organization Role that has ACL blocked

The user called "localadmin" is a member of the Organizational Role called OrgRole

When you create a new user and look at the trustees of that newly created user, you'll see something like this:

As you can see, the localadmin user now has Supervisor rights over the user it created. If it were not for the ACL attribute, this would not be the case.

Information about this problem is contained in TID 10080778. We then asked Novell Support for clarification on this, as the TID mentioned there was enhancement request to fix it. Here is what we were told:

"In eDirectory 8.7.3 an enhancement was added that allows the ACL templates to be modified in schema. These ACL templates determine what rights are granted when an object is created. There is an ACL template on the schema class "Top" that grants the creator of an object supervisor rights to the object being created. The ACL template on the "Top" class is a safety to make sure no object is created without someone who has supervisor right to it. Taking away the ACL will take away this safety. In your case you would need to modify this ACL template for "Top" in order to have the container administrator's function as you would like.

Modifying the ACL templates is not something that should be done lightly, and the ramifications of this should be understood clearly before you take any action. This will affect the creation of ALL objects in the tree. If something goes wrong, you may experience unexpected results. Whatever changes you make will be synchronized across the servers, and it will be very difficult to roll back. A mistake can cause the whole tree to become unknown! If you would like to implement it, then I would suggest you to try it on a test environment. I would not recommend making these kinds of changes to the production tree without testing it on a lab setup. Then you should test all other aspects of it and be confident enough to roll out the change."

Extremely scary for anyone!

Anyhow, we found a workaround for our problem using the famous JRB Utilities. We have a scheduled weekly script that gets all the userids from all of the Organizational Roles in the tree, sorts the entries using Perl (to remove duplicates), and then removes the offending ACL from the userIDs.

Here's what you need once you have Perl installed and JRB Utilities. We use the free Active Perl from the following url http://www.activestate.com/Products/ActivePerl. The JRB Utilities that you need are ORGROLES and FINDREF.

Here is the batch file that we run:

orgroles * /r /x /yd /j /v /l=aclremovelist.log,nowrap /n
perl orgroles.pl < aclremovelist.log > aclremovelist.txt 
findref @aclremovelist.txt /o=user /a=acl /d /l=aclremove.log,nowrap /e=aclremove.err,nowrap

And here is a copy of the Perl script orgroles.pl. All users are in a context called Users for each of the sites hence the use of ".*.Users.*" in the Perl script.


# How to run me
# perl OrgRoles.pl < aclremovelist.log

my ( $sort_string ) = ".*.Users.*\.[NHAGVIM]" ;

while (  )
  chomp ;
  next if ( !/$sort_string/ ) ;
  next if ( /Occup/ ) ;
  $_ =~ tr/A-Z/a-z/ ;
  $array { $_ } = $_ ;

foreach ( sort ( keys %array ) )
  print $_, "\n" ;

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© Micro Focus