Setting Up Admin Container Rights
Novell Cool Solutions: Tip
By Aaron Burgemeister
Digg This -
Posted: 14 Mar 2007
A Forum reader recently asked:
"In our current environment, we only have one admin under a container, therefore we will be out of luck if the admin get locked or accidentally get removed. We would like to come up with a solution that will prevent this situation.
One solution is to create more admins and a group that has S right to the root of the tree, and then add all the admins to the group. I have a few questions about this approach.
1) Besides giving additional admin the S right to the root of the tree, should I assign all the roles that current admin has to the additional admin?
2) I have all the drivers "security equals" current admin. I also have the current admin as "exclude user" on all the drivers. Do I need to add an additional admin to these two variables?"
And here's the response from Aaron Burgemeister ...
To create another admin who is truly as powerful as the original, simply give S rights to [Entry Rights] at the root of the tree (tree object) - Inheritable. End of story (unless you are using IRFs). Groups are okay, but when you delete your group you're out of luck. Roles are the same (but when you delete it you're out of luck for all admins). Creating admins from roles is great, but for your alternate "oh-shoot-I-messed-up admin," I would make it explicitly equivalent to the tree.
Regarding your drivers, you shouldn't be setting them equivalent to admin. Admin is great for getting it going initially or getting it going in test (to prevent rights issues), but the principle of "least-privilege" is a very good thing and the right way to do anything in IT (and even in other places of your life). In my tree I do the following, which works well (at least for me if not others):
dc=idm,dc=service,dc=system contains my DriverSet(s) for the tree.
This container is dedicated to IDM services in my tree (system). I also create any roles needed for IDM (for its drivers) in this same container. The role names are usually like "DriverNameDriverSetNameRole" - the names are long, but nobody cares because they are only used for rights. The role has all the rights the driver needs (and NO MORE), and the driver is security-equiv to that role. If the role is deleted, only one driver dies. If the "admin" dies, the role still survives because it is explicitly getting rights.
This provides some nice organization for the tree, because all my services (IDM, LUM, RBS, servers etc.) are in a separate part of the tree from the main users. Users are in my dc=org container (under their organizations, like o=novell, o=suse, etc.) in whatever structure I want.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com