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

**URL:** <https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583>\
**Category:** SHF Discussion and Questions\
**Tags:** provisioning, workflows, identity-security-cloud\
**Created:** [August 4, 2023, 12:48pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583 "2023-08-04T12:48:19Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![udayputta](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/udayputta/32/14195_2.png) [@udayputta](https://developer.sailpoint.com/discuss/u/udayputta)\
**Post date:** [August 4, 2023, 12:48pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/1 "2023-08-04T12:48:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\
**Post date:** [August 4, 2023, 1:12pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/2 "2023-08-04T13:12:04Z")

</div>

Have you tried running the [reload account](https://developer.sailpoint.com/idn/api/v3/reload-account) API action? Or will that not work since it’s reliant on the DN?

---

<div class="post-metadata">

**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\
**Post date:** [August 4, 2023, 1:36pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/3 "2023-08-04T13:36:07Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![udayputta](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/udayputta/32/14195_2.png) [@udayputta](https://developer.sailpoint.com/discuss/u/udayputta)\
**Post date:** [August 4, 2023, 2:11pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/4 "2023-08-04T14:11:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![udayputta](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/udayputta/32/14195_2.png) [@udayputta](https://developer.sailpoint.com/discuss/u/udayputta)\
**Post date:** [August 4, 2023, 2:11pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/5 "2023-08-04T14:11:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\
**Post date:** [August 4, 2023, 2:11pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/6 "2023-08-04T14:11:53Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![udayputta](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/udayputta/32/14195_2.png) [@udayputta](https://developer.sailpoint.com/discuss/u/udayputta)\
**Post date:** [August 4, 2023, 2:13pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/7 "2023-08-04T14:13:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mcheek](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mcheek/32/23705_2.png) [@mcheek](https://developer.sailpoint.com/discuss/u/mcheek)\
**Post date:** [August 4, 2023, 2:25pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/8 "2023-08-04T14:25:39Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iamnithesh](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/iamnithesh/32/42445_2.png) [@iamnithesh](https://developer.sailpoint.com/discuss/u/iamnithesh)\
**Post date:** [August 4, 2023, 11:25pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/9 "2023-08-04T23:25:13Z")

</div>

Would adding this to BeforeProv rule will help?

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

```

---

<div class="post-metadata">

**Author:** ![udayputta](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/udayputta/32/14195_2.png) [@udayputta](https://developer.sailpoint.com/discuss/u/udayputta)\
**Post date:** [August 6, 2023, 2:45pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/10 "2023-08-06T14:45:50Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![iamnithesh](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/iamnithesh/32/42445_2.png) [@iamnithesh](https://developer.sailpoint.com/discuss/u/iamnithesh)\
**Post date:** [August 6, 2023, 3:43pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/11 "2023-08-06T15:43:34Z")

</div>

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?

> [@udayputta](#):
>
> 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.

Thanks for clarifying

---

<div class="post-metadata">

**Author:** ![udayputta](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/udayputta/32/14195_2.png) [@udayputta](https://developer.sailpoint.com/discuss/u/udayputta)\
**Post date:** [August 7, 2023, 7:35am UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/12 "2023-08-07T07:35:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mikeburns365](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mikeburns365/32/6890_2.png) [@mikeburns365](https://developer.sailpoint.com/discuss/u/mikeburns365)\
**Post date:** [October 5, 2023, 3:47pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/13 "2023-10-05T15:47:12Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![RAKGDS](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/rakgds/32/2795_2.png) [@RAKGDS](https://developer.sailpoint.com/discuss/u/RAKGDS)\
**Post date:** [October 9, 2023, 6:00am UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/14 "2023-10-09T06:00:51Z")

</div>

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](https://community.sailpoint.com/t5/SaaS-Release-Notes/tkb-p/saas-release-notes?env=production&date=2023-08-14)

---

<div class="post-metadata">

**Author:** ![udayputta](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/udayputta/32/14195_2.png) [@udayputta](https://developer.sailpoint.com/discuss/u/udayputta)\
**Post date:** [October 31, 2023, 2:35pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/15 "2023-10-31T14:35:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dopstrick](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/dopstrick/32/5232_2.png) [@dopstrick](https://developer.sailpoint.com/discuss/u/dopstrick)\
**Post date:** [October 31, 2023, 7:16pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/16 "2023-10-31T19:16:25Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![udayputta](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/udayputta/32/14195_2.png) [@udayputta](https://developer.sailpoint.com/discuss/u/udayputta)\
**Post date:** [October 31, 2023, 7:30pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/17 "2023-10-31T19:30:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\
**Post date:** [December 30, 2023, 7:30pm UTC](https://developer.sailpoint.com/discuss/t/remove-all-roles-assigned-by-access-request-when-the-termination-event-triggers/15583/18 "2023-12-30T19:30:53Z")

</div>

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