Creating a role just for deprovisioning in ISC

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

So i got a request to create a role for deprovisioning or removing from the specific AD group and they add users manually in that AD group but want to automate the deprovisioning part only. So what criteria I should be putting in the role to make it work just for removing users from that AD group with this criteria
Identity attribute - stale - contains - false ← I thinking about this but don’t know weather it works or not as it’s only removing users from that AD group. they only want the condition those users account goes stale (stale condition is if a user does not logging for 45 days or more there account turn to be stale) or terminated.
Help me on this one I am confused how role can just use for deprovisioning.

2

Hi @jalad10 ,

A role alone cannot be used for deprovisioning. There are a few options you can try, depending on what works for your organization.

  1. Use the role to add a new AD group and configure the Standard Services Before Provisioning Rule to remove users from the desired group. Basically create a dummy AD group that can be added to these stale/inactive users based off the role, and use the Before Provisioning trigger of this dummy group being added to remove the intended group.
  2. Still using the Standard Services Before Provisioning rule, you can create an Inactive lifecycle state that is calculated based off if the account is considered stale. This avoids the need for a role or a dummy group as you can use the before provisioning trigger of a user being moved into this lifecycle state to remove the intended group.
  3. Use the Identity Attributes Changed Workflow Trigger to have a workflow remove this access. When the identity attribute that is determining if an identity has a stale/inactive account is changed to whatever value, it can cause this workflow to trigger then use the Manage Access Workflow Action to remove the intended access. This avoids using a role, dummy group, or creating a new lifecycle state, but it might not be as clear to other ISC Admin users how this access is being removed.

I personally like option #2 as this seems more like a lifecycle event with an identity/account becoming stale/inactive and you can more easily build on other actions that might be needed, but any of these options can work depending on what works best for you in your situation.

Please let me know if this helps!

  • Zach
1 Like
3

Thanks for the reply
I am confused as I never used Standard Services Before Provisioning Rule before and about the dummy AD group like how it will work to remove the intended AD group. Do I need to add both AD groups (dummy and original) in one role or any configuration in dummy AD group. Also that link won’t allowing me to sign it looks like only some if particular people can access that page.

Also how I am gonna create a dummy AD group from ISC as i can’t see any option

4

You need a SailPoint account to access that site/documentation. You should be able to create one if you are an active customer/partner. Here is another post talking about how to deploy this rule if you haven’t before. You would still need a SailPoint account to open a request with support to deploy this rule.

In this solution, the role would just provision (grant) only the dummy AD group to the specified group of users given whatever criteria you set.

However, I was just reading through the documentation to respond to this post and I realized I was mistaken. I forgot this rule only has the option to remove all or all but one entitlement, it cannot remove a single specified entitlement. Sorry about that!

Instead, you would either have to write your own Before Provisioning rule, or use something like the AfterModify AD connector rule which will call a PowerShell script to take whatever action, such as removing a group.

There is one more way I just thought of that could work and might be the simplest option. You could make a role that has the assignment criteria if the stale identity attribute is false and if the user has the AD group (entitlement) assigned to them, the users get added to the role. The role would include the AD group (entitlement) in the access assignment also, but it wouldn’t actually assign this group since it would be a requirement to be a member of the group in the first place to get added to the role. In this case, if the stale identity attribute changes, the users no longer meet the role criteria, and the group would be removed automatically.

5

Thanks Zach. That simple option worked. I will ask if something comes up.

6

Great to hear! If you wouldn’t mind, could you please mark this post with the solution that worked for you in case this is helpful to other folks with a similar question?

1 Like
7

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