I have 5 AD groups for application: TestApp.. User can have only 1 AD group at a time. when a modify request is submitted, user AD group should be replaced with new AD group.
how can i achieve this in SailPoint ISC without any rules. Has any one worked on this usecase?
I’m thinking you can achieve this without using rules by making the group attribute single-valued instead of relying on the standard multi-valued memberOf attribute.
From my perspective, the approach would be:
Create one Access Profile for each AD group (5 in total).
Configure the Access Profiles as mutually exclusive using Role/Access Profile prohibited combinations, so a user can never have more than one of these groups at a time.
Since the attribute is single-valued, requesting a new group should naturally generate a modify operation that replaces the existing value with the new one. This would eliminate the need for manual add/remove operations or custom rules.
If anyone has a better approach or suggestion, please feel free to share.
Thank you.
I’d suggest using an SoD policy to make the five AD groups mutually exclusive. With preventive mode, ISC will detect the conflict during the access request and trigger the remediation.
@suraj_gorle , regarding making memberOf single-valued, I’d be cautious as memberOf is multi-valued by default in AD. Changing this could impact aggregation, as ISC may treat all group memberships as a single value rather than separate entitlements.
Otherwise, another option would be to use rules to handle the logic.
With out Rule, This could be achieved to manage mutually exclusive access is to change how the data is modeled on the source. Instead of aggregating these 5 AD groups as standard multi-valued entitlements, map them to a single-valued account attribute.
And 2nd option you can use the workflow with Trigger to the Access Request Decision, Action - get Identity Access (Check the existing AD groups), Define comparison with YES/NO then Action with revoke old and provision new.
Hello Chandra. There is no native “replace” for AD groups in ISC. Requesting a new group does not remove the old one.
If this is Request Center, model the groups as Access Profiles and use an Approval Policy workflow to remove any other TestApp AP after approval. This gives eventual replacement, not strict one-at-a-time, because the new grant and removal provision separately.
If strict sequencing is needed without a rule, use an Interactive/Form workflow:
Form → Generic Approval Policy → Remove old access → Wait → Add new access
This controls the order, but is not an atomic AD swap.
If an identity attribute can drive the selection, mutually exclusive roles are the cleanest option.
Select an unused Extension Attribute in AD, say extensionAttribute8
Create an Entitlement Type (TestApp) on the AD Source
Mark extensionAttribute8 an Entitlement of type TestApp in the Account Schema (keep it single-valued)
Define 5 values as Entitlements
TestApp Ent 1: Value {whaatever}
etc
Create 5 Requestable Access Profiles each with the 1 associated Entitlement*
Create 5 (non-requestable) Roles, eg. TestApp Role 1 with assignment criteria of the associated TestApp Entitlement, eg TestApp Ent 1
Add the associated AD Group Entitlement to each Role
If that works, a User should be able to request the Access Profile, that will update extensionAttribute8 with the new value which will be picked up as an Entitlement and then by Role assignment criteria adding the User to the AD Group, while removing from the existing group
*Edited because Entitlement requests are sticky, whereas Access Profile requests aren’t