If you use iManager, you should be familiar with the concept of Role-Based Services. The idea behind it was to abstract away the eDirectory trustees of Browse, Compare, Create, Delete, and so on, and instead allow a right such as Create User, or perhaps a Helpdesk role that can do whatever your Helpdesk needs to do.
You can select which users belong to a role, what the role contains, and allow the role to grant the rights to do the actual back-end stuff.
One of the things that can make administering Role-Based Services difficult is that sometimes you need to be the Owner of the collection, in order to do some maintenance tasks. Of course, the solution is to log in as the Owner of the collection and grant the account you want to use access.
But wait, you do not know the credentials for that account. Ah, so now we run into the difficult problem that iManager as a management tool often gets us into. Sometimes to fix a problem with iManager, you need a working iManager to fix it!
This can be quite frustrating. The most common example I can think of is LDAP management. If your LDAP server’s settings are somehow modified such that iManager will not work, you are supposed to use iManager to fix it. ConsoleOne’s snap-ins do not support all the features in later eDirectory versions of the LDAP snapin, so you really need to be careful to do the minimal amount of work in Console One lest you cause potential problems. (The worst part is that you do not really know what is different, and what not to touch.)
OK, it’s accepted that you need to use iManager to fix LDAP in for your iManager server. Um, well – where do I go now? The answer is usually to install iManager Mobile or use another iManager instance somewhere else that is still working to fix this server’s instance. Not a great solution, but it usually works.
Also complicating the issue is that a single eDirectory tree can have as many Role-Based Services collections as you would like. Oh, and did I mention that between versions 1 and 2 of iManager, the schema changed? That means you can have a 1.x-compatible Role- Based Services as well as a 2.x compatible Role-Based Services collection container.
Normally, being an Admin user in the tree is sufficient to perform any task, but in the case of Role-Based Services, you need rights inside iManager in order to manage it.
Now the good news is that with objects in eDirectory, of course, the owner is stored in attributes, and as an Admin you can manipulate those attributes.
The object class is rbsCollection2 (to distinguish between that and rbsCollection for V1.x iManager collections). If you look at the schema (via ConsoleOne’s Schema manager – or via DSBrowse on Netware or Windows at the rbsCollection2 object, then Optional Attributes) you should see an attribute called Owner. This is Distinguished Name syntax, so it’s nice and easy to set via your tool of choice and give it the distinguished name of the Admin user you want to add.
Now if you go into iManager, you will still not be the Collection Owner, which is the goal here.
It turns out that ownership of a collection is sort of like Group membership, in that it is a reciprocal pair of attributes. What that means is that the rbsCollection2 object has a DN syntax attribute that holds the name of the Owner. The User gets an attribute called rbsOwnedCollections2 (again to differentiate between the V1.x attribute of rbsOwnedCollections), that holds the Distinguished Name (DN) of the Role Based Services Collection (version 2) object that you are owner of.
So it is not enough to set just one – you have to set both of them.
There is a lot of benefit to a model like this. The obvious example is that you can look at a User and know what RBS collection they own. You can look at an RBS Collection and know who the owners are. It just means you need to maintain both. Now of course, if you grant ownership via iManager it does this for you in the background.
It is only in that annoying case of needing the tool to fix the tool, that you need to know this detail.