Highlighted
Commodore
Commodore
576 views

Role and Resource Service Driver :TTL Checking expiry for

Jump to solution

Hello

IDM 4.7.3 AE

 

Role and Resource Service Driver. 

I am bit curious, this driver keeps showing me log for TTL expiry check  for some not all roles and resources, I wonder what is TTL its checking for and what is criteria its selecting these roles and resources?

 

this is what i see in driver trace log:

 

[05/11/20 21:23:00.250]:Role and Resource Service Driver :TTL: Checking expiry for resource <DN TO RESOURCE>

[05/11/20 21:23:00.298]:Role and Resource Service Driver :TTL: Checking expiry for role <DN TO ROLE>

 

/Maqsood.

Labels (1)
Tags (1)
0 Likes
1 Solution

Accepted Solutions
Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

On the nrfNextExpiration I agree, but I think the reasoning was using a Time/Date syntax field, you can search for all expirations between last run and now (Like Lothar's PWNotify does for Password expirations) a simple query for all expiring roles is easy.

Then figuring out which one is expiing requires a lot of work, but once you have a user, not so terrible.  Look at each nrfAssignedRoles (For direct assignment), nrfGroupRoles (For group assigned), nrfContainerRole, and something for dynamic I think.  In each of those Path syntax attribbute the Path.xml component has XML inside it, with the start_tm, req_tm, and end_tm nodes.  So parse that XML and look at the end_tm dates and then decide.

Doing a query for those is really hard. But if there is a flag to say, look at this guy at this time, it really simplifies it.

I am sure there has to be a better way, but this seems to be how they do it.

 

View solution in original post

0 Likes
6 Replies
Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

I think that nrfNextExpiration is set on users when ONE of their assigned roles/resources has an expiration.  So then it looks at all the assignments on the user to figure eout which one is due. 

But that does not entirely fit in what you are showing logged though.

0 Likes
Highlighted
Commodore
Commodore

 @geoffc   this is also visible on trace:

 

[05/11/20 21:37:00.000]:Role and Resource Service Driver :RES_TIMER: Thread ID:1153356 Checking for workflows to be retried...
[05/11/20 21:37:00.000]:Role and Resource Service Driver :TTL: Thread ID:1153355 Checking for pending role requests...
[05/11/20 21:37:00.002]:Role and Resource Service Driver :TTL: Thread ID:1153355 Checking for workflows to be retried...
[05/11/20 21:37:00.005]:Role and Resource Service Driver :TTL: Thread ID:1153355 Checking for expired role assignments for identities contained under: ORG

 

is there any shim tace option on Role and Resource driver to see what is doing?

 

 

another thing, nrfNextExpiration is on the user, and it has no indication which role or resource is expiring!, very strange design!

 

 

/Maqsood

 

0 Likes
Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

On the nrfNextExpiration I agree, but I think the reasoning was using a Time/Date syntax field, you can search for all expirations between last run and now (Like Lothar's PWNotify does for Password expirations) a simple query for all expiring roles is easy.

Then figuring out which one is expiing requires a lot of work, but once you have a user, not so terrible.  Look at each nrfAssignedRoles (For direct assignment), nrfGroupRoles (For group assigned), nrfContainerRole, and something for dynamic I think.  In each of those Path syntax attribbute the Path.xml component has XML inside it, with the start_tm, req_tm, and end_tm nodes.  So parse that XML and look at the end_tm dates and then decide.

Doing a query for those is really hard. But if there is a flag to say, look at this guy at this time, it really simplifies it.

I am sure there has to be a better way, but this seems to be how they do it.

 

View solution in original post

0 Likes
Highlighted
Knowledge Partner Knowledge Partner
Knowledge Partner

@geoffc wrote:

I am sure there has to be a better way...


I'm convinced almost everything related to the integration of the role model has a better way, and the reason we have to deal with such crap is bad architecture at the beginning and sticking to it for over a decade, applying patch over patch to workaround each new issue coming up.

Storing DNs as text on XML blobs is just a horrible idea, I wonder how they got away with this in the beginning as it's so obviously begging for pain and one of the reasons renames and moves in ID Vaults are a bad idea.

Novell and all the intermediate owners of the product could've created a new Edir syntax that allows to tie two or more DNs as components together, which it is needed in this use case. Or the could've used separate objects for object-to-role associations, much like request object.

Instead at some point a lame helper attribute like nrfNextExpiration has been added.

Actually we could just use the request objects and keep then as long as a role is assigned instead of killing them a few days after the request is finished. That would also allow multiple overlapping assignments of the same role with different requesters/approvers and multiple future planned assignment periods of the same role.

Another annoyance: why does RRSD take ages to process renames/moves in large environments? Because it queries *all* users with direct role/resource assignments and checks if a requester DN needs to be updated. And it repeats that for each and every move and rename in the tree. In a synchronous blocking thread that is. *Sigh*

To be fair, though: RRSD gets better working around the fundamental problems of the role model implementation with each version, the latest 4.7.4 being another big step forward. But it's all fighting symptoms instead of curing the disease once and forever.

Sorry for the rant, just had too much of this coming up and spoiling my days the last few weeks.

______________________________________________
https://www.is4it.de/identity-access-management
Highlighted
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
Somewhat mean to say, but I'm glad I'm not the only one dealing with this crap in large environments...
--
Smile, IT confuses people!
0 Likes
Highlighted
Commodore
Commodore

We are using the functionality in a different way so renames are not hitting us.

 

All the roles and resources are created in IDM as groups from external systems where they belong(sourced) using IDM drivers.  upon creation we tag (add custom attributes to)  these groups(roles|resources) with different metadata such as UUID, (generated from id-provider), category, owner, etc.

we have written a IDM driver(NetIQ REST)  which connects to userapp identity service and does following

  -  Create/Updates roles and resources based on category and types

 -   Add delegate role manager permissions for the owner of resources of roles.

 -   Displayname of the role|resource can be updated from the source system without causing any issues.

 

We don't allow self-service in userapp, we have blocked browse using ACL in eDirectory, so that only role | resource owner has permissions to give user assignments(direct) with a reason text (usually a support ticket reference) for reviews and audits later.

/Maqsood.

 

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.