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…
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:
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.
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.
Demonstrating the techniques for establishing such an LDIF file are beyond the scope of this document.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.