Handle legacy entitlements which are not part of roles

How to handle legacy entitlements which will not be used for new accounts provisioning.

AD has 1000s of legacy entitlements which are currently assigned to existing users. However for new user provisioning or mover case, we might not be using these entitlements.

What is the ideal way to handle these legacy entitlements during data migration and remove them during leaver.

Thanks

Hi @nmuthusamy

During leaver, you do remove all of the access user has rite not just these legacy entitlements.

How does these legacy entitlements added to the users ?

If you don’t wanna use in user provisioning then you don’t create Access Profiles and Roles for the same legacy entitlements, so that those are not available for manual requests or auto assignment.

Are these entitlements added at AD ?

Are you looking to filter these entitlements, so that you don’t see them in IDN ?

Hi @KRM7 ,

How does these legacy entitlements added to the users ? - These were assigned to the users before we migrated to Sailpoint.

Are these entitlements added at AD ?
Yes, they were added at AD.

Are you looking to filter these entitlements, so that you don’t see them in IDN ?
No I still need these entitlements to be visible in IDN but I dont have usecase to use these entitlements for provisioning or mover case.

We need these entitlements to be just there and removed when the user gets offboarded.

Thanks

You can use before provisioning rule and remove all entitlements including idn provisioned and which were existing before idn was introduced.

Service standard rule is quite common practice to achieve this.

2 Likes

Got it.

  1. Don’t create Access Profiles/Roles for these legacy entitlements.
  2. Remove Entitlements from Request center, it is good practice to enable access requestable through Access Profiles/Roles

Offboarding:
There is different process followed by every implementation as per their project requirements. Most commonly used is

  1. Disable user on last working day EOD or next day
  2. Remove all the access after 2/3 weeks
  3. Delete account after a month

Timelines might change, but process is heavily followed. Check this post for reference.
User Deprovisioning in Active Directory - IdentityNow (IDN) / IDN Discussion and Questions - SailPoint Developer Community Forum

Possibilities of removing access and deleting accounts:

  1. Certification campaign: launch a certification after last working day, revoke all access.
  2. Before Provisioning Rule: You can use any extension attribute or description attribute even, enable sync for that attribute. When there is a sync, Before Provisioning Rule should monitor and update the plan accordingly to remove the user access. You can delete account even using same Rule.
  3. Workflow: You can remove the access but you cannot delete account. Currently workflow Manage Accounts → Delete account supported only for Delimited source. Remember Workflow is a licensed module.

Hope this helps :slight_smile:

Thanks
Krish

3 Likes

Hi @KRM7 ,

Thanks for the detailed reply. Our usecase doesnt use Access Request, we have a different portal for that. So the only way to remove entitlements when I offboard this user is to use cloud rule.
Do you have any other suggestion?

Thanks

Hi @chirag_patel ,

Thanks for the input. We will test this.

Thanks

If you don’t have access request then

  1. Roles are assigned with criteria automatically, add LCS to the criteria so that access will be removed automatically when user moved to inactive state.
  2. Entitlements/Access added at source end (AD), can be removed using BP Rule.
  3. You can use certification campaign and workflows as well, but BP Rule will be simple to implement here.

You can also use the “ConnectorBeforeDelete” rule that is executed on the connector side (on IQService).
As it’ll be a powershell script that is executed before account is deleted (or move to another OU) then you can do anything you want, like removing all the groups still assigned to the account.
If you don’t delete account but move them to a specific OU you can also use “ConnectorBeforeModify” or “ConnectorAfterModify” and check (according to OU) if you need to remove all groups still assigned to user or not.
Connector rule are easier to use as you don’t need to ask PS every time you need to update them :slight_smile:

1 Like

Yes, that is also good option. But I never had success with altering plan in Native Rules like we do in IIQ.

If you are intended to remove groups using PowerShell that will work for sure.

Thank you @pbourgi and @KRM7

In case of BP rule, when we tried removing entitlements, the rule still tries to remove those entitlements assigned via roles. Those entitlements assigned at target system is not getting removed.

If possible, could you pls give me a short description how do it via BP rule?

Thanks

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