Following a Role Grant in the RRSD Driver – Part 5

0 Likes
In the first four articles of this series, I discussed what you see in the Roles and Resources Service Driver (RRSD) when different events are triggered out of the User Application. When you are in the User Application, via IDM Home (which makes SOAP calls to the IDMProv interface) or in the classic User Application Interface (the IDMProv web app) at the conclusion of your request the end result is an object, often an nrfRequest or the like object.

This is the sort of thing that the RRSD is looking forward to reacting about.

In part 1 of this series I showed what happened when you granted a Role to User, and examined some interesting errors along the way to success. Then I showed what a Revoke of a Role Association looks like in the RRSD trace.

In part 2 of this series I showed what creating a Role, assigning a Resource to the Role via nrfResourceAssociation object, and a more detailed look at assigning a role to a user look like in trace.

In part 3 of this series I discussed how the shim seems to work, based on observations of its behavior and how you might influence some of its operations for better performance.

In part 4 of this series I showed how an error I ran into, disclosed some of the inner workings of the driver, and that the error of failing to make a SOAP call, showed that it was actually making a SOAP call, something it did not send a success status message for, thus only by failing did I learn it existed.

In another article, that I should have called part 5, but did not, I discussed the various attributes that get set on a user when it is granted a Role and if it has Resources, the inherited Resource (and other Role) assignments.

However, I will call this article part 5 and leave the previous one to stand on its own merit.

Here I have an example of an nrfResourceAssociation call that I would like to look through and discuss. There is an error buried in there that is of interest. The event starts as an <add> event:


[02/25/15 10:34:16.683]:rrsd ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Evaluation" version="4.5.0.2">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<add cached-time="20150225183416.583Z" class-name="nrfResourceAssociation" event-id="idvault1#20150225183416#2#1:359b4fe6-5a61-4540-daa1-e64f9b35615a" qualified-src-dn="dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20150225103416-c5972c2204614d938d2c4b0765e02bc1" src-dn="\ACMEIDVAULT\system\service\idm\dvs0\userapp\AppConfig\RoleConfig\ResourceAssociations\20150225103416-c5972c2204614d938d2c4b0765e02bc1" src-entry-id="64800" timestamp="1424889256#6">
<add-attr attr-name="nrfRole">
<value timestamp="1424889256#4" type="dn">\T=ACMEIDVAULT\dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level30\CN=Cost Centers\CN=1010 Eng HW</value>
</add-attr>
<add-attr attr-name="nrfResource">
<value timestamp="1424889256#6" type="dn">\T=ACMEIDVAULT\dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceDefs\CN=CC-1010</value>
</add-attr>
<add-attr attr-name="nrfStatus">
<value timestamp="1424889256#3" type="int">10</value>
</add-attr>
</add>
</input>
</nds>


This starts simply as the creation of the nrfResourceAssociation object with nrfRole and nrfResource pair of attributes specified that define the two objects being linked. The nrfStatus is set to 10 at create time. Not much else is said about the object based on the limited filter in this driver.

As we saw before, the main DirXML Script policy in this driver exists to convert events into commands, which happens in the Subscriber event transform policy:

[02/25/15 10:34:16.689]:rrsd ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Evaluation" version="4.5.0.2">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<nrf:resourceassociation dn="dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20150225103416-c5972c2204614d938d2c4b0765e02bc1" xmlns:nrf="urn:dirxml:nrf"/>
</input>
</nds>


As discussed before the RRSD shim is not a traditional IDM driver that handles events based on data that comes in, but rather one it gets a command it reconsiders the entirety of the object and re-evaluates everything about the object. There are good reasons for tis, but it seems like supporting a sync and doing proper eventing would be more efficient.

After processing the command, the shim returns this message.

