Remove All Roles assigned by access request when the termination event triggers

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hi All,

We want to remove roles assigned via Access Request when the user gets terminated.
The roles has AD groups along with other entitlements. When the user is terminated his/her AD account moves to De-Provisioning OU. Until the AD account aggregation completes IDN cannot see the updated OU.

We initially tried using workflow with identity attribute change (cloudlifecycle) as the trigger and manage access steps to remove the roles. Roles would be removed but IDN is not able to remove the AD groups assigned by the roles because AD account is already moved to de-provisioning OU.

We are looking for a better approach to fix this which is remove the roles and the access assigned by the roles especially the AD groups. We also need the audit of removing groups in IDN.

If anyone has better solution can suggest here. The key thing is AD account need to move to de-provisioning OU, roles need to be removed and AD groups assigned by the roles.
We do not want to hard code the AD group names in BP rule.

Thanks.

2

Have you tried running the reload account API action? Or will that not work since it’s reliant on the DN?

3

Also, what is the action that moves the user to a different OU? If you’re using a ConnectorAfterModify rule to do that, just do the AD group removals in PowerShell. That’s what we do.

4

Does this API will pull the account even when the DN is not correct. Is this similar to single account aggregation?

5

We used BP (Before Provisioning) rule to do this. We cannot move it to after modify script as we need to track the events, removal of groups

6

I haven’t tried it, but I would assume it’s the same thing as a single account aggregation

7

okay. Then my thought is it would not work. Because single account aggregation happens using DN of the account. If DN is updated it would simple fail.

8

Sounds like your only option is to run a full source aggregation and then attempt to remove access

9

Would adding this to BeforeProv rule will help?

List groupList = new ArrayList();
groupList.add("CN=Domain Users,......,dc=domainName,dc=com");
accountRequest.add(new AttributeRequest("memberOf", ProvisioningPlan.Operation.Set, groupList))
10

This was one of the option but the problem with this is, we need to hard code all the groups that were assigned using roles.
User can have some groups which can stay when the account is terminated. We do not want to hardcode any groups in BP rule.
Is it possible to identify the groups which are assigned by roles via access request and make if future proof without hardcoding group or role or source names?

11

In your original post you mentioned the below quoted phrase. Were you removing all the ROLEs from the user or just the ones assigned via Request Center?

Thanks for clarifying

12

hi Nithesh,

Thanks for the suggestion.
Yes as I mentioned in my original post we are using workflow to remove Roles which an Identity has during termination. Based on the Roles concept if the role is assigned via access request then they can be removed either by cert or by requesting them to remove via access request again.
For roles assigned via assignment criteria they would get removed automaticaly as the criteria will not match once the identity is terminated.
So, we used workflow to remove roles which are assigned by access request. The groups assigned by these roles has some memberOf (groups) of AD. That we are removing by hard coding the names in beforProv rule. Now we do not want to do this becuase there are lot of groups to be removed and this is not a good way as there is lot of maintenance activity. Hence we are re-evaluating this design and wanted to check if there is a better approach to remove the groups.

1 Like
13

via your workflow, how were you able to remove all Requested Roles? I do not see an ‘Action’ option for that. Did you make a custom HTTP request?

14

Hey Uday,
Did you check the latest update on AD connector ? It does aggregate the user after the OU is moved OOTB.You dont need to run any aggregation now. Do you still get the error in Workflow when you are trying to remove groups as per your initial design ?

The Active Directory connector now instantly returns the Resource Object to IdentityNow on any OU changes done by the AC_New Parent, which can be further utilized to any rule to work with the updated Resource Object data values.

https://community.sailpoint.com/t5/SaaS-Release-Notes/tkb-p/saas-release-notes?env=production&date=2023-08-14

15

Yes we still see the error. We dropped from this and using BeforeProvisioning rule as of now we had little amount of groups to be removed.

16

We built something similar for a client. We used the workflow approach you started with:
trigger on lifecyclestate change, then get access, then manage access

You can add a ‘wait’ step between the trigger and get access steps. This will give the account enough time to move to the deprovisioned OU, and your get access step should now return the correct DN for the AD account.

You will have to move the AD account using AC_NewParent (if you’re moving the account via powershell, this won’t work).

17

We have already took care of OU movement in the rule. Yes we are testing a sample workflow with wait step of 5 mins.
What we are observing during our testing is some of the criteria based Role are not being removed when the criteria is not matching. Looks like a bug we need to deal seperately with SailPoint.

18

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