Article

So, stumbling along toward a potential rights issue I had to try this to verify it worked:

How do you REALLY know what rights your IDM driver has?

I mean, really? Okay, in theory you should be able to do something like open iManager/ConsoleOne and view trustees of an object and go for Effective Rights. In this way, even if you don’t have explicit rights to an object, the inheritance should be calculated properly. That works well, but what if you want to know if the driver will actually be able to DO something despite rights (for example, creating a home directory on a remote server that could have more involved than simple rights like NCP communication)? Well it turns out that you can actually log in as a driver. Yes, that’s right - a login via your favorite client as the driver itself. Give it a shot in iManager or ConsoleOne and, once you’re in there, try to do something that your driver should be able to do.

As an example, I have an Organizational Role assigned to manage ONLY things in the dc=testwo-1workorder.dc=idm.dc=service.dc=system container. That's because its entire purpose life in life is to give rights to my WorkOrder driver, and that is the container for WorkOrders. The Security Equivalence is set up between the driver and the Org Role properly (or so I believe, but that’s why we’re testing, after all) and now I’ll log in as that driver.

Once in my favorite administration tool, I try to create an object under o=system and get an error quickly. I do the same under dc=org and get another error. Now I try to create something under my dc=testwo-1workorder.dc=idm.dc=service.dc=system container and happily can continue.

This could also be useful when management asks if it was IDM that blew up a container of servers. In a tree designed with servers in one part and users in another, there’s no reason for the driver to have rights to servers. If they aren’t assigned and you can prove it, that will be one less thing for you to worry about on the IDM front.