[02/25/15 10:34:16.737]:rrsd ST:: Processing resource association
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20150225103416-c5972c2204614d938d2c4b0765e02bc1
[02/25/15 10:34:16.737]:rrsd ST:: Retrieving resource association objects based on a role or resource DN. DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level30\CN=Cost Centers\CN=1010 Eng HW
[02/25/15 10:34:16.738]:rrsd ST:: Retrieving resource association objects based on a role or resource DN. DN: dc=com\O=acmes\OU=users\OU=Active\OU=Others\CN=warren.smith
[02/25/15 10:34:16.738]:rrsd ST:: Retrieving resource association objects based on a role or resource DN. DN: dc=com\O=acmes\OU=users\OU=Active\OU=Employees\CN=john.cho
[02/25/15 10:34:16.859]:rrsd ST:: Processing request
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0
[02/25/15 10:34:16.882]:rrsd ST:: Processing request
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0


First we get told it is processing the resource association:

[02/25/15 10:34:16.737]:rrsd ST:: Processing resource association
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20150225103416-c5972c2204614d938d2c4b0765e02bc1


Then it looks at the Role object to see if anyone has the Role assigned that would need the Resource assigned.

[02/25/15 10:34:16.737]:rrsd ST:: Retrieving resource association objects based on a role or resource DN. DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level30\CN=Cost Centers\CN=1010 Eng HW


Looks like it found two.

[02/25/15 10:34:16.738]:rrsd ST:: Retrieving resource association objects based on a role or resource DN. DN: dc=com\O=acmes\OU=users\OU=Active\OU=Others\CN=warren.smith
[02/25/15 10:34:16.738]:rrsd ST:: Retrieving resource association objects based on a role or resource DN. DN: dc=com\O=acmes\OU=users\OU=Active\OU=Employees\CN=john.cho


Thus it realizes it has to do more than just link the Role and Resource objects, now it has to update the users already assigned to the Role and grant the Resource, which if it has an Entitlement also means granting the entitlement.

It looks like it actually makes two ResourceRequests objects along the way for the task of processing those two found users.

[02/25/15 10:34:16.859]:rrsd ST:: Processing request
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0
[02/25/15 10:34:16.882]:rrsd ST:: Processing request
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0


Once completed, we get the following status events out of the shim. The above trace was the shim tracing out the work it was doing, then it goes and does it, finally returning the results. This is a limitation of how much trace shows based on how the developers wrote this shim.

[02/25/15 10:34:16.905]:rrsd ST:SubscriptionShim.execute() returned:
[02/25/15 10:34:16.905]:rrsd ST:
<nds dtdversion="4.0">
<source>
<product instance="rrsd" version="4.5.0.0">NetIQ Role Service Driver</product>
<contact>NetIQ Corporation</contact>
</source>
<output>
<status event-id="0" level="success">Created resource request
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0</status>
<status event-id="0" level="success">Transitioned request status from 0 to 30
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0</status>
<status event-id="0" level="success">Transitioned request status from 30 to 30
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0</status>
<status event-id="0" level="error">Unable to add assigned resource to user
Resource: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceDefs\CN=CC-1010
User: dc=com\O=acmes\OU=users\OU=Active\OU=Others\CN=warren.smith
Reason: novell.jclient.JCException: modifyEntry -672 ERR_NO_ACCESS</status>
<status event-id="0" level="success">Transitioned request status from 30 to 80
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0</status>
<status event-id="0" level="success">Created resource request
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0</status>
<status event-id="0" level="success">Transitioned request status from 0 to 30
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0</status>
<status event-id="0" level="success">Transitioned request status from 30 to 30
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0</status>
<status event-id="0" level="error">Unable to add assigned resource to user
Resource: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceDefs\CN=CC-1010
User: dc=com\O=acmes\OU=users\OU=Active\OU=Employees\CN=john.cho
Reason: novell.jclient.JCException: modifyEntry -672 ERR_NO_ACCESS</status>
<status event-id="0" level="success">Transitioned request status from 30 to 80
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0</status>
<status event-id="0" level="success">Transitioned request status from 10 to 50
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20150225103416-c5972c2204614d938d2c4b0765e02bc1</status>
<status event-id="0" level="success">Modified resource association
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20150225103416-c5972c2204614d938d2c4b0765e02bc1</status>
</output>
</nds>


There is a lot in there to unpack. We get 12 <status> events out of there. Let's go through them and see what happened.

    <status event-id="0" level="success">Created resource request
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0</status>


We saw that it decided it needed two ResourceRequests to handle updating the users, so this is the first message, that it created the first of the two resource requests. Which suggests we would get 6 events per user found.

    <status event-id="0" level="success">Transitioned request status from 0 to 30
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0</status>


First step is to request a change of the state from 0 to 30 on the Resource Request. It is worth noting, our nrfResourceAssociation object started with a nrfStatus of 10. I once saw a reference to some of these values, but there was not pattern to them, and the status values were different for every type of object and event. I was unhappy with that model.

    <status event-id="0" level="success">Transitioned request status from 30 to 30
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0</status>


Now we get confirmation that it actually did change the status to 30, although it says from 30 to 30, which is a bit odd, should have been from 0 to 30, I would have expected.

    <status event-id="0" level="error">Unable to add assigned resource to user
Resource: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceDefs\CN=CC-1010
User: dc=com\O=acmes\OU=users\OU=Active\OU=Others\CN=warren.smith
Reason: novell.jclient.JCException: modifyEntry -672 ERR_NO_ACCESS</status>


Now we get the error. A negative number in the 600 range is usually an eDirectory error code. If you have never run into a -672 before, you are probably not doing this thing correctly. This is the simplest kind, that if you read the error definition you might think your tree is broken, but really it just means no permission, which the text nicely says as ERR_NO_ACCESS.

Here we see that a lack of documentation bit us. I think the driver documentation should define the minimal eDirectory permissions each driver requires. It makes a lot of sense to NOT assign the driver as security equals to Admin. That is a recipe for disaster, even if it is much simpler than anything else. In Dev, I have no problem doing this permission overdose, but in production systems, (and usually tuning it in Dev first) you need to create an object with the permissions, and then make the driver security equals. As it happens, it is wise to use an object that cannot login, like an Organizational Role, to make it harder to abuse. This of course can cause an issue with the PCRS (Permissions, Collection, and Reconciliation Service) code add ons for many drivers, that assumes there is a password on the object the driver is security equals. PCRS uses that to call dxcmd with some parameters to setup and start some jobs.

In this case, we were getting ready in Prod, and using a locked down user with minimal permissions. This was a case where we found that we needed more permissions on the users. The RRSD driver needs permissions on a wide variety of drives and areas.

The AppConfig container contains a number of places RRSD will be working. You can see that the RoleConfig subcontainer which handles Roles and Resources is a good start. Under the RoleConfig in the AppConfig container there will be at least the following container where RRSD will need mostly full permissions:
Requests
RoleDefs
ResourceDefs
ResourceAssociations
ResourceRequests

The Requests container is where Role assignment requests, of Users to a Role, but also Role to a Role, Group to a Role, and Container to a Role will be written. These are the nrfRequests objects that RRSD processes.

The RoleDefs has three subcontainers out of the box, Level10, Level20, and Level30 for the three types of Roles supported. RRSD is responsible for managing and at least reading these objects so it will need read and modify permissions here.

ResourceDefs is where the nrfResource objects live and will require permissions to read and modify as well. I do not think RRSD needs create permissions in either RoleDefs or ResourceDefs, since it should not ever be creating them but take care when limiting permissions.

ResourceAssociations are written by the User Application after a request to link a Role to a Resource is made, so only modify and read is required here.

ResourceRequests requires create permissions as distinct from the others as we have seen in this trace example. As part of processing the ResourceAssociation request it created two ResourceRequests.

Likely you will also need permission to the PRD containers, since a Role or Resource request could require a workflow started to approve it before it can be fully granted, and the RRSD shim looks like it reads those on startup.

As a first approximation to save a lot of time, I usually give the Security Equals object full permissions on the AppConfig container with inheritability.

In my case we did that, but forgot that it needed to reach out and touch the users as well. Which was a silly oversight, sine of course it needed to update the users. That is kind of the ultimate point of this shim, to make sure the users have the proper Entitlements based on their Role and Resource assignments.


    <status event-id="0" level="success">Transitioned request status from 30 to 80
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-ddb5136e19334a49a31d4f91a1792adc-0</status>

Since we had an error, the 672, the status of the request is not success, which would seem often to be 50, but rather an error of 80.

<status event-id="0" level="success">Created resource request
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0</status>
<status event-id="0" level="success">Transitioned request status from 0 to 30
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0</status>
<status event-id="0" level="success">Transitioned request status from 30 to 30
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0</status>
<status event-id="0" level="error">Unable to add assigned resource to user
Resource: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceDefs\CN=CC-1010
User: dc=com\O=acmes\OU=users\OU=Active\OU=Employees\CN=john.cho
Reason: novell.jclient.JCException: modifyEntry -672 ERR_NO_ACCESS</status>
<status event-id="0" level="success">Transitioned request status from 30 to 80
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20150225103416-e59c50bce09948e5a0341f96cf778cef-0</status>

We then process the second resource request exactly the same way, with the same failure.

<status event-id="0" level="success">Transitioned request status from 10 to 50
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20150225103416-c5972c2204614d938d2c4b0765e02bc1</status>
<status event-id="0" level="success">Modified resource association
DN: dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=ResourceAssociations\CN=20150225103416-c5972c2204614d938d2c4b0765e02bc1</status>


But interestingly enough, the ResourceAssociation object goes to 50, with success. Even though one of it assigned members failed.

Almost immediately after the status documents, you get a modify of nrfStatus, on the Subscriber channel, but this time on the Role object, not on the ResourceAssociation object.


[02/25/15 10:34:19.031]:rrsd ST:Processing events for transaction.
[02/25/15 10:34:19.032]:rrsd ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Evaluation" version="4.5.0.2">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<modify cached-time="20150225183418.985Z" class-name="nrfRole" event-id="idvault1#20150225183418#2#1:6218388c-4516-4f8a-b987-8c3818621645" qualified-src-dn="dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level30\CN=Cost Centers\CN=1010 Eng HW" src-dn="\ACMEIDVAULT\system\service\idm\dvs0\userapp\AppConfig\RoleConfig\RoleDefs\Level30\Cost Centers\1010 Eng HW" src-entry-id="55517" timestamp="1424889258#1">
<modify-attr attr-name="nrfStatus">
<add-value>
<value timestamp="1424889258#1" type="int">50</value>
</add-value>
</modify-attr>
</modify>
</input>
</nds>


This becomes a command to the RRSD shim as before.

[02/25/15 10:34:19.038]:rrsd ST:
<nds dtdversion="4.0" ndsversion="8.x">
<source>
<product edition="Evaluation" version="4.5.0.2">DirXML</product>
<contact>NetIQ Corporation</contact>
</source>
<input>
<nrf:role dn="dc=system\dc=service\dc=idm\CN=dvs0\CN=userapp\CN=AppConfig\CN=RoleConfig\CN=RoleDefs\CN=Level30\CN=Cost Centers\CN=1010 Eng HW" xmlns:nrf="urn:dirxml:nrf"/>
</input>
</nds>


There is nothing to do, since the Role was already granted and it nulls out as an event. Even with the error it does not seem like it re-evaluates that far down to Resources.

Now next would be adding more permissions to the object that the RRSD object is security equals to, and testing. Let me save that for the next article in this series.

Labels:

How To-Best Practice
Comment List
Related
Recommended