How does RRSD know what Roles to grant a user?

This has been  bugging me for a while.  RRSD is a bit of a black box and that offends me personally.

Anyway, I know that when you send an event for a user or Resource or Role into the driver, the policies throw away the specific attribute changes and convert the operation from <modify> or <add> to <nrf:request or nrf:role or nrf:Identity 'commands instead of 'events.

Then the shim considers the object in its entirety.  This makes sense for a Role or Resouorce.  Look at the associated Reources or child/parent roles and consider what the membership loks like and check that everyone listed has the needed child roles or resources.

But in the case of a user, it re-evaluates the Roles assigned.  Thus the question... Where does it look for the assigned Roles?

If you remove an nrfAssignedRoles value from a user and migrate through RRSD it should be put back.

Is it looking at nrfRequest object?  But the default is to delete those within 7 days, so what happens on the 8th day?

There is much here I do not understand and would like to understand.  Anyone has some insight to share?

  • Not exactly sure which place, but there are a few attributes for roles.  Two of them are sitting in filter (nrfMemberOf and nrfDynamicGroupMembership).  I suppose that second one isn't quite a role...

    There is also an attribute nrfAssignedRoles and nrfGroupRoles.

    As far as I can tell, nrfGroupRoles are roles you get, as the name implies, based on a group you are a member.  nrfMemberOf is the master list of all roles you are a member and nrfAssignedRoles are the roles you are directly assigned.

    You also have securityEquals for each one of the roles you are a member, just like with group memberships.

    To your more direct question, it appears as though nrfAssignedRoles are removed by the Roles and Resources driver, but that can create one or more removals for nrfMemberOf due to child roles, group roles, etc.  It also monitors group memberships and nrfDynamnicGroupMembership to react on those as well.

    For your example, if you remove an nrfAssignedRole, then migrate, the nrfMemberOf should put back the Assigned role because it is on your account due to one of the items in nrfMemberOf, whether it be a child of one of those, or simply one of those.  For example, if you are directly assigned 3 roles (nrfMemberOf has 3 values), but 1 of those roles has 2 children, I would expect to see 5 values in nrfAssignedRoles.  If you then remove one of those values, upon migrate, it'll use nrfMemberOf to re-evaluate your memberships and even if you removed a child, it'll rediscover the child and reassign it based on evaluating its parent from nrfMemberOf.


    Of course this is all just educated guesses, but it is pretty logical.  I've spent more time than I'd like to admit troubleshooting roles and resources performance issues recently and you get some additional details when staring at trace level 4 as well as some ndstraces, etc for hours on end.  It gives you an idea of how much time some of those operations can take as it searches to find the relevant data.

    Have I mentioned I LOATHE rename events?

  • Do not remove nrfAssignedRoles! It has much more data than nrfMemberOf and cannot be reconstructed from nrfMemberOf. nrfAssignedRoles is also the source for Identity Reporting.

    For example, if you are directly assigned 3 roles (nrfMemberOf has 3 values), but 1 of those roles has 2 children, I would expect to see 5 values in nrfAssignedRoles

    It's the other way round: only directly assigned roles are in nrfAssignedRoles. nrfMemberOf also lists inherited, group, and container roles.

  • Rob and Norbert, thank you for responses.


    I think you are missing the point I am asking... 

    What is RRSD looking at, to rebuild users?  That is where I am going with the Q.

    Per Norbert,

    nrfAssignedRoles are directly assigned Roles.

    nrfGroupRoles are roles assign to a Group, unrolled and stamped on the user.

    nrfContainerRoles are container roles, unrolled and stamped on the user.

    nrfMemberOf should be the entire set of Roles.


    But say a user is getting a new Role, RRSD looks at the roles it has/needs, is it looking elsewhere or just what is on the user itself? 

  • When a user is granted a role, it is actually looking at an nrfRequest object with an nrfStatus at a specific value (30?).  That contains the targetDN and the sourceDN, which are who to assign and what to assign.

    Based on the role to assign, it goes to the resourceAssociations to find all resources, but it also traverses the child roles as well and explodes those.

    It gets hairy when REMOVING a role, because you have to remove the role, its children and all associated resources, HOWEVER, you have to validate that no other still granted role is providing a reason for any of those resources and/or child roles to be left on the user.


    On a migrate of the user, it must be looking at just the assignment attributes (nrfAssignedRoles, nrfGroupRoles, etc).  Iterate through those values and explode them to determine any children that should be added.