Check Password Synch Status as a Non Administrative Task.
Addressing Excessive RBS default rights.
This document assumes basic knowledge of iManager, eDirectory, RBS and RBS Custom task configuration.
While this document focuses on the specific “Check Password Synch Status” task, the concepts can be applied to any number of roles wherein the default RBS assigned rights are excessive.
Scenario: I wanted to setup a limited role that allowed members to check the password synchronization status of users across a set of IDM drivers. So I built a custom role containing only that task. During creation of that task, I noted (as in the screenshot) that there was a “Rights Advisory… Supervisory”
Intriguing as that was, I pressed on.
After creating the role, I had to associate a couple of different members, and I discovered another intriguing fact about RBS Role Member associations. First, I assign a user to have the right to do this task across the entire tree.
Here’s the member association:
And here is the resulting trusteeship …
So far, exactly as expected… a Role Object, part of my RBS container, is assigned as a trustee of [root] any member of that role will get the rights it assigns, which are…
Supervisor of the tree? Really? It takes supervisor rights to the assigned scope to view a user’s IDM Password Synch Status? (It doesn’t, but I don’t want to get ahead of myself.)
Let’s make another member association. This time I want to make a Group have the rights at the root.
I assumed that, as an associated member of the role, it would get the benefits of the trusteeship already established for the individual user in the previous step. What is it they say about not assuming?
Apparently, eDirectory does not calculate inherited rights from an RBS role, through a Group, to a User. So instead of using the existing RBS role object trustee, the RBS system establishes additional trusteeships for Groups that are members. And, yes, the Group is assigned the Supervisor right to the specified scope… in my case, to the [root].
So what’s the problem? Using iManager, the user is still limited to only checking password statuses, right? Sure. But, if the user accesses the tree via means other than iManager, they have Supervisor rights to the tree. ConsoleOne, Novell Client, NWAdmin32…
FIX AND RECOMMENDATIONS:
There is a fix, and short of reprogramming the NPM or creating a custom NPM, there are a couple of recommendations on how to approach the use of roles for which you have to modify the default rights.
The picture that follows demonstrates the specific rights required to allow a user to Check DIRXML Password Synch Status.
WHERE these rights are granted apparently matters, though I have not investigated…Since the right to use the DirXML-AccessCheckObjectPassword implies sending a document through the drivers, these rights must be assigned at a level that will inherit to the Driver Set, as well as to all the users on which you want this role to be able to verify password synch status.
Bottom line: It is possible to modify the default rights assigned by any RBS Role, to eliminate security risks. What ACL modifications and where to place them in your tree is up to you to find out for each specific case.
All is well, right? Not so fast. What happens when you add another member to the role, at ANY level of the tree? You will find that ALL members have the ACL’s reset to the default of Supervisor, at the level/scope which they are defined.
No matter how much careful work you put into setting the correct level of rights for this role, throughout your tree, when you add a single new member association it will all be undone.
Again, short of reprogramming default NPM’s, or copying and creating custom NPM’s so that they do NOT assign overbroad rights, you need to manage the problems presented with as little effort as possible. There are two ways to minimize the problem in this case:
- Assign/Associate only “Groups” to your custom role for Password Sync Status. This gives you the flexibility to add new people to the roles without causing the “re-set” of ACL’s on the scoped OU’s.
- If you require varying groups to have varying rights at different levels of the tree, assign/associate those Groups to the role at their respective scopes.
- AFTER assigning all members to the role, go to each scope OU level where you assigned a group to use this role, and modify the assigned rights as depicted earlier.
- Strictly manage/control who adds member associations to roles that assign excessive rights. You must be aware when someone makes a change that is going to suddenly assign supervisor rights to multiple people in the tree.
- Adopt a method for managing the rights whenever a new user or group is added as an RBS Role member.
- Export the ACL’s for those OU’s and create an LDIF file so that future re-establishment of these rights is easier and less “manual.”
- Then, when you add new group assignments to new scopes It should be a simple task to cut/paste a section for any new “role” or “group” ACL that gets added as a result of new Member Associations to new scopes.
- After modifying the LDIF file to contain a section for the newly associated member(s), reimport it to quickly re-establish the correct rights.
This method is practical if you have a role with multiple scopes, multiple individual user memberships… in other words, a lot of ACL’s that will be modified when a new member is added.
If you have a single scope, manually modifying the attributes on group and role trustees may be manageable.
That’s all well and good if you are NEVER going to add another member association to a role. Since every NEW member association will reset the ACL’s for all existing members, and since it is impractical to think your role will be setup correctly and finally on day one, it makes sense that you need to manage the ACL’s after new members are added.
Demonstrating the techniques for establishing such an LDIF file are beyond the scope of this document.