I have found this  What happens when you assign a Role to a User but unfortunately, I could not find any clue there. 

I wrote that, a long time ago,(7 years ago !!!) and I still do not fully understand the nature of the nrfRequest objects.

Must they persist the entire life of the grant?

When RRSD gets a User 'command' (See series on how RRSD works, linked inside that article) it re-evaluates all of the users Roles/Resources.  Does it read the nrfRequests to know what Roles to add/remove?  If so all the Requests must persist.

If not, how does it know?

I have yet to divine how that works.  IF someone knows (Norbert Klasen ) I would love to find out.

When you look in IDMDash, at the Role (under Administration menu) it looks up the users currently assigned.  Are your 500 showing up in that Role? 

I know it uses a REST call to find them.  What does that REST call look for under the covers?  Also something that would be very interesting to understand.

I would GUESS it looks at nrfMemberOf on users, whose DN matches this DN.  Since that is a 'fast' query a simple DN query.

nrfMEmberOf is just a list of DN's of Roles on the user, be they via Group, Container, Direct Assignment, or inherited.

Ah!  Have you looked at nrfINheritedRoles to see if maybe they got the role through inheritance?

Actually, I have searched through your articles and actually comment below this one (Following a Role Grant in the RRSD Driver – Part 6) I think gives the answer.  

So in short if I am right all nrfRequest objects with nrfStatus=50 are cleaned up. If the request is temporary that data is stored in nrfAssignedRoles attribute, which is looked at by RRSD based upon nrfNextExpiration which is set when the nrfRequest is cleaned up.

I can confirm that the endDate is stored in the nrfAssignedRoles attribute. So what that means is that nrfRequest is just a median for UserApplication to create for RRSD to process, it does not store permanent data.

Example of the nrfAssignedRoles value:

cn=anonymizedName,cn=Requestable,cn=Level10,cn=RoleDefs,cn=RoleConfig,cn=AppConfig,cn=User Application Driver,cn=driverset1,ou=IDM,ou=System,o=IDV#0#
<assignment>
	<start_tm>20240827075759Z</start_tm>
	<end_tm>20240831220000Z</end_tm>
	<req_tm>20240827075759Z</req_tm>
	<req>cn=uaadmin,ou=SA,ou=Apotek1,o=IDV</req>
	<req_desc>anonymized description</req_desc>
</assignment>

Very good tips! Thank you I will look into it...

I can confirm the user is not under the assigned objects under that requested role administration tab in IA. Neither do I see this role when I look at the user in IA.

These roles are not inherited and are only requested through form and need to be approved.

And nrfNextExpiration is maintained as a Time syntax attribute on any user that has ANY expiration coming.  This way RRSD can search for any expiring users in a time window, in a fast fashion, since you cannot really usefully index text inside a Path component.  (Which I see now that I looked at the article linked is mentioned in the comment there as well).

So if a user were to lose a nrfAssignedRoles value, then RRSD cannot reconstruct and re-assign it on the next re-evaluation of the user. Conversely it has no way to remove excess Roles, and only when they have an expiring Role I guess.

I guess, if the Role Grant was because of a Group membership or Container, RRSD would fix it, if missing.  But individual grants can potentially get lost. 

Lets revisit that then...  You start by saying you find all 500 of them via LDAP. I am unclear what the 'them' was?  Roles you wish to clean up?

Assuming we are working via LDAP what attributes have you looked at to confirm membership? (Especially if the REST call, made through IDDash) is not showing them.

Ok let me try again, I need to clean up the list of old requestable roles:

• x
• x1
• x2
• ... (about 500)

Before I can clean them up I want to make sure no one else is using them anymore.

My first idea was to check nrfRequest objects in LDAP, thinking if any exist the roles are still in use. This I checked with LDAP query:

(|

(nrfSourceDN=x)

(nrfSourceDN=x1)

(nrfSourceDN=x2)

(nrfSourceDN=...)

)

But as we figured out now this is not really the way to go as they get cleaned up...

The other LDAP Query I did (thankfully - otherwise I would think they are not used anymore), that came to my mind is:

(|

(nrfAssignedRoles=x#0#*)

(nrfAssignedRoles=x1#0#*)

(nrfAssignedRoles=x2#0#*)

(nrfAssignedRoles=...#0#*)

)

So this one finds all users that still have those old roles assigned.

Change it to look at nrfMemberOf, since that is DN not path syntax.  And there are nameSpace values other than 0 or 1 possoible.

w