Access request response very slow

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

Hi,
we have observed and also end users are reporting that access requests are really slow.
If you select the Role , the selection butto to became “green” can take 1/2 min or more. Request than is completed in another 2 min.

Any experience in such case ?

Regards,
Gabriele.

1 Like

When you selecr Role, IIQ is evaluating all IT Roles associated with this role together with Account Selector rules defined for this IT Roles. If the rule is not efficient it might make slow response.

Hi @gabs1,

Just to add to what Kamil mentioned, the access request submission time is also dependent on the LCM workflow. So. if you are using custom workflow check the efficiency of that and if you have multiple Policies, that can also have an impact depending on the rule configured for the policies.

1 Like

Thank you Kamil.
Issue is that we do not have any IT rules for that particular role.

Also I tried:

  1. Request role that assign an IT not in AD > FAST
  2. Request role that assign IT in AD , for not correlated HR account > FAST

I have a selector rule in the quicklink configuration ( What can member request) , but I was excluding it, as the issues persist with SysAdmin capability (where usually quicklink ar bypassed)

Regards,
Gabriele.

Hi Gabriele,
Could you plase paste here XML of the role which is cuasing problems? I suspect something might be wrong there.

@Jarin_James - I agree but I believe @gabs1 said the problem is that when you just select the role - it takes a lot of time until it can be submitted. This is usualy account selector issue. The problem you described happens usually after submition of the request as this is when LCM Provisinoning is started.

@kjakubiak Agreed. Just added that because @gabs1 mentioned that the request again takes another 2 mins to get completed after Role selection.

I was thinking about Policies as well. So guys policy is evaluated after submitting the request and not earlier stage when the Project is created ?

@kamil_jankowski : xml attached.

Role_example.xml (1.1 KB)

@Jarin_James - got it, sorry, missed this part of the ticket

@gabs1 could you please also include

    <Reference class="sailpoint.object.Bundle"  name="IT-Active-Directory-memberOf-T2-IAM-S-License-365-F3.HK"/>
    <Reference class="sailpoint.object.Bundle"  name="IT-Active-Directory-memberOf-T2-User-S-All-Intune-Users.HK"/>

this roles?

it.xml (1.4 KB)
The second one is the same of this attached , just different entitlement.

Role looks good, is it maybe possible that the identity would have a lot of links in AD? As honestly I see no reason why it may take that long.

Regarding second delay - with execution - if there’s no approval after request is summited, Sailpoint is trying to provision change to AD immediately and will return the context only once the operation is finished. That means that the delay contains also time needed to establish and handle communication between IIQ and AD.

This behaviour can be controled inside of the LCM Provisioning workflow by this variable
image

If you set it to false it will background workflowcase before executing provisioning. This will improve user experience as the request will be created much faster. But it will make the provisioning to happen later because this backgrounded workflowcase will have to be picked up by the Perform Maintenance task and processed in the background.

Yeah, those template for roles are used also to trigger the AD creation account. So in this case no AD link exist neither other already assigned entitlement.

Looks like something changed, I’m going to verify it. I was wondering that might be some Before AD provisioning rule as well…

Just to confirm, when the policies are evaluated ?

Are you seeing this issue after upgrading the system to v8.3 and you did not had this issue in the previous versions ?

when you are requesting this access, can you monitor DB to see any any long running query in system because it calculates any pending access requests present for the user.

you can also capture the browser trace to see the slowness when exactly is it happening.

@gabs1
Policies trigger even before request submission based on the configurations you have in attached LCM workflow of variables of policy scheme, allowRequestsWithViolations and few more variables, based on the values policies are evaluated sometimes even before the request is submitted.

Hi Vinod!
Looks like that. We upgraded recently to 8.3p3 few month back.

I will try to do such capture. Cool stuff is that user is new fresh aggregated user from HR :smiley:

Hi,
I made some test and browser trace. Take a look on the screenshot, something new for me… what does is the addtionalQuestions ?

Anyone had similar issues?

Please see the response in community website by the SailPoint team.
https://community.sailpoint.com/t5/IdentityIQ-Forum/Selecting-a-role-takes-long-time-in-access-request-in-8-3/td-p/236461

see if you can apply the latest patch 8.3 p3 as they mentioned in 8.3 p2 patch some fixes are applied.

We are already on P3.
I was looking to that community post as well. Going to ask our CSM more info.

I tried also to revert changes to previous release, nothing.

What we observed is that looks happening only with Active Directory entitlements! We are now trying to debug what might be the issue there, maybe some form references or attributes calculation…

Regards,
Gabriele.

An update from my side.
We found the root cause of it !!! The old rule: is always a network issue , is always valid.
Well, some strange topology changes affected the directories servers and basically our provisioning form, that so checks in AD before creating accounts , was taking more than 2 min to get an answer!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.