The different permissions in User Application

If you are an eDirectory person, you are used to handling user access requests to other objects. If you come from the Open Enterprise Server world, you are used to how that interfaces with a file system (like NSS). The inheritance model is pretty straightforward and easy to understand, most of the time.

In the Identity Manager world, you are used to getting the permissions needed for your driver to be able to manage the objects in scope. Of course if you have been using the latest driver configurations and like to cut the permissions down to as granular/minimal a level as you can, you will have noticed the need for more permissions. Like needing the ability to Write objects in the driver objects container. This is so the MSysInfo GCV (Global Configuration Object) can be re-written on driver startup, once the driver figures out its GUID and some other info.

If you have the PCRS (Permissions Collection and Reconciliation Service) versions of the Entitlement policies in your drivers (Like Active Directory from IDM 4.5 or so) then your driver needs the ability to modify the Job objects.

If you use Entitlements with Resources, and User Application, the driver needs permissions to write the EntitlementConfiguration object, potentially every driver startup.

But these are pretty straightforward, heck in Dev, most lazy people just make the driver Security Equals to the Admin user and all is well. Of course, when it is time to go to Prod you have to start whittling down the permissions to the minimum necessary.

Then there is the User Application. Oh boy, here we go.

As far as I can tell, there are least four different levels of permissions.

  1. Original style eDirectory permissions. To see PRDs you need eDir permissions to find them in a query. This is how you limit access to PRDs to users, in terms of what they see when they click on Make a Process Request.

  • Administrator roles in User Application itself. Role Admin, Role Manager, Reporting Admin/Manager, etc. These are 'magic' roles, that User App issues on first unpacking of the WAR for the configupdate defined User App Admin object.

  • In addition to the high level 'Administrative roles' on top of that you can fine tune permissions, with ACLs in eDir. Grant the user the ACL, on the object, to nrfAccess* attributes. So you could be a Role Manager, but only to the three Roles that you have W permission to the nrfAccessMgrAssginRole. Now this attr is NEVER instantiated on any object in the tree. Instead UA does the getEffectiveRights() style call to see if the logged in user has access.

  • User App Admin Assignment, which in 4.02 is a item in the Admin tab. This is stored in the DB in the table:


    You have to work out the [PERMISSIONIID] and then its something like


    for the [PRINCIPALNAME] all gets quite hard rescuing the UA Administration

    It is best to get Support involved if you have lost access to this account and need to rescue it.

Now lets dive in a bit deeper on those items. The first, eDirectory permissions to see the PRDs is a useful one. The first thing you have to remember is to remove the [BC] permission at the root of the tree, that allows everyone to SEE the objects in a query, so that all the PRDs appear. If they are visible to a user, then the user can start one. The other approach is to leave the Browse and Compare at the [Root] of the tree, and use an Inherited Rights Filter to block the inheritance of the BC permissions. Of course, first make sure to explicitly grant some object permission to see around the IRF (since Admin will get inheritance filtered as well).

Once you have done that, you can use the native eDirectory permissions to grant access. In fact, I worked with a client that used a PRD to grant access to other PRDs by granting Group memberships. That is, the Group has permission to see the PRD, and then a Role/Resource for the Group is added by the first PRD which puts the user in the group and via Security Equals to the Group the user can now see the PRD.

You end up with a lot of groups in the IDV for managing PRD access, but it is workable. Also it helps if you have a driver that implements IDV local groups as Resource addressable. I have a package to add onto a Loopback driver that allows you make a Resource that grants IDV group membership. Usually the Entitlements/Resources in drivers is for in connected systems. But doing this for the IDV is actually pretty simple if you understand how it works under the covers. You can get it from my Package repository at:

This is probably the most straightforward of all the permissions in play in the User Application.

The next one is the Administrative magic roles.

To reset Admin roles, in 4.0x and earlier, you needed to find the configuration.AppDefs.Appconfig.UADriverDN.Driverset.YourOU.YourTree-O and edit the XML and find the Admin initialized node and delete it from the XML blob. Bleh. This is slightly painful, especially since the XML blob is quite large. The certificates used for the User Apps SAML federation with eDirectory are stored in there, and you should avoid breaking that if you can.

Read more here:

In 4.02 at some patch level, they added an option to re-initialize Admin roles in the GUI under Advanced options on the first tab, in, which does the work of resetting this flag for you.

The interesting part is that these get generated by the User App itself, as it unpacks the WAR the first time and someone loads the web page. So it is not enough per se, to just restart the Web Application server (Tomcat, WebSphere, JBoss) you actually have to open the web page, and that seems to kick off the process.

I even once collected the trace from the User App logs, which made the nrfRequest objects, and then the Roles and Resource Driver trace file for creating it all. I thought about doing an article with that trace, but it was even too boring for me to write about.

The third type of permissions is kind of the interesting one. The permissions for the engine, so that dxcmd can manage IDM drivers uses a similar model. In some ways, when you see that User App is using it, you start to wonder why they even bothered with the Administrator roles at all. I.e. Why have two permission models? If anyone has a clue, or has inferred a reason, please do comment as it puzzles me. (Or as Sheldon might say 'It Vexes me').

Basically the permission model looks to see if the user in question COULD access an attribute. Now those attributes are not in any classes, they sort of float in schema unattached, without a care in the world, and thus they never exist in your tree. But if you have permission to read a value it might have, then you have permission to perform the task.

The list of attributes I grabbed from Designer's Manage Vault Schema consists of this set:


Some of these depend on the context, where having the ability to read them, means you can read the thing whose access is being controlled, and if you have the Write permission, you can modify the thing being protected.

The best way I can think of to figure out what you might need to grant, is using the Administrator interface in User App you can assign a Role Administrator to only one or two Roles, and then look at the specific ACL attribute values it grants.

If you look in LDAP the ACLs are a smidgen harder to read than if you open them in iManager or some other tool that knows how to render them. This is because the permission is a bit mask value, and it depends on if the context is a Attribute or an Entry. You can see a nice representation of this in this TID:

ACL syntax is an example of an interesting attribute syntax. I happen to be a big fan of PATH syntax, which is a DN, a 32 bit integer, and a string in one attribute. ACL is really A DN, a 32 bit integer, and a string. In the Path example, the DN is the volume object (referencing an Netware or NSS volume), the nameSpace is the 32 bit integer to represent which name space the reference is using, and then the string with the actual path to the file on that referenced volume.

For ACL, the DN is the object getting the permission TO, the object it is written on. The permission is a 32 bit integer bit mask, and the string is name of the attribute/entry/pseudo thingy that is being considered. I say Pseudo thingy, since there are some funny permissions thingies, like [This], [Entry Rights], [Attribute Rights] that are more than just simply attributes. I am sure there is a proper name for them, but I do not know what it actually would be called technically.

What I find interesting is that the DN reference itself is really a 32 bit integer holding the object ID in the local database, it is just that all tools 'render' the value as the name of the object, usually the full object Distinguished name. Thus Path and ACL are really 2 32 bit integers and a string. They are just used slightly differently. I like the syntaxes in eDirectory and find them interesting to use in unexpected ways. There is Timestamp syntax, which is 3 32 bit integers, which is fun (Lothar uses it in his PWNotify driver to store the Last Referenced Time of the last run of the driver.)

The permissions that the engine uses (as iManager and dxcmd exposes) are a little simpler and less granular. They are:


The other big example of this is the Password Management 'attribute'. Worse the behavior changed between versions of eDirectory. It used to be that having Read permission to the Password Management would let you perform password resets, and then I think in a later eDirectory they changed it so that Read meant you could actually read back the password value, which of course is way different than what you might have expected in previous version. I am pretty sure I am getting that not entirely correct, but it was the third example of this approach that I knew about. Someone will remind me and I will correct it in an update.

If you have run into others in eDirectory, please let me know since I am quite curious.

Finally we have the User App Administrator, that is stored in the database. I would have thought that if the directory was down, you could potentially still login, but I see it stores the user reference as an LDAP reference so that is not so helpful.

Alas, this one it is suggested to get Supports help to fix if you lose it. My understanding is that the reference is a DN as a string, not a GUID, so it seems unlikely you would ever have to edit the DB to fix it. Rather, just use your other eDir admin accounts to either recreate the object in the tree as needed, or else reset its password to something you know.

If you have found any other possible permission models I missed, please let me know so I can add it into this one.


How To-Best Practice
Comment